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:[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
