RFR: 8054717: SJavac should track changes in the public apis of classpath classes!

[Andreas Lundblad]

Hi compiler-dev,

Here's a patch for JDK-8054717 which makes sjavac detect modifications of dependencies on the class path.

Description:
Change 1: Dependencies now tracked on class level rather than package level
Change 2: Changes in classpath classes now detected

How the sjavac recompilation logic works:

1. Taint files that
    A) have new mod times
    B) depend on classpath classes with new public apis
2. Compile tanited packages
3. For those classes whose public api changed, taint their dependents
4. Repeat from step 2 until no files are tainted


Motivation for Change 1:
In order to solve step 1B above, sjavac needs to look up the pub api of a classpath dependency. If all we have to work with is package dependencies, this is unnecesarily complicated. If we, on the other hand, have a fully qualified class name, we can simply look up the class symbol through the ClassFinder.

Class level dependency tracking also caters for less recompilation: If A only depends on pkg.B, it should not need to be recompiled if the pub api of pkg.C is updated.

Note that the previous decision of compiling only full packages still stands.


Left for future work:
- Optimization: Modtime detection classpath dependents to avoid unnecessary pub api lookup (JDK-8065996)
- The recompilation logic and dependency tracking should be done on the level of compilation units (JDK-8065995)
- Logic for dealing with ambiguous imports due to incremental change in the code (JDK-8065997)

Tests:
- All langtools tests pass
- Building the JDK works
- JPRT -bo works fine

Minor remarks:
- I had to mark the (Java)FileObjectWithLocation as @Trusted to avoid having javac wrap the file objects (and make the location information inaccessible).
- Public APIs, previously stored in strings and/or list of strings, is now stored as a proper PubApi class
- PubApiExtractor.java corresponds to what Fredrik called Compile.java in his verison of the patch
- The javac_state file is larger than before. java.base has the largest state file and it's on 7 MB. Should writing/parsing of this file turn out to take considerable amount of time, I have a couple of ideas to trim it down.


Link to web review:
http://cr.openjdk.java.net/~alundblad/8054717

Link to bug report:
http://bugs.openjdk.java.net/browse/JDK-8054717

-- Andreas Lundblad