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