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

On Wed, May 17, 2017 at 2:15 PM, David Holmes wrote: > On 18/05/2017 2:36 AM, Martin Buchholz wrote: > >> >> Yes, Java still has a serious startup performance problem; that should >> be attacked more directly. >> > > ?? Not sure what startup has to do with the topic here. There would be less ne

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

It’s this one :-) https://bugs.openjdk.java.net/browse/JDK-8180399 http://cr.openjdk.java.net/~iignatyev/8180399/webrev.00/ Does the Locks test need to depend on stuff in /lib/test

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

Are these classes used? If not should they be deleted? Paul. > On 16 May 2017, at 17:01, Igor Ignatyev wrote: > > 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

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

+1 Paul. > On 16 May 2017, at 16:52, Igor Ignatyev wrote: > > 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

Re: Proposal: javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()

> From: Alan Bateman > To: Andrew Guibert > Cc: core-libs-dev@openjdk.java.net > Date: 05/12/2017 04:02 AM > Subject: Re: Proposal: > javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder() > > On 11/05/2017 22:25, Andrew Guibert wrote: > Alan, could you please commit this patch for m

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

> On May 17, 2017, at 3:06 PM, Naoto Sato wrote: > > Revised the fix according to your suggestions: > > http://cr.openjdk.java.net/~naoto/8180375/webrev.01/ > http://cr.openjdk.java.net/~naoto/8180375/webrev.01-00/ (change since ver.00) Looks okay to me. Thanks Mandy

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

Revised the fix according to your suggestions: http://cr.openjdk.java.net/~naoto/8180375/webrev.01/ http://cr.openjdk.java.net/~naoto/8180375/webrev.01-00/ (change since ver.00) Naoto On 5/16/17 3:09 PM, Mandy Chung wrote: Naoto, The javadoc of getBundle(String, Module) and getBundle(String

Re: RFR: JDK-8180447: Trailing space in JDK_JAVA_OPTIONS causes an application fail to launch

> On May 17, 2017, at 11:46 AM, Henry Jen wrote: > > Hi, > > Please review a trivial fix for JDK-8180447[1], which we also makes the > output of options picked up by the environment variable in one line instead > of two for easier extraction from output. > > Cheers, > Henry > > [1] http://c

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

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 suggesting any API to mutate environment variables. This is about an API to re-read an alr

Re: JDK 9 doc-api-only RFR of 7086489: File.lastModified should accuracy as well as resolution

On 5/17/17 1:28 PM, Brian Burkhalter wrote: This wording "the unit of time of the return value is a millisecond” sounds weird. I would have written "the unit of time of the return value is milliseconds.” OK. How about then (ignore formatting)? * @apiNote * While the unit of time of th

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

Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8177809 Patch: http://cr.openjdk.java.net/~bpb/8177809/webrev.00/ Change the native portion of the Unix implementation to use the full time structure available. Note that for macOS, at least with HFS Plus, this

Re: JDK 9 doc-api-only RFR of 7086489: File.lastModified should accuracy as well as resolution

Hi Stuart, Thanks for the careful reading and comments. On May 17, 2017, at 1:15 PM, Stuart Marks wrote: > This is for JDK 9, right, so we want only non-normative doc changes? > > I'd think this should be an @apiNote instead of @implSpec. The @apiNote > clarifies but doesn't change the semant

Re: JDK 9 doc-api-only RFR of 7086489: File.lastModified should accuracy as well as resolution

This is for JDK 9, right, so we want only non-normative doc changes? I'd think this should be an @apiNote instead of @implSpec. The @apiNote clarifies but doesn't change the semantics, whereas @implSpec can impose requirements on the implementation and is thus normative. The intent of the wor

JDK 9 doc-api-only RFR of 7086489: File.lastModified should accuracy as well as resolution

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-7086489 Patch: [1] Thanks, Brian [1] Hg mq diff --- a/src/java.base/share/classes/java/io/File.java +++ b/src/java.base/share/classes/java/io/File.java @@ -923,6 +923,12 @@ * java.nio.file.Files#readAttr

Re: RFR: JDK-8180447: Trailing space in JDK_JAVA_OPTIONS causes an application fail to launch

On 17/05/2017 19:46, Henry Jen wrote: Hi, Please review a trivial fix for JDK-8180447[1], which we also makes the output of options picked up by the environment variable in one line instead of two for easier extraction from output. Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/jdk

RFR: JDK-8180447: Trailing space in JDK_JAVA_OPTIONS causes an application fail to launch

Hi, Please review a trivial fix for JDK-8180447[1], which we also makes the output of options picked up by the environment variable in one line instead of two for easier extraction from output. Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/jdk9/8180447/webrev/

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

Stop trying to add APIs to mutate environment variables. It's not going to happen! There is no known way to mutate environment variables in a multithreaded Unix process without risk of native crashes (and I have worn the hat of poor support engineer trying to diagnose SEGV in getenv). IIRC we ma

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

> On 17 May 2017, at 15:55, Daniel Fuchs wrote: > > On 17/05/2017 02:34, Brian Burkhalter wrote: >> 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

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

On 17/05/2017 02:34, Brian Burkhalter wrote: 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,

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

On 17/05/2017 8:45 PM, Remi Forax wrote: What i really like in Java is the diversity of options. We are discussing here to add or not a way to get the live environment in a Java process, at the same time on hotspot-compiler-dev Yasumasa posts a message with a set of examples that shows how to

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

What i really like in Java is the diversity of options. We are discussing here to add or not a way to get the live environment in a Java process, at the same time on hotspot-compiler-dev Yasumasa posts a message with a set of examples that shows how to do any C syscalls from Java using JVMCI (an

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

> > >> I disagree, this would be totally expected behavior. The daemon and this >> process would run in different shells and I am unaware of any daemon >> process that auto-magically reconfigures it’s self to adapt to any other >> arbitrary shell’s changed environment variables. > > The thing is th