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
