Page tree
Skip to end of metadata
Go to start of metadata

An explanation of the key aspects to the place and purpose of nb-javac. 

(INCOMPLETE WORK IN PROGRESS.)

What is nb-javac?

"nb-javac" consists of two libraries (nb-javac-api.jar and nb-javac-impl.jar) that provide a NetBeans-specific fork of the Java JDK Java compiler.

What exactly does nb-javac do?

NetBeans uses nb-javac for the Java Editor, i.e., parsing and lexing for features such as syntax coloring, code completion, and the like.

Where is nb-javac found in the NetBeans Mercurial repo?

In a separate repository: hg.netbeans.org/main/nb-javac

Where is nb-javac found in the NetBeans installation directory?

In the "java" folder, provided by the "java" cluster, see: Overview: NetBeans Structure

Is nb-javac going to be Apache licensed?

No. nb-javac is not part of Oracle's donation of NetBeans to Apache.

How can nb-javac be distributed, given that it will not be Apache licensed?

Of course of paramount importance is that the user encounters no problems at all and that NetBeans as always works out of the box. The most obvious mechanism to installing nb-javac is to do it in the same way as done for JUnit (before JUnit licensing changed and it became a standard part of NetBeans), i.e., during installation a question can be asked "Which languages would you like to work with?" and if Java is chosen nb-javac will be downloaded and installed:

wiki.apidesign.org/wiki/AutoUpdate

What does nb-javac do that's different to vanilla javac?

A few years back, the NetBeans team wrote a page describing what nb-javac does in addition to/differently to vanilla javac:

http://wiki.netbeans.org/JavacDiff

Looking at the page now, some of the things listed above are not part of nb-javac anymore (e.g., cancelling and some part of the error recovery paragraph) but it still gives a reasonable overview and is good to get an idea what kinds of things nb-javac does. 

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

  1. The pace at which javac/JDK moves and at which NetBeans moves is simply different. E.g., imagine a refactoring breaking a user's code because of error recovery misbehaving. Once the problem is found it may be fixed in nb-javac in hours or days. Fixing it in javac can easily take weeks or even months (and much more effort in testing and review). 

  2. Even some changes that from the NetBeans point may look innocent may be hard to get into vanilla javac. For example, when javac detects a syntax error, it normally ends without getting to a semantic analysis. This does not work for an IDE (noone probably wants to lose almost all features just because a semicolon is missing). But it may be difficult to push through a fix to semantic analysis for a syntactically broken code (sometimes this passed before, other times, there was a pushback on such changes, depending on the nature of the change needed). 

  3. Some of the changes in nb-javac may be very hard to get in unless it has another user than just NetBeans.

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

  1. Write a new library/compiler. Not quite realistic.
     
  2. Use some other than javac (like from Eclipse). Not sure what would be the differentiator between Eclipse and NetBeans? Would result in incompatible changes and probably almost a complete re-write of the existing Java support in NetBeans (unless the Java support itself would be taken from Eclipse as well, which aside from everything else would be a lot of rework too). 
     
  3. Use a vanilla (unpatched) javac from the current runtime JDK. Besides other complexities, one would need to run on JDK 9 to get the possibility of JDK 9 support (and on, e.g., Valhalla to get the possibility of having Valhalla support), which might possibly lead to workarounds for differences/bugs between JDK versions. Plus, we might run into trouble with strong encapsulation. 
     
  4. Use a vanilla (unpatched) javac corresponding to a particular revision from the OpenJDK, but let NetBeans have a firm (binary) copy against which it would run, regardless of which runtime JDK would be used. Still a significant endeavour. 
     
  5. Keep nb-javac as it is now. Certainly the least amount of work and complexity.

Show me the patch!

hg clone http://hg.netbeans.org/main/nb-javac/
cd nb-javac
hg diff -r 8e9e1a2373a4 -r 061355d195b

Note: It is huge (this full patch has more that 35000 lines, though that includes additional tests, additional project metadata, etc). The wiki page above gives a better overview of what the patch does.

There are about 10k LLOC with additional tests and about 10k LLOC of modifications with the main purpose of exposing more internals and better error recovery.

 

 

  • No labels