Re: [12] RFR: 8212941: Loosen the range of JapaneseEra

Hi Joe, On 10/26/18 3:00 PM, joe darcy wrote: Hi Naoto, I'd like to see a bit some discussion up front about the expected evolution of this class. For example, "once an era is defined, subsequent versions of the API will add a constant for it. etc. Eras are expected to have consecutive

Re: RFR: XXS JDK-8213056,,Nested anchor tags in java.lang.module

Looks good. Mandy On 10/26/18 3:10 PM, Jonathan Gibbons wrote: Please review a couple of very small changes to fix some HTML issues in the generated docs. The first change removes an empty paragraph; the second avoids causing nested tags. JBS:

Re: RFR: XXS JDK-8213056,,Nested anchor tags in java.lang.module

+1 -Joe On 10/26/2018 3:10 PM, Jonathan Gibbons wrote: Please review a couple of very small changes to fix some HTML issues in the generated docs. The first change removes an empty paragraph; the second avoids causing nested tags. JBS: https://bugs.openjdk.java.net/browse/JDK-8213056

Re: [12] RFR: 8212941: Loosen the range of JapaneseEra

Hi Naoto, I'd like to see a bit some discussion up front about the expected evolution of this class. For example, "once an era is defined, subsequent versions of the API will add a constant for it. etc. Eras are expected to have consecutive integers associated with them, etc. " Once a

Re: Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken

Great!  I have pushed this changeset. Mandy On 10/26/18 2:09 PM, Martin Buchholz wrote: Thanks for doing this - I tested the patch and it'll work for us. On Fri, Oct 26, 2018 at 8:46 AM, Mandy Chung > wrote: jsr166 depends on the internal Unsafe xxxObject

Re: Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken

Thanks for doing this - I tested the patch and it'll work for us. On Fri, Oct 26, 2018 at 8:46 AM, Mandy Chung wrote: > jsr166 depends on the internal Unsafe xxxObject methods and is currently > broken. Since the rename is motivated by Valhalla, we agree to keep the > internal Unsafe xxxObject

[12] RFR: 8212941: Loosen the range of JapaneseEra

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8212941 The proposed fix and CSR (not approved yet) are located at: http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ https://bugs.openjdk.java.net/browse/JDK-8212942 This change is intended to

Re: Fwd: Re: JMathConstant submission for upcoming JDK

Hello, I would not support a class with this purpose of this scale to be added to the JDK. BigDecimal has had constants for zero, one, and ten since JDK 5.0 shipped in 2004. I consider myself to have a reasonable math background for a non-mathematician and I don't know what field many of

Re: RFR(JDK 12/java.xml) 8212866: Broken link to schematron.com

Thanks Lance! On 10/26/18, 12:27 PM, Lance Andersen wrote: looks OK Joe On Oct 26, 2018, at 3:24 PM, Joe Wang > wrote: Hi, Looks like schematron.com is gone. Tested since the issue was reported 3 days ago, each time got a database

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Roger, > On Oct 25, 2018, at 7:15 AM, Roger Riggs wrote: > > The FIS skipping past of end of file is puzzling. Quite so. > If the 'were beyond EOF' was considering the possibility that the file was > being > extended concurrently with the skip operation then it would not be random, >

RE: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions

Hi Andrew, you might have a point here. I'll revisit that. Thanks Christoph > -Original Message- > From: Andrew Luo > Sent: Freitag, 26. Oktober 2018 20:43 > To: Langer, Christoph ; core-libs-dev d...@openjdk.java.net>; nio-dev ; Xueming > Shen > Cc: Schmelter, Ralf > Subject: RE:

Re: JMathConstant submission for upcoming JDK

Redirecting to core-libs-dev. I filed https://bugs.openjdk.java.net/browse/JDK-8213045. Paul On 10/26/18, 10:50 AM, "jdk-dev on behalf of Hohensee, Paul" wrote: This would go to core-libs-dev, and would be a spec change since it adds a class. The concept could be expanded to

Re: RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f

+1 Naoto On 10/26/18 12:38 PM, Martin Buchholz wrote: Looks good to me. On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil wrote: Hi all, Please review the latest TZDATA integration (tzdata2018f) into JDK12. Bug: https://bugs.openjdk.java.net/browse/JDK-8213016 Webrev:

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I noticed the following statement in the JEP: In this latter case, the tool can either create a native package from a previously created application image, or it can create a native package directly. I cannot tell from the command summary whether this option has been implemented or not.

Re: RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f

Looks good to me. On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2018f) into JDK12. > Bug: https://bugs.openjdk.java.net/browse/JDK-8213016 > Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/ > > All the

Re: RFR(JDK 12/java.xml) 8212866: Broken link to schematron.com

looks OK Joe > On Oct 26, 2018, at 3:24 PM, Joe Wang wrote: > > Hi, > > Looks like schematron.com is gone. Tested since the issue was reported 3 days > ago, each time got a database connection error. Schematron became an ISO > standard later after the JAXP specification and this packageinfo

RFR(JDK 12/java.xml) 8212866: Broken link to schematron.com

Hi, Looks like schematron.com is gone. Tested since the issue was reported 3 days ago, each time got a database connection error. Schematron became an ISO standard later after the JAXP specification and this packageinfo page was written, so replacing the link to schematron.com with a pointer

Fwd: Re: JMathConstant submission for upcoming JDK

