Dear Svata,
First of all, I would like you thank you for offering work to support
keep JDK8 alive!
Though reading through your mail, I'd wonder how JDK was able to evolve
beyond Java 8 it had 80+ percent usage in 2018.
The secret is that they forked/branched JDK. As you mentioned there are
still maintenance releases for JDK8. In the model Neil offered no one is
prevented to do maintenance releases for NetBeans 18 (or any previous
version of Apache NetBeans if he/she wishes). It seems there are people
willing to put work on that. That's really good and appreciated. "Some
modules that are of independent use (eg. lookup, utilities, etc.) might
be nominated and advertised to continue JDK 8 support for the time
being.", that would make the maintenance work easier.
It is also being said that "The IDE will continue to support users
developing projects for/with JDK 8, for as long as nb-javac and other
dependencies allow." . I think the team would understand if we keep our
Gradle Tooling library on JDK8 level for the foreseeable future.
On the you "offer coding help with compatibility bridges, analysis
and/or migration of the code" could be your next side-gig. Companies
using aged software shall pay the price. (You can still buy OS/2 named
Arca OS at the base price of $129, for a 6 months support). So you can
think of, with this change we open a possibility to monetize your
NetBeans knowledge.
On the data to be collected, well it would nice to see such a data,
though I do not think that should affect the decision. However you can
use such data to track the importance of keeping the JDK8 (JDK11)
support alive. That should erode with time.
On 4/9/23 16: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-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
---------------------------------------------------------------------
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