Bugzilla – Full Text Bug Listing
| Summary: | "--release" option is unavailable in project compiler settings | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Stefan Moebius <stmoebius> |
| Component: | UI | Assignee: | Kalyan Prasad Tatavarthi <kalyan_prasad> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | loskutov, simeon.danailov.andreev, stephan.herrmann |
| Version: | 4.8 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Stefan Moebius
Kalyan, can you please have a look? @Stefan Moebius Please provide screen shots of your Project compliance preference page. Also please provide the screen shots of thee workspace preference page for Installed JREs and for Execution Environment when JavaSE-1.8 is selected on the page. I have not been able to reproduce this issue. Please reopen this bug if you are facing this issue even now. Please provide screen shots of your Project compliance preference page. Also please provide the screen shots of thee workspace preference page for Installed JREs and for Execution Environment when JavaSE-1.8 is selected on the page. Hi Stephan, I have a question regarding the "javac --release" option in the JDT compiler. We are planning to support Java 8 and Java 11 simultaneously in our product and I think we are running into some corner cases. I see the following relevant bugs: https://bugs.eclipse.org/bugs/show_bug.cgi?id=527260 (support "--release N" in JDT) https://bugs.eclipse.org/bugs/show_bug.cgi?id=539222 (this ticket, "--release" checkbox disabled in Java project preference page) In particular, our compiler (JDT+xtext) ran into a problem with a project that has JRE 8 on the classpath, but only JRE 11 installed in the workspace. In that case, I see that "--release 8" ("release=enabled") is not used, although "compliance=1.8" is used (in this bug I read that its expected, "release" is allowed only with JRE 9+). What is the expected JDT behavior here? The project has JRE 8 on the classpath, so theoretically it doesn't need "--release 8". But JDT only has JRE 11 to compile against, which implies "--release 8" is needed. I'm asking for JDT itself; we normally have both JREs available, a problem in our code causes JRE 8 to be missing in our compiler application (we'll try to fix our code to address the problem). The stripped-down snippet is: package test; public class TestMath { public static void main(String[] args) { long a = 4L; long f = Math.floorDiv(a, 4); System.out.println(f); } } Exception in thread "main" java.lang.NoSuchMethodError: java.lang.Math.floorDiv(JI)J at test.TestMath.main(TestMath.java:7) JRE 8 is on the classpath, compliance is set to 1.8, JRE 11 is the only installed JRE. The problem itself is expected, when "--release 8" is not used during the compile. Best regards and thanks, Simeon (In reply to Simeon Andreev from comment #4) Some (probably incomplete) observations: JDT/UI disables that check box for reasons that are obscure to me: fComplierReleaseCheck.setEnabled(checkValue(INTR_COMPLIANCE_FOLLOWS_EE, USER_CONF) || checkValue(INTR_COMPLIANCE_FOLLOWS_EE, DISABLED)); (This goes back to bug 527569 - 2 commits). Next, when I set release=enabled in .settings/org.eclipse.jdt.core.prefs, still release was not used on this path: JRTUtil.getJrtSystem(File, String) line: 108 JRTUtil.getJrtSystem(File) line: 104 JRTUtil.getModulesDeclaringPackage(File, String, String) line: 177 ClasspathJrtWithReleaseOption(ClasspathJrt).getModulesDeclaringPackage(String, String) line: 254 JRTUtil does not know about the #release value correctly set in ClasspathJrtWithReleaseOption. => This is an obvious bug in JDT/Core Beyond that, the --release feature is flawed by design. Search for JDT bugs mentioning ct.sym and you'll see that JDT has no fair chance to correctly implement this feature. In particular, we recommend to use that feature only with JDK > 11, well actually, you'll probably need the JDK that was most recent at the time a given Eclipse version was released. So in order to gain backward compatibility we got a complete version lock. Go figure. The mentioned recommendation against --release 11 also has a finger in the pie: ClasspathJrtWithReleaseOption refuses to use release information on some paths if !this.isJRE12Plus. Good luck. Moreover I couldn't reproduce how you created bytecode mentioning java.lang.Math.floorDiv(JI)J I always get java/lang/Math.floorDiv:(JJ)J |