Re: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java: add some instrumentation which might illuminate the failure of 2016-09-14

2017-04-25 Thread Brian Burkhalter
Hi Amy, The status of test.dir is a little vague to some of us right now. Your comments are appreciated. Brian On Apr 25, 2017, at 6:32 PM, Amy Lu wrote: > On 4/26/17 12:06 AM, Brian Burkhalter wrote: >> Hi Amy, >> >> I think test.dir is preferred in case the folder location is specified to

Re: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java: add some instrumentation which might illuminate the failure of 2016-09-14

2017-04-25 Thread Amy Lu
On 4/26/17 12:06 AM, Brian Burkhalter wrote: Hi Amy, I think test.dir is preferred in case the folder location is specified to the harness. Yes, makes sense. (I'm not a reviewer.) Thanks, Amy Brian On Apr 24, 2017, at 8:22 PM, Amy Lu > wrote: I noticed somethi

Re: RFR: 8178298 (LdapLoginModule)Migrate the JNDI properties technote to javadoc doc-files

2017-04-25 Thread Vyom Tewari
On Tuesday 25 April 2017 08:41 PM, Chris Hegarty wrote: Vyom, On 24 Apr 2017, at 10:15, Vyom Tewari wrote: Hi All, Please review the simple doc fix. Webrev : http://cr.openjdk.java.net/~vtewari/8178298/webrev0.0/index.html Bugid : https://bugs.openjdk.java.net/browse/JDK-8178298

Re: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java: add some instrumentation which might illuminate the failure of 2016-09-14

2017-04-25 Thread Brian Burkhalter
Hi Amy, I think test.dir is preferred in case the folder location is specified to the harness. Brian On Apr 24, 2017, at 8:22 PM, Amy Lu wrote: > I noticed something else: > 148 Path zpath = Paths.get(System.getProperty("test.dir", "."), > > 272 Path zpath = Paths.get(Syste

Re: RFR: 8178298 (LdapLoginModule)Migrate the JNDI properties technote to javadoc doc-files

2017-04-25 Thread Chris Hegarty
Vyom, > On 24 Apr 2017, at 10:15, Vyom Tewari wrote: > > Hi All, > > Please review the simple doc fix. > > Webrev : http://cr.openjdk.java.net/~vtewari/8178298/webrev0.0/index.html > > Bugid : https://bugs.openjdk.java.net/browse/JDK-8178298 > > Note, this patch depends on "JDK-817872

Re: Accessing module internals from bytecode rewriting agent

2017-04-25 Thread Remi Forax
[...] > > Meanwhile, Mandy Chung has kindly offered to look into the security > considerations that are at play and come up with a less restrictive > policy which enforces the security needs more accurately. At that point > I will probably remove the fallback -- in part because I hope that by > t

Re: Accessing module internals from bytecode rewriting agent

2017-04-25 Thread Andrew Dinn
On 25/04/17 07:22, Alan Bateman wrote: > On 25/04/2017 04:26, Martin Buchholz wrote: > >> : >> >> java.lang.IllegalArgumentException: illegal lookupClass: class >> java.util.PriorityQueue >> >> Bytecode rewriting agents have the power to inject code into classes; >> they >> should somehow also be

Re: Accessing module internals from bytecode rewriting agent

2017-04-25 Thread Jeremy Manson
Thanks. It wouldn't have occurred to me that I needed to use a Java 9 API. I can't remember ever having an upgrade path for anything in any Java version for which I couldn't use the same code in Java N and Java N+1, if the use case was a supported part of the spec in both. The usual migration pa