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 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
