On 24.10.22 16:02, Michael Bien wrote:
Hi Geertjan,
replies inline
On 24.10.22 12:49, Geertjan Wielenga wrote:
Hi all,
Right now, when we build NetBeans, we’re using the javac from the JDK
that
we’re using to do the build — so that we’re dependent on the JDK team,
which can decide to drop features.
_If_ the JDK team decides to drop features from javac. NetBeans would
have to find ways to work with the new situation. Anything else would
mean to truly fork javac (again) and maintain it just for NetBeans. I
don't think this is realistic. (remember: nb-javac is "just" an
automated backport which already is the best case scenario of a fork)
_If_ we are concerned about this scenario we should consider joining
the OpenJDK community outreach program to get enough lead time and
maybe the chance to influence decisions.
btw javac has actually a public API, it won't simply disappear from
one release to the other without warning
(https://docs.oracle.com/en/java/javase/19/docs/api/jdk.compiler/com/sun/source/tree/package-summary.html).
I would approach this from a different POV and ask why NB requires
nb-javac in the first place, instead of trying to find more stages in
the NB life cycle where we can add it.
Installers could install (globally or purely as RT for NB) the exact
version of the JDK (while opening the vendor axis if so desired) NB
was tested against. I also just finished a demo which (optionally)
downloads and extracts a "runtime JDK" into the netbeans folder, if
the zip distribution is started on a JDK which does not meet NB's
exact requirements (or it asks the user to set a path). This same hook
could also upgrade NB in place, even though this wasn't it's main
purpose and would be off topic to this discussion (although pretty
cool IMO).
I was actually thinking about recording a video right when I saw this
mail to show how first-launch would look/feel if the JDK requirement
is not met.
https://www.youtube.com/watch?v=8uEIqAd2JBk
(middle section sped up slightly)
description:
user starts NetBeans but only JDK 8 was found, bootstrapper makes a
disco API request, downloads and extracts JDK 19.0.1 and uses it as
runtime JDK ("Default Java Platform") for NetBeans. Subsequent starts
use the runtime JDK. All without nb-javac.
If the user would have had the required JDK version in the path, thanks
to an installer or otherwise configured e.g. via start
options/netbeans.conf, it would simply use it instead and start as usual.
-mbien
advantages:
- nb-javac is gone, all nb-javac issues are gone (we still fix
showstopper issues today which were introduced during NB 12's lifespan
e.g #4838) -> less maintenance instead of extra maintenance
- user runs on the latest JDK at the time of the NB release -> the
first java project created will have access to newest java APIs and
language features out of the box
- latest JVM/JDK performance enhancements for your favorite tool for
free -> once again: best available out of the box experience
- significantly simplified testing. We (and CI) test against one
exact distribution version, since NB controls the "runtime JDK" version
- user env setup issues reduced to a minimum
- NB could use up2date third party libraries and APIs without having
to find workarounds and patch their EOL java 8 versions (one security
vuln and someone will have a sleepness night, its just a matter of time)
- cleaner code in general, no weird platform selection logic in
editor hints for example which may or may not work dependent on which
JDKs the IDE has access to. Less workarounds, if (version > x),
reflection code etc.
- and yes, _if_ we wanted, we could use latest language features in
NB_the_IDE (while leaving platform or selected modules at 8), without
the workaround of frgaal-lang which only provides a subset of lang
features
- even plugin devs could use latest Java if they so desire (they
already can, but you know what I mean)
- ...
from a purely pragmatic perspective:
adding nb-javac to more stages of the lifecycle would solve issues
which don't exist right now while adding complexity and extra work. I
am also worried that this won't stop with nb-javac, the next obvious
step right after it would be frgaal. I addressed this in prev
discussions why I think this is a bad idea so I won't repeat it here.
It is worth mentioning that there is _still_ no GA version of nb-javac
19 (or 19.0.1) in maven central. NB16rc1 uses a build released months
(!) before GA. nb-javac does not maintain itself unfortunately, NB is
its only user - If this isn't working _today_ why would it work later?
Who of the NB community would like this extra task of maintaining
nb-javac and why do we have to wait before its part of the build too?
Adding more dependencies without having any assurances isn't very wise
- all things considered. The basic precondition for adding a
dependency of any kind is: does someone maintain it?
The Disco module, right now, cannot be compiled on JDK 8 because it sets
its target to 11, though if nb-javac were used during the build, because
nb-javac right now supports everything up to 19.
this is a non-issue. The getDownloadLink() method I wrote yesterday
night is 15 LOC long. The disco REST API is very easy to use, even
without the added convenience of the Java 11 disco client lib.
Comparatively speaking something like this disappears in the noise
when compared to the impact of swapping out and maintaining a compiler.
-0,99f from me (since I promised to not veto),
best regards,
michael
Gj
---------------------------------------------------------------------
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
