Thank you Sváťa for writing this email. It open another "can of worms" in the "lazy consensus" thread - in my opinion clearly rendering the "lazy consensus" as obsolete.
I still need a bit of time to think about using your email strategically, but in any case I'm happy. I am no longer the only one who gets all the hater! Thank you Sváťo! -jt Dne po 10. 4. 2023 1:16 uživatel Svata Dedic <svatopluk.de...@gmail.com> napsal: > 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-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
