Community
Participate
Working Groups
HEAD The .class files compatibility option in Preferences>Java>Compiler is basically meant to make sure that one can write 1.5 code using the 1.5 source level setting and still guarantee his clients using 1.4 VM that the code will execute using the .class files compatibility setting. However, currently the UI does not allow setting .class files compatibility lower than the source level setting. This makes the option redundant because code compiled for 1.x VM is vby default supposed to execute on 1.x + n VM. This needs to be investigated and fixed.
(In reply to comment #0) > HEAD > > The .class files compatibility option in Preferences>Java>Compiler is basically > meant to make sure that one can write 1.5 code using the 1.5 source level > setting and still guarantee his clients using 1.4 VM that the code will execute > using the .class files compatibility setting. Nope, down-compile 1.5 to 1.4 is not supported. See also javac's answer to this: c:\JavaSDKs\jdk6_26\bin>javac -source 1.5 -target 1.4 javac: source release 1.5 requires target release 1.5
(In reply to comment #1) > (In reply to comment #0) > > HEAD > > > > The .class files compatibility option in Preferences>Java>Compiler is basically > > meant to make sure that one can write 1.5 code using the 1.5 source level > > setting and still guarantee his clients using 1.4 VM that the code will execute > > using the .class files compatibility setting. > > Nope, down-compile 1.5 to 1.4 is not supported. See also javac's answer to > this: > c:\JavaSDKs\jdk6_26\bin>javac -source 1.5 -target 1.4 > javac: source release 1.5 requires target release 1.5 We have tests in the compiler which check such down compile and from JDT Core point of view it is in fact allowed. See org.eclipse.jdt.core.tests.compiler.regression.VarargsTest.test060() for instance. OTOH, if it is indeed not allowed, then this option should be removed because it is useless (as per the second part of my comment 0). Please reconsider.
> We have tests in the compiler which check such down compile and from JDT Core > point of view it is in fact allowed. See > org.eclipse.jdt.core.tests.compiler.regression.VarargsTest.test060() for > instance. > > OTOH, if it is indeed not allowed, then this option should be removed because > it is useless (as per the second part of my comment 0). It's not useless. Some use it at their own risk. We (JDT Core) support it on a best effort basis but we won't surface it in the UI.
(In reply to comment #3) > It's not useless. Some use it at their own risk. We (JDT Core) support it on a > best effort basis but we won't surface it in the UI. Ok, but in that case if someone asks me what that option does, what should I say? I'll be wrong if I say it is meant for running 1.6 code on a 1.7 VM I'm wrong, because that is anyway guaranteed. If I say it is meant for running 1.5 code on 1.4 VM (which is the real purpose), I'll again be wrong because this is not allowed in the UI. Can you give an example of how someone will use this option? (Just asking for my own clarity. I agree with your explanation above)
(In reply to comment #4) > (In reply to comment #3) > > It's not useless. Some use it at their own risk. We (JDT Core) support it on a > > best effort basis but we won't surface it in the UI. > > Ok, but in that case if someone asks me what that option does Which option? The one in the UI or 1.5 -> 1.4?
(In reply to comment #5) > Which option? The one in the UI or 1.5 -> 1.4? I meant to ask about the .class files compatibility option in the UI dialog. Is there any real scenario in which the user would want to tweak it as of now. Or will removing the UI option break anything? (I didn't mean the JDT/core option is useless. I meant the option as surfaced in the UI dialog looks redundant.)
(In reply to comment #6) > (In reply to comment #5) > > Which option? The one in the UI or 1.5 -> 1.4? > > I meant to ask about the .class files compatibility option in the UI dialog. Is > there any real scenario in which the user would want to tweak it as of now. Or > will removing the UI option break anything? Yes, just try with scenarios that are supported, e.g. 1.3 -> 1.2.
(In reply to comment #7) > Yes, just try with scenarios that are supported, e.g. 1.3 -> 1.2. Ah! Now i see. So there is indeed one case which works. Source = 1.3 and class file compat <= 1.2. Hmm, this is new information for all of us. Thanks Dani. :) Any particular reason why there's a special allowance in case of source level = 1.3?
Ayush, ask yourself why 1.7 source cannot be compiled and run on a 1.6 VM. (Hint: AutoCloseable, Suppressed Exceptions, MethodHandle etc) VM would not have changed from 1.2 to 1.3, or the 1.3 source does not rely on any 1.3 VM specific features.
(In reply to comment #9) > VM would not have changed from 1.2 to 1.3 Then the option is once again redundant. > or the 1.3 source does not rely on > any 1.3 VM specific features. Yes this is my guess, but while we're at it, will be good to know the exact story.
(In reply to comment #8) > (In reply to comment #7) > > Yes, just try with scenarios that are supported, e.g. 1.3 -> 1.2. > > Ah! Now i see. So there is indeed one case which works. > Source = 1.3 and class file compat <= 1.2. > Hmm, this is new information for all of us. Thanks Dani. :) > > Any particular reason why there's a special allowance in case of source level = > 1.3? This is not the only combination. In 1.3 compliance the default target was even 1.1. It really depends on whether the new source constructs can be covered with the older class file format(s).
I think the basic confusion stems from the message shown when we disallow, being more general than the reality It states categorically that "Classfile compatibility must be equal or greater than source compatibility." and not that the combination the user is playing with is not feasible.
(In reply to comment #12) > I think the basic confusion stems from the message shown when we disallow, > being more general than the reality It states categorically that > "Classfile compatibility must be equal or greater than source compatibility." > and not that the combination the user is playing with is not feasible. Good point. I've adjusted the summary.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
