Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Chris Hegarty
Igor, > On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: > > Hi Felix, > > I have suggested the exact opposite change[1-3] to fix the same problem. I’m sorry, but this is all just too confusing. After your change, who, or what, is responsible for building/compiling the test library dependencies?

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Daniel Fuchs
Hi Felix, This looks much better to me. Thanks! -- daniel On 01/06/2017 04:27, Felix Yang wrote: Hi Chris and Daniel, new webrev with a few of explicit builds than wildcard. http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ Thanks, Felix On 2017/5/31 18:20, Chris Hegarty wrote:

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Chris Hegarty
> On 1 Jun 2017, at 04:27, Felix Yang wrote: > > Hi Chris and Daniel, > >new webrev with a few of explicit builds than wildcard. > > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ This seems very odd to me: http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/test/sun/security

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Felix Yang
Hi Chris, updated webrev: http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ -Felix On 2017/6/1 17:11, Chris Hegarty wrote: On 1 Jun 2017, at 04:27, Felix Yang wrote: Hi Chris and Daniel, new webrev with a few of explicit builds than wildcard. http://cr.openjdk.java.net/~xiaofeya

RFR : 8181205:JRE fails to load/register security providers when started from UNC pathname

2017-06-01 Thread Seán Coffey
The recent JDK-8163528 fix caused a regression for JDK binaries launched with a UNC pathname. We can use the Paths class to create the required File. I managed to put a test together which should test this code path. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8181205/webrev/ JBS recor

Code Review Request, JDK-8181439 Test the jdk.tls.namedGroups System Property

2017-06-01 Thread Xuelei Fan
Hi Valerie, Please review the test update: http://cr.openjdk.java.net/~xuelei/8181439/webrev.00/ More test cases are added for FFDHE groups so as to check unavailable groups in some platforms or JDK releases. Thanks, Xuelei

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Igor Ignatyev
> On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: > > Igor, > >> On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: >> >> Hi Felix, >> >> I have suggested the exact opposite change[1-3] to fix the same problem. > > I’m sorry, but this is all just too confusing. After your change, who, or > wha

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Igor Ignatyev
> For example: doing this may be enough for now: > > * @build jdk.test.lib.process.* > > But what if in the future, jdk.test.lib.process is restructured to have a > private package jdk.test.lib.process.hidden? To work around > CODETOOLS-7901986, all the test cases that must be modified to t

Re: JPMS Access Checks, Verification and the Security Manager

2017-06-01 Thread Alex Buckley
On 5/23/2017 7:44 AM, Volker Simonis wrote: So maybe I rephrase my question a little more generally: Is it required for the verifier to do security and/or access checks during the verification phase or could/should these checks be postponed to runtime? The issue with verification errors due to m

RFR(XS) : 8180895 : java/security/AccessController/DoPrivAccompliceTest.java has to be improved

2017-06-01 Thread Igor Ignatyev
http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html > 81 lines changed: 37 ins; 23 del; 21 mod; Hi all, could you please review the fix which improves and refactors DoPrivAccompliceTest.java test? the test had several issues: - it did not fail if the java spawned by JavaToolUti

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Ioi Lam
On 6/1/17 1:17 PM, Igor Ignatyev wrote: On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: Igor, On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: Hi Felix, I have suggested the exact opposite change[1-3] to fix the same problem. I’m sorry, but this is all just too confusing. After your chang

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Ioi Lam
On 6/1/17 1:17 PM, Igor Ignatyev wrote: On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: Igor, On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: Hi Felix, I have suggested the exact opposite change[1-3] to fix the same problem. I’m sorry, but this is all just too confusing. After your chang

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Felix Yang
Hi Igor and Ioi, I partially agree with you. As initially stated in the proposal and bug(JDK-8181299 ), I don't think this patch is a fix but a quick workaround to make them runnable. "explicit" is reasonable for me. But "explicit" s

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Igor Ignatyev
Hi Felix, none of the jdk tests which fail w/ NCDFE: jdk/test/lib/process/StreamPumper depend on StreamPumper directly, they get this dependency transitively from jdk/test/lib/process/ProcessTools, so I don't see how you will find this good definition of "explicit" even for the failures at hand

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

2017-06-01 Thread Felix Yang
Igor On 2017/6/2 10:11, Igor Ignatyev wrote: Hi Felix, none of the jdk tests which fail w/ NCDFE: jdk/test/lib/process/StreamPumper depend on StreamPumper directly, they get this dependency transitively from jdk/test/lib/process/ProcessTools, That is why I think it is a bug too. so I don't