Community
Participate
Working Groups
Using Ecliipse 3.1.1 on the Ubuntu BreezyBadger release on PC to compile a Java Project written for 1.4. The compiler compliance level, generated .class files compatability, and source compatability are set to 1.4. 'Use default compliance settings' is also unchecked. With these settings, the ((String)o).compareTo( o ) is not accepted. With the same code compiled with the SUN javac tool using the -source option of 1.4: javac -source 1.4 Prgm04.java The compile works. The JDT needs to accept the 1.4 option. The test case used is as follows: import java.io.*; import java.util.*; import java.lang.*; public class Prgm04 { public static void main(String args[]) { try{ Object obj1 = new String("Hello"); if( ((String)obj1).compareTo(obj1)==0) { System.out.println("There is a match"); } else { System.out.println("There is no match"); } }catch(Exception e) { } } }
It compiles fine if a 1.4 library is used. If a 1.5 library is used, an error is reported. javac 1.5 with -source 1.4 compiles this code fine, but fails like we do in 1.5 mode. So this is an issue with source level 1.4 with a 1.5 library used and compliance 1.5. Kent, any idea how this can be fixed?
"So this is an issue with source level 1.4 with a 1.5 library used and compliance 1.5." I cannot even create a project with those settings. I get an error saying 'Classfile compatibility must be equal or less than source compatibility' How did you create it?
Sorry - forget that. Compliance != classfile compatibility
Proposal is to consider bridge methods if sourceLevel < 1.5. Pls backport to 3.1.x stream as well.
When you say that it passes using javac, you are not comparing the same thing. javac -source 1.4 ..... would correspond to: - compliance 1.5 - source 1.4 -target 1.4
Added GenericType test886 Released into HEAD, will appear in 3.2M5. And as Olivier mentioned, this support is for compliance level 1.5 & source level 1.4. If you want compliance to be 1.4, then please use a 1.4.2 JRE.
Backported to 3.1.3 stream.
Verified for 3.2 M5 using build I20060214-0010
This is just a confirmation because I'm having a similar problem: Does this mean that if I'm needing to compile for a 1.4 JRE, I need to be running eclipse in a 1.4 JRE? I'm having the same problem running Sun's 1.5.0_07 JRE, Eclipse 3.1.2M2 with all compiler levels set to 1.4. I would think it would be totally valid to run eclipse with the latest JRE, but run/compile against an older one. Sorry if this is repetitive, but I want to know how much VM flexibility I have when running eclipse. Thanks.
(In reply to comment #9) > ...I would > think it would be totally valid to run eclipse with the latest JRE, but > run/compile against an older one. According to the javac 1.5.0 docs (http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html): The -bootclasspath and -extdirs should be specified when cross-compiling. Effectively, Eclipse's compiler settings do not allow changes to these to anything other than the default. That leads comment #6. I'm guessing that you guys build eclipse for 1.3 compliance (I don't see 'assert's anywhere in your code), so does that mean you run in a 1.3 JRE?
No we do not run Eclipse on 1.3 VMs. Various people use 1.4 or 1.5 VMs. "I would think it would be totally valid to run eclipse with the latest JRE, but run/compile against an older one." Yes it is but the fix for this bug did not make it into 3.1.2 so until you upgrade to 3.2RC7, you'll have to run on a 1.4.x VM if you do not want to change compliance to 1.5.
Thank you very much for your response. One additional question: In comment #10, I mentioned the javac docs that say you should specify a bootclasspath and extdirs when compiling. How does the eclipse compiler get around this requirement?
We have our own compiler. We do not run javac.
Yes, I understand that. But, I'm guessing that javac allows you to specify the bootclasspath so that there is no chance of hooking into an API that isn't compatible with your target JRE. I'm wondering how your compiler gets around the need for a different bootclasspath at compile time. If this isn't an appropriate question for this bug, could you point me in the direction of the appropriate resources? Thanks.
*** Bug 153734 has been marked as a duplicate of this bug. ***
