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

http://cr.openjdk.java.net/~iignatyev//8180399/webrev.00/index.html > 186 lines changed: 87 ins; 90 del; 9 mod; Hi all, could you please review this small patch which moves LockFreeLogManager class from jdk test library to the top level test library? this fix is a part of ongoing effort on

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

On 17/05/2017 6:21 AM, Martin Buchholz wrote: On Tue, May 16, 2017 at 12:29 PM, Chris Hegarty wrote: Re-reading/refreshing the env variables has come up before, in other contexts. As David pointed out [1], re-reading introduces no more risk than is already there (

Re: JDK 9 doc-only RFR of 8180353: FileOutputStream documentation does not indicate properly whether files get truncated or not

Hi Chris, Let’s skip the first revision (May 16, 2017, at 12:54 PM PDT) of the patch and go for this one instead: --- a/src/java.base/share/classes/java/io/FileOutputStream.java +++ b/src/java.base/share/classes/java/io/FileOutputStream.java @@ -91,6 +91,10 @@ * If the file exists but is

Re: RFR 8u Backport: 8179515: Class java.util.concurrent.ThreadLocalRandom fails to Initialize when using SecurityManager

Thanks Roger! David On 17/05/2017 2:54 AM, Roger Riggs wrote: Hi David, Looks fine. Roger On 5/16/2017 3:02 AM, David Holmes wrote: The existing code in 8u was a little different to 9, but the new code is identical (other than package names): webrev:

RFR(S) : 8180397 : remove jdk.testlibrary.IOUtils

http://cr.openjdk.java.net/~iignatyev//8180397/webrev.00/index.html > 92 lines changed: 0 ins; 81 del; 11 mod; Hi all, could you please review this small clean-up which removes jdk.testlibrary.IOUtils class from test library? IOUtils provides one method readFully(InputStream), which can be

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

http://cr.openjdk.java.net/~iignatyev//8180395/webrev.00/index.html > 200 lines changed: 101 ins; 99 del; 0 mod; Hi all, could you please review this small fix which move FilterClassLoader and ParentLastURLClassLoader class from jdk testlibrary to top level testlibrary? this fix is a part of

RFR(S): 8180391: move SerializationUtils to top level testlibrary

http://cr.openjdk.java.net/~iignatyev//8180391/webrev.00/index.html > 119 lines changed: 56 ins; 54 del; 9 mod; Hi all, could you please review this small fix which move SerializationUtils class from jdk testlibrary to top level testlibrary? jdk.testlibrary.SerializationUtils does not have

Re: RFR: 8180385: fix HTML issues in java.xml module

Hi Jon, Thank you for the explanation. Makes sense. No worries :-) Best Lance > On May 16, 2017, at 7:02 PM, Jonathan Gibbons > wrote: > > Lance, > > The name seemed unnecessary given the context of the method associated with > the doc comment (i.e

Re: RFR: 8180385: fix HTML issues in java.xml module

Lance, The name seemed unnecessary given the context of the method associated with the doc comment (i.e getNamespaceURI) and the preceding sentence: >> the following table describes the returned Namespace URI value for all possible prefix values: If that was editorial overreach, I

Re: RFR: 8180385: fix HTML issues in java.xml module

Hi Jon, Looks good. Thanks again! -Joe On 5/16/2017 3:27 PM, Jonathan Gibbons wrote: Please review these fixes to update the public doc comments in the java.xml module for HTML 5. Webrev: http://cr.openjdk.java.net/~jjg/8180385/webrev.02/ API: http://cr.openjdk.java.net/~jjg/8180385/api.02/

Re: RFR: 8180385: fix HTML issues in java.xml module

Hi Jon src/java.xml/share/classes/javax/xml/namespace/NamespaceContext.java - Was there a reason you omitted {@code getNamespaceURI(prefix)} when creating the caption? Looks pretty good otherwise > On May 16, 2017, at 6:27 PM, Jonathan Gibbons > wrote: > >

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

Hi, > On May 17, 2017, at 3:11 AM, Cédric Champeau > wrote: > > Hi Uwe, > > I already explained multiple times why we need this. Short answer: because > we must. Slightly longer answer: because the build environment, the daemon, > has to reflect the environment

RFR: 8180385: fix HTML issues in java.xml module

Please review these fixes to update the public doc comments in the java.xml module for HTML 5. Webrev: http://cr.openjdk.java.net/~jjg/8180385/webrev.02/ API: http://cr.openjdk.java.net/~jjg/8180385/api.02/ -- Jon

Re: [9] RFR: 8180375: Rename Provider to .spi.Provider

Naoto, The javadoc of getBundle(String, Module) and getBundle(String,Locale,Module) methods also mention the service type “baseName”Provider that needs update as well. Mandy > On May 16, 2017, at 2:52 PM, Mandy Chung wrote: > > >> On May 16, 2017, at 11:14 AM, Naoto

Re: [9] RFR: 8180375: Rename Provider to .spi.Provider

> On May 16, 2017, at 11:14 AM, Naoto Sato wrote: > > Hello, > > Please review the changes to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8180375 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8180375/webrev.00/ > >

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

On Tue, May 16, 2017 at 12:31 PM, Cédric Champeau wrote: > > So far the only suitable workaround I can think of is an agent that would > rewrite `System.getenv` to call our internal APIs. I'll suggest that in our > next meeting (which is happening 30 mins from now). >

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

Hi Jonathan, Bazel is a cathedral when Gradle is a bazaar, Bazel uses a controlled subset of Python as build language, and a strictly defined API that do not let you extend Bazel in an arbitrary way. Those two approaches, a strict DSL or a general purpose languages retargeted to be used as a

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

On Tue, May 16, 2017 at 1:03 PM, Jonathan Bluett-Duncan < jbluettdun...@gmail.com> wrote: > Hi Cédric, > > I don't know if it's been considered, but has anyone from the Gradle team > asked the Bazel team about this problem? > I'm not on the Bazel team, but ... they are focused on being hermetic

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

On Tue, May 16, 2017 at 12:29 PM, Chris Hegarty wrote: > > Re-reading/refreshing the env variables has come up before, in other > contexts. As David pointed out [1], re-reading introduces no more risk than > is already there ( if specified correctly ). > Adding a Java

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

Hi Cédric, I don't know if it's been considered, but has anyone from the Gradle team asked the Bazel team about this problem? They may have useful insight about this problem with `System.getenv`, considering that Bazel is apparently very fast and (partially) written in Java. I hope this helps.

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

I don't deny some people do not have the problem :) 2017-05-16 21:56 GMT+02:00 Uwe Schindler : > Hi, > > Another example is not having your problem is Jenkins CI: It maintains a > map of environment variables throughout the build. And you have to use that > a a state

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

Hi, Another example is not having your problem is Jenkins CI: It maintains a map of environment variables throughout the build. And you have to use that a a state container throughout the build. I have never seen a plug-in not using that, because it's fundamental to the whole build server. If

Re: JDK 9 doc-only RFR of 8180353: FileOutputStream documentation does not indicate properly whether files get truncated or not

Hi Chris, Thanks for the review. Here is a revised version, thanks to a comment from Daniel, which I think might be better: Thanks, Brian --- a/src/java.base/share/classes/java/io/FileOutputStream.java +++ b/src/java.base/share/classes/java/io/FileOutputStream.java @@ -91,6 +91,10 @@ *

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

Hi Mario, I'm not suggesting to change the JDK. My original email is about having a new API to get a live view. Alternatives, like new methods to refresh the view, are non-breaking (I think). I perfectly understand, and fully respect, the willingness not to break millions of developers, and

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

> On 16 May 2017, at 20:19, Mario Torre wrote: > .. > Regarding your example: > > """ > println System.getenv('MY_VAR') > > doesn't print "foo" after doing: > > MY_VAR=foo gradle printVar > """ > > I agree that the environment variables may change during the

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

2017-05-16 20:38 GMT+02:00 Cédric Champeau : > Let me rephrase: it's tiring to have to repeat why we need it, and why we > honor the contract of environment variables. Why is it so hard to admit the > JDK has a bug? Hello Cédric, I hope you don't take it wrong or

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

Let me rephrase: it's tiring to have to repeat why we need it, and why we honor the contract of environment variables. Why is it so hard to admit the JDK has a bug? I proposed different solutions for this, including non breaking changes (a new method). All I have in return is suggestions to change

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

I’m sorry you find it tiring, but I think you underestimate how high the bar is (and should be) for changing how Java works just because it’s inconvenient for your situation. In my view, you’re not remotely there on justifying this. By all means continue, but “this is too tiring” isn’t a

[9] RFR: 8180375: Rename Provider to .spi.Provider

Hello, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8180375 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8180375/webrev.00/ This is to change the package name of the resource bundle provider to a different one, by appending

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

Hi Uwe, I already explained multiple times why we need this. Short answer: because we must. Slightly longer answer: because the build environment, the daemon, has to reflect the environment from the CLI (or the IDE, in case we call using the tooling API), at the moment the build is executed. Why?

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

Hi, I still don't understand why you need to change the environment variables of the actual process. I was talking with Rémi about that last week, and it's not obvious to me why you need that. Sure, it is easier to change the environment of the actual process and then spawn a child process for

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

2017-05-16 18:57 GMT+02:00 Sanne Grinovero : > Hi Cédric, > > we use Gradle a lot in our team (Hibernate) and all your efforts to > make it faster are highly appreciated. > > I can assure you that during a normal day of work while we might > rebuild a project a few hundred

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

Hi Cédric, we use Gradle a lot in our team (Hibernate) and all your efforts to make it faster are highly appreciated. I can assure you that during a normal day of work while we might rebuild a project a few hundred times, I'll rarely have to change environment variables. Obviously I don't

Re: RFR 8u Backport: 8179515: Class java.util.concurrent.ThreadLocalRandom fails to Initialize when using SecurityManager

Hi David, Looks fine. Roger On 5/16/2017 3:02 AM, David Holmes wrote: The existing code in 8u was a little different to 9, but the new code is identical (other than package names): webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev.8u/ Bug:

Re: RFR(S): 8180195: remove jaxp testlibrary

Hi Joe, Frank, thank you for the review! Cheers, -- Igor > On May 15, 2017, at 8:21 PM, huizhe wang wrote: > > +1. Thanks Frank for checking. > > -Joe > > On 5/15/2017 7:50 PM, Frank Yuan wrote: >> Looks fine, although I am not a reviewer. >> >> Thanks >> Frank >>

Re: Java-Time Clock Implementation Note

I'll let you log the issue, as you'll know what flags to set to get it through the process! Stephen On 16 May 2017 at 15:39, Daniel Fuchs wrote: > Thanks Stephen, > > On 16/05/2017 15:32, Stephen Colebourne wrote: >> >> Its not terrible, but I think confusing enough it

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

2017-05-15 7:14 GMT+02:00 David Holmes : >> There would have to be a caveat on System.getenv(true) if we went that >> path, that it is up to the user to ensure it is called in as safe a >> manner as possible having regard to any concurrent updates in their >> application

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

Matthias, Looks good to me. -Dmitry On 2017-05-16 13:21, Baesken, Matthias wrote: > Sure, I forward it to serviceability-dev . > > -Original Message- > From: Alan Bateman [mailto:alan.bate...@oracle.com] > Sent: Dienstag, 16. Mai 2017 11:51 > To: Baesken, Matthias

Java-Time Clock Implementation Note

In JDK 9, the implementation of Clock has been improved to be better than millisecond in most cases [1]. However, I've just noticed that the Javadoc of the "Implementation Note" is now wrong. It says: "The clock implementation provided here is based on System.currentTimeMillis(). That method

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

Sure, I forward it to serviceability-dev . -Original Message- From: Alan Bateman [mailto:alan.bate...@oracle.com] Sent: Dienstag, 16. Mai 2017 11:51 To: Baesken, Matthias ; core-libs-dev@openjdk.java.net Cc: Simonis, Volker Subject:

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

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 execution, a JNI call performed by a random native tool could

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

Thanks for the explanation, David. That doesn't sound much more risky than what we already do today in getenv. Cheers, Dalibor -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE

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

On 16/05/2017 10:04, Baesken, Matthias wrote: Hello, could you please review this small change : http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/ it fixes a number of places in jdk.jdwp.agent where in case of an error it is attempted to write to NULL . Bug : JDK-8180413 : avoid

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

Hi Matthias, this definitely makes sense. If 'data' is NULL, one should not access its fields, except a hard crash is desired... Reviewed. Don't forget to update the copyright year. Best regards Christoph From: Baesken, Matthias Sent: Dienstag, 16. Mai 2017 11:05 To:

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

Hello, could you please review this small change : http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/ it fixes a number of places in jdk.jdwp.agent where in case of an error it is attempted to write to NULL . Bug : JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent

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

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: http://cr.openjdk.java.net/~xiaofeya/8087307/webrev.00/ Related product Changes:

Re: JDK 9 doc-only RFR of 8180353: FileOutputStream documentation does not indicate properly whether files get truncated or not

Looks good Brian. -Chris. > On 16 May 2017, at 02:27, Brian Burkhalter > wrote: > > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8180353 > Patch:[1] > > Thanks, > > Brian > > [1] Hg diff > > ---

Re: RFR 9 (doc) 8180319 : Update Serialization spec to omit obsolete serialver -show and change history

On 15 May 2017, at 16:58, Roger Riggs wrote: > > Please review editorial updates to the serialization spec to remove > obsolete serialver -show option and the obsolete change history. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-serialver-noui-8180319/ Looks

RFR 8u Backport: 8179515: Class java.util.concurrent.ThreadLocalRandom fails to Initialize when using SecurityManager

The existing code in 8u was a little different to 9, but the new code is identical (other than package names): webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev.8u/ Bug: https://bugs.openjdk.java.net/browse/JDK-8179515 9 changeset:

RFR: JDK-8180202: -XXaltjvm is not working anymore on MacOSX

Hi David, Please review simple fix for JDK-8180202, recall we hard coded "server", this is incorrect because the function CheckJvmType will determin the correct jvmtype based on jvm.cfg *or* path/jvmtype specified by -XXaltjvm. IMO all this needs to be cleaned up when jvm.cfg is removed.