RFR: 8010465: Can't enable sjavac when building in jprt.

Erik Joelsson erik.joelsson at oracle.com
Mon Apr 8 13:21:17 UTC 2013

On 2013-04-08 15:17, Anthony Petrov wrote:
> Thanks for clarifying that. Makes sense to me.
> The fix looks good to me, btw, although I'm not a build expert.
> Also, could you clarify why do Windows builds fail with sjavac? Is 
> this a known bug in sjavac or the build system?
It looks to me like a bug in sjavac. I have seen it work previously.

> -- 
> best regards,
> Anthony
> On 04/08/13 17:03, Erik Joelsson wrote:
>> Sjavac also enables parallel execution of java compilation, speeding up
>> full builds as well. But even if it didn't, being able to verify that
>> sjavac builds work in jprt will be a must if we are to enable it by
>> default.
>> /Erik
>> On 2013-04-08 14:56, Anthony Petrov wrote:
>>> Just curious: sjavac is supposed to address the issue with slow
>>> incremental builds. JPRT builds are full builds usually. What is the
>>> benefit of using sjavac for full builds?
>>> -- 
>>> best regards,
>>> Anthony
>>> On 04/08/13 13:44, Erik Joelsson wrote:
>>>> Reminder that I would like this reviewed.
>>>> /Erik
>>>> On 2013-03-21 12:49, Erik Joelsson wrote:
>>>>> This patch makes it possible to enable sjavac in jprt runs. This is
>>>>> achieved by adding -buildenv ENABLE_SJAVAC=true to the jprt command
>>>>> line.
>>>>> http://cr.openjdk.java.net/~erikj/8010465/webrev.root.01/
>>>>> Doing this uncovered another bug. Adding the keyword "nofile" to the
>>>>> LOG variable is done to disable logging build output to a file. JPRT
>>>>> does this on all build runs since it already saves the build output.
>>>>> The value of LOG is also sent to sjavac to help it filter its output,
>>>>> but sjavac does not accept "nofile" as input. The logic to remove
>>>>> "nofile" before sending it to sjavac didn't work and is also fixed in
>>>>> this patch.
>>>>> The sad news is that all the windows builds currently fail with 
>>>>> sjavac
>>>>> enabled, but having this feature will help us harden sjavac to the
>>>>> point where we can make the switch.
>>>>> /Erik

More information about the build-dev mailing list