Re: RFR(JDK11/NIO) 8205058 throw CharacterCodingException --> Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

Hi Joe, I would suggest always embed a malformed exception into the iae as showed below, then the extra flag is no longer needed. private static void throwMalformed(int off, int nb) { String msg = "malformed input off : " + off + ", length : " + nb; throw new

RE: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions

Hi Vladimir, Please find the updated webrev link. Webrev Link: http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.00/ Bug link: https://bugs.openjdk.java.net/browse/JDK-8205528 Please let me know if you have additional questions. Thanks and Regards, Smita -Original Message- From:

Re: RFR(JDK11/NIO) 8205058 throw CharacterCodingException --> Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

Hi Alan, Sherman, Here's a version where we, as Sherman suggested, throw an IAE with CCE as the cause. This approach reduces code duplication in SC, although it complicates the impl a little bit with the added parameter and the different behavior between the existing usages of the methods and

Re: RFR: 8205184: Delegating Iterator implementations that don't delegate forEachRemaining()

Committed.

Re: Proposal: optimization of Map.copyOf and Collectors.toUnmodifiableMap

Hi Peter, Sorry for the delay again. I got pulled into a P1 escalation. I don't think I'll have time to look at this in any detail until after JDK 11 ramp-down. s'marks On 6/22/18 9:51 AM, Peter Levart wrote: Hi Stuart, Do you still fear that "single-threaded-object" idiom is not safe?

Re: RFR(xs): JDK-8201610: fix broken link in UnicastRemoteObject

+1 Had one of those myself recently :-) > On Jun 25, 2018, at 7:44 PM, Stuart Marks wrote: > > Hi all, > > Please review this small fix for a broken link. > > Patch appended below. > > Bug: > >https://bugs.openjdk.java.net/browse/JDK-8201610 > > Thanks, > > s'marks > > > > diff -r

Re: RFR(xs): JDK-8201610: fix broken link in UnicastRemoteObject

+1 Paul. > On Jun 25, 2018, at 4:44 PM, Stuart Marks wrote: > > Hi all, > > Please review this small fix for a broken link. > > Patch appended below. > > Bug: > >https://bugs.openjdk.java.net/browse/JDK-8201610 > > Thanks, > > s'marks > > > > diff -r 8b98dcf37891 -r 3da3bcc7b28b >

RFR(xs): JDK-8201610: fix broken link in UnicastRemoteObject

Hi all, Please review this small fix for a broken link. Patch appended below. Bug: https://bugs.openjdk.java.net/browse/JDK-8201610 Thanks, s'marks diff -r 8b98dcf37891 -r 3da3bcc7b28b src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java ---

Re: RFR(s): 8203670: unmodifiable List iterator() implementations should not be ListIterators

