Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8) - What is the alternative JDK 8 exit strategy?

[Michael Bien <mb...@gmail.com>]

What is actually the JDK 8 exit strategy of those who vetoed? Since so 
far none was given.

options:
  a) there is none, the NetBeans project ends when JDK 8 ends (or before 
that; this would explain frgaal etc)
  b) NetBeans waits until JDK 8 ends, and is then migrated in big bang 
fashion to JDK 3x (assuming it is still possible), expecting the same 
jump from NB users


If we actually care about users, we do have to give them an upgrade path 
too. The pragmatic way of doing this is to have some NetBeans releases 
which require JDK 8 (we have them already), then have a few releases 
which require JDK 11 and after that some which require JDK 17 and so 
forth. The fact that the steps are small is a feature of the new release 
model! Waiting for the killer-feature before upgrade would be a mistake 
for long running projects.


beside providing an upgrade path, this will also:
  - improve UX
  - allow NB to get rid of EOL libs
    - which reduces virus scanner complains we are periodically getting 
from admins
    - and also reduces the probability of an actual security issue 
without us having an upgrade path available
  - and it will keep the project somewhat interesting for contributors 
(this is a non-technical reason but it shouldn't be ignored since 
NetBeans is a community effort now)

The OpenJDK release train isn't waiting for NetBeans, we have to make a 
decision very soon or it leaves.

Neil's proposal is c) and is fully compatible with the notion of long 
running NB LTS releases which keep supporting JDK 8 if there is 
sufficient interest for it.

Don't get me wrong, a) is actually a perfectly valid strategy. I have 
seen it often in projects which know they move on from java or expect to 
be replaced by other projects in future before the support contract 
ends. But this doesn't work for long running endeavors since those would 
run into b) and that would be very short sighted.

best regards,
michael


