This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why does Eclipse complain about #Override on interface methods?
I have some Java code that was written using Eclipse and the Java 6 SDK, so methods that implement an interface are annotated with #Override - an annotation that is legal in Java 6, but not in Java 5.
I'd like to compile the same code using the Java 5 SDK (javac on Mac OS X 10.5). Everything compiles and runs fine except for the #Override annotations. Is there any way I can get javac to ignore the #Override annotations for this project, or is the only solution to remove them all?
Unfortunately, the only way is to actually remove the annotations.
If you do want to have your code compile and run with Java 5, you should develop targeting Java 5. Otherwise, you might accidentally rely on a Java 6 specific SDK methods and such.
Apparently you can upgrade to Java 1.5 u21 and this will fix the problem:
Why is javac failing on #Override annotation
You can use JDK6 to compile 1.5 code. Use -bootclasspath, -target, and -source. Alternatively, I believe the Eclipse compiler treats #Override the same (this might be wrong!).
1.5 has finished its End of Service Life period, and I suggest letting it rot.
#Override is valid in java 5 -> http://java.sun.com/j2se/1.5.0/docs/api/index.html?java/lang/Override.html
I recommend that you check your project's compiler settings in Eclipse, perhaps at Project -> Compiler -> Error/Warnings -> Annotations?
Java 6 is available for OS X. Check software update. When you have it, set it to be the default java version, and then compile.
Related
I am trying to use Jasmin to convert Jasmin assembly code to a Java class file. Using the Hello World example from here.
The following error is returned:
Exception in thread "main" java.lang.NoSuchMethodError: jasmin.parser.parse()V
at jasmin.ClassFile.readJasmin(ClassFile.java:1160)
at jasmin.Main.assemble(Main.java:81)
at jasmin.Main.run(Main.java:200)
at jasmin.Main.main(Main.java:157)
I suspect that it may be a problem with the Java version since Jasmin seems to be old and probably implemented using an older Java version.
So far I have tried to run the example using this command: java -jar jasmin.jar test.j.
I have tried to run it with Java 8, 7, 6 and 4 unsuccessfully.
The version of Jasmin I have used is 2.4.
Furthermore I have also tried to download Jasmin's source code and compile it manually, with the same result.
Does anybody have any pointers or ideas on how to solve this issue?
The issue is that, if you have other versions of cup in Java's classpath, jasmin might run intro troubles and it will throw a NoSuchMethodError.
To fix this, just remove the other CUP versions from Java's classpath.
All credit goes to #MargaretBloom for finding the issue.
Java 9 imports a new HTTP/2 Client API which seems good to use but is there any way to use it in Java 8?
OR
Is there any shim/polyfill(from javascript) available to make it available in Java 8?
Is there any way to use it in java 8?
No, because the jdk.incubator.http module has been added since Java 9.
So it wouldn't be possible to compile it with a --release 8 option on the compiler work with Java8. You would end up getting errors as:
$ javac --release 8 .../src/com/HttpGet.java
$ .../src/com/HttpGet.java:3: error: package jdk.incubator.http does not exist
import jdk.incubator.http.HttpClient;
^
With minimal code to reproduce this as:-
import jdk.incubator.http.HttpClient;
public class HttpGet {
public static void main(String[] args) {
HttpClient httpClient = HttpClient.newBuilder().followRedirects(HttpClient.Redirect.ALWAYS).build();
System.out.println(httpClient.version());
}
}
Moreover, the documentation clearly reads this upfront
Incubating Feature. Will be removed in a future release.
In principle, the source for it is available. You could copy it, compile it and create a jar usable with Java 8 (possibly with some changes or missing features if the code needs Java 9 anywhere), similarly to ThreeTen-Backport providing java.time for Java 6/7.
But there doesn't seem to be one available yet (after a quick search). If you decide to go in this direction, make sure to follow the relevant licenses.
For whatever reason I had to change pc's as a result of the change I now have to use Java 6 (the final update) Instead of java 7. When importing my existing project to Java 6 I get the following error in my auto generated code that was generated by Netbeans and is not modifiable
cannot find symbol
symbol: variable Type
location: class Window
frame.setType(java.awt.Window.Type.POPUP); //Type is underlined
The output for the error is as follows:
javac: invalid target release: 1.7
Usage: javac <options> <source files>
use -help for a list of possible options
C:\Users\Adminstrator\Downloads\NetBeansProjects\NetBeansProjects\Pat0.3\nbproject\build-impl.xml:915: The following error occurred while executing this line:
C:\Users\Adminstrator\Downloads\NetBeansProjects\NetBeansProjects\Pat0.3\nbproject\build-impl.xml:268: Compile failed; see the compiler error output for details.
What does this do? Is it necessary, would deleting that the component help? Which component is it, is there a quick fix?
Your build.xml specifies the target="1.7" flag to javac, which java 6 doesn't know how to interpret. Changing it to 1.6 will technically get past that error.
However, the enum Window.Type was added in Java 7, so you simply can't expect changing the target to work; your project's source uses Java 7 features. I'm sure that's not the only one.
Your options are therefore to methodically go through and remove/replace all Java 7 code (likely introducing some bugs) or just to.. install Java 7.
There is somewhere in your project a setting for the java compiler that tells it to generate classes for jre7. javac from jdk6 cannot generate classes for that version, hence the error. So you should look into the properties of your project and set up javac to generate classes for jr6. You might also have fix some of your non-generated code if for example you have used features that came with java 7 such as diamond operator or multy catch block etc.
Also the javadoc for Window.Type states it is available only since 1.7. You might want to re-generate that code or better yet just install jdk7.
Can you override method in java without using annotations? Because eclipse doesn't support it if you use JRE6, you need to switch back to 5 to use #Override annotation. Will this method be overriden if I remove the annotation?
#Override public String toString() {
return name + " [" + genre + "]";
}
Can you override method in java
without using annotations?
Yes, the #Override annotation is not required to override a method.
Just by the act of having a method definition with the same method signature of an ancestor class is enough to override a method.
The #Override annotation is just a reminder to the compiler that says that the method definition is intended to override a method.
If a method that has a #Override does not actually override a method, the compiler will throw a compiler error -- the annotation serves as an additional compile-time check to see whether the method definition does indeed override a method.
Because eclipse doesn't support it if
you use JRE6, you need to switch back
to 5 to use #Override annotation.
I happen to use Eclipse targeting Java 6, and am able to use the #Override annotation, so I'm not quite sure what can be causing this. Annotations has been supported from Java 5, and has been more tightly integrated into the language since Java 6.
Edit
From Andreas_D's comment to the question:
smile - this just indicates, that the
current source level for your project
is < 1.5. This setting is pretty
independant from the JRE, you actually
can use JRE 1.6 together with source
level 1.4 - and I guess, that's what
happened.
This sure seems to be one way a compile error can occur!
The way to check if the "compiler compliance level" is set to something under Java 5 is,
Go to the Properties of the Java project in Eclipse
Then, go to the Java Compiler menu
Check that the Compiler Compliance Level is set to 1.5 or higher.
Edit
Regarding to Gandalf StormCrow's screenshot, appears that the compiler compliance level is set lower than JDK 1.5. Clicking on the Change project compliance and JRE to 1.5 quick fix should fix up the current situation.
The issue is, annotations were introduced in Java 5.
It appears that the Java project in Eclipse is currently set so the source code can only contain features which were introduced prior to Java 5, therefore disallowing the use of annotations.
The way to fix the situation is tell Eclipse that features from Java 5 can be used, by setting the compiler compliance level to 1.5 or higher.
#override is just a way of ensuring that if you change the contract (the method overriden) this method will not compile. Without it, it will be considered as a different fonction.
As for the JRE6, i'm not sure what you mean : annotations are supported.
Try the jdk ?
You do not need to use the #Override annotation. However, if you do and the method fails to override a method in a superclass then the compiler will return an error.
Eclipse is adding #Override annotations when I implement methods of an interface. Eclipse seems to have no problem with this. And our automated build process from Cruise Control seems to have no problem with this. But when I build from the command-line, with ant running javac, I get this error:
[javac] C:\path\project\src\com\us\MyClass.java:70: method does not override a method from its superclass
[javac] #Override
[javac] ^
[javac] 1 error
Eclipse is running under Java 1.6. Cruise Control is running Java 1.5. My ant build fails regardless of which version of Java I use.
The #Override annotation spec changed in Java 1.6. In Java 1.5, the compiler did not allow the #Override annotation on implemented interface methods, but in 1.6 it does. First search result I found is a blog post here.. It was not well documented, but it did change.
Eclipse is adding it because your Eclipse is set for 1.6 compliance. You should try to keep your build and eclipse environments on the same version of Java. It's unclear to me by your specifying Cruise Control is running Java 5 on whether or not it is compiling using a separate JDK6 or not.
Separate from the above 1.5 vs 1.6 #Override annotation rules, remember that Eclipse has its own compiler implementation (not javac) and will occasionally have different behavior. Whenever something compiles in Eclipse, but not Ant or Maven, you will need to find a way to make both compilers happy.
I can't really explain the problem you're seeing but it seems to be related to the fact that JDK 5 will not allow #Override on implemented methods of an interface, only on overridden methods present in a super class.
JDK 6 will allow #Override on any of them.
If your ant build fails it may be passing a source parameter to javac, asking for JDK 5 compliance.
The direct answer to the question "Why" an error is raised by javac when #Override is used in the context of a method implementation is actually in the java specifications:
"The rationale for this is that a concrete class that implements an interface will necessarily override all the interface's methods irrespective of the #Override annotation, and so it would be confusing to have the semantics of this annotation interact with the rules for implementing interfaces."
See http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.6.1.4
But apparently someone changed his mind for java 1.6 and 1.5 u21...
#Override tags for implemented methods are new to Java 1.6. In Java 1.5 #Override is only correct when overriding a method in a base class. Read more here and here.
A lot of people, including me, got busted by this. See here for a bigger SO discussion
Eclipse would be pointing to 1.6 version of Java rather than 1.5.
See here for configuring java version in eclipse.
Ensure that there is only one definition of that interface.
Example:
HttpServletRequest
This is an interface with different specs depending on provider.
Compare pax-web-jetty and apache-felix-jetty. They have different methods.
I have had the same problem when building a project with ANT. The solution to the problem was to change the following property inside the build.properties file:
javac.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
to:
javac.compiler=modern
That solved the problem and the project got compiled and deployed successfully.