[Sorry for the repeat, this time to ensure Robert sees the question] Hi Robert, No doubt a useful list of constants for some developers. Can you elaborate on why you think these constants should be in the JDK and why they are the right constants especially as related to precision and length.

RE: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions

I'm not a committer/reviewer but noticed something: In ZipUtils.java: private static final Map> permCache = new WeakHashMap<>(); This is static, and is concurrently modified, so will it cause issues if multiple threads are operating on ZIP filesystems (even if they are different objects/ZIP

RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f

Hi all, Please review the latest TZDATA integration (tzdata2018f) into JDK12. Bug: https://bugs.openjdk.java.net/browse/JDK-8213016 Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/ All the TimeZone related tests are passed after integration. Note: The used tzdata files are from the

Re: JMathConstant submission for upcoming JDK

Hi Robert, No doubt a useful list of constants for some developers. Can you elaborate on why you think these constants should be in the JDK and why they are the right constants especially as related to precision and length. I would expect for some applications these would be more precise than

Re: Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken

On 26/10/2018 16:46, Mandy Chung wrote: jsr166 depends on the internal Unsafe xxxObject methods and is currently broken. Since the rename is motivated by Valhalla, we agree to keep the internal Unsafe xxxObject methods as deprecated in the jdk repo. Webrev:

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

On 26/10/18 16:14, Daniel Fuchs wrote: > Hi Rob, > > Looks better to me know. Though I admit that: > > 53 this.replies = new LinkedBlockingQueue<>(8 * > replyQueueCapacity / 10); > > is still a bit mystifying... Why not use the full > replyQueueCapacity provided? That doesn't look >

Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken

jsr166 depends on the internal Unsafe xxxObject methods and is currently broken. Since the rename is motivated by Valhalla, we agree to keep the internal Unsafe xxxObject methods as deprecated in the jdk repo. Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213043/webrev.00 Mandy

Proposal: Stream.iterateWhile(T seed, Function> mapper)

Hi, Please, consider adding a new static method to the `Stream` interface (names TBD): static Stream iterateWhile( T seed, Function> mapper ); == OVERVIEW == + non-null equivalent of `Stream.iterate(seed, hasNext, next)` [1] + `mapper` like in

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Hi Rob, Looks better to me know. Though I admit that: 53 this.replies = new LinkedBlockingQueue<>(8 * replyQueueCapacity / 10); is still a bit mystifying... Why not use the full replyQueueCapacity provided? That doesn't look strictly equivalent to the highWatermark logic that you

RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions

Hi, please review this enhancement of jdk.nio.zipfs to support Posix file permissions. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 I had already posted this change as part of a larger fix for "6194856: Zip Files lose ALL

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

Yes, thanks a lot Alan. Vyom and Martin both had some very helpful feedback so I'm hoping to hear from both! -Rob On 26/10/18 15:34, Alan Bateman wrote: > On 25/10/2018 17:34, Rob McKenna wrote: > > This recently received CSR approval, so it seems like a good time to pick > > the codereview

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Thanks again Daniel, http://cr.openjdk.java.net/~robm/8139965/webrev.04/ -Rob On 26/10/18 09:54, Daniel Fuchs wrote: > Hi Rob, > > Now I'm concerned about this method: > > 71 synchronized boolean addReplyBer(BerDecoder ber) { > 72 // check the closed boolean value here as

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

On 25/10/2018 17:34, Rob McKenna wrote: This recently received CSR approval, so it seems like a good time to pick the codereview up again: http://cr.openjdk.java.net/~robm/8160768/webrev.08/ I went through a number of iterations with Rob on the API/javadoc so I think the API parts in

Re: Exceptions in Iterator.forEachRemaining()

Mostly my fault, and even more inconsistent than you say. I filed https://bugs.openjdk.java.net/browse/JDK-8213038 (but don't use an iterator after a call to forEachRemaining!) On Thu, Oct 25, 2018 at 11:55 PM, Zheka Kozlov wrote: > Hi everyone. > > I noticed that different Iterator

RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

Hello. Could you review the fix ? Bug:https://bugs.openjdk.java.net/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.00/ I'd like to obtain a sponsor for this issue. IBM964 charset and IBM29626C charset are required for default charset on AIX zh_TW and

Re: Time-zone database issues

On Fri, 26 Oct 2018 at 08:52, Ramanand Patil wrote: > Hi Naoto, > Thank you for filing the bug. As far as tzdata2018f release is concerned I am > going ahead with the integration, with the help of the patch provided here- > https://mm.icann.org/pipermail/tz/2018-October/027032.html Which avoids

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Hi Rob, Now I'm concerned about this method: 71 synchronized boolean addReplyBer(BerDecoder ber) { 72 // check the closed boolean value here as we don't want anything 73 // to be added to the queue after close() has been called. 74 if (cancelled || closed)

RE: Time-zone database issues

Hi Naoto, Thank you for filing the bug. As far as tzdata2018f release is concerned I am going ahead with the integration, with the help of the patch provided here- https://mm.icann.org/pipermail/tz/2018-October/027032.html Which avoids 25:00 in rearguard format. [

Exceptions in Iterator.forEachRemaining()

Hi everyone. I noticed that different Iterator implementations behave differently when an Exception is thrown inside a Consumer passed to forEachRemaining(): private static void test(List list) { Iterator iterator = list.iterator(); try { iterator.forEachRemaining(i -> {