On 10.04.23 06:20, Michael Bien wrote:
Hi Svata,
thanks for your detailed response, my reply is inline
On 10.04.23 01:16, Svata Dedic wrote:
I would also (now) ask to restrict from advocating language goodies
agreed. This whole discussion is almost exclusively about APIs and
bytecode levels. Language features come just as side effect of a JDK
upgrade as bonus on top.
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.
and
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 actually disagree here. The worse situation would be to have to
upgrade from 8 to 21 or take an even larger leap, since we waited so
long that there are no other LTS releases available under the "new"
OpenJDK release model.
The "new" OpenJDK release model has several LTS releases at the same
time. They are shorter, but the migration risk is lower once a project
escaped JDK 8 - since it was the last big release (by design!).
We can build all clusters and run CV tests on JDK 21 right now already
btw (#5653) and made progress with some high priority issues, e.g.
#4952, #4904. Neil's/Geertjan's installers ship with the latest JDK, I
am also always running NB on a recent JDK for testing purposes. There
is always the possibility to encounter migration specific issues, but
I don't see us missing a deadline any time soon because of that - I
think we can say with good confidence that NetBeans is working fine on
JDK 11+. (the majority of tests are now also running on JDK 11)
We should move to JDK 11 ASAP since time is running out as you pointed
out. I don't see any reason to wait longer just so that we forced to
skip LTS versions.
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
this is not about JDK 11 features specifically. The proposal is about
an upgrade policy. This goes beyond JDK 11. Even if JDK 11 would be
not super interesting feature wise, it is simply a step to the next
LTS release. If it is a boring step - even better for everyone involved.
I don't get why fighting the "new" OpenJDK release model is considered
a viable option here.
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 !!
I don't laugh. I would just point to the collection of NB versions out
there which work perfectly fine on XP (likely even better, since they
were built with different assumptions about hw and sw in mind). I can
tell you also with 99% certainty that if someone would file a XP
specific NB issue it would be simply closed or ignored. (maybe someone
will add a smiley there)
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).
Right, maven indexing is not mandatory and can be turned off via
options (NB 18 will have some more options, see #5646).
However, the impact is more than just completion/hints/etc in pom
files. For example some wizards will try to get a recent archetype by
checking the index (also a pending enhancement to improve the
experience there #5753). The index is more integrated than it might
seem at first glance.
I don't think gradle features use index queries right now, but they
could one day, since gradle projects often use maven repos for their
dependency management too. Adding index queries to gradle features
right now would be risky until we made progress with the current
situation.
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).
Correct. Some queries could be indeed covered by online services, see
#4971 for a prototype, although this doesn't come for free since those
services were not really designed with an IDE in mind. Some queries
won't work at all, e.g even a prefix search of groupIDs wasn't
supported last time I checked, latencies can be anything between 200ms
and 5s compared to close to instant from the local index.
Using queries in hints for example would be difficult with such
unpredictable latencies. Checking a pom file with 50 artifacts for
version upgrades could take less than a second using a local index and
minutes via the service (assuming we don't get throttled in the middle
of it).
The question here is again, whether we need Lucene 9.5.0 because of
new APIs, or because of its implementation progress.
3 reasons:
- Lucene 8.x is EOL, sticking to an EOL library is dangerous with no
upgrade path available, committing to JDK 8 would lock us in
- maven-indexer (speaking of the lib here, not of our IDE module)
requires JDK 11 too. To implement index filters we have to make some
changes upstream. Index filters would solve index size issues for
users which... well don't like large cache folders, we got a lot of
complaints about this btw. Same rule applies here, that would be
another EOL lib - this one does networking (!) which makes it worse
for reasons I don't have to explain.
- "implementation progress" is the "cherry on top": MT index
extraction and other under-the-hood improvements via Lucene which
improve performance without noteworthy changes on our side.
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
We can likely solve some of those problems without JDK 11. We already
"backported" a lucene bugfix by importing a class into our repo and
running some classloading tricks. Matthias made an experiment to cut
off the indexing impl entirely on JDK 8 etc.
But this will be a never ending story. Lucene is not only used for
maven indexing. It also is a core part of code scanning (and I think
this goes beyond java). However, this group of modules uses a far
older (#4697) version of lucene right now. I began upgrading it
locally but decided to pause it until maven-indexer is solved, since
it would face the same issues.
The next problem will be maven 4 itself which will likely drop support
for running on JDK 8 judging form discussions I had on apache slack
from a few weeks ago. We should ask again - I agree.
So yes NetBeans could continue to go this path but all we will have in
a few years on JDK 8 is a JTextArea with no features. We will also
spend a lot of time restructuring code and making cuts instead of
fixing bugs and adding features - this will only become more difficult
and more time intensive.
Don't let maven distract us here, I only kept mentioning it since that
was the area I have been working on. The whole java ecosystem moves
on: Jetty, Jakarta EE, Spring, Jenkins, Maven, Lucene, (...)
If we don't turn features off which use EOL libs, we would only
pretend to support JDK 8. Since users would be in the same situation
by using an EOL version of NetBeans itself. The only difference there
is that it would allow us to move to JDK 11 and give users an actual
upgrade path without all the extra steps.
and again: If someone would like to spin a NB LTS release -> now would
be a good time.
- 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).
I would recommend against adding such complexity. This might look sane
(and easy) at first glance but consider this: Not only will it make
testing more complex, it will also add difficult to cover scenarios,
e.g a broken index when someone starts NB on a different JDK since the
whole impl changes. Not to mention that users actually running on JDK
8, would obviously keep using EOL libraries - the better option would
be to turn the features off IMO.
This would also avoid having to maintain two implementations. This is
essentially like branching a LTS version of a (slowly growing) subset
of NB - not a fan of that idea.
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.
Well, we are running out of time. The JDK 8 issue isn't exactly new.
So if someone wants to analyze things even more, it should happen soon
IMO.
You might disagree here, but the burden is now on the JDK 8 proponents
to come up with reasons to stay on it till 2030. Moving to the "new"
OpenJDK release model is the obvious choice to me instead of trying to
fight it. Neal's LTS-1
sorry, typo I meant Neil of course :)
proposal is a conservative one, it includes even spacial casing for
selected modules etc.
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.
or someone (ideally more than one person) volunteers to branch a NB
LTS release and we can move on with the proposal :)
best regards,
michael
-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