I have dowloades the sources of the android musicplayer vanilla. When i compile it with eclipse i get several compiler-error
that complain that a method with #Override is not an override.
I made the source compilable by removing the false #Overrides.
I donot know, why there are these wrong #Overrides.
Maybe they are there because the autor developed for an other android-baseclasslibrary that has these methods while my
java 6 with android 2.1 does not have it.
Is there a way to make it compileable without deleting the false #Overrides?
You need to switch to JDK6 :
Enable Java 1.6 Compiler in your project properties under Java Compiler
Make sure your java Runtime Environement is at 1.6
The problem may come from using different versions.
It's not a good practice to make it compileable without deleting the false #Overrides because it is made for a reason and if you CAN disable it, you may have problems elsewhere and you wouldn't know where the problems are happening
So, just delete the false or check for a newer version of vanilla
Related
I have a Codename One project on Netbeans using their plugin.
Is there a way to make it work? I enabled it in project's settings and still doesn't show in final jar.
The annotations are in the libraries of the project. and I can see it being done in the output:
warning: Supported source version 'RELEASE_6' from annotation processor 'org.netbeans.modules.openide.util.ServiceProviderProcessor' less than -source '1.8'
I used instructions here: https://netbeans.org/kb/docs/java/annotations-lombok.html
Update:
I thought it was clear but seems it's not. All this is using Netbean's Lookup. Let's say I have one jar as project dependency with one interface in it, let's say ITest. Also a class implementing the interface, for example:
#ServiceProvider(service=ITest.class)
public class Test implements ITest{
..
}
So in the Codenamone Project I call it like this:
Lookup.getDefault().lookupAll(ITest.class);
But it come up empty. I know the system works as it does in other projects, just porting it to Codename one. Seems like it is not seeing the annotations in the dependencies.
I don't know if that will work and I'm pretty curious about it myself. Make sure you created a Java 8 version of the project and you are running on top of Java 8 to get started.
In the past things like this were done using bytecode manipulation e.g. see this code from the work done by Steve.
I am trying to compile a java file, which uses package com.sun.xml.internal.messaging.saaj.soap.dynamic, using ANT-1.9.3 but I'm receiving error
package com.sun.xml.internal.messaging.saaj.soap.dynamic does not
exist
I tried compiling both JDK7 and JDK 8 and getting the same error.
I can see the package exist inside rt.jar of both JDK. I have set JAVA_HOME also properly.
Can someone help me to resolve this issue?
Unfortunately for you, this behaviour is probably intentional and your usage is deliberately unsupported. If your code used to compile under Java6 and now doesn't under Java7 or Java8 then you've basically fallen foul of
From one release to another, these classes may be removed, or they may be moved from one package to another
http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html
See also http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6778491 for a technical description of a possible cause of not being able to compile a class which references a 'com.sun.*' class but which throws the same compiler error you're seeing despite the fact that the referenced class exists in rt.jar. Also for the kind of response which Oracle give to bug reports relating to it;)
Unfortunately, using undocumented, unsupported APIs often has this kind of 'bite you in the posterior' kind of effect.
Please add the line, < compilerarg line="-XDignore.symbol.file" compiler="modern"/ > for < javac > tag in your build.xml. This should solve your problem. It solved for me.
For reference you can view the forum link
http://www.icesoft.org/JForum/posts/list/19871.page#sthash.srrN9Ijk.dpbs
Is it possible to create an annotation (or some other way) to force the GWT compiler to not compile a method? I have a class that I also use on app-engine (in a shared folder) and one method in it requires a server side only function which causes GWT to not compile. I would like GWT to just ignore the method (while appengine does not).
I figured either an annotation, or a pre-compile script that erases the method prior to compilation. Both methods would work for me, it would be best if I could still compile through the eclipse IDE.
Anyone else thought of this or tried it?
Not until now. Very recently such annotation was added #com.google.gwt.core.shared.GwtIncompatible("Description why..."). It is applicable on classes or methods.
But the patched code was not released yet! Official status is FixedNotReleased. And i can personally confirm, it is not in current GWT 2.5.1 version. I am hopeful for upcoming 2.5.2.
See:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/core/shared/GwtIncompatible.java?spec=svn11570&r=11570
http://code.google.com/p/google-web-toolkit/issues/detail?id=3769
https://gwt-review.googlesource.com/#/c/2320/
Note, there is already similar annotation com.google.gwt.thirdparty.guava.common.annotations.GwtIncompatible in gwt-dev.jar, however
it does not work, compiler still wants to compile my incompatible method in shared class.
Prior to GWT version 2.6, there is no annotation to make the GWT compiler ignore a method. There is a requests for it in the GWT issue tracker, and apparently it is scheduled for the 2.6 release.
One workaround approach is to have the "offending" method in a class of its own and ignore that class in your .gwt.xml file:
<source path="gwtclient">
<exclude name="AppEngineOnlyClass.java" />
...
</source>
...
Hope that helps a bit.
Cheers,
I know, this sounds like an old question, which has been asked before(*). But it is a little bit different. I installed a clean system with the newest versions of JDK (7u2) and eclipse (and also AndroidSDK). When I import old projects, I get an error "The method methodName(Parameter) of type Class must override a superclass method".
The #override-tag was there (correctly), because the method overrides a method of an INTERFACE of the superclass. somehow compiler thinks that this tag is just for superclass directly. As far as i know #override is not changed in Java 7 and my project was working properly on 6. Is it a possible bug or compability problem or I am missing something?
(*)Similar problem used to happen, when compiling on JDK5, simply because #override was yet implemented in Java 5. Solution was, of course changing compiler compliance level to 6. But what is it with JDK 7 now?
You shouldn't use JDK 7 for the development. There is a requirement that you have to use JDK 5 or 6.
Is there a version of JDE for emacs that supports the JDK 6.10? I haven't been able to find any information on this. While it runs, every time I attempt to compile files the JDE says that it doesn't recognize my JDK version and reverts to assuming it is a Java5 version.
I've made following customizations for JDE:
'(jde-bug-debugger-host-address "127.0.0.1")
'(jde-bug-jre-home "/usr/lib/jvm/java-6-sun")
'(jde-compile-option-debug (quote ("all" (t nil nil))))
'(jde-debugger (quote ("jdb")))
'(jde-global-classpath (quote ("." "/usr/share/java/" "/usr/lib/jvm/java-6-sun/")))
'(jde-jdk-doc-url "/usr/share/doc/sun-java6-jdk/html/api/index.html")
'(jde-jdk-registry (quote (("1.5" . "/usr/lib/jvm/java-6-sun"))))
'(jde-regexp-jar-file "/usr/share/java/regexp.jar")
'(jde-sourcepath (quote (".")))
So it compiles without complaints, although I have jdk 1.6.0.07.
You can set your paths up in the configuration settings by "registering" a JDK version using M-x customize-variable and choosing jde-jdk-registry. Save that state, then do M-x customize-variable again, customize jde-jdk and pick the one you want.
That should do it; if not, give us a little more detailed information.
Yes, I've done that. The problem is when I call 'jde-compile, The message 'The JDE does not recognize JDK6.0.10 JDK. Assume JDK 1.5 Javac?" appears. Also, It doesn't look like the Java6 constructs, such as annotations, have been defined in the syntax checking or indentation rules.