Re: [DISCUSS] Shall NetBeans improve Java/JDK? Without Frgaal this time...
On Sun, 9 Oct 2022 at 18:21, Jaroslav Tulach 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-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
Re: [DISCUSS] Shall NetBeans improve Java/JDK? Without Frgaal this time...
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-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit:
Re: [DISCUSS] Shall NetBeans improve Java/JDK? Without Frgaal this time...
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
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-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
