Community
Participate
Working Groups
import java.io.OutputStreamWriter; import java.io.PrintWriter; public class Test extends PrintWriter implements Runnable { public Test(OutputStreamWriter out, boolean flag) { super(out, flag); } public void run() { } } We report: ---------- 1. ERROR in C:\tests_sources\Test.java (at line 3) public class Test extends PrintWriter implements Runnable { ^^^^ The return type is incompatible with Writer.append(char), PrintWriter.append(char) ---------- 2. ERROR in C:\tests_sources\Test.java (at line 3) public class Test extends PrintWriter implements Runnable { ^^^^ The return type is incompatible with Writer.append(CharSequence, int, int), PrintWriter.append(CharSequence, int, int) ---------- 3. ERROR in C:\tests_sources\Test.java (at line 3) public class Test extends PrintWriter implements Runnable { ^^^^ The return type is incompatible with Writer.append(CharSequence), PrintWriter.append(CharSequence) ---------- 3 problems (3 errors) I believe this should work. If the source level is set to 1.5, it works.
javac 1.5 with -source 1.4 compiles this code.
Generic signatures would be ignored, I guess.
Philippe: What does it mean to use -source 1.4 but -compliance 1.5? Are 1.5 features supported or not? Are they supported in binaries or not? Why do we have 2 flags?
ping.
My understanding of the compliance 1.5 is that it means that it behaves like javac 1.5 (for method lookup, covariance, ...). The source level is used to find out what constructs are allowed. -source 1.5 means the autoboxing, enums, foreach, static import and generics are supported. In the test case, you can see that there is no 1.5 constructs.
The compliance flag is to emulate a certain JDK level. Now when you use JDK 1.4 compiler, you can also instruct it to compile in -source 1.3. Same for 1.5, get a hold onto JDK 1.5, and compile with -source 1.4 mode. Feels like a case where we trigger 1.5 behavior based on compliance level instead of using the source level. Compliance level is determining behavior common to all source levels (so compliance is master mode, then source level is submode).
Added MethodVerify test030
What changes are needed to be done for M4 source/build distribution for successfull build? Thanks! Andrew (the issue was inspired by me :-)
I would need to replace the org.eclipse.jdt.core plugin with the one from a nightly build that contains the fix. http://download.eclipse.org/downloads/drops/N20050109-0010/index.php should be fine. You just need to download the JDT Runtime Binary distribution and extract the org.eclipse.jdt.core plugin from it and override the one from M4.
After replacing JDT-binary (and stripping "_3.1.0" in directry names ) I have got the same three errors. Must I modify something in build.xml files?
Covariance refers to the ability to narrow the return type of a method when overriding it: public class X { public Object foo() { return new X(); } } public class Y extends X { public Y foo() { return new Y(); } } Then when compiling: class Z { { new Y().foo(); } } The invocation of Y.foo() is targeting: "#foo()Y" (and not "#foo()Object"). However, a 1.4 compiler is not expecting such subtleties, hence the problems you are seeing. By toggling the compiler compliance to 1.5 (keeping source level to 1.4 and target to 1.4) you would compile your code clear. But do not intend to run it on a 1.4 VM in the end. The generated binaries are tagged as working on 1.4; but there are direct references to 1.5 specific constructs which have no equivalent in true 1.4 libraries (for instance, there would be not "#foo()Y" method in a real 1.4 library).
There are "-target" and "-source" javac options (and there are appropriate properties in build.xml files, and I have tried to set them to "1.4" in all the src/buid tree with the same result). But I have not found anything concerning "-compliance" javac/ant property.
Verified in I20050215-2300
Note: testcase in comment 11 is invalid in -source 1.4 mode (even 1.5 compliance). The original bug was rather related to ignoring bridge methods in 1.5 libraries.
Note: testcase in comment 11 is invalid in -source 1.4 mode (even 1.5 compliance). The original bug was rather related to ignoring bridge methods in 1.5 libraries. Also see bug 128560
