You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Jaroslav Tulach <ja...@gmail.com> on 2022/10/09 17:21:03 UTC
Re: [DISCUSS] Shall NetBeans improve Java/JDK? Without Frgaal this time...
Thank you for your reactions.
If you dedicated 40 minutes and watched my "Forget/Ignore Kotlin, use Java19"
talk at https://www.youtube.com/watch?v=ua-8ySwFgqg and didn't get convinced
about anything, then I doubt additional email messages can change something.
Anyway thanks for your reactions, I've only received positive feedback so far.
Emmanuel wrote:
> PS I loved the beard, I didn't recognize you at first glance
Laszlo wrote:
> Thanks for sharing the presentation!, I really enjoyed it. +1 for that
> mustache!
Thank you guys. This is why I was avoiding barber since the COVID outbreak!
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. The benefit is obvious - one will be able to build on JDK 37+ ;-) While
JDK's `javac` compiler drops supported target options like crazy, JDK still
knows how to execute even the oldest bytecode. By having a compiler "part of
the build script" - our builds will be more reproducible in the future, even
with the newest JDKs.
Please note that for this to happen, I'll be fine with any javac family
compiler available on Maven central. E.g. I will use `nb-javac`: https://
cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac
I'd start slower this time by eating our own dog food. I'd just modify
NetBeans build script to compile NetBeans source with nb-javac. This shall be
the non-controversial part of "improve Java by mimicking Kotlin" project - all
comments I've heard so far attack other aspects - nobody criticized including
a compiler into the build script vision.
Best regards and keep the comments coming. I am reading them all.
-jt
Dne středa 5. října 2022 19:47:24 CEST, Jaroslav Tulach napsal(a):
> Hi.
> Recently I brought [Frgaal retrofit compiler](http://frgaal.org) to your
> attention again. There was a [PR-4682](https://github.com/apache/netbeans/
> pull/4682) and then a discussion in the thread about (not) supporting ecj in
> NetBeans: https://lists.apache.org/list.html?dev@netbeans.apache.org -
> thank you for your comments.
>
> It all boils down to a simple question: Shall NetBeans try to improve
> shortcomings of the JDK?
>
> I have recently given a talk [Forget/Ignore Kotlin, use Java19](https://
> www.youtube.com/watch?v=ua-8ySwFgqg). There is a slide describing the
> benefits of Kotlin around 5th minute. Clearly the fact that the Kotlin
> language quickly evolves and still can be used to generate JDK8 code is a
> huge benefit.
>
> Frgaal (described around 25 minute) can do the same. It has been modeled to
> mimic the Kotlin model:
> - language specification independent of the JDK
> - compiler version specified as part of project build script
>
> Moreover Frgaal is 100% compatible with future Java language specification -
> easy to drop it after switching to newest JDK. Overall it is way easier to
> adopt latest Java thru Frgaal than trying to switch to a completely new
> language. Why do I have to explain it again and again?
>
> NetBeans can support Frgaal without any problems as it is also (just like
> nb- javac) a member of the Javac family. All these compilers generate
> exactly the same errors and provide the same WYSIWYG experience. Same
> errors in the IDE, same on the command line, same on the CI.
>
> All that is needed is: We have to realize that "innovation happens
> elsewhere" and make Java better than the one produced by the JDK team!
>
> Anyone has guts to follow better-than-JDK vision? Then let me integrate
> Frgaal into NetBeans and bring the latest Java language features to users
> of older JDKs.
> -jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Shall NetBeans improve Java/JDK? Without Frgaal this time...
Posted by Neil C Smith <ne...@apache.org>.
On Sun, 9 Oct 2022 at 18:21, Jaroslav Tulach <ja...@gmail.com> wrote:
> Emmanuel wrote:
> > PS I loved the beard, I didn't recognize you at first glance
>
> Laszlo wrote:
> > Thanks for sharing the presentation!, I really enjoyed it. +1 for that
> > mustache!
>
> Thank you guys. This is why I was avoiding barber since the COVID outbreak!
:-) ... or should that be :-})
> I believe that Java ecosystem would be better, if we adopted some of these
> benefits as well.
I enjoyed the presentation, although I also think the Java ecosystem
is better for the current JDK development cycle. The Java ecosystem
might be better for adopting some of these benefits. I remain dubious
it's the right thing for this project to be at the vanguard of this
...
> Let's only focus on the first two now. Let's make the compiler part of the
> project build script first ...- all
> comments I've heard so far attack other aspects - nobody criticized including
> a compiler into the build script vision.
Well, there was criticism of using Frgaal *by default* in end-user
build scripts. I happen to agree a lot with something else you've
said about NetBeans in the past, its benefit of being a transparent
(WYSIWYG?) UI to the build system. Which to me means in this regard
we should always be taking a lead on standard user defaults from Maven
and Gradle themselves.
In terms of NetBeans' own build, I have mixed feelings. I would note
that using Frgaal in NetBeans' build was previously vetoed, so I'd be
interested to see how concerns and impacts raised in that are
addressed differently with this proposal. eg. I remember one concern
being about non-standard build tools in relation to the IDE and
platform applications inside Linux distros. Everything that Michael
says in this thread certainly needs consideration.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Shall NetBeans improve Java/JDK? Without Frgaal this time...
Posted by Ernie Rael <er...@raelity.com>.
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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Shall NetBeans improve Java/JDK? Without Frgaal this time...
Posted by Michael Bien <mb...@gmail.com>.
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Shall NetBeans use fixed version of javac compiler?
Posted by Jaroslav Tulach <ja...@gmail.com>.
FYI: I've prepared https://github.com/apache/netbeans/pull/4795
Just like Kotlin offers two benefits:
> and Ernie nicely summarized them as:
> > - language specification independent of the JDK
> > - compiler version specified as part of project build script
I believe it is beneficial to bring those benefits to Java as well. Let NetBeans
project benefit from using NbJavac more!
-jt
Dne neděle 9. října 2022 19:21:03 CEST, Jaroslav Tulach napsal(a):
> Thank you for your reactions.
>
> If you dedicated 40 minutes and watched my "Forget/Ignore Kotlin, use
> Java19" talk at https://www.youtube.com/watch?v=ua-8ySwFgqg and didn't get
> convinced about anything, then I doubt additional email messages can change
> something. Anyway thanks for your reactions, I've only received positive
> feedback so far.
> Emmanuel wrote:
> > PS I loved the beard, I didn't recognize you at first glance
>
> Laszlo wrote:
> > Thanks for sharing the presentation!, I really enjoyed it. +1 for that
> > mustache!
>
> Thank you guys. This is why I was avoiding barber since the COVID outbreak!
>
>
> 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. The benefit is obvious - one will be able to build on JDK 37+ ;-) While
> JDK's `javac` compiler drops supported target options like crazy, JDK still
> knows how to execute even the oldest bytecode. By having a compiler "part
> of the build script" - our builds will be more reproducible in the future,
> even with the newest JDKs.
>
> Please note that for this to happen, I'll be fine with any javac family
> compiler available on Maven central. E.g. I will use `nb-javac`: https://
> cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac
>
> I'd start slower this time by eating our own dog food. I'd just modify
> NetBeans build script to compile NetBeans source with nb-javac. This shall
> be the non-controversial part of "improve Java by mimicking Kotlin" project
> - all comments I've heard so far attack other aspects - nobody criticized
> including a compiler into the build script vision.
>
> Best regards and keep the comments coming. I am reading them all.
> -jt
>
> Dne středa 5. října 2022 19:47:24 CEST, Jaroslav Tulach napsal(a):
> > Hi.
> > Recently I brought [Frgaal retrofit compiler](http://frgaal.org) to your
> > attention again. There was a [PR-4682](https://github.com/apache/netbeans/
> > pull/4682) and then a discussion in the thread about (not) supporting ecj
> > in NetBeans: https://lists.apache.org/list.html?dev@netbeans.apache.org -
> > thank you for your comments.
> >
> > It all boils down to a simple question: Shall NetBeans try to improve
> > shortcomings of the JDK?
> >
> > I have recently given a talk [Forget/Ignore Kotlin, use Java19](https://
> > www.youtube.com/watch?v=ua-8ySwFgqg). There is a slide describing the
> > benefits of Kotlin around 5th minute. Clearly the fact that the Kotlin
> > language quickly evolves and still can be used to generate JDK8 code is a
> > huge benefit.
> >
> > Frgaal (described around 25 minute) can do the same. It has been modeled
> > to
> > mimic the Kotlin model:
> > - language specification independent of the JDK
> > - compiler version specified as part of project build script
> >
> > Moreover Frgaal is 100% compatible with future Java language specification
> > - easy to drop it after switching to newest JDK. Overall it is way easier
> > to adopt latest Java thru Frgaal than trying to switch to a completely
> > new language. Why do I have to explain it again and again?
> >
> > NetBeans can support Frgaal without any problems as it is also (just like
> > nb- javac) a member of the Javac family. All these compilers generate
> > exactly the same errors and provide the same WYSIWYG experience. Same
> > errors in the IDE, same on the command line, same on the CI.
> >
> > All that is needed is: We have to realize that "innovation happens
> > elsewhere" and make Java better than the one produced by the JDK team!
> >
> > Anyone has guts to follow better-than-JDK vision? Then let me integrate
> > Frgaal into NetBeans and bring the latest Java language features to users
> > of older JDKs.
> > -jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists