Thanks all, I see some progress.
@Mike thank you for the clear explicit recommendation; we're preparing an hopefully concise and precise enough mail for legal to ask for their assistance
About the feature flags, I actually think that we don't need them... more than we already do!
For example in the code of ECJ's `*Scope` classes, we can read in 39 places some patterns like: `if (level <= ClassFileConstants.JDK_NNN)`, (where level can be sourceLevel, complianceLevel...)
In the DOM, we have some `ASTNode.unsupportedInX_Y_Z()` methods which are extensively used and do act as a feature flag (throwing exceptions or disabling features when compilation doesn't target a recent enough Java version).
So basically instead of adding some new flags as I suggested earlier, we can just stick to the usual flags. Master could easily include support for Java 24; as long as the file support Java 23, the Java 24 code wouldn't harm; just as it won't harm after Java 24 is released and the BETA_JAVA24 branch is merged.
Just "hiding" the Java 24 source level from the UI seems enough to hide all Java 24 support. The Java 24 specific code is internal and basically not used.
So if we stick to this existing pattern, which I believe is enough, then we don't need a new process; things become just "working on the master branch" but with the same usual patterns of guarding the new features by the Java version which make them available.
Cheers,
Mickael
