Versions Compared

Key

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

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.

NetBeans 13 uses Javac from JDK 17!

  • Approved

    Jira
    serverASF JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId5aa69414-a9e9-3523-82ec-879b028fb15b
    keyLEGAL-563

  • Repository with automatically generated nb-javac
  • PR-3206 integrates the below proposed solution into NetBeans 1713.
  • 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) is problematic

  • 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

  • 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 

...