On 10.04.23 01:16, Svata Dedic wrote:
> Please remember that the published proposal not only covered JDK8's 
> fate, which we argue about right now, but also the idea to drop JDK11 
> in 2024. So take my
>
> * -1 (at the moment) for JDK8 phase out with NB19;
> * and ANOTHER -1 to the JDK11 plans as presented in this thread (but 
> that should be discussed separately anyway, not hidden in dropping 
> JDK8 thread)
>
> Summary:
> - I do not think that dropping JDK8 now is a good idea
> - I do not think that sufficient relevant data for the decision was 
> collected; I think that we did not even start to collect it.
> - I do think we can find and reach a reasonable compromise.
> - I propose some action items to make the decision better informed and 
> based.
> - I offer coding help with compatibility bridges, analysis and/or 
> migration of the code.
>
> TL;DR:
>
> I'd like to offer some coding support to retain JDK8 as well - but 
> (which IMHO did not happened really during past heated exchanges) need 
> to agree on support scope before committing. I'd like to emphasize 
> that *runtime* compatibility should be treated separately from 
> *development* environment requirements. I would also (now) ask to 
> restrict from advocating language goodies - as there are different 
> options to achieve that, not necessarily requiring the change of the 
> codebase runtime requirements.
>
> I will quite from Ernie Rael's post (quoting stats from 2022):
>> even though Java 11 had been available for more than a year. Since
>> then, the balance has shifted between these two LTS release versions.
>> More than 48% of applications are now using Java 11 in production (up
>> from 11.11% in 2020) with Java 8 a close second, capturing 46.45% of
>> applications using the version in production.
>
> There was an idea to basically tell users with requirements for older 
> JDKs (now 8, 11 in 2024) they should use the last released platform 
> (NB18) that supports their environment. This really mean to *abandon 
> the users*, as they will not receive any new features or bugfixes. 
> While maintenance effort surely requires work if we still support 
> JDK8, porting features (albeit selectively) back to old platform 
> requires even usually much more effort. The offer that platform users 
> do that for us may seem formally correct, but in reality it requires 
> deep knowledge of many parts of the IDE, not just knowledge of the 
> 'system parts' affected by JDK differences. Exemplified on myself, 
> although I could be able to assist to develop bridges for different 
> JDK versions for features determined as necessary for the new codebase 
> (with possible graceful degradation or function disable on old 
> runtimes), I sincerely doubt I would be able to assist with 
> backporting a user-facing feature. I believe this is a general case, 
> as the 'domain knowledge' is far more scarce than the knowledge of 
> system libraries.
> So the seemingly positive approach, it turns out to be rather 
> offensive in its implications to platform users, which is an outcome I 
> do not like.
>
> This could be eventually barely acceptable in case of JDK8, I do not 
> see reasonable to set minimum JDK to 11 at all. The reason is that 
> while JDK8 has support cycle of 11 years (2015 released, 2026 EOLed by 
> RH / IBM), JDK 11 has a super short shorter cycle despite being LTS 
> (2021-24) and JDK17 just 6 years (2021-2027). From this perspective, 
> forcing the users to upgrade JDK 8 > JDK 11 by NB19 in 2023, and then 
> again to JDK17 by (even if ve move OUR deadlines) right during 2024 
> given the *upstream support ceases for 11* in 10/2024, is ... a very 
> bad idea.
>
> I've read the thread again, and I must think there's a lot of heated 
> feelings, but very little of hard data. Let me say I understand (some 
> of) the urge to upgrade and I'd like myself to be able to use some 
> JDK11+ APIs in NB platform (but also pretty sure that other upgrade 
> proponents are interested in *different* sets of APIs). But there are 
> different perspectives - so important IMHO that I am willing to offer 
> my personal time to support older JDKs, too.
>
> In fact, *we  all* (IMHO and me explicitly included) never went as far 
> as to write down the fact and consolidate the info to get the overall 
> picture. The consolidated list is important so the maintenance burden 
> could become more obvious even to nonbelievers - or, in other hand, 
> the JDK8 preservation may turn not such high barrier, and JDK11 
> features not as critical to outweigh the JDK8 drop for the whole 
> codebase. We do not have AFAIK such an overview. We did not even start 
> to collect such a list, instead of that, the general tone of the 
> discussion was exagerrated "march forward, kill all the old stuff, let 
> the (IT) God sort it later".
>
> Also note that we can *lower* the guarantees: e.g. not run JDK8 tests 
> every commit, to reduce the resource consumption for the test matrix. 
> But such negotiation didn't really happen. So far, the major +1s were 
> not based on technical details, but rather on emotions or feelings - 
> "new is good", or at least the thread reads.
>
> First of all, the general idea that "JDK8 is dead" does not seem 
> correct. It's true that Oracle stopped public updates - I do not have 
> knowledge of the details, but the Internet chatters about a business 
> needs, so be it. Anyway RedHat took the role of JDK8 steward and does 
> it well: 6 updates in 2022, 1 update in 2023 so far - not only 
> strictly security updates, but also other maintenance/bugfixes. IBM, 
> AdoptJDK, Azul, Redhat, Amazon - they all are releasing JDK8. Redhat, 
> Adoptium and IBM (now) declares maintenance (not just security) till 
> 2026; even longer (!!) than maintenance for JDK 11 - which is also a 
> LTS release. JDK8 is also the last release that can be really 
> installed on Windows XP - don't laugh !! There may be perfectly valid 
> reasons NOT to update - e.g. tool or hardware dependencies and it is 
> the *last* release not twisted by the JDK module system. While the JDK 
> modules can be seen as a benefit, it's true it complicated (and 
> continue to complicate) life for all other modular approaches: 
> NetBeans, OSGi, JBoss, ...
>
> As NetBeans platform, and to lesser degree ide cluster, parts of java 
> cluster (maybe other parts as well) form *application platform*, not a 
> development environment - any policy change made here will directly 
> affect these applications. Again it should be noted that the issue is 
> NOT language goodies, the preferred runtime, or the compilation 
> environment - but the runtime required to run NetBeans (extended) 
> Platform - based applications. Not necessarily the minimum runtime for 
> NetBeans IDE.
>
> Next, the external conditions that would require us ultimately to move 
> to newer runtime come (considering Java cluster) from Maven and 
> Gradle. So far, Gradle 8 still declares runtime support for JDK8; 
> Maven 4 alpha, so far declares the same. I am not aware of plans from 
> those two to drop JDK8 runtime support soon (but see the action items).
> So until JDK8 upstream support really ceases (which is now scheduled 
> to 2026), I propose to make a policy to either keep the ability to 
> *run* on JDK8 for
> - platform, as it forms a base for non-IDE applications in general
> - for java cluster: java build tools themselves still support that
> - in base technology modules whenever possible
> ... or have a solid technical explanation why it is not possible, or 
> not feasible - an explanation written down, agreed on or voted.
>
> I'll go through some examples of why I think we do not decide based on 
> facts, but rather than feelings:
> To give an example of my own area: I'd love to have 
> CompletableFuture.defaultExecutor() method for final rewrite of 
> RequestProcessors to completable futures. But it can be overcomed with 
> some limitations and ugly implementation. It is not a hard barrier, 
> but "only" requires significant effort.
>
> Similarly (but speaking just from a shallow understanding, MBien 
> hopefully kindly forgives and/or corrects), Maven Indexer: it is not 
> *mandatory* not even for Java development (especially if gradle is 
> involved). The experience will surely degrade, as IDE won't be able to 
> suggest versions, or suggest libraries based on symbols. But that's 
> the choice of user and/or packager, and we can safely leave the choice 
> open instead of making it *instead* of our users. Not to mention that 
> there are other possibilities - like create a thin internal layer that 
> allows to call Lucene 8.11.2 (on JDK8) or Lucene 9.5.0 (on JDK11). Or 
> - if we consider now omnious online presence - online queries for 
> symbols, package names and versions that could completely replace the 
> indexer (and maybe this should be offered as an alternative even on 
> new system, as downloading the gig size maven central content is 
> horrible).
> The question here is again, whether we need Lucene 9.5.0 because of 
> new APIs, or because of its implementation progress. And even if it 
> was for APIs, the approach can be different, if
> - the new API is only used (for example) to configure / setup Lucene 
> engine. This could be more or less easily bridged for different Lucene 
> versions, or
> - the new APIs are used extensively throughout the codebase, and a 
> delegation layer is not feasible.
> Here, I miss an analysis why it is _necessary_ or _highly desirable_ 
> to mandate Lucene 9.x -- in what parts it offers significant API 
> advantage over 8.x line (that supports JDK8) so it justifies dropout 
> of older platform. If it is for better *implementation behaviour* then 
> heck, I am hands-in for creating a bridge layer to work with Lucene 
> 8.x (JDK8) *and* Lucene 9.x (JDK11+). Just give me some initial 
> guidance and some time - but nobody asked for that, or gave such 
> analysis (or at least I do not know about one; apologies if I missed it).
>
> Similarly *other* parts that press us to upgrade JDK *runtime* should 
> be clearly articulated, analysed and possibilities evaluated; and 
> ideally decided upon. And maybe some contributor appears to help with 
> both the analysis and/or the necessary bridge. Maybe - but certainly 
> not when the idea is just waved off in absence of presentable data.
>
> So before concluding on anything, I propose these action items:
>
> - (?) anyone in regular touch with Gradle / Maven developers, so they 
> could share longer-term JDK support plans in their project ?
> - (*) get JDK platform stats out of AutoUpdate server logs, should be 
> available on netbeans vm
> - determine critical (unavoidable) external dependencies for platform 
> cluster; collect their JDK runtime support plans
> - collect (non-exhaustive, just known) list of non-platform modules 
> that are already known to serve as application library.
> - collect list of APIs from JDK11, JDK17 desirable to be actually used 
> in the codebase.
>
> (*) I volunteer to do this one. (?) I might be able to take this one 
> if noone else is willing to do so.
>
> I am sure others could (should) add their own action items, in their 
> areas of knowledge. It would be helpful not only to decide on JDK8 
> fate, but also on designing the migration path from JDK11 later. We 
> should decide for the best outcome of project users, anyway.
>
> -Svata
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists