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
