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

[Jonathan Gibbons]

Fredrik,

Can you please explain the following some more:
> It is important that this public api scanning does not require a javac 
> server started though. 

This is /not/ the direction we want to take sjavac.  We want to change 
sjavac from its current client/server split to a (very) thin client, 
with most of the work happening in the server.   In some version of an 
ideal world, the client would be so simple it could be written in C and 
not invoke a JVM at all.   The client should just locate the server 
(starting it if necessary) and then dispatch its command line args to be 
processed in the server.

Doing more and more work in a cold unshared JVM to avoid doing work in a 
hot shared JVM seems like a bad way to go.

-- Jon



On 08/21/2014 01:42 AM, Erik Joelsson wrote:
> 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
>