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