As an engineer I know how to solve technical issues like working in a branch.
It's not rocket science. Recently Hannes made great improvements in making
things smoother than before [1]. And we (JDT) have even adopted the
responsibility for P-Builds. A little hiccup here and there is part of our
business, isn't it? So let's not exaggerate on the complexity of working with a
branch.
It's not rocket science but it's one extra challenge that we could spare to contributors when comparing JDT with other projects. Some challenges have technical reasons that we can't really overcome at the moment; but some -such as this branching process- are things that we can easily act upon.
If you have legal expertise I'd be happy to hear how we can convince Oracle that
releasing support for unreleased Java versions is fine. Without such legal
advice I don't see value in this long running discussion.
I've grown some better understanding of legal stuff regarding Java, and while I'm wouldn't consider myself an expert, I don't think this legal argument still holds true (if it ever did). It all revolves around the concept of what one mean by "releasing".
If releasing mean shipping public support for JEP-X, JEP-Y, JEP-Z and availability out of the box (as specified by JLS), then feature flags is not contradictory at all and there is nothing that really prevents having preparatory work for a JEP in the code. It's possible to release ECJ and JDT compatible with Java 23 and have in it some feature flags to enable JEP-X, JEP-Y, JEP-Z (eg `-Djdt.experimental.jepX.enable=true`), that would still "hide" the feature by default to not harm users and legal, but that curious people could activate for testing. On that aspect, the JEP support becomes an internal compiler-specific feature that becomes released (ie on by default) only when corresponding Java is released.
For example, on could assume that the Y-Builds we ship on
download.eclipse.org are already releases as they're publicly available. But it looks like JDT project has defined that this is not a release because it was not announced as such a release and it's not on marketplace. Those criteria would still hold with feature flags instead of a branch.
Let's imagine we get some more official support of my former statement (feature flags are legally good enough), would it be fine to replace branches with feature flags for next Java support development?
