Re: RFR: 8010465: Can't enable sjavac when building in jprt.
Hello, Is anyone looking into this issue (on the jbs, noone is assigned)? This has been biting me as well on Windows builds quite a while. Naoto On 4/8/13 7:11 AM, Alexander Scherbatiy wrote: On 4/8/2013 5:21 PM, Erik Joelsson wrote: 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. It also failed on my Windows system. There is the created issue: 8008641 Build fails with the --enable-sjavac option Thanks, Alexandr. /Erik -- 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
Re: RFR: 8010465: Can't enable sjavac when building in jprt.
Erik, Would you like me to look at this? -- Jon On 04/11/2013 10:56 AM, Naoto Sato wrote: Hello, Is anyone looking into this issue (on the jbs, noone is assigned)? This has been biting me as well on Windows builds quite a while. Naoto On 4/8/13 7:11 AM, Alexander Scherbatiy wrote: On 4/8/2013 5:21 PM, Erik Joelsson wrote: 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. It also failed on my Windows system. There is the created issue: 8008641 Build fails with the --enable-sjavac option Thanks, Alexandr. /Erik -- 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
Re: RFR: 8010465: Can't enable sjavac when building in jprt.
Good to know this is unrelated to this fix. Thanks. -- best regards, Anthony On 4/8/2013 17:21, Erik Joelsson wrote: 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. /Erik -- 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
Re: RFR: 8010465: Can't enable sjavac when building in jprt.
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
Re: RFR: 8010465: Can't enable sjavac when building in jprt.
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
Re: RFR: 8010465: Can't enable sjavac when building in jprt.
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? -- 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
Re: RFR: 8010465: Can't enable sjavac when building in jprt.
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. /Erik -- 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
Re: RFR: 8010465: Can't enable sjavac when building in jprt.
On 4/8/2013 5:21 PM, Erik Joelsson wrote: 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. It also failed on my Windows system. There is the created issue: 8008641 Build fails with the --enable-sjavac option Thanks, Alexandr. /Erik -- 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
Re: RFR: 8010465: Can't enable sjavac when building in jprt.
Looks ok with me. ;^) -kto On 4/8/13 2:44 AM, Erik Joelsson erik.joels...@oracle.com 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
Re: RFR: 8010465: Can't enable sjavac when building in jprt.
Hi Erik: This looks good - approved. Sorry for the delay. Tim 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
