Community
Participate
Working Groups
Mixed setups are always problematic and will bite the user sooner or later. I often see issues were a project is set up for J2SE-1.4, but developers compile against a 1.5 JRE. They often use new APIs and only realize their fault when users complain about NoSuchMethodExceptions. JavaCore#CORE_INCOMPATIBLE_JDK_LEVEL should be set to "warning" by default".
I plan to make to make this change only in the BETA_JAVA8 branch. Any disagreements ?
(In reply to comment #1) > I plan to make to make this change only in the BETA_JAVA8 branch. > Any disagreements ? Yes. We should do this for 4.3 and maybe even 3.8.2. Note that we already show a warning on the 'Java Compiler' properties page for such a setup. And we also have 'Warning' as default if there's no strictly compatible JRE for the chosen EE.
Manoj, please take a look. First please prepare a patch for 4.3. TIA.
Dani, I worry that this is create gazillions of warnings in the automated tests suites of various SDK projects. What do you suggest as a mitigation strategy ? Is there a way we can figure out whether junits are running or not and according to initialize it to ignore vs warning ? If we were do invent a new system property or such, is there a ready place where it is easily defined ? Should there be a heads up to eclipse-dev to expect a new warning in setups that use a different JRE ?
(In reply to comment #4) > Dani, I worry that this is create gazillions of warnings in the automated > tests suites of various SDK projects. Very good point Srikanth. And actually this, not just affects test projects: All projects which are still on 1.4 will get that warning (because 'org.eclipse.core.runtime' is at 1.5 now). And they will not only get one warning but one per required bundle that has BREE > 1.4. In addition I found something strange when testing it now: 1. create a Java project with compliance 1.4 and 1.4 JRE (or J2SE-1.4 EE) 2. set incompatible required binaries to Warning ==> a warning is generated for the well-setup project: Incompatible .class files version in required binaries. Project '1.4' is targeting a 1.2 runtime, but is compiled against 'C:JavaSDKs/jdk1.4.2_30/jre/lib/rt.jar' (from the container 'JRE System Library [jdk1.4.2_30]') which requires a 1.4 runtime This looks wrong/unexpected and we also don't show a warning in the project creation wizard or on the 'Java Compiler' properties page. I guess this needs another round of investigation and discussion.
Hmm, it looks like the implementation of JavaCore.CORE_INCOMPATIBLE_JDK_LEVEL in in ClasspathEntry doesn't really solve the problems it was intended to solve (bug 36674). I think we should first fix the implementation problems and then reassess whether we can set it to "warning" by default (not for 3.8.2). I don't think the current implementation is useful, and I would replace it. We could go the long way and deprecate the old option, add migration code, etc., but I would just declare the old thing as buggy and fix it. It's really not useful the way it currently is. The option should just check whether the configured System Library on the classpath and the COMPILER_CODEGEN_TARGET_PLATFORM make sense: - ClasspathEntry#validateLibraryEntry(..) should compare the versions with ==, not "libraryJDK > projectTargetJDK" (at least for Java versions >= 1.5; for 1.4 and below, some special treatment is probably necessary, since the class file version didn't always match the JDK version back then). - ClasspathEntry#validateClasspathEntry(..) should not consider required projects. That's not what "incompatibleJDKLevel" is about. - Javadoc of CORE_INCOMPATIBLE_JDK_LEVEL should tell about the fixed implementation.
(In reply to comment #6) > Hmm, it looks like the implementation of > JavaCore.CORE_INCOMPATIBLE_JDK_LEVEL in in ClasspathEntry doesn't really > solve the problems it was intended to solve (bug 36674). I think we should > first fix the implementation problems and then reassess whether we can set > it to "warning" by default (not for 3.8.2). > > I don't think the current implementation is useful, and I would replace it. > We could go the long way and deprecate the old option, add migration code, > etc., but I would just declare the old thing as buggy and fix it. It's > really not useful the way it currently is. +1 (we discussed this together yesterday).
Ping!
(In reply to comment #8) > Ping! Dani, what is the right priority for this, given Manoj (and others) are near full time on Java 8 ?
(In reply to comment #9) > (In reply to comment #8) > > Ping! > > Dani, what is the right priority for this, given Manoj (and others) are near > full time on Java 8 ? (In reply to comment #9) > (In reply to comment #8) > > Ping! > > Dani, what is the right priority for this, given Manoj (and others) are near > full time on Java 8 ? I expect this fix to be quite simple (less than a day). Maybe this could be the first task for Shankha? I'm pushing on this because currently people don't get a warning when working with 1.5 compliance and a 1.4 JRE (as an example) and it just happened again this week that code got released that later didn't compile.
Jay, please help take this forward, thanks.
Shankha, please go through comments. If you have any questions, we can discuss. Let's target this for M6.
Jay, can you take this over - this needs to go in for M6.
(In reply to comment #6) > - ClasspathEntry#validateLibraryEntry(..) should compare the versions with > ==, not "libraryJDK > projectTargetJDK" (at least for Java versions >= 1.5; > for 1.4 and below, some special treatment is probably necessary, since the > class file version didn't always match the JDK version back then). There is a problem with this - I find some of the jars part of the JRE libraries are compiled with an older version of JDK. Such libraries would get flagged too. Can we live with that? > - ClasspathEntry#validateClasspathEntry(..) should not consider required > projects. That's not what "incompatibleJDKLevel" is about. Let's say project A (at JRE 1.4 level) depends on project B (at JRE 1.5 level) and project B has a JAR in it's classpath that was compiled with 1.5. If we remove that check, we would let some genuine error cases slip through, won't we?
(In reply to comment #14) Good points. JavaCore#CORE_INCOMPATIBLE_JDK_LEVEL in fact doesn't solve bug 36674, and it doesn't look like we have a good solution to make it fix that problem. However, we already have org.eclipse.jdt.launching.JavaRuntime.PREF_STRICTLY_COMPATIBLE_JRE_NOT_AVAILABLE, which is the right solution for bug 36674. And that one is already set to "warning" by default. Projects that use the recommended setup (EE on the classpath) already have enough support to detect the bad situation. Closing this bug.
Verified for 4.3 M6.