Hi Stuart! Out of curiosity. What if someone does something like if (it instanceof ListIterator) { // optimized for bidirectional access } else { // slower algorithm } previous(), nextIndex() and previousIndex() methods are not declared to be optional, so is it appropriate to throw

Re: RFR(JDK11/NIO) 8205058 throw CharacterCodingException --> Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

Hi Alan, The test testMalformedRead and testMalformedWrite now expect an UnmappableCharacterException instead of IOE: webrevs: http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev01/ Thanks, Joe On 6/25/18, 9:48 AM, Joe Wang wrote: On 6/24/18, 12:11 PM, Alan Bateman wrote: On

RFR(s): 8203670: unmodifiable List iterator() implementations should not be ListIterators

Hi all, Please review this small changeset that ensures that calling iterator() on an unmodifiable List (from List.of, et. al.) returns an instance that cannot be downcast to ListIterator and used as such. Bug: https://bugs.openjdk.java.net/browse/JDK-8203670 Webrev:

Re: RFR: 8205184: Delegating Iterator implementations that don't delegate forEachRemaining()

On Mon, Jun 25, 2018 at 11:17 AM, Paul Sandoz wrote: > Looks good. Sometimes in these cases i reach for proxy rather than > explicit code. It tends to be more robust to certain changes at the expense > of reflective complexity. > > Hmmm ... Never done that in a test before. > You could

Re: RFR 8195650 Method references to VarHandle accessors

Looks good. Matches the existing JVMS. Thanks for the tests. thanks, Karen > On Jun 19, 2018, at 8:08 PM, Paul Sandoz wrote: > > Hi, > > Please review the following fix to ensure method references to VarHandle > signature polymorphic methods are supported at runtime (specifically the >

Re: RFR 8195650 Method references to VarHandle accessors

Good fix. Reviewed. > On Jun 25, 2018, at 9:11 AM, Paul Sandoz wrote: > > Gentle reminder. > > I would like to get this reviews and pushed before the ramp down phase one > kicks in this week. > > Paul. > >> On Jun 19, 2018, at 5:08 PM, Paul Sandoz wrote: >> >> Hi, >> >> Please review

Re: RFR: 8148188: Enhance the security libraries to record events of interest

Many thanks for the review comments Erik. Replies inline. On 24/06/2018 14:21, Erik Gahlin wrote: Hi Sean, Some of the changes in the webrev belongs to JDK-8203629 and should be removed for clarity. Some initial comments: default.jfc, profile.jfr: The events should not have

Re: Review Request: JDK-8205623: Replace use of Class::getPackage with Class::getPackageName

On 25/06/2018 19:46, mandy chung wrote: This patch replaces the use of Class::getPackage with Class::getPackageName in jdk.internal.reflect.ReflectionFactory, sun.util.resources.BreakIteratorResourceBundle, and javax.xml.catalog.CatalogMessages.  Class::getPackageName avoids the overhead of

Re: RFR 8205547 : FileChannel/CleanerTest.java fails due to expected FD count

Thanks Paul, I'll add a comment. On 6/25/2018 2:26 PM, Paul Sandoz wrote: On Jun 25, 2018, at 11:08 AM, Roger Riggs > wrote: Hi Paul, Updated the webrev in place: http://cr.openjdk.java.net/~rriggs/webrev-fd-count-wrong-8205547/ On 6/25/2018 1:41 PM, Paul

Review Request: JDK-8205623: Replace use of Class::getPackage with Class::getPackageName

This patch replaces the use of Class::getPackage with Class::getPackageName in jdk.internal.reflect.ReflectionFactory, sun.util.resources.BreakIteratorResourceBundle, and javax.xml.catalog.CatalogMessages. Class::getPackageName avoids the overhead of constructing Package objects.

Re: RFR 8205547 : FileChannel/CleanerTest.java fails due to expected FD count

> On Jun 25, 2018, at 11:08 AM, Roger Riggs wrote: > > Hi Paul, > > Updated the webrev in place: > http://cr.openjdk.java.net/~rriggs/webrev-fd-count-wrong-8205547/ > > > On 6/25/2018 1:41 PM, Paul Sandoz wrote: >> Hi

Re: RFR: 8205184: Delegating Iterator implementations that don't delegate forEachRemaining()

Looks good. Sometimes in these cases i reach for proxy rather than explicit code. It tends to be more robust to certain changes at the expense of reflective complexity. You could probably reduce the test method names by removing the “forEachRemainingIsDelegated_” given that can be inferred

Re: RFR 8205547 : FileChannel/CleanerTest.java fails due to expected FD count

Hi Paul, Updated the webrev in place:   http://cr.openjdk.java.net/~rriggs/webrev-fd-count-wrong-8205547/ On 6/25/2018 1:41 PM, Paul Sandoz wrote: Hi Roger, Are you missing the throwing of an exception when the fdCount != fdCount0? (and relatedly i could not tell if the print statements were

Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions

I forgot to reply to your answers. On 6/22/18 2:49 PM, Kamath, Smita wrote: Hi Vladimir, Please see my answers to your questions as below: 1) One question so: why you have own copy of base64 charsets and not using one in library: I am using vpgatherdd instruction to fetch multiple values

Re: RFR 8205547 : FileChannel/CleanerTest.java fails due to expected FD count

Hi Roger, Are you missing the throwing of an exception when the fdCount != fdCount0? (and relatedly i could not tell if the print statements were for temporary debugging and you intended to remove them) Since you check before hand for support of UnixOperatingSystemMXBean there appears no need

Re: RFR: jsr166 integration 2018-06

Committed except for http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8203662: remove increment of modCount from ArrayList and Vector replaceAll() http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html

Re: RFR(JDK11/NIO) 8205058 throw CharacterCodingException --> Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

On 6/24/18, 12:11 PM, Alan Bateman wrote: On 20/06/2018 04:32, Joe Wang wrote: Thanks Alan. I created 8205058 to capture your suggestions. Please see below for more details. Changed the internal APIs to throw CCE instead. In the same way as the previous changeset for 8201276, these

Re: [11]RFR 8196213: sun/security/tools/jarsigner/warnings/NoTimestampTest.java test fails on ar_SA locale.

Looks good. Naoto On 6/25/18 12:04 AM, Dora Zhou wrote: Hello, Please help review the fix for JDK-8196213. Thank you. Set default locale to en-US so that the output display the date using Gregorian Calendar and Latn numbering system(0~9). Bug:

Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions

> On Jun 22, 2018, at 5:17 PM, Vladimir Kozlov > wrote: > > On 6/22/18 3:58 PM, Paul Sandoz wrote: >> Hi Smita, >> I am ok with it if Vladimir is :-) One slight concern is this may be biasing >> towards the x86 implementation of the intrinsic. > > Looking on code and it will be a lot of

Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions

