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

Fredrik Öhrström oehrstroem at gmail.com
Fri Aug 8 22:22:29 UTC 2014

Here is very useful feature addition to sjavac, in fact it is required for
a modularized OpenJDK build (Jigsawified), where not all sources are sent
to sjavac at the same time.

sjavac should track the public apis of the classes in the classpath, that
the previous compile 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 the first draft of this large patch. In particular the new file
Compile.java is a misnamer, it does NOT compile, it is used to extract the
public apis of the classes on the classpath. Somehowe Compile.java should
perhaps be part of JavaService. It is important that this public api
scanning does not require a javac server started though.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140809/b593ed02/attachment-0001.html>

More information about the compiler-dev mailing list