Review request: 8004658: Add internal smart javac wrapper to solve JEP 139

[Jonathan Gibbons]

Important preliminary feedback.

In general, all test files must have a standard GPL copyright -- without 
classpath exception.  In general, the only exception is files where the 
line numbering is a significant part of the test, such as source files 
used to generate error messages containing line numbers, that will be 
compared against golden files.  That doesn't appear to be the case here, 
so copyright headers should be present.

Secondary.  It is ... disappointing ... to see a profusion of shell 
scripts coming in. In general, shell scripts have proved problematic and 
difficult to maintain. It would be much nicer to see this logic 
(eventually?) in java code.  Seeing "sleep" in test code is also ... 
disappointing ....    Also, if you used Java code, you would not have to 
be dealing with the cross-platform issues of the "ls" command!

In the test, you use TESTCLASSES where you should often be using the 
scratch (current) directory.

-- Jon

On 01/08/2013 06:32 AM, Fredrik Öhrström wrote:
> And here is an updated webrev, with cleanups and more tests.
>
> http://cr.openjdk.java.net/~ohrstrom/webrev-8004658-sjavac-v2/
>
> //Fredrik
>
> 2012/12/6 Fredrik Öhrström <fredrik.ohrstrom at oracle.com>:
>> This the smart javac wrapper that makes use of the javac hooks for reporting
>> dependencies.
>> The easiest way to test it, is to clone build-infra and use --enable-sjavac
>> with configure.
>>
>> After building, do "export PATH=build/.../jdk/bin:$PATH"
>> then you can do:
>> sjavac src -d bin --server:portfile=/tmp/myport
>>
>> The more sources you have under the src directory, the merrier. With enough
>> sources,
>> it will actually use multiple cores. Run it again, and nothing will happen,
>> since it
>> quickly determines that all artifacts are up to date. (add -h headers if you
>> expect
>> native method headers to be generated.)
>>
>> Try changing public methods, and recompile, dependent packages will be
>> recompiled.
>> Try changing private or package private methods, and recompile, only that
>> package will be recompiled.
>> Try changing a native method, the header file will be regenerated.
>>
>> The smart javac wrapper is not part of the final image. (The sjavac launcher
>> and its classes
>> in the tools.jar are explicitly stripped from the image.) It will remain a
>> build tool, while we
>> experiment and improve its multi core performance and evaluate how it should
>> integrated into the full product.
>>
>> The real test is of course, to add "public void helloWorld() {}" to
>> Object.java and
>> do "make LOG=info". Or add a native method to Adler32.java and watch
>> how the build system recompiles libzip.so (remember to do "make LOG=info")
>> to see the incremental build properly.
>>
>> http://cr.openjdk.java.net/~ohrstrom/webrev-8004658-sjavac/
>>
>> //Fredrik