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/09/28 20:31:51 UTC
[DISCUSS] Supporting ecj in NetBeans
Supporting `ecj` in NetBeans makes no/little sense. Let's have a discussion to
agree on that.
Few times in the past (most recently at https://github.com/apache/netbeans/
pull/4682#issuecomment-1257208904) there was a note suggesting to support
`ecj`. Usually such suggestion appears whenever I propose to use http://
frgaal.org retrofit compiler.
Using `ecj` makes no sense - the biggest strength of NetBeans is its WYSIWYG
nature - errors in the editor are exactly the same as errors one gets on
command line when executing `mvn` or `gradlew`. That's because NetBeans relies
on the family of Javac compilers - be it `javac` from the latest JDK or our
own `nb-javac` port.
`ecj` is completely different compiler. It has own bugs, own view of Java
source code and it can never achieve the same WYSIWYG experience as `javac` in
NetBeans provides. Supporting `ecj` seems like a step backwards. I am not
going to stop anyone working on `ecj` support, but I believe the NetBeans
project will have better prospects when it adheres to the family of Javac
compilers.
As an author of https://cwiki.apache.org/confluence/display/NETBEANS/
Overview%3A+nb-javac plan, I believe there is no use of `ecj` in NetBeans.
-jt
PS: Yes, Frgaal does belong into the Javac family. It is a slightly modified
version of the `javac` from the latest JDK that removes the (artificial)
limitation that prevents `target < source`.
---------------------------------------------------------------------
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] Supporting ecj in NetBeans
Posted by Jaroslav Tulach <ja...@gmail.com>.
Dne čtvrtek 29. září 2022 19:40:37 CEST, Matthias Bläsing napsal(a):
> Hi,
>
> I'm the author of the referenced comment:
> https://github.com/apache/netbeans/pull/4682#issuecomment-1257208904
>
> there is not integration of anything into the IDE. It is about making
> "new" JDK features available to older bytecode targets.
Can I repeat your sentence, Matthias? Your comments "aren't related to
integration of anything into the (NetBeans) IDE"? Neither frgaal, neither ecj?
Is that really what you are saying? Then, great!
As nobody else expressed the desire to integrate `ecj` into NetBeans and
Matthias comments aren't proposing to add support for `ecj` into NetBeans
either, we can conclude that NetBeans are unlikely to support `ecj` in the
near future. Thank you all for sticking to such a wise decision.
NetBeans biggest strength is the close adherence to latest JDK `javac` which
provides the NetBeans users almost WYSIWYG experience when editing Java.
Errors, warnings they see in the editor are just like what they get on the
command line.
-jt
PS: Of course, when someone donates own work and decides to integrate `ecj`
into NetBeans, nobody is going to stop such effort. We are a friendly community
and happily accept contributions, right?
---------------------------------------------------------------------
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] Supporting ecj in NetBeans
Posted by Matthias Bläsing <mb...@doppel-helix.eu.INVALID>.
Hi,
I'm the author of the referenced comment:
https://github.com/apache/netbeans/pull/4682#issuecomment-1257208904
there is not integration of anything into the IDE. It is about making
"new" JDK features available to older bytecode targets. For this the
default maven javac is replaced by a fork of the OpenJDK javac named
frgaal.
In my comment I argue, that frgaal has little chance to ever upstream
its modifications to the javac. To my knowledge (sorry I have no
reference), it is a pretty clear decision of the OpenJDK developers,
that they don't want to implement a backporting compiler and it was
also an explicit decision, that the class version is bumped on each JDK
release independend of the question whether the bytecode really
changed. The latter, again from my memory, because compiling against a
newer JDK also implies using new APIs and thus is a protection
mechanism.
But there is an elephant in the room, which is ecj. Contrary to the
OpenJDK javac ejc has had backporting capabilities for a long time.
What is more ecj is the backend of Eclipse, which gives it, in my mind,
some OpenJDK fork. It also has better version coverage, which currently
(version 3.31.0) ranges from 1.3 to 18. Given that OpenJDK is dropping
support for 1.7, this is impressive.
If ecj can't compile code, that OpenJDK can compile or create different
behavior, it is either an error in one of the two javac or in the JLS.
I would people let use their runtime JDK as basis, then they get
consistent results. Everything else (especially backporting
compilation) is an advanced topic, that should be considered by people,
that know what they are doing.
Greetings
Matthias
Am Mittwoch, dem 28.09.2022 um 22:31 +0200 schrieb Jaroslav Tulach:
> Supporting `ecj` in NetBeans makes no/little sense. Let's have a discussion to
> agree on that.
>
> Few times in the past (most recently at https://github.com/apache/netbeans/
> pull/4682#issuecomment-1257208904) there was a note suggesting to support
> `ecj`. Usually such suggestion appears whenever I propose to use http://
> frgaal.org retrofit compiler.
>
> Using `ecj` makes no sense - the biggest strength of NetBeans is its WYSIWYG
> nature - errors in the editor are exactly the same as errors one gets on
> command line when executing `mvn` or `gradlew`. That's because NetBeans relies
> on the family of Javac compilers - be it `javac` from the latest JDK or our
> own `nb-javac` port.
>
> `ecj` is completely different compiler. It has own bugs, own view of Java
> source code and it can never achieve the same WYSIWYG experience as `javac` in
> NetBeans provides. Supporting `ecj` seems like a step backwards. I am not
> going to stop anyone working on `ecj` support, but I believe the NetBeans
> project will have better prospects when it adheres to the family of Javac
> compilers.
>
> As an author of https://cwiki.apache.org/confluence/display/NETBEANS/
> Overview%3A+nb-javac plan, I believe there is no use of `ecj` in NetBeans.
> -jt
>
> PS: Yes, Frgaal does belong into the Javac family. It is a slightly modified
> version of the `javac` from the latest JDK that removes the (artificial)
> limitation that prevents `target < source`.
>
>
>
---------------------------------------------------------------------
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] Supporting ecj in NetBeans
Posted by Michael Bien <mb...@gmail.com>.
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: 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] Supporting ecj in NetBeans
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 30 Sept 2022 at 16:01, Ernie Rael <er...@raelity.com> wrote:
> 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.
So, understand the caveats and use it?
> > 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.
This I think is a separate concern. There was a conversation some
time ago (pre-nbjavac inclusion) about running aspects of javac on the
target platform. I've not looked enough at Gradle support to know how
feasible falling back to running aspects of Gradle support on the
target platform is?
But ideally that would always be adapting to the platform NetBeans is
working with, not necessarily what it's running on.
> It seems like many on the team have strong opinions on what a proper
> developer should be doing;
I don't think any of the comments should be read in that way.
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] Supporting ecj in NetBeans
Posted by Eric Bresie <eb...@gmail.com>.
I think the intent has already been expressed well but it sounds (1) (2)
like ecj provides the same basic functionality as nb-javac does which has
basically become less of a concern for recent NB versions. So is there any
more value of an alternative here? If they want ecj shouldn't they just
stick with Eclipse if they prefer it?
Eric Bresie
ebresie@gmail.com
References,
(1)
https://stackoverflow.com/questions/3061654/what-is-the-difference-between-javac-and-the-eclipse-compiler
(2) https://stackoverflow.com/a/3061680/214665
On Fri, Sep 30, 2022 at 8:41 PM Michael Bien <mb...@gmail.com> wrote:
> forgot to reply to this part
>
> On 30.09.22 16:59, Ernie Rael wrote:
> > At a minimum, seems worth having a "try the newest language features"
> > option and/or NewProject category.
>
> NB can download JDKs (of any vendor or version, including EA builds).
> The option is a bit buried under
>
> tools -> java platforms -> add platform -> download JDK via foojay
>
> Neil and me recently added some improvements in that area and cleaned up
> the UI (should be all in NB 15), so feedback is appreciated esp if
> something doesn't work.
>
> I personally don't see why we would have to add a new project type for
> this or swap out a compiler of the generated new project. Maybe we could
> add a Java target setting (or registered JDK combo box?) to the
> new-project wizard and it would recommend downloading (and registering)
> a JDK if the target is not covered by the registered JDKs.
>
> 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] Supporting ecj in NetBeans
Posted by Michael Bien <mb...@gmail.com>.
forgot to reply to this part
On 30.09.22 16:59, Ernie Rael wrote:
> At a minimum, seems worth having a "try the newest language features"
> option and/or NewProject category.
NB can download JDKs (of any vendor or version, including EA builds).
The option is a bit buried under
tools -> java platforms -> add platform -> download JDK via foojay
Neil and me recently added some improvements in that area and cleaned up
the UI (should be all in NB 15), so feedback is appreciated esp if
something doesn't work.
I personally don't see why we would have to add a new project type for
this or swap out a compiler of the generated new project. Maybe we could
add a Java target setting (or registered JDK combo box?) to the
new-project wizard and it would recommend downloading (and registering)
a JDK if the target is not covered by the registered JDKs.
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] Supporting ecj in NetBeans
Posted by Ernie Rael <er...@raelity.com>.
> 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 <ne...@apache.org>
> Envoyé : jeudi 29 septembre 2022 13:02
> À : dev@netbeans.apache.org
> Objet : Re: [DISCUSS] Supporting ecj in NetBeans
>
> On Thu, 29 Sept 2022 at 03:51, Laszlo Kishalmi <la...@gmail.com> 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: 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
>
>
>
>
---------------------------------------------------------------------
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] Supporting ecj in NetBeans
Posted by Eric Barboni <sk...@apache.org>.
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 <ne...@apache.org>
Envoyé : jeudi 29 septembre 2022 13:02
À : dev@netbeans.apache.org
Objet : Re: [DISCUSS] Supporting ecj in NetBeans
On Thu, 29 Sept 2022 at 03:51, Laszlo Kishalmi <la...@gmail.com> 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: 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] Supporting ecj in NetBeans
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 29 Sept 2022 at 03:51, Laszlo Kishalmi
<la...@gmail.com> 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: 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] Supporting ecj in NetBeans
Posted by Jaroslav Tulach <ja...@gmail.com>.
> frgaal: compiler candy without new API, is just like alcohol-free beer.
One doesn't have to be completely drunk to enjoy the party...
> > they are not developed independently. Streams without lambdas would be
> > no fun.
...moreover this is the opposite implication!
There are many libraries that can benefit from using lambdas. Many libraries
that are easier to use with text blocks. Has there been any `record` in the
JDK-15, btw.?
Telling people to avoid using the latest and greatest Java features just
because they couldn't have fun with streams, is just completely missing the
point!
-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] Supporting ecj in NetBeans
Posted by Laszlo Kishalmi <la...@gmail.com>.
Michael sums it up well. I agree completely.
ecj until someone knock on the door and shows the work done is not worth
to discuss.
frgaal: compiler candy without new API, is just like alcohol-free beer.
On 9/28/22 16:10, Michael Bien wrote:
> Hi Jaroslav,
>
> I personally always liked the fact that NB is using the same compiler
> for the editor features as the project during build. Although it
> wasn't technically the same since it had some modifications, but this
> isn't the case anymore, since current NB uses the automatically
> backported nb-javac which is now identical except its language level
> (which also simplifies maintenance, yey!).
>
> Moving away from javac (or supporting both which would make somewhat
> sense for projects which build with ecj) would be likely a lot of work
> since it isn't using the same AST APIs as javac, I don't see this
> happening.
>
> Is someone proposing to work on that? If not, then we might not even
> have to discuss this further ;)
>
> regarding frgaal.
>
> Getting new language features in java is really easy, all you have to
> do is to upgrade the JDK and bump the language level. There are always
> multiple LTS releases available from several vendors and upgrades are
> usually not a lot of work (esp. when compared to other popular
> languages like python). JDK upgrades also provide new API, JDK lib and
> JVM improvements for free. API and language always goes hand in hand,
> they are not developed independently. Streams without lambdas would be
> no fun.
>
> Even javac and JDK libs are not developed independently. Programs
> compiled with Java 9+ language level will use invokedynamic for String
> code sections. Bytecode compiled with -release 8 will not (it can't
> since the API is not there: JEP 280).
>
> Features like String templates will be very hard for frgaal to support
> since those are not simple language features - it would likely have to
> somehow inject upstream JDK code which is problematic.
>
> frgaal to me is a last resort in situations where you can't upgrade
> the JDK, but for whatever reason really want a particular language
> feature. My default response to that would be: don't do it, its
> unlikely that just by adding a language feature will improve your
> productivity in any meaningful way (unless you do it for fun in a
> student project or something similar). We are also likely speaking of
> old projects, since green field projects have even less reasons to
> stick to old JDKs. There would be a lot of convincing work required to
> introduce frgaal in a project I am involved with, given the
> alternatives with their benefits (I am not saying that there is no
> niche).
>
> Projects like Frgaal (anyone remember Retroweaver?) were awesome back
> when applets were still there and everyone was afraid to use generics
> since it would reduce the amount of potential users which could run
> the applet.
>
> (there is also the non-technical POV: I am pretty sure you can't call
> it java anymore if you retropile(?) something, but IANAL)
>
> best regards,
> michael
>
>
> On 28.09.22 22:31, Jaroslav Tulach wrote:
>> Supporting `ecj` in NetBeans makes no/little sense. Let's have a
>> discussion to
>> agree on that.
>>
>> Few times in the past (most recently at
>> https://github.com/apache/netbeans/
>> pull/4682#issuecomment-1257208904) there was a note suggesting to
>> support
>> `ecj`. Usually such suggestion appears whenever I propose to use http://
>> frgaal.org retrofit compiler.
>>
>> Using `ecj` makes no sense - the biggest strength of NetBeans is its
>> WYSIWYG
>> nature - errors in the editor are exactly the same as errors one gets on
>> command line when executing `mvn` or `gradlew`. That's because
>> NetBeans relies
>> on the family of Javac compilers - be it `javac` from the latest JDK
>> or our
>> own `nb-javac` port.
>>
>> `ecj` is completely different compiler. It has own bugs, own view of
>> Java
>> source code and it can never achieve the same WYSIWYG experience as
>> `javac` in
>> NetBeans provides. Supporting `ecj` seems like a step backwards. I am
>> not
>> going to stop anyone working on `ecj` support, but I believe the
>> NetBeans
>> project will have better prospects when it adheres to the family of
>> Javac
>> compilers.
>>
>> As an author ofhttps://cwiki.apache.org/confluence/display/NETBEANS/
>> Overview%3A+nb-javac plan, I believe there is no use of `ecj` in
>> NetBeans.
>> -jt
>>
>> PS: Yes, Frgaal does belong into the Javac family. It is a slightly
>> modified
>> version of the `javac` from the latest JDK that removes the (artificial)
>> limitation that prevents `target < source`.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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] Supporting ecj in NetBeans
Posted by Michael Bien <mb...@gmail.com>.
Hi Jaroslav,
I personally always liked the fact that NB is using the same compiler
for the editor features as the project during build. Although it wasn't
technically the same since it had some modifications, but this isn't the
case anymore, since current NB uses the automatically backported
nb-javac which is now identical except its language level (which also
simplifies maintenance, yey!).
Moving away from javac (or supporting both which would make somewhat
sense for projects which build with ecj) would be likely a lot of work
since it isn't using the same AST APIs as javac, I don't see this happening.
Is someone proposing to work on that? If not, then we might not even
have to discuss this further ;)
regarding frgaal.
Getting new language features in java is really easy, all you have to do
is to upgrade the JDK and bump the language level. There are always
multiple LTS releases available from several vendors and upgrades are
usually not a lot of work (esp. when compared to other popular languages
like python). JDK upgrades also provide new API, JDK lib and JVM
improvements for free. API and language always goes hand in hand, they
are not developed independently. Streams without lambdas would be no fun.
Even javac and JDK libs are not developed independently. Programs
compiled with Java 9+ language level will use invokedynamic for String
code sections. Bytecode compiled with -release 8 will not (it can't
since the API is not there: JEP 280).
Features like String templates will be very hard for frgaal to support
since those are not simple language features - it would likely have to
somehow inject upstream JDK code which is problematic.
frgaal to me is a last resort in situations where you can't upgrade the
JDK, but for whatever reason really want a particular language feature.
My default response to that would be: don't do it, its unlikely that
just by adding a language feature will improve your productivity in any
meaningful way (unless you do it for fun in a student project or
something similar). We are also likely speaking of old projects, since
green field projects have even less reasons to stick to old JDKs. There
would be a lot of convincing work required to introduce frgaal in a
project I am involved with, given the alternatives with their benefits
(I am not saying that there is no niche).
Projects like Frgaal (anyone remember Retroweaver?) were awesome back
when applets were still there and everyone was afraid to use generics
since it would reduce the amount of potential users which could run the
applet.
(there is also the non-technical POV: I am pretty sure you can't call it
java anymore if you retropile(?) something, but IANAL)
best regards,
michael
On 28.09.22 22:31, Jaroslav Tulach wrote:
> Supporting `ecj` in NetBeans makes no/little sense. Let's have a discussion to
> agree on that.
>
> Few times in the past (most recently at https://github.com/apache/netbeans/
> pull/4682#issuecomment-1257208904) there was a note suggesting to support
> `ecj`. Usually such suggestion appears whenever I propose to use http://
> frgaal.org retrofit compiler.
>
> Using `ecj` makes no sense - the biggest strength of NetBeans is its WYSIWYG
> nature - errors in the editor are exactly the same as errors one gets on
> command line when executing `mvn` or `gradlew`. That's because NetBeans relies
> on the family of Javac compilers - be it `javac` from the latest JDK or our
> own `nb-javac` port.
>
> `ecj` is completely different compiler. It has own bugs, own view of Java
> source code and it can never achieve the same WYSIWYG experience as `javac` in
> NetBeans provides. Supporting `ecj` seems like a step backwards. I am not
> going to stop anyone working on `ecj` support, but I believe the NetBeans
> project will have better prospects when it adheres to the family of Javac
> compilers.
>
> As an author ofhttps://cwiki.apache.org/confluence/display/NETBEANS/
> Overview%3A+nb-javac plan, I believe there is no use of `ecj` in NetBeans.
> -jt
>
> PS: Yes, Frgaal does belong into the Javac family. It is a slightly modified
> version of the `javac` from the latest JDK that removes the (artificial)
> limitation that prevents `target < source`.
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
>