Hello devs,

just a short status update and a few things to keep an eye on for the next 
releases.


The master branch is now able to build and run on JDK 26-ea b24, CI was updated 
via #9017.

This means NB 29 is on a good path, only nb-javac 26 is missing (but some 
changes of the
valhalla javac experiment might be transferable #8995).

NB 30 will adjust the lower bound of the build/run requirements to JDK 21, 
following
the build/run policy[1](, also last confirmed/discussed in [2]).

Other than that it should remain uneventful. crosses fingers.

 - - - 

For NB 31 and later we have to keep an eye on build and runtime warnings (meta 
issue: #8256).

There are two areas in particular:
 - for-remaval API usage in dependencies
 - misc.Unsafe mem access API usage in dependencies (which will throw UOE from 
JDK 27 onward)

-> which boils down to updating dependencies.


We reduced quite a bit of technical dept in past releases, but there is still 
more to do.

lucene 3.6 is ancient. Updating it is a little tricky but might be doable, I 
started a wip 4.0
branch a while ago which focused first on few modules (see comment in #8384).
If we don't manage to update: there is a plan B for patching out the 
misc.Unsafe usages
which are mostly in old lucene's memory tracking utility (update is preferable 
obviously).
(we would have to get it to 5.x at least and could probably take a 
stabilization break there for
a release or two)

NB's osgi binding is also ancient and unsurprisingly uses for-removal API. 
Getting #9020 through first will
likely make any osgi impl changes easier. (please help Laszlo with that effort)

truffle/GraalVM integration, uses misc.Unsafe too. Tests use GraalVM 22.3.1, 
which I believe is
based on JDK 17. If those things are not updated in time, they might get 
disabled for releases or
end up being removed.

guava was fixed in past and #9021 fixes guice

there might be more to discover.

- - -


Whenever there is time I try to slip some sweeping deprecation fix PRs in. Even 
though they
are mostly chore, they still reduce the log file size and improve observability 
(#8927, #8940 etc).

More than once, seamlessly trivial refactoring did also discover/fix real 
issues.

reviews welcome ;)

best regards,

michael


[1] 
https://cwiki.apache.org/confluence/display/NETBEANS/Minimum+JDK+build+and+run+policy
[2] https://lists.apache.org/thread/omt7lfqjvjbfc83w8q8886gnjg8d6syf


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



Reply via email to