On 09.10.22 19:21, Jaroslav Tulach wrote:
However let's return back to the topic of the talk. Kotlin has some benefits
and Ernie nicely summarized them as:
- language specification independent of the JDK
- compiler version specified as part of project build script
- language quickly evolves
- still can be used to generate JDK8 code
I believe that Java ecosystem would be better, if we adopted some of these
benefits as well.
Let's only focus on the first two now. Let's make the compiler part of the
project build script first. That will detach the compiler/language from the
JDK.
I would advice against this. NetBeans has to deal with many compiler and
JDK versions in various stages already. There is the JDK it runs on,
nb-javac, the javac of the project platform. There are tests which use
nb-javac, some use the javac of the test JVM, others use a different JDK
in addition to the test JVM's JDK. I don't feel adding another layer and
splitting the build into JDK and javac version is helping the situation.
I would try to go the opposite route and remove layers.
To give a positive example: the simple fact that NB is allowed to ship
nb-javac now, enabled us to remove a lot of reflection code and even
some bytebuddy hacks (this resolved many bugs). Now imagine for a moment
if NB could ship the rest of the JDK too. We could remove nb-javac, and
we would have 1 axis in the test matrix of the java cluster. And 1-2
axis everywhere else. So simple that you can explain the build and
runtime setup of NB to someone in a minute.
This is a very academic goal in my opinion. Why would a project like NB
want to compile to Java 8 bytecode when there is JDK 37? NB couldn't
even use third party libraries which have record APIs since they would
be on the wrong bytecode level! Not to mention the APIs of JDK 37.
Language and API do go hand in hand - that is a feature, not a bug. If
this would have to change, it would have to be within the OpenJDK project.
The java ecosystem is moving forward. It has to. Spring, Jakarta EE,
jetty, jenkins, lucene... all bump their JDK requirements (Spring 6
jumps directly to JDK 17 for example). The current version of lucene
requires JDK 11. What are we supposed to do now? Lucene 8.x which is
used in the maven modules, already has a custom, at runtime loaded patch
which is backporting a bugfix to keep things going. Should NB fork
lucene 9? nb-lucene? The JDK downloader module is also using JDK 11 APIs
and depends on libraries on the same bytecode level. Dealing with those
issues would be all unnecessary extra steps which make maintenance
harder for no real benefit.
The JDK requirement sets the baseline contract between libraries. The
ecosystem has to bump the JDK version otherwise it can't interface on a
higher baseline.
Please, lets not add another layer of complexity just to have arrows in
switch. Sticking to 8 while everything is moving on is not realistic
IMO. I would argue that remaining on 8 is counter productive for the
ecosystem. Lets go with the flow and bump versions at a reasonable pace,
while giving everyone the opportunity to upgrade. There are always
multiple LTSes available at any given point in time which allows
adoption "at your own pace". JDK 8 was the last big Java release.
Upgrades after that are much smaller steps. LTSes are now shorter but
are also released at a higher rate.
Not too long ago NB couldn't even build on JDK 11 or 17. NB still can't
test all clusters on 11. The nbm maven templates have to learn the java
module system somehow, since it is not obvious which add-opens flags an
application has to set etc. So much to do to improve the OpenJDK
experience while also moving forward.
There are also still quite some java 1.5 rawtype warnings left before
having to worry about arrows in switch of frgaal-lang ;)
-0,99f from me
best regards,
michael
---------------------------------------------------------------------
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
