On 30.09.22 16:59, Ernie Rael wrote:
> automatically backported nb-javac
I wouldn't say automatically makes it "technically the same"; I don't
know much about the mechanisms that do javac --> nbjavac, maybe it's
not that bad. If frgaal was automatically generated from javac, would
that make them the same and alleviate concerns about "non-standard"
java compiler?
thats true. Just because the mechanism which transforms source code is
automated does not mean that the result is equivalent. I had another
sentence behind that one you quoted. It is identical except the language
level (of the nb-javac library).
here are the jackpot rules:
https://github.com/JaroslavTulach/nb-javac/blob/master/make/langtools/netbeans/nb-javac/src/META-INF/upgrade/nbjavac.hint
The purpose of nb-javac is to allow users to run NB on JDK 11, 17 or
"current at release" - thats it. You can uninstall nb-javac and if you
are willing to run NB on a JDK with the same javac version the release
of NB was written against. For NB 15 it would be JDK 18, NB 16 will
require JDK 19.
I once proposed to not load the nb-javac module at all if the JDK
version is matching (might be doable without much effort) but this was a
little bit academic since both javacs are the same. The main reason I
proposed it was so that users who want to experiment with upstream JDKs
can simply launch NB on them without having to uninstall modules.
But thats super niche, an entry in a FAQ would probably have the same
effect ;)
> frgaal to me is a last resort in situations where you can't upgrade
the JDK
Like if you want your code to work as a generally available NetBeans
plugin? And NetBeans isn't the only example where a particular,
old/not-latest, jdk is required; I think it's pretty common.
then you have to stick to JDK 11. But if you are fine with the
consequences (i gave some examples in the original mail), and really,
really want particular language features while not wanting to bump the
requirement on your plugin: Do it ;)
Maybe we can even bump the NB JDK requirement to 17 on a future release
if there is interest from the community. This would also shrink the test
matrix.
> but for whatever reason really want a particular language feature.
At least for me, I want to become conversant with newer jdk features,
not simply one feature; that's enough reason for me to use frgaal and
it removes a great frustration. text block is first for my immediate
use; and there's a project I work with that "where" switch pattern
matching will be very useful (they're still on 1.8, thinking about
moving to 11); and using Record as I come across places where it
can/should be used to improve code quality is sweet.
of course! I have many hobby projects too which use ea jdks for
experiments. My blog runs on ea loom for over two and a half years by
now and logs directly to JFR, starts with jcriu etc. If frgaal helps you
with something like that - awesome. But we have to distinguish a little
bit between free time experiments and "serous business". I don't want to
discourage anybody to experiment with something like frgaal.
If i would use a nb plugin as free time project to get comfortable with
latest language features, i would simply bump the language level to
"current jdk" in the module manifest, put a disclaimer in the
description and encourage others to upgrade too. I wouldn't bother with
frgaal even there. Esp since it likely won't support the interesting
features anyway (string templates etc).
Why learn new language features but skip APIs? APIs are at least as
important.
> adapt to the platform NetBeans is working on
I don't like that as the only choice. I'm forced to use jdk-11 to run
NetBeans, because I have to use gradle 6.8.x and for some reason this
forces a jdk requirement on NetBeans.
time for nb-gradle to cover this issue (i am kidding!)
If frgaal is "technically the same" then why not use it? ...
it isn't. tldr of my previous mail: it doesn't produce java.
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
