JDK-8054717 : SJavac should track changes in the public apis of classpath classes!
  • Type: Sub-task
  • Component: tools
  • Sub-Component: javac
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-08-08
  • Updated: 2015-07-07
  • Resolved: 2015-06-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b69Fixed
Related Reports
Blocks :  
Blocks :  
Blocks :  
Blocks :  
Blocks :  
Blocks :  
Blocks :  
Description
sjavac should track the public apis of the classes in the classpath, that the previous compiles has linked to. If the public api of the linked to classes has changed, then this should trigger a recompile of the appropriate sources.

This is a very useful feature. Currently sjavac must be fed all sources that belong to the product in a single huge compile. The OpenJDK is already at the limit of what fits in a reasonable (of today) sized Java heap.
Other products are significantly larger and therefore cannot make use of the incremental compile in sjavac.

With this feature, it is possible to compile the product as separate jar files, as long as the build dependencies for the jar files are a directed acyclic graph, then each succesive compile will detect if there were any changes in the public apis of the dependency jar files. If the public apis of the dependencies were not changed, and there were no other source  changes for that jar, it will not be recompiled! But if there were changes in the public apis of the dependencies, then only the appropriate parts of the jar will be recompiled!

This is solved by storing (in the javac_state file) references to classes on the classpath with the timestamp of the class and the jar. If the jar timestamp is not changed, then no further checking is done, if the jar timestamp is changed, then the class timestamps are checked, if a class timestamp is changed, then the public api is calculated and compared with the value in the javac_state file.

Previously javac_state contained a textual representation of the public api. This is no longer possible since the classpath public apis are huge! Instead the hash of the textual representation for each class is stored in the javac_state file.






Comments
This issue is blocked by JDK-8066725 since sjavac needs to be able to read class files on class path in order to extract the public api.
21-01-2015

Multiple parallel invocations of javac triggers erroneous SharedNameTable sharing.
21-01-2015