Skip to main content
[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) 
Thanks to all who have chimed in so far.

I'll add my p.o.v. in two batches:
- In this post I'll discuss what are the uncertainties in the solution space, assuming that it's a good habit to address greatest uncertainties first. 

- Afterwards I think a closer look at the problem space will help, too.
Currently, each "side" wants to see "the other" question answered first, before exploring their part of the solution, quite understandably :)
I'd like to highlight one certainty we gained: grammar changes could easily be the roadblock we cannot overcome - we cannot switch between two grammars in the same implementation. Period. Until s.o. comes with a solid technical answer to this problem we could simply stop here, saying feature switches are not a feasible solution.
But let me reframe what I see as the greatest uncertainty atm: perhaps we don't have a common understanding of what is meant by "feature switches". Some may have noticed that JDT has always had the option to select from a set of Java versions :) - is that a feature switch in the sense of this discussion? I doubt it, because what we seem to need is a definition of "feature switch" that serves as a guarantee that if we follow that road we are protected against law suites from Oracle, i.e., we need a definition with legal strength.
If the definition would be: the switch/toggle must prevent any execution of any line of code targeting the next java version, then we can pretty clearly say that this would put development to a grinding halt due to extra complexity. So, can anybody put forward a definition of "feature switch" that combines legal strength with technical feasibility? Until we see this, we will not be able to get any meaningful answers. 

so much for part one,
Stephan

Am 15.01.25 um 09:51 schrieb Mickael Istria:
On Wed, Jan 15, 2025 at 6:49 AM JAYAPRAKASH ARTHANAREESWARAN <jarthana@xxxxxxxxxx <mailto:jarthana@xxxxxxxxxx>> wrote: 

    If we are unable to answer Stephan’s first question [1], then everything
    else becomes a moot point.
We will get an answer whenever we ask; but I'd rather ask only after this discussion, as some technical blockers might be unveiled. But for the rest of discussion, let's assume the answer from legal would be that we can have feature flags controlling unspecified-yet compiler behavior (and some UI elements to control them). 

    ____

    The Java version release spans two eclipse releases let’s say E1 and E2. If
    we are going to publicly say that E1 is going to include Java 24 changes,
    what exactly do we promise? Or we just don’t care at all? Or the developers
    are supposed to factor in the half-way E1 milestone and plan their changes
    accordingly?
I don't think anyone has suggested to claim public support in E1. What I'd suggested is that in E1, there would be some flags such as `-Djdt.jepXYZ` existing for testers to enable the current support for the upcoming Java feature; but some guards to disable such features by default. Then only when Java gets released and JDT support is complete enough, instead of a merge, we just remove those flags in the code to enable support by default. And this would happen in E2. So I don't think BETA branch vs feature flags do change anything regarding the timeframe when next Java support is GA. 

    Fact of the matter is, the Java release generally occurs even after E2, so,
    we can’t even promise anything for E2. And what happens during the quiet
    period between the builds, however short it is? This is a classic case that
    warrants a different branch and a merge strategy.
Branches could still be used for individual development when necessary. The difference is that branches would be used "when necessary" (eg quiet period) instead of "for the whole development of next Java version". 

    And yet, we are thinking of developing in the same branch, even at the cost
    of convoluted code with switch, flags and what not. I can’t think of a
    reasonable answer to any of these questions. But then, may be, I am biased 😊
Indeed, the code would be more convoluted but the process to develop/contribute/ merge would be way less convoluted. My perception is that the process to contribute to next Java version in JDT is really difficult and has thrown dozens of people away. Indeed, there are a few example of people working on JDT for years or on Eclipse Platform many hours a week (and being paid for that) who can deal with this convoluted process efficiently enough for them, but there are some who just give up trying to contribute to next Java version because this process is too complicated and makes them less efficient and less successful. And I suspect this is more people giving up than peopel actually contribution, and that "mainstreaming" the process would keep some more people around and that it would be worth the cost of a few `if (Boolean.getBoolean("jdt.jepXYZ")` here and there. 
But I'm biased too.

    So, the few adopters who care about, can in fact take the Y builds and
    experiment.
Well, that's one issue I'm trying to address, and IMO 1 issue that should be the priority for JDT as a project if it wants to remain viable on the long run: how come there are so few adopters who care about? I think the BETA branch is one bit of a cause here. 

Cheers

Back to the top