Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Distributing GPLv2+CPEx licensed component in Apache software is hard

    • it would be way easier to use plain javac  from a JDK

    • nb-javac  has to be downloaded by end-user on demand via autoupdate
  • On demand download is problematic

  • Testing matrix is complicated

    • each supported JDK needs to be tested twice - with nb-javac  and without nb-javac 

  • Every bug/problem one needs to know whether nb-javac  was or wasn't in use

  • nb-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 `javac`

  • Upstream JDK javac hasn't been IDE ready up to JDK15
    • see below for details
  • Without NbJavac one needs to run NetBeans on latest JDK to get latest language features
    • Serious disadvantage compared to competitors IDEs
    • They have their own Java parsers and support latest features on any JDK
    • javac 

Eliminating the need for nb-javac

...

  • 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 Requiring to execute the IDE on latest JDK to try latest features 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 like itfind 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` javac  and let run it on JDK8! Of course, there are issues:

  • latest `javac` latest javac  is written in the language syntax of modern Java
    • such syntax cannot be compiled to JDK8 bytecode with `javac`
  • latest `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 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 example Optional.isEmpty()  method has been added in JDK11. Let's add following rule:

...

That automatically rewrites all occurences occurrences of optional.isEmpty()  to !optional.isPresent()  and that is going to compile on JDK8. Few more (~30) rules like this and the `javac` 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 with `javac` 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.

...

  • small extensions to allow parsing and attributing a "standalone" statement, expression, etc. in the given context.
  • small extensions to JavacTaskImpl to allow per-file per-phase parsing of multiple sources in the same instance of javac
  • access restrictions loosened for a lot methods/classes (private->protected, etc.)
  • inlineTags cache for ParamTagImpl and ThrowsTagImpl
  • string folding is disabled (by "disableStringFolding" option) to so that concatenated strings are represented by full trees
  • ToolProvider loads classes from context classloader
  • TreeInfo.symbolFor works all trees that refer to a symbol

What is the reason that nb-javac is a fork and not part of the javac main repository?

...

Taking a step back, what are the potential alternative Java parsing libraries to support the optional module for Java in NetBeans?

...