-
Sub-task
-
Resolution: Fixed
-
P3
-
None
-
b69
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8098597 | emb-9 | Andreas Lundblad | P3 | Resolved | Fixed | team |
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.
- backported by
-
JDK-8098597 SJavac should track changes in the public apis of classpath classes!
-
- Resolved
-
- blocks
-
JDK-8044133 Make sjavac the default in the build scripts
-
- Resolved
-
-
JDK-8043311 JEP 199: Smart Java Compilation, Phase Two
-
- Closed
-
- is blocked by
-
JDK-8066725 javac produces classfiles it cannot read
-
- Closed
-
-
JDK-8078261 Initialization of DocLint triggers out of order initialization of Dependencies
-
- Closed
-
-
JDK-8079335 The field Gen.stringBufferType is no longer needed (and not always initialized properly)
-
- Closed
-
-
JDK-8078600 Infinite loop when compiling annotations with -XDcompletionDeps
-
- Closed
-
-
JDK-8080870 Open up Dependencies for use from other packages
-
- Closed
-
- relates to
-
JDK-8055922 Work around sjavac limitation with public api tracking cross modules
-
- Resolved
-
-
JDK-8129562 JDK 9 build using boot-jdk classes instead of newly compiled classes
-
- Resolved
-