Re: JDK 10 RFR of 8182710: File.listRoots() always returns the root of CD drive

Looks good as well. With best regards, Tagir Valeev. On Wed, Jun 28, 2017 at 8:49 PM, Brian Burkhalter < brian.burkhal...@oracle.com> wrote: > I rather like that. How about this (without “ds”)? > > public File[] listRoots() { > return BitSet > .valueOf(new long[] {listRoo

Re: JDK 10 RFR of JDK-8183173: Add private constructors to Fdlibm-internal classes

Thank you, Joe! Looks good. Shura > On Jun 28, 2017, at 4:06 PM, joe darcy wrote: > > Hello, > > Please review the patch below to address > >JDK-8183173: Add private constructors to Fdlibm-internal classes > > There are four fdblim methods ported to Java (so far) and thus four > constr

Re: JDK 10 RFR of JDK-8183175: Add explicit constructors to MalformedParameterizedTypeException

Hi Joe, On Jun 28, 2017, at 5:41 PM, Joseph D. Darcy wrote: >>> Please also review the corresponding CSR issue: >>> >>>https://bugs.openjdk.java.net/browse/JDK-8183177 >> >> This looks OK as well but is there any action to be taken aside from reading >> it? >> > > Yes; procedurally plea

Re: JDK 10 RFR of JDK-8183175: Add explicit constructors to MalformedParameterizedTypeException

Hi Brian, On 6/28/2017 5:37 PM, Brian Burkhalter wrote: Hi Joe, On Jun 28, 2017, at 5:01 PM, joe darcy > wrote: As noted in JDK-8183175: Add explicit constructors to MalformedParameterizedTypeException the exception type java.lang.reflect.MalformedParamet

Re: JDK 10 RFR of JDK-8183175: Add explicit constructors to MalformedParameterizedTypeException

Hi Joe, On Jun 28, 2017, at 5:01 PM, joe darcy wrote: > As noted in > >JDK-8183175: Add explicit constructors to > MalformedParameterizedTypeException > > the exception type java.lang.reflect.MalformedParameterizedTypeException does > not include any explicit constructors. A no-arg const

JDK 10 RFR of JDK-8183175: Add explicit constructors to MalformedParameterizedTypeException

Hello, As noted in JDK-8183175: Add explicit constructors to MalformedParameterizedTypeException the exception type java.lang.reflect.MalformedParameterizedTypeException does not include any explicit constructors. A no-arg constructor and a string constructor should be added in the usua

Re: JDK 10 RFR of JDK-8183173: Add private constructors to Fdlibm-internal classes

Hi Joe, Looks fine. Brian On Jun 28, 2017, at 4:06 PM, joe darcy wrote: > Please review the patch below to address > >JDK-8183173: Add private constructors to Fdlibm-internal classes > > There are four fdblim methods ported to Java (so far) and thus four > constructors added.

JDK 10 RFR of JDK-8183173: Add private constructors to Fdlibm-internal classes

Hello, Please review the patch below to address JDK-8183173: Add private constructors to Fdlibm-internal classes There are four fdblim methods ported to Java (so far) and thus four constructors added. Thanks, -Joe diff -r c150ee32ec89 src/java.base/share/classes/java/lang/FdLibm.java -

Re: [10] RFR: 8160199: Language's script should be reflected in user.script on Mac OS X

Thanks, Brent! Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8160199/webrev.04/ And my comments embedded below: On 6/28/17 2:16 PM, Brent Christian wrote: Hi, Naoto This looks quite good. I will test a bit with some of the trickier locales. BTW, the script will now also be

Re: RFR: JDK9 : JDK-8183141: java --help-extra in non-English locales lists --permit-illegal-access which no longer exists

2017/6/28 14:00:14 -0700, kumar.x.sriniva...@oracle.com: > Please review fix for [1] with this webrev [2]. All this does is remove > the incorrect option in the localized pages, as described in [1]. Is this really a P1 bug? - Mark

Re: [10] RFR: 8160199: Language's script should be reflected in user.script on Mac OS X

Hi, Naoto This looks quite good. I will test a bit with some of the trickier locales. BTW, the script will now also be reflected in Locale.getScript() and Locale.getDisplayScript(). Just a few comments: --- src/java.base/macosx/native/libjava/java_props_macosx.h Update copyright year ---

RFR: JDK9 : JDK-8183141: java --help-extra in non-English locales lists --permit-illegal-access which no longer exists

Hello, Please review fix for [1] with this webrev [2]. All this does is remove the incorrect option in the localized pages, as described in [1]. I have tested all of them on Unix with the limited default Western European locales, I have on the system. Appreciate if someone wants to check it out

[10] RFR: 8160199: Language's script should be reflected in user.script on Mac OS X

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8160199 The fix is located at: http://cr.openjdk.java.net/~naoto/8160199/webrev.03/ The gist of the issue was that the script code has not been properly treated in macOS specific code. Since it shar

Re: JDK 10 RFR of 8182710: File.listRoots() always returns the root of CD drive

I rather like that. How about this (without “ds”)? public File[] listRoots() { return BitSet .valueOf(new long[] {listRoots0()}) .stream() .mapToObj(i -> new File((char)('A' + i) + ":" + slash)) .filter(f -> access(f.getPath()) && f.exist

RE: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Hi Ogata, > > remove the second run with -Dsun.nio.cs.bugLevel=1.4 > > How can I do this? Is it sufficient to remove the following line at the > beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 > EmptyCharsetName" Yes, this line should be removed. Currently there are two @ru

RE: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Hi Christoph, Thank you for your help. I'll change the tests and update weberv. > remove the second run with -Dsun.nio.cs.bugLevel=1.4 How can I do this? Is it sufficient to remove the following line at the beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetNam

RE: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Hi Claes, this looks like a good idea, too. I'll try to take care of it after the Charset.atBugLevel() is done. Best regards Christoph > -Original Message- > From: Claes Redestad [mailto:claes.redes...@oracle.com] > Sent: Mittwoch, 28. Juni 2017 10:58 > To: Langer, Christoph ; Kazunori

RE: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Hi Christoph, Thank you for helping me on the CSR. Hi Peter, Thank you for pointing out the CSR process. I've learnt. Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 17:47:41: > From: "Langer, Christoph" > To: Peter Levart , Kazunori Ogata > Cc: "ppc-aix-port-...@openjdk.java.n

RE: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Hi, I just filed the CSR: https://bugs.openjdk.java.net/browse/JDK-8183116. I set it to status "Proposed". I assume it will be handled by the csr group automatically? As for the patch: I just recognized that we'll need to update the tests jdk/test/java/nio/charset/Charset/EmptyCharsetName.java

Re: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

On 27/06/2017 19:32, Langer, Christoph wrote: : @Alan: Do we need a CSR ("Compatibility & Specification Review") request here since support for "sun.nio.cs.bugLevel" will be removed? This system property pre-dates OpenJDK but it would have had a CCC at the time. So creating a CSR to indicat

Re: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Looks good to me, pending CSR approval. Additionally, maybe this is a good opportunity to re-examine the very similarly implemented sun.nio.ch.bugLevel used in sun.nio.ch.Util and sun.nio.ch.SelectorImpl? As a separate bug, of course. /Claes On 2017-06-28 08:45, Langer, Christoph wrote: Hi Og

RE: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Hi Petar, thanks for pointing out the need for the CSR, I thought so too. I’ll run through the CSR process… It’ll probably be an interesting learning experience for me as well ☺ Best regards Christoph From: Peter Levart [mailto:peter.lev...@gmail.com] Sent: Mittwoch, 28. Juni 2017 10:45 To: Ka

Re: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Hi Ogata, The change looks good. But I think this needs to go through CSR. The CSR FAQ page at: https://wiki.openjdk.java.net/display/csr/CSR+FAQs writes... Q: What sort of changes require CSR review? A: Any change to a JDK interface meant to be used outside of the JDK itself requires CSR re