> 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?
> 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.
> 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.
> 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.
> I don't think it's fair to call those opinions short-sighted
Perhaps "near-sighted" would be more accurate ;-)
It seems like many on the team have strong opinions on what a proper
developer should be doing; I appreciate seeing opinions about best
practices. There seem to be two main issues: Is frgaal safe? Is making
it trivial to use the latest language features a good/distinguishing IDE
feature and one that user's would appreciate?
If frgaal is "technically the same" then why not use it? It comes down
to alerting the user if they set target < source.
At a minimum, seems worth having a "try the newest language features"
option and/or NewProject category. And it's easy to switch. BTW, I agree
that the "language-feature without library" is a hassle, but as far as
I've seen, the compile fails; so not too severe. It would be nice to
have an error shown while editing (is that about boot path?).
-ernie
On 9/29/22 9:27 AM, Eric Barboni wrote:
Hi,
I'm not very fluent on what is needed in NetBeans to get ecj to work if we
would like to. So difficult to say yes or no.
Will not be me integrating 😝 but cannot presume for others.
Best Regards
Eric
On the side of frgaal (an off topic)
Personnal side:
testing new jdk feature without messing up jdk settings Nice to have
but no need to retro to jdk 8; retro to current jdk is enough.
Cannot jump to far in jdk version (NetBeans has to be patched for that)
On teaching side could be cool, as most of our jdk are locked for a year so in
the second semester a new JDK comes and you cannot play with new apis :D.
Will also be drawback, frgraal setup project perfectly usable in NetBeans then
opened in another IDE, and some will complains that NetBeans generate code that
is outlined red (no matters if it compile).
And maybe more relevant sample than a helloword could also be nice :p
-----Message d'origine-----
De : Neil C Smith <[email protected]>
Envoyé : jeudi 29 septembre 2022 13:02
À : [email protected]
Objet : Re: [DISCUSS] Supporting ecj in NetBeans
On Thu, 29 Sept 2022 at 03:51, Laszlo Kishalmi <[email protected]>
wrote:
Michael sums it up well. I agree completely.
Yes, as always, pretty spot on!
frgaal: compiler candy without new API, is just like alcohol-free beer.
:-) Yes. Very much seems like a solution looking for a problem to me.
I'm not sure that comment was much in favour of ecj support as against pushing
frgaal as a good option for anything but very niche cases.
It's rare a PR gets -1, let only multiple, so I don't think it's fair to call
those opinions short-sighted. There are some good points raised in the PR
description, but no mention of frgaal there. A better discussion would be on
those points than ecj support.
Personally I think promoting the latest java(c) features is better done by
ensuring the IDE supports the latest JDK as best we can; as Eric suggested,
enhancing the templates to take more account of running / target platform (eg.
choose platform as first step?); and (from a somewhat biased position)
promoting installers that run NetBeans on a local, latest supported, JDK out of
the box.
Best wishes,
Neil
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
