Re: RFR 8087307/9, new tests for ServiceLoader updates for module

Hi Felix, I have some comments as below: 1. Possible test gaps for Locating Order 1.1 providers in named module have high priority than providers in unnamed 1.2 ServiceLoader.load​(ModuleLayer layer, Class service) is not tested 2. Possible test gap for automatic module, it

Re: RFR 9 : 8180633 : Remove intermittent key from java/lang/ClassLoader/Assert.java

+1 Mandy > On May 18, 2017, at 3:59 PM, Brent Christian > wrote: > > Hi, > > The test: > java/lang/ClassLoader/Assert.java > > has been passing consistently on our automated test systems for quite a > while. The last recorded failure I found happened ~18

Re: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds (always ends in 000)

Hi Brian, looks good to me, although i am not JDK10 reviewer, one minor comment i think you can combine the below two statements to one rv = (jlong)sb.st_mtimespec.tv_sec * 1000; rv += (jlong)sb.st_mtimespec.tv_nsec / 100; rv= (jlong)sb.st_mtimespec.tv_sec * 1000

Re: RFR 8087307/9, new tests for ServiceLoader updates for module

Not a reviewer. Just noticed that tests don't have @modules. Is it better to include @modules when introducing new test? Thanks, Amy On 5/19/17 9:38 AM, Felix Yang wrote: Ping:) -Felix On 16 May 2017, at 4:59 PM, Felix Yang wrote: Hi there, please review the

Re: RFR 8087307/9, new tests for ServiceLoader updates for module

Ping:) -Felix > On 16 May 2017, at 4:59 PM, Felix Yang wrote: > > Hi there, > >please review the new tests added for ServiceLoader updates for module > system. > > Test bug: > >https://bugs.openjdk.java.net/browse/JDK-8087307 > > Webrev: > >

Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent

Hi Matthias, The fix looks good to me. It must be tested at least with the JTreg com/sun/jdi tests. Do you need a sponsor? Thanks, Serguei On 5/16/17 03:21, Baesken, Matthias wrote: Sure, I forward it to serviceability-dev . -Original Message- From: Alan Bateman

Re: RFR 9 : 8180633 : Remove intermittent key from java/lang/ClassLoader/Assert.java

Sounds fine Brent; thanks, -Joe On 5/18/2017 3:59 PM, Brent Christian wrote: Hi, The test: java/lang/ClassLoader/Assert.java has been passing consistently on our automated test systems for quite a while. The last recorded failure I found happened ~18 months ago. I propose that the

RFR 9 : 8180633 : Remove intermittent key from java/lang/ClassLoader/Assert.java

Hi, The test: java/lang/ClassLoader/Assert.java has been passing consistently on our automated test systems for quite a while. The last recorded failure I found happened ~18 months ago. I propose that the 'intermittent' jtreg key be removed from this test: -- diff -r ee3280639210

Re: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner

> On May 18, 2017, at 2:41 PM, Mandy Chung wrote: > > >> On May 18, 2017, at 2:37 PM, Igor Ignatyev wrote: >> >> >>> On May 18, 2017, at 2:34 PM, Mandy Chung wrote: >>> This comment is not related to the change. The

Re: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner

> On May 18, 2017, at 2:37 PM, Igor Ignatyev wrote: > > >> On May 18, 2017, at 2:34 PM, Mandy Chung wrote: >> This comment is not related to the change. The package name >> `jdk.test.lib.wrappers` is odd. TimeLimitedRunner and InfiniteLoop

Re: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner

> On May 18, 2017, at 2:34 PM, Mandy Chung wrote: >> On May 15, 2017, at 2:00 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html >>> lines changed: 2 ins; 88 del; 6 mod; >> >> Hi all, >> >>

Re: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner

> On May 15, 2017, at 2:00 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html >> lines changed: 2 ins; 88 del; 6 mod; > > Hi all, > > could you please review this small fix which removes TimeLimitedRunner class > from

Re: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner

Hi, still looking for a Reviewer. Cheers, -- Igor > On May 15, 2017, at 2:00 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html >> lines changed: 2 ins; 88 del; 6 mod; > > Hi all, > > could you please review this small

