Community
Participate
Working Groups
If the region between the stars (in the code below) is uncommented, Eclipse will not present a warning or error, but compiling the class with javac.exe will produce an error (java 1.4 will complain that it cannot override final method compareTo, and java 1.5 will complain that two compareTo methods have the same erasure). If the region between the stars is commented, Eclipse will give an error saying that compareTo must be defined, but javac.exe will give no warnings or errors. The bottom line is that there seems to be no way to build any project in Eclipse that contains a subclass of Charset!!! // Begin code for CharsetSub.java : import java.nio.charset.Charset; import java.nio.charset.CharsetDecoder; import java.nio.charset.CharsetEncoder; public class CharsetSub extends Charset { public CharsetSub(String name, String[] aliases) { super(name, aliases); } public CharsetEncoder newEncoder() { return null; } public CharsetDecoder newDecoder() { return null; } public boolean contains(Charset x) { return false; } //****************************** (the region between the stars) public int compareTo(Object obj) { return compareTo((Charset) obj); } //****************************** public static void main(String[] args) { new CharsetSub("test", new String[] { "test" }); System.out.println("Compilation succeeded."); } }
Created attachment 66778 [details] Demonstration of the bug Compile the code as is with javac.exe, and marvel at the error. Compile it with Eclipse with the region between the stars commented, and marvel at that error.
I'll try to extract a small test case.
In 3.3, you don't need the method: public int compareTo(Object obj) { return compareTo((Charset) obj); } anymore. It works fine.
I could not reproduce the behavior you describe. Both I20070517-1700 (3.3 RC1) and M20070212-1330 (3.2.2) report an error when the offending block is not commented out, and compile OK when it is commented out. This is the same behavior as javac (1.5 and 6). Released MethodVerifyTest#141 and 142 for regression detection purposes. Closing as WORKSFORME.
The problem is with 1.4.2. Eclipse does not report any error when compliance is 1.4 although javac does: D:\usr\OTI\tests\jdk1.4.2>compile CharsetSub.java java version "1.4.2_15-ea" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-ea-b01) Java HotSpot(TM) Client VM (build 1.4.2_15-ea-b01, mixed mode) CharsetSub.java:13: compareTo(java.lang.Object) in CharsetSub cannot override compareTo(java.lang.Object) in java.nio.charset.Charset; overridden method is final public int compareTo(Object obj) { ^
Hmm... In fact Eclipse does report an error with compliance 1.4 when JRE System Library 1.4.2 is used but does not when JRE >= 1.5 is used... However, there's still a problem here because javac still report the same error whatever the JRE specified on the classpath (I've tried with 1.5.0 and 1.6.0). So, it seems that as soon as the source level is set to 1.4, the compiler needs to report an error in this case... Andrew, as you get the error if you refer to the correct JRE in your project, do you agree to reduce the severity of this bug to 'normal'?
The compiler already had this problem in 3.2.2...
Reduce the severity as there's a way to build a project that contains a subclass of Charset (as you did not answer to my comment 6, I guess you agreed... )
(In reply to comment #6) ... > However, there's still a problem here because javac still report the same error > whatever the JRE specified on the classpath (I've tried with 1.5.0 and 1.6.0). > Have discussed the issue with Frédéric today. Our tests so far show that: - javac 1.4 referencing the 1.5 rt.jar in its bootclasspath gets an expected lib mismatch error: 'bad class file: \opt\jdk1.5.0\jre\lib\rt.jar(java/nio/charset/Charset.class) class file has wrong version 49.0, should be 48.0'; - javac 1.4 referencing the 1.5 rt.jar in its classpath does refer to the 1.4 rt.jar indeed, hence this matches Eclipse using compliance 1.4 and JRE 1.4, which duly reports an error; - javac 1.5 with -source 1.4 referencing the 1.5 rt.jar gets a warning but no error; no error is expected because the T of Comparable#compareTo gets erased; the matching Eclipse configuration works as well. Comment 5 does not reveal any true problem, I'll hence mark the bug as WORKFORME again. Please feel free to reopen if I missed a broken test case.
Verified for 3.3 RC2 using I20070525-1350 build
