Hi. After enumerating the `nb-javac` deficiencies (below) and writing a plan to address them at our wiki https://cwiki.apache.org/confluence/display/NETBEANS/ Overview%3A+nb-javac I am here with implementation of the automatic conversion of JDK16(!, yes we are half a year ahead the plan!) `javac`. Please join me in reviewing and discussing the consequences for NetBeans here or in the PR#12:
https://github.com/oracle/nb-javac/pull/12 Manually written nb-javac is dead. Long live the new nb-javac! -jt On Dec 18, 2020 [I wrote](https://lists.apache.org/thread.html/ r5f210c99b0926aeaac2d0c3c419ff4b79e01f15b67c5ddcf32a51bbe%40%3Cdev.netbeans.apache.org%3E): > Hi. > First and foremost. I admire the work Arvind & his team are doing while > maintaining [nb-javac](http://github.com/oracle/nb-javac). I am sure they > don't hate it. Neither do I, but let's talk about the rest of us who have > some concerns... > > > Our love and hate relationship to nb-javac needs to be resolved. We > > suggest people to go without it, then we suggest people to try that. > > Also with the current release we see an increased amount of NPE-s and > > parsing errors. > > > > > > Two directions of thinking: > > 2. we need to get rid of nb-javac. > > #2 is a long term (~ a year) thing. I've been discussing possible ways > > to implement #2 and I think it can be done, > > if JDK's javac is improved with currently missing IDE-friently > > capabilities. > > > More on that in a separate email later. > > OK, this is the email. Let's enumerate the "haters": > > - Apache doesn't like `nb-javac` as it is GPLv2+CPEx component and those > are hard to distribute > - it would be way easier to use plain `javac` from a JDK > - distribution is problematic - needs internet connection and nb-javac > isn't yet on Maven central > - testers hate `nb-javac` as it multiplies the matrix of things to test > - each JDK needs to be tested twice - with `nb-javac` and without > `nb-javac` > - with every bug/problem one needs to know whether `nb-javac` was or > wasn't in use > - recent version `nb-javac-15` isn't really stable, see complains on the > mailing list > - maintainers of JDK's `javac` hate `nb-javac` because it is a fork of > their own work > - nobody likes forks > - ironically Arvind's team is part of JDK organization - e.g. it > maintains own fork of JDK's `javac` > > Clearly there are numerous drawbacks and we need a way out. Let's get rid > of `nb-javac` as we know it. Let's replace it with JDK's own `javac`! > Great, right? But there are problems... > > - `javac` in JDK15 isn't good enough > - compile on save doesn't work > - re-compilation of a single method doesn't work > - runs out of memory more often than `nb-javac`. > > Before we can get rid of `nb-javac`, we need to be sure `javac` in JDK is > good enough. I let Jan Lahoda (a JDK engineer working on `javac`) comment > and solve(!) this somehow. Let's now assume JDK17 offers good enough > `javac`, now we: > > - suggest people to use JDK17 when using Apache NetBeans IDE > - not a big problem, JDK17 is LTS, but then? > - if people wanted to use language features of JDK19, they'd have to run > on 19! > - that's not what competition does - they support latest language > features running on JDK11 LTS or even JDK8 LTS > > The story may end here and it can be a good enough story for Apache > NetBeans IDE. However, I don't like it. It is not good enough story yet. I > & OracleLabs want to run on LTS and support the latest Java features. As > such I am ready to make sure JDK17's `javac` runs on JDK8. Can anything > stop me? > > - latest `javac` is written in the language syntax of modern Java > - such syntax cannot be compiled to JDK8 bytecode with `javac` > - latest `javac` is using APIs not available on JDK8 > - one needs to rewrite these calls to some older APIs > - the behavior needs to be tested to remain the same > > The great revelation is that both these problems can be solved with > [Jackpot](https://netbeans.apache.org/jackpot/index.html)! Rather than > maintaining manual patches like `nb-javac` does, let's write Jackpot rules > and apply them automatically. For example `Optional.isEmpty()` method has > been added in JDK11. Let's add following rule: > > ```jackpot > $1.isEmpty() :: $1 instanceof java.util.Optional > => > !$1.isPresent() > ;; > ``` > > That automatically rewrites all occurences of `optional.isEmpty()` to > `!optional.isPresent()` and that is going to compile on JDK8. Few more > (~30) rules like this and the `javac` is almost ready to run on JDK8! Then > we need to run some tests to verify the behavior is same as of JDK's > `javac` and then we'll be where I want us to be: > > People can use Apache NetBeans with `javac` from the latest JDK or they can > use the automatic port of the same code running on JDK8. Ideally the > behavior shall be identical. No more questions: Are you using nb-javac or > not? No more duplicated testing matrix. > > Moreover vendors of applications built on top of NetBeans can decide > whether they include `nb-javac` port or not. OracleLabs will include it as > we really want our tools to run on GraalVM based on JDK8 and still support > the latest Java features. > > Let's develop the new `nb-javac` and let's learn to love it! > -jt --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