Re: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds (always ends in 000)

+1 On 5/18/2017 3:34 PM, Brian Burkhalter wrote: Oh, I guess I need a +1 from a JDK10 Reviewer. On May 18, 2017, at 12:23 PM, Brian Burkhalter wrote: Hi Brent, On May 18, 2017, at 11:43 AM, Brent Christian wrote: This will get

Re: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds (always ends in 000)

Oh, I guess I need a +1 from a JDK10 Reviewer. On May 18, 2017, at 12:23 PM, Brian Burkhalter wrote: > Hi Brent, > > On May 18, 2017, at 11:43 AM, Brent Christian > wrote: > >> This will get some good bake time in 10, a chance for

Re: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds (always ends in 000)

Hi Brent, On May 18, 2017, at 11:43 AM, Brent Christian wrote: > This will get some good bake time in 10, a chance for incompatibilities (if > any) to be revealed. Good point - thanks! Brian

Re: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds (always ends in 000)

Hi, Brian This looks fine to me. This will get some good bake time in 10, a chance for incompatibilities (if any) to be revealed. -Brent On 5/17/17 1:54 PM, Brian Burkhalter wrote: Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8177809 Patch:

Re: RFR(S) : 8180621 : remove jdk.testlibrary.management.InputArguments

> On May 18, 2017, at 11:19 AM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8180621/webrev.00/index.html >> 88 lines changed: 0 ins; 88 del; 0 mod; > > Hi all, > > there is no usage of jdk.testlibrary.management.InputArguments by jdk/test or >

RFR(S) : 8180621 : remove jdk.testlibrary.management.InputArguments

http://cr.openjdk.java.net/~iignatyev//8180621/webrev.00/index.html > 88 lines changed: 0 ins; 88 del; 0 mod; Hi all, there is no usage of jdk.testlibrary.management.InputArguments by jdk/test or any other tests, so this test library class can be removed. webrev:

Re: RFR(S) : 8180399 : move jdk.testlibrary.LockFreeLogManager to the top level test library

Paul, doh, too many review requests in parallel, thank you for providing the correct links. yes, you are right j/l/m/ThreadMXBean/Locks test does not depend on jdk testlibrary anymore, I have cleaned it up and retested: > * @author Mandy Chung > * @author Jaroslav Bachorik > * > - *

Re: JDK 10 RFR of 8180519: Windows FILETIME should be converted to and from ULARGE_INTEGER not LARGE_INTEGER

Hi Brian, Looks fine, Roger On 5/18/2017 12:03 PM, Brian Burkhalter wrote: Please review this change at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8180519 Patch: http://cr.openjdk.java.net/~bpb/8180519/webrev.00/ This change is probably inconsequential but does

JDK 10 RFR of 8180519: Windows FILETIME should be converted to and from ULARGE_INTEGER not LARGE_INTEGER

Please review this change at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8180519 Patch: http://cr.openjdk.java.net/~bpb/8180519/webrev.00/ This change is probably inconsequential but does make the code consistent with the documentation linked to the issue. Regression

Re: RFR(XS): move FilterClassLoader and ParentLastURLClassLoader to top level testlibrary

> On 17 May 2017, at 17:02, Paul Sandoz wrote: > > Are these classes used? If not should they be deleted? > +1 I found out that these classes are currently used in other places and it’s very convenient to keep ‘em around in the right test library location. Paul. >

RE: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent

Great, thanks ! -Original Message- From: Langer, Christoph Sent: Donnerstag, 18. Mai 2017 15:27 To: Baesken, Matthias Cc: Simonis, Volker ; Dmitry Samersoff ; core-libs-dev@openjdk.java.net;

RE: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent

Hi Matthias, I have added a jdk9-fix-request label to the bug and added a comment. Let's see if it gets approved for JDK9. Best regards Christoph > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On > Behalf Of Dmitry Samersoff > Sent: Dienstag,

Re: 9 (docs-only) RFR: 8180428: Clarify implementation note in Clock.java to match implementation changes made by JDK-8068730

