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

[Jonathan Gibbons]

I think the path to a thin Java client is relatively quick and easy.

Once you have located the server, you just have to change the protocol 
to send argv over the connection and accept stream output coming back.  
The bulk of the code that currently lives in the fat client can equally 
well exist and be executed in the server.

The bug that Eric described in his message of 08/21/2014 01:42 AM sounds 
as much like a bug in the build as in sjavac. If a file in a module is 
modified, in the worst case, all dependent modules should be recompiled. 
Yes, that is suboptimal, but at least it would give correct class 
files.    sjavac may provide the means to reduce the set of modules that 
need to be recompiled, but the build should be capable of behaving 
reasonably even without sjavac.

-- Jon


On 08/22/2014 08:02 AM, Fredrik Öhrström wrote:
> The path to a super thin client is quite long with a lot of 
> interesting technical problems (I suppose that is why the royal we has 
> not authorized  RFR:8044131 since that does not reach the thin client 
> in one go, but is a mere first step) however classpath dependency 
> tracking is needed now.
>
>
>
> 2014-08-22 0:05 GMT+02:00 Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>>:
>
>     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/>
>             <http://cr.openjdk.java.net/%7Eohrstrom/webrev-8054717-classpathdep/>
>
>             https://bugs.openjdk.java.net/browse/JDK-8054717
>
>             //Fredrik
>
>
>
>

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