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