Still looks good to me! Thanks, David On 18/05/2017 7:58 PM, Daniel Fuchs wrote: Hi, Please find below a clarification of the implementation note in Clock.java: 8180428: Clarify implementation note in Clock.java to match implementation changes made by JDK-8068730

9 (docs-only) RFR: 8180428: Clarify implementation note in Clock.java to match implementation changes made by JDK-8068730

Hi, Please find below a clarification of the implementation note in Clock.java: 8180428: Clarify implementation note in Clock.java to match implementation changes made by JDK-8068730 https://bugs.openjdk.java.net/browse/JDK-8180428 The change below was already discussed here:

Re: Getting a live view of environment variables (Gradle and JDK 9)

On 18/05/2017 6:19 PM, Cédric Champeau wrote: Can you elaborate as to why specifying the "big kill switch" --permit-illegal-access is not viable? Specifically if you use: -XX:+IgnoreUnrecognizedVMOptions --permit-illegal-access it should work on 9 and be ignored on earlier releases. mmm

Re: Getting a live view of environment variables (Gradle and JDK 9)

On 18/05/2017 09:35, Stephen Colebourne wrote: : I agree with Daivid that my expectation for the method System.getenv would be that it calls native code every time it is invoked assuming that the Javadoc didn't say otherwise (because environment variables are outside the Java universe). As

Re: Getting a live view of environment variables (Gradle and JDK 9)

On 18 May 2017 at 09:07, David Holmes wrote: > I'm quite surprised by some of the reactions here. Given the read-once > nature of System.getenv was never documented I expected most people to be > surprised that it took a snapshot-on-first-use, and that reading the actual

Re: Getting a live view of environment variables (Gradle and JDK 9)

> On 18 May 2017, at 09:07, David Holmes wrote: >> ... >> The reason to use a daemon is to avoid multiple starts of a JVM in-between >> steps in a build. > > Yes, though I've been looking at this from the actual API proposal > perspective, not the "how can we avoid

Re: Getting a live view of environment variables (Gradle and JDK 9)

> > > Can you elaborate as to why specifying the "big kill switch" > --permit-illegal-access is not viable? Specifically if you use: > > -XX:+IgnoreUnrecognizedVMOptions --permit-illegal-access > > it should work on 9 and be ignored on earlier releases. > > mmm that's interesting, I actually

Re: Getting a live view of environment variables (Gradle and JDK 9)

Hi Cedric, Starting a new sub-thread on this as I want to back up on something. Can you elaborate as to why specifying the "big kill switch" --permit-illegal-access is not viable? Specifically if you use: -XX:+IgnoreUnrecognizedVMOptions --permit-illegal-access it should work on 9 and be

Re: Getting a live view of environment variables (Gradle and JDK 9)

On 18/05/2017 5:46 PM, Kirk Pepperdine wrote: On May 18, 2017, at 6:15 AM, David Holmes wrote: On 18/05/2017 2:36 AM, Martin Buchholz wrote: Stop trying to add APIs to mutate environment variables. It's not going to happen! Not sure who or what you are

Re: Getting a live view of environment variables (Gradle and JDK 9)

> On May 18, 2017, at 6:15 AM, David Holmes wrote: > > On 18/05/2017 2:36 AM, Martin Buchholz wrote: >> Stop trying to add APIs to mutate environment variables. It's not going >> to happen! > > Not sure who or what you are directing this at Martin. Certainly I'm not

Re: Getting a live view of environment variables (Gradle and JDK 9)

Hi Cedric, I understand what you are trying to do, it is my opinion that you are trying to do this in a completely unexpected way. That the environment variables in the JVM are read only once is an issue in that a nohup should refresh them That all the code in the JVM may (or may not) react to

Re: Getting a live view of environment variables (Gradle and JDK 9)

Hi Cedric, On 05/16/2017 12:05 PM, Cédric Champeau wrote: Thanks Peter for your thoughts, but I don't think it's as simple as that. As I explained in my original email, there are multiple ways the environment variables can be mutated, and it can be done _externally_. Typically, during a task