Historically NetBeans project relies on nb-javac for Java editing features, i.e., parsing and lexing, for features such as syntax coloring, code completion, refactorings, and the like.
NetBeans 13 uses Javac from JDK 17!
- Repository with automatically generated nb-javac
- PR-3206 integrates the below proposed solution into NetBeans 13.
- PR-1 makes sure only Classpath exception covered files are used in the
- PR-3251 includes the here-in proposed Javac in all NetBeans complementary binaries
- PR-2783 allows compilation against JDK-17 Javac API - removes need for (reflection & co.) hacks
Javac from JDK is Great!
Relying on Javac has some positive aspects, but also some downsides.
- Adopting latest Java language features is simple(r)
- Errors, hints, warnings in the editor match exactly the command line build
- Close co-operation with JDK language team
On demand download (of newest javac on old JDKs) is problematic
user needs internet connection
- download server needs to be on (finally nb-javac is at least hosted on Maven central)
e.g. sometimes download fails
- Code is complicated
- Supporting multiple releases of javac (from different JDKs) complicates NetBeans code
- NetBeans code in
java.source& related modules if full of reflection
- NetBeans is using internal API of javac (Trees API) and it changes incompatibly with every release
Testing matrix is complicated
each supported JDK needs to be tested twice - with
every JDKs javac is a bit different
Every bug/problem one needs to know whether
nb-javacwas or wasn't in use
nb-javac-15isn't really stable
Oldnb-javac is a fork of JDK's javac
nobody likes forks
ironically Arvind's team is part of JDK organization - e.g. it maintains own fork of JDK's
Eliminating the need for nb-javac
Clearly there are numerous drawbacks and Apache NetBeans needs a way out. Let's get rid of
nb-javac as we know it. Let's replace it with JDK's own
javac ! However there are some problems...
javacin 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 NetBeans can really get rid of
nb-javac , the `javac` in JDK is needs to be good enough.
Using JDK 17 javac Instead
Let's now assume JDK17 offers good enough
javac , now NetBeans project can suggest/require people to use JDK17 to run 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
Requiring the latest JDK to execute the IDE is serious disadvantage compared to competitors IDEs, but possibly the story may end here and it might even be a good enough story for Apache NetBeans IDE. However...
Automatically Generating nb-javac
However, I don't find the restriction of latest JDK satisfying. It is not good enough story yet. There are parties that want to run on the IDE on some Java LTS version and still support the latest Java features. To address their needs let's take JDK17's
javac and let run it on JDK8! Of course, there are issues:
javacis written in the language syntax of modern Java
- such syntax cannot be compiled to JDK8 bytecode with `javac`
javacis 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 existing Apache NetBeans tools! Rather than maintaining manual patches like
nb-javac does, let's write advanced refactoring rules and apply them automatically. For example
Optional.isEmpty() method has been added in JDK11. Let's add following rule:
That automatically rewrites all occurrences of
!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! Run few tests to verify the behavior remains the same after the automatic transformation and that's all. People can use Apache NetBeans IDE 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.