search

eclipse-jdt / eclipse.jdt.core

Eclipse Public License 2.0
157 stars 125 forks source link

Using ECJ parser targetting newer -source version should emit a warning #3018

Open mickaelistria opened 3 days ago

mickaelistria commented 3 days ago

Currently, if I have a project setup with its options to target newer Java version (for example m2e might do it, and it's not too wrong if one has a project really targetting Java 24 already)

org.eclipse.jdt.core.compiler.codegen.targetPlatform=24
org.eclipse.jdt.core.compiler.compliance=24
org.eclipse.jdt.core.compiler.release=disabled
org.eclipse.jdt.core.compiler.source=24

then ECJ fail back to using latest, which is a good option. But it does it without showing any hint in the IDE, so the users may have wrong expectations of Java 24 being supported. In such case, it would be helpful if ECJ would put a warning such as "Requested unsupported Java version 24, failing back to latest supported version (23)".

mickaelistria commented 3 days ago

@iloveeclipse I see you recently added checks in the compiler for too old versions, I'm thinking of something similar (not aborting). But also, and maybe more importantly, I would like to have those checks on the Parser, so those errors can be seen when reconciling too (if builder is disabled).

jukzi commented 3 days ago

mind to propose a PR at best with junit test?

mickaelistria commented 3 days ago

I'm trying; struggling with the many layers where the version is "fixed" silently instead of directly forwarded to the compiler to fix it ultimately.

stephan-herrmann commented 2 days ago

the users may have wrong expectations of Java 24 being supported.

Small reminder: it's not our decision to support or not support Java 24, which simply doesn't exist until 2025/03/18.

This should be reflected in whatever warnings will be added here.

mickaelistria commented 2 days ago

I don't really mind about the actual message, supported/available/implemented/present... they're all the same to me in this context. But we're not there yet; currently the big issue I face is that the CompilerOptions will always "fix" the versions so they're in the range of what's supported by ECJ, even if the project options say otherwise. I would like to try changing that and having the "fix" part of ECJ instead of project options->CompilerOptions conversions. And this is made even more difficult by the fact that the compiler uses the ClassFile levels instead of the source versions internally.... My current idea is that we keep in the CompilerOptions the "raw" project settings (eg initialRequestedSourceVersion), even if they don't directly match ECJ capabilities, and have ECJ also validating/warning about those "raw"settings, so we don't change the existing implementation.