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

Erik Joelsson erik.joelsson at oracle.com
Thu Aug 21 08:42:31 UTC 2014


I can't comment on the code quality of this patch, but I do think this 
feature is important. I can't recommend people to try sjavac with a 
straight face at the moment as it will no longer guarantee a correct 
incremental build. The current behavior when I add a public field to 
java/lang/Object is that all of java.base is recompiled, then the rest 
of the modules are sent to sjavac (as make thinks they need to be 
recompiled) and sjavac does nothing with them.

/Erik

On 2014-08-09 00:22, Fredrik Öhrström wrote:
> 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.
>
> http://cr.openjdk.java.net/~ohrstrom/webrev-8054717-classpathdep/ 
> <http://cr.openjdk.java.net/%7Eohrstrom/webrev-8054717-classpathdep/>
>
> https://bugs.openjdk.java.net/browse/JDK-8054717
>
> //Fredrik



More information about the compiler-dev mailing list