Well, I'm listening.
Thanks for sharing the presentation!, I really enjoyed it. +1 for that
mustache!
Improve Java/JDK how exactly? I mean with nb-javac, I can still run
NetBeans on Java 11 and be able to develop for Java 19. If I'd do that
do I want to run that code on JDK 8 or JDK 11? No.
If for whatever reason I would like to have that code run on JVM 11, can
I configure my build script to use Frgaal? Yes I can.
If I would ask, does the IDE help me to configure my build script to use
Frgaal, on those (I assume minority cases). The answer is: No.
Would I use such a feature: probably not.
However, that's me. I think, that would be Ok, to create a module, which
provides project templates that are using Frgaal, in a separate
category, for Maven and Gradle, or if you brave enough for Ant as well.
Using Frgraal as Javac behind the scenes is big -1 for me. We just came
out of the external nb-javac ages. Finally the try to enable/disable
nb-javac issues are not on the top of the lists any more.
On 10/5/22 20:51, Michael Bien wrote:
-1 from me
some points reiterated from the other thread, the short version is:
- language, API and runtime in java land are not developed
independently, there are reasons for that, its a feature not a bug if
you double down on it, and the JDK does so.
- one consequence of this is that frgaal very likely won't be able to
support language features which rely on JDK APIs without injecting JDK
code which would be problematic (e.g String Templates), which means
that this isn't java anymore, its something in between two versions.
(not getting into the legal discussion since this is not my field)
- upgrading the JDK is easy in java compared to other popular
languages, and it tends to get easier once you escaped the claws of 8
- adding more reasons to stay on 8 is like digging a deeper hole,
while you actually want to get out of it
- I disagree that frgaal is just like nb-javac, since nb-javac is not
retrofitting the program it compiles, nb-javac is javac just
backported using refactoring rules so that it can run on JDK 8 while
producing the same result as regular javac. You can run NB on javac of
your JDK if you match the versions of the particular releases.
- NB creating a new java project for the user should create a new
java project and not something which almost resembles a current
version of java (the language), but not quite. Minus APIs and runtime
features.
- I am all for making it easier to work with new java versions. NB
could streamline a few use cases, for example by adding a java
platform combo box to the new-project-wizard and a configure button
which directly opens the "add Platform" dialog to configure and/or
download JDKs using the foojay discovery service. This would allow
someone who is running NB on 8 to setup a project which is using a
current JDK with a few clicks. A new user might not know that the JDK
downloader exists which hides behind Tools -> Java Platforms -> add
Platform.
However, there certainly are niche use cases for projects like frgaal,
just like there were with RetroWeaver when applets were trendy. Esp if
you are sure you never want to leave the hole you dug - if you
planning to get out of it, just work on the reasons which hold you
back, don't spend time to get comfortable there ;)
Since NB supports maven/gradle etc, it should do fine with frgaal just
as long you keep your NB up2date:
public static void main(String[] args) {
System.out.println("runtime: "+Runtime.version());
System.out.println("""
this feature requires
JDK 15+
""");
}
press play
[stdout] runtime: 11.0.16+8-LTS
[stdout] this feature requires
[stdout] JDK 15+
[stdout]
javap -verbose dev/mbien/mavenproject1/Mavenproject1.class | grep major
major version: 55
all i did was to configure the frgaal plugin in the pom.xml while
using stock NB 15 with its nb-javac 18.
best regards,
michael
On 05.10.22 19:47, Jaroslav Tulach wrote:
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