Hi Kamath, Instead of throwing an aiobe, should the generateImplEncode() be like void generateImplEncode(byte[] src, int sp, int sl, byte[] dst, int dp) { if (sp < sl) { implEncode(src, sp, sl, dst, dp, ...); } } Any benefit of separating it into its own method? Thanks,

Re: RFR 8195650 Method references to VarHandle accessors

Gentle reminder. I would like to get this reviews and pushed before the ramp down phase one kicks in this week. Paul. > On Jun 19, 2018, at 5:08 PM, Paul Sandoz wrote: > > Hi, > > Please review the following fix to ensure method references to VarHandle > signature polymorphic methods are

Re: RFR: jsr166 integration 2018-06

> On Jun 24, 2018, at 1:29 PM, Doug Lea wrote: > > On 06/22/2018 01:28 PM, Paul Sandoz wrote: > >>> 8203864: Execution error in Java's Timsort >>> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/TimSort/index.html >>> https://bugs.openjdk.java.net/browse/JDK-8203864 >>> >>

Re: [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale

Looks good. Naoto On 6/25/18 12:37 AM, Dora Zhou wrote: Hi Naoto, Thanks a lot for the review. I have made suggested changes, Kindly have a look at: http://cr.openjdk.java.net/~ljiang/8194152/webrev.01/ Regards, Dora From:

RFR 8205547 : FileChannel/CleanerTest.java fails due to expected FD count

Please review a test improvement to avoid unexpected file opens/closes during the file channel CleanerTest. The test now follows the pattern of the other java/io/File*/UnreferencedXXXClosesFd tests by waiting for the cleaner and file descriptors to be reclaimed by GC. Webrev:  

Re: RFR JDK-8205090 / JDK-8204930

Hi Patrick, Roger, On Jun 25, 2018, at 7:22 AM, Roger Riggs wrote: > Looks fine, thanks for the followup > > @Brian, please sponsor Will do today. Brian

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

On 25/06/2018 15:29, Baesken, Matthias wrote: Hi, do you consider both the file name and line number as sensitive ? There was a similar discussion on net-dev recently related to leaking host names in exceptions. Something similar may be needed here Do you know the outcome of this

RE: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

Hi, do you consider both the file name and line number as sensitive ? > > There was a similar discussion on net-dev recently related to > leaking host names in exceptions. Something similar may be needed here > Do you know the outcome of this discussion ? Best regards, Matthias >

Re: RFR JDK-8205090 / JDK-8204930

Hi Patrick, Looks fine,  thanks for the followup @Brian, please sponsor Thanks, Roger On 6/25/2018 9:37 AM, Patrick Reinhart wrote: Can anyone take this? -Patrick Am 23.06.2018 um 02:26 schrieb Brian Burkhalter mailto:brian.burkhal...@oracle.com>>: Hi Patrick, I reviewed the CSR with

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

On 25/06/2018 14:55, Baesken, Matthias wrote: Hello, please review this small change that improve exception messages during manifest parsing of jar archives . Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8205525 Webrev :

[RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

Hello, please review this small change that improve exception messages during manifest parsing of jar archives . Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8205525 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8205525/

Re: RFR JDK-8205090 / JDK-8204930

Can anyone take this? -Patrick > Am 23.06.2018 um 02:26 schrieb Brian Burkhalter : > > Hi Patrick, > > I reviewed the CSR with some minor changes as you will have seen. The webrev > looks OK. I’ve not been following this thread that closely so perhaps someone > else should also review it. I

Re: RFR 8202292 : test/jdk/java/io/FileOutputStream/UnreferencedFOSClosesFd.java fails with "raw fd count wrong"

Created new issue: https://bugs.openjdk.java.net/browse/JDK-8205610 Thanks for the suggestion David On 6/25/2018 1:00 AM, David Holmes wrote: Hi Roger, On 23/06/2018 12:49 AM, Roger Riggs wrote: Hi Brian, Mandy, Listing the open file descriptors can be a useful utility. Originally I

Re: free(): corrupted unsorted chunks

Hi Bernd, Many thanks for your suggestions. It looks like the native APR library was the issue, at least it hasn't crashed yet after removing that library https://tomcat.apache.org/tomcat-8.0-doc/apr.html (the libapr1 package in Ubuntu) and re-configuring the /etc/tomcat8/server.xml to use NIO

Re: [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale

Hi Naoto, Thanks a lot for the review. I have made suggested changes, Kindly have a look at: http://cr.openjdk.java.net/~ljiang/8194152/webrev.01/ Regards, Dora From: naoto.s...@oracle.com To: dan.z.z...@oracle.com,

[11]RFR 8196213: sun/security/tools/jarsigner/warnings/NoTimestampTest.java test fails on ar_SA locale.

Hello, Please help review the fix for JDK-8196213. Thank you. Set default locale to en-US so that the output display the date using Gregorian Calendar and Latn numbering system(0~9). Bug: https://bugs.openjdk.java.net/browse/JDK-8196213 Webrev: