> On Dec 18, 2020, at 3:36 PM, Jaroslav Tulach <jaroslav.tul...@gmail.com> > wrote: > > 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...
... > > - 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 If such a JDK is installed, NB should use the tooling in it to support the latest features. NB should be able to run on JDK 17 while supporting an editor that is aware of JDK 19 features and using javac from the target JDK as needed. I think the best way forward is to work with plain javac and solve the “problems” above. > 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. But why? Just run JDK 17’s javac on JDK 17. If necessary, NB can create a separate process to handle this. > 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. I don’t think Jackpot will work for a method reference like Optional::isEmpty, will it? Jackpot is a workaround, not a solution. > 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. Instead let’s forget compiling and running on JDK 8. It’s old. We can’t stay in the past forever. The time has come to move on. Maybe for JDK 17? A policy of requiring the latest LTS JDK for the latest NB is reasonable to me. > Let's develop the new `nb-javac` and let's learn to love it! Doesn’t it make more sense to work toward making regular javac do what is needed? Regards, Scott
