Let me confess that I'm not sure what is proposed, in my simplistic view
it's letting NB users have target less than source. I don't entirely
understand all the stuff this msg is addressing.
But considering these points
- How useful is frgaal for NB/java user community? Makes NB more
attractive?
- What are the risks? (remember nb-javac hell)
- What are the problems? (language vs API)
It does seem from the msg and the following statement in particular:
> make maintenance harder for no real benefit
"target < source" is not of any real use to the NetBeans/java community.
The added NetBeans complexity is a giant risk.
I don't understand all the stuff related to "Why would a project like NB
want to compile to Java 8 ...". Is that suggested?
-ernie
On 10/9/22 2:46 PM, Michael Bien wrote:
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: [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
---------------------------------------------------------------------
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
