Page History

Historically NetBeans project relies on (nb-)javac  for javac  for Java editing features, i.e., parsing and lexing, for features such as syntax coloring, code completion, refactorings, and the like. This has some positive aspects, but also some downsides. Read more about nb-javac in Differences: nb-javac.

Pros:

• 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

Cons:

NetBeans 13 uses Javac from JDK 17!

• Approved

  Distributing GPLv2-CPE licensed component in Apache software is hard (however possible

  Jira
  server ASF JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key LEGAL-563

  at the end)

  • 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
• 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 nb-javac  generated binary
• 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.

Pros:

• 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

Cons:

• On demand download (of newest javac on old JDKs) On demand download 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 nb-javac  and without nb-javac 

  • every JDKs javac is a bit different

• 
  

• 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

• Old nb-javac  is  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 

...

Let's now assume JDK17 offers good enough javac  , now NetBeans project can suggest/require people to use JDK17 when using 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 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...

...

That automatically rewrites all occurrences 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! 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.The PR-12 implements here-in proposed conversion.