Compilation for JavaSE-1.8 does not guarantee Java 8 class files

[ewillink]

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4735 describes some pain after upgrading from Java 5 to Java 8 BREE. The problem was eventually diagnosed to a reference to the @since Java 12 java.lang.const.Constable in a Java 8 class file.

https://stackoverflow.com/questions/43102787/what-is-the-release-flag-in-the-java-9-compiler is helpful identifying -source, -target and --release as necessary to ensure Java 8 validity.

Problem: the JDT compiler preference page allows selection of compliance with the JavaSE-1.8 execution environment. This appears to automatically impose (grey-out) -source and -target 1.8; good. But it also greys out --release and imposes org.eclipse.jdt.core.compiler.release=disabled; bad.

Surely JavaSE-1.8 shoiuld impose org.eclipse.jdt.core.compiler.release=enabled or at least allow the user to choose?

[akurtakov]

I have investigated very similar issue just yesterday.
Mandating release=enabled will surely disallow cases where one compiles for old release and uses new API if available or old one if not there e.g. tycho does so(https://github.com/eclipse-tycho/tycho/blob/8a012d6cd3428a98d52bbe65b9df4c9ec774bff7/tycho-core/src/main/java/org/eclipse/tycho/core/ee/ListSystemPackages.java#L28).
Being able to choose between source/target and release "strategies" sounds like the path forward.
It's most likely possible to even edit the prefs file manually to set the settings as you prefer them as in eclipse-jdt/eclipse.jdt.ui#1448 it has been discovered that what UI shows and actual prefs page their could be differences.

[ewillink]

Using 'future' API seems pretty suspect to me, although, to use an analogy, I can just see that a Shakespearean sonnet about Artificial Intelligence is not impossible. However release enabled should be a strongly encouraged default. Allowing the prefs to differ from the UI is a recipe for disaster since the prefs is regularly improved whenever the UI page is accessed.

[stephan-herrmann]

Problem: the JDT compiler preference page allows selection of compliance with the JavaSE-1.8 execution environment. This appears to automatically impose (grey-out) -source and -target 1.8; good. But it also greys out --release and imposes org.eclipse.jdt.core.compiler.release=disabled; bad.

When you select JavaSE-1.8 this is meant to refer to an actual JDK 1.8. That JDK does not support --release (and does not need it). Therefor the combination of JavaSE-1.8 and --release is illegal.

The point to observe: you should not "lie" when associating actual JDKs to (abstract) execution environments. If you compile against JDK 17 say JavaSE-17 and --release 1.8. If you compile against JDK 1.8 just say JavaSE-1.8 and be done.

[iloveeclipse]

I do not see a bug here, closing.

[stephan-herrmann]

I do not see a bug here, closing.

Not a bug, right.

@ewillink to see the desired magic at work, configure a workspace with only a new JRE, e.g., 22, and then create a project compiling against JavaSE-1.8. All the sudden the preference page will look like this:

See the info at the bottom?

The only thing left to be desired: when migrating an existing project from 1.5 to 1.8 or such, while only a newer JRE is installed, the --release box isn't automatically selected.

• workaround: temp disable "Use compliance from exec env ..."
• check --release
• revert the other box

I don't think this is worth implementing a specific wizard, but "contributions are welcome" ...

[ewillink]

@iloveeclipse surely you should allow more than 7 minutes for a response before arbitrary closure?

@stephan-herrmann when I select JavaSE-1.8 i expect the result to suit all JavaSE-1.8 executions. I do not have the option of using JavaSE-1.8 since the Eclipse IDE now mandates Java 17 which does support --release so I expect it to be used.

@stephan-herrmann The image you show seems perfect. My use of 4.32 with jdk-17.0.8 as default and jdk-11.0.19 and jdk-1.8.0_371 and jdk-1.5.0_22 also installed is almost the same as your image: BUT the greyed out --release is not selected and there is no info that it is selected. Your suggestion of disabling, changing, reverting doesn't work for; the --release remains greyed out.

It is only class files built 'by Tycho' that are problematic, so perhaps the IDE is getting it right, but JDT is failing to communicate the --release to the Tycho compilation or the Tycho compilation is ignoring it. Whatever, somewhere there is a bug. I should not be having to spend a couple days investigating why I get a strange CNFE crash in my (jdk11) compatibility tests. When I specify JavaSE-1.8, I expect JavaSE-1.8 compliance or a diagnostic explaining why I'm not getting it.

[stephan-herrmann]

@stephan-herrmann when I select JavaSE-1.8 i expect the result to suit all JavaSE-1.8 executions. I do not have the option of using JavaSE-1.8 since the Eclipse IDE now mandates Java 17 which does support --release so I expect it to be used.

You do have the option to configure a 1.8 JRE under "Installed JREs". If you do so, it will be used for your "JavaSE-1.8" project and all will be well.

@stephan-herrmann The image you show seems perfect. My use of 4.32 with jdk-17.0.8 as default and jdk-11.0.19 and jdk-1.8.0_371 and jdk-1.5.0_22 also installed is almost the same as your image: BUT the greyed out --release is not selected and there is no info that it is selected. Your suggestion of disabling, changing, reverting doesn't work for; the --release remains greyed out.

In that configuration "JavaSE-1.8" selects jdk-1.8.0_371 and hence --release is neither necessary nor possible.

It is only class files built 'by Tycho' that are problematic,

Also tycho should not need --release when compliance 1.8 is set and jdk-1.8.0_371 is found (e.g., via toolchains.xml).

somewhere there is a bug.

Perhaps. Provide a sample project where JDT violates your settings, and I will look at it.

[ewillink]

Also tycho should not need --release when compliance 1.8 is set and jdk-1.8.0_371 is found (e.g., via toolchains.xml).

I have a JDK 8 in toolchains.xml, but globally the Eclipse IDE enforces at least JDK 11 and maybe even JDK 17. So I presume that a per-plugin toolchain setting override could be required to use the JDK 8. But since I use auto-poms for regular plugins, I don't want to have to introduce custom poms. Perhaps the bug is that the auto-pom fails to auto-toolchain.

[stephan-herrmann]

Also tycho should not need --release when compliance 1.8 is set and jdk-1.8.0_371 is found (e.g., via toolchains.xml).

I have a JDK 8 in toolchains.xml, but globally the Eclipse IDE enforces at least JDK 11 and maybe even JDK 17. So I presume that a per-plugin toolchain setting override could be required to use the JDK 8. But since I use auto-poms for regular plugins, I don't want to have to introduce custom poms. Perhaps the bug is that the auto-pom fails to auto-toolchain.

I hope you see, that there is too much "maven" / "tycho" and too much "perhaps" involved, for anyone in JDT to take action. The folks at tycho and / or m2e might know more.

[ewillink]

Perhaps, but the org.eclipse.jdt.core.compiler.release=disabled contrary to your image seems like a problem that clearly occurs at the JDT level.

[stephan-herrmann]

Perhaps, but the org.eclipse.jdt.core.compiler.release=disabled contrary to your image seems like a problem that clearly occurs at the JDT level.

Did I ever mention that precise reproducible steps might help in our communication? 😄

[ewillink]

Absolutely. I often insist on repros from my users.

But producing a small repro can be very time consuming, sometimes insightful, sometimes a waste of time. I therefore advocate a preliminary discussion in case it is a recognisable problem.

org.eclipse.jdt.core.compiler.release=disabled contrary to your image seems like a clear problem; perhaps not in the IDE because perhaps the IDE uses Java 8; perhaps in Tycho because the need for 100% Java 8 compliance has not been propagated.

OCL commit 0a5c414abace6489afdbe65acfc3cbd63ba73870, 2 ahead of master refactored a routine to avoid a Constable local variable. a9c8a4c657302d9cb8a3f07aabdb32c1f668af77 is therefore a repro; ok in IDE, bad in the 'Build OCL DIstribution - nightly" m2e launch.

The handleProblem method in plugins/org.eclipse.ocl/src/org/eclipse/ocl/lpg/AbstractProblemHandler.java hosts the problematic ?: that gives a bad Constable reference.

[stephan-herrmann]

a9c8a4c657302d9cb8a3f07aabdb32c1f668af77 is therefore a repro

in my book this doesn't qualify as "steps for reproduction".

sometimes a waste of time

I feel that further discussion is also a waste of time.