Re: [12] RFR: 8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values

Thanks, +1 from me (not an OpenJDK reviewer). Stephen On Mon, 24 Sep 2018 at 21:40, Naoto Sato wrote: > > Hi Stephen, > > Thank you for the review. > > On 9/22/18 11:57 PM, Stephen Colebourne wrote: > > The change seems simple enough. > > Does the test prove the change though? I thought the issue

Re: RFR: JDK-8197398 (zipfs) OutOfMemoryError when talking contents of empty JAR file

This RFR should be removed from core-libs-dev. nio-dev is the correct mailing list. The test needs to be fixed before that happens (and possibly the code also) regards, Sean. On 25/09/2018 06:53, Deepak Kejriwal wrote: Hi, Gentle reminder for review below fix. Regards, Deepak -Origina

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

Hi Stephen, Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT as well ? -Original Message- From: Stephen Colebourne Sent: Sunday, September 23, 2018 12:36 PM To: core-libs-dev Subject: Re: RFR: JDK-81661

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

On 09/24/2018 09:14 AM, Alan Bateman wrote: > I'm not questioning the need to support NVM, instead I'm trying to > see whether MappedByteBuffer is the right way to expose this in the > standard API. Buffers were designed in JSR-51 with specific > use-cases in mind but they are problematic for many

Re: RFR: JDK-8211071: unpack.cpp fails to compile with statement has no effect [-Werror=unused-value]

> 25 sep. 2018 kl. 10:21 skrev Roman Kennke : > > Not sure this is the correct list. Please redirect as appropriate. I believe core-libs is the appropriate place. Cc:d. > > Please review the following proposed change: > > > There are 3 asserts in unpack.cpp which check only constants, and

Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

I think it makes sense for both, although I was only considering appendInstant() when I wrote it. Stephen On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal wrote: > > Hi Stephen, > Is the addition to the documentation in your mail below meant for only > appendInstant() method or for DateTimeFormatter

RFR (Enhancement): 6194856: Zip Files lose ALL ownership and permissions of the files

Hi all, I had asked for opinions regarding adding posix permission support to JDK’s zip handling libraries and tools [1]. Since I didn’t get clear “no, you can’t do this” answers, I’m now concretely proposing some enhancements in the area of java.util.zip, jdk.zipfs and jdk.jartool. I have reop

Re: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and permissions of the files

On 25/09/2018 15:57, Langer, Christoph wrote: Hi all, I had asked for opinions regarding adding posix permission support to JDK’s zip handling libraries and tools [1]. Since I didn’t get clear “no, you can’t do this” answers, I’m now concretely proposing some enhancements in the area of java

Re: [12] RFR: 8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values

Look fine Naoto. Thanks, Roger On 09/24/2018 04:39 PM, Naoto Sato wrote: Hi Stephen, Thank you for the review. On 9/22/18 11:57 PM, Stephen Colebourne wrote: The change seems simple enough. Does the test prove the change though? I thought the issue was with months, not years? The jira iss

Re: Reactive Streams utility API

> On 25 Sep 2018, at 05:33, James Roper wrote: > > Hi Pavel, > > > > As for the MutexExecutor itself, that was mostly written by Viktor Klang, and > I believe he wrote it based on his experience implementing similar constructs > for Akka mailboxes. There is one major problem with it that I

RFR: JDK-8211121: Remove sun.reflect.ReflectionFactory::newInstanceForSerialization

Hi all: JDK-8211121 removes sun.reflect.ReflectionFactory::newInstanceForSerialization which was only used by the java.corba module. It was missed as part of the initial removal of the Java EE modules. The diff for the change: — s$ hg diff src/jdk.unsupported/share/classes/sun/reflect/Ref

Re: RFR: JDK-8211121: Remove sun.reflect.ReflectionFactory::newInstanceForSerialization

Hi Lance, Looks fine; thanks, -Joe On 9/25/2018 4:10 PM, Lance Andersen wrote: Hi all: JDK-8211121 removes sun.reflect.ReflectionFactory::newInstanceForSerialization which was only used by the java.corba module. It was missed as part of the initial removal of the Java EE modules. The diff

Re: Reactive Streams utility API

Sounds good to me, I'll ping Viktor to make sure he sees it too. On Wed, 26 Sep 2018 at 06:34, Pavel Rappo wrote: > > > On 25 Sep 2018, at 05:33, James Roper wrote: > > > > Hi Pavel, > > > > > > > > As for the MutexExecutor itself, that was mostly written by Viktor > Klang, and I believe he wr

Patch for 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars

Hi, There are some comments in the source code like this: > XXX Need to handle UTF8 values and break up lines longer than 72 bytes in Attributes.java on lines 299, 327, and 370. Bug 6202130 also suggests to add a test to show that the character set is fully supported before actually removing

Re: RFR: JDK-8211121: Remove sun.reflect.ReflectionFactory::newInstanceForSerialization

The imports statement of jdk.internal.misc.SharedSecrets and JavaSecurityAccess can be removed. Otherwise looks fine. Mandy On 9/25/18 4:10 PM, Lance Andersen wrote: Hi all: JDK-8211121 removes sun.reflect.ReflectionFactory::newInstanceForSerialization which was only used by the java.corba