It seems like the development speed for sjavac needs to be increased significantly, one JIRA bug, one 2 week review cycle, leads to one commit is much too slow. I belive it would be good to have a separate repository to do quicker development of sjavac, and test out all sorts of interesting stuff, after which a larger more polished review can be published here. I have now created such a high speed development repository and published my changes that I made over two late night hacks: https://bitbucket.org/jabberbeak/sjavac
I believe that now when the OpenJDK sources are modularized, we should move sjavac to its own "module" perhaps jdk.sjavac. I also published a blog post on the contents of the high speed development repository, called "The Smart Javac Wrapper JDK8 Backport with Extras" and it can be found here: http://fredrikohrstrom.blogspot.se/ On Fri, Aug 22, 2014 at 8:42 PM, Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote: > 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.gibb...@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/> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8054717 >>>> >>>> //Fredrik >>>> >>> >>> >> > >
