search

eclipse-jdt / eclipse.jdt.core

Eclipse Public License 2.0
164 stars 130 forks source link

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

Closed mickaelistria closed 3 weeks ago

mickaelistria commented 1 month 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 1 month 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 1 month ago

mind to propose a PR at best with junit test?

mickaelistria commented 1 month 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 1 month 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 1 month 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.