[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)
|
As you seem to be eager to invest in this issue, here are two things that might
help:
* get public confirmation from Eclipse Foundation legal staff that what you plan
will not invite Oracle to file a multi million dollar law suite.
* ask people who do work in BETA branches, how easy it would be to ensure that
every little change that is currently done in the branch can be safely protected
by a "feature switch" without making their lives much harder. As a preparation
you could have a look at some of the JLS diffs which specify the changes to be
made. Here's a good example:
https://cr.openjdk.org/~iris/se/24/spec/draft/java-se-24-draft-spec-31/specs/primitive-types-in-patterns-instanceof-switch-jls.html
best,
Stephan
Am 13.01.25 um 08:58 schrieb Mickael Istria:
On Sun, Jan 12, 2025 at 9:45 PM Stephan Herrmann <stephan.herrmann@xxxxxxxxx
<mailto:stephan.herrmann@xxxxxxxxx>> wrote:
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
<http://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?
