Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

+// no spec changes relative to supertype +public T[] toArray(IntFunction generator) { You probably at least need @inheritDoc for the unchecked exception throws (as I've forgotten many times) There's a new javadoc option "--override-methods summary" that was recently added

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll

+1 being also able to write, List l = ... l.addEach("foo", "bar", "baz"); is a nice addition. Rémi - Mail original - > De: "Stuart Marks" > À: "Martin Buchholz" > Cc: "core-libs-dev" > Envoyé: Mardi 5

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll

On 12/4/17 7:50 PM, Martin Buchholz wrote: https://bugs.openjdk.java.net/browse/JDK-8193031 http://cr.openjdk.java.net/~martin/webrevs/jdk/Collections-addAll/ * Adds all of the specified elements to the specified collection. * Elements to be added may be specified individually or

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

Hi Martin, - Mail original - > De: "Martin Buchholz" > À: "Stuart Marks" > Cc: "core-libs-dev" > Envoyé: Mardi 5 Décembre 2017 05:26:02 > Objet: Re: RFR(s): 8060192: Add default method

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On Mon, Dec 4, 2017 at 8:26 PM, Martin Buchholz wrote: > > The biggest question is whether Collection.toArray(generator) pulls its > weight, especially in view of https://shipilev.net/blog/ > 2016/arrays-wisdom-ancients. > Oh wait - Aleksey actually links to this bug!

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

The needToWorkAround6260652 changes ought to be in a separate changeset. The biggest question is whether Collection.toArray(generator) pulls its weight, especially in view of https://shipilev.net/blog/2016/arrays-wisdom-ancients. I rarely want to dump elements into a typed array. Dumping into

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

+// no spec changes relative to supertype +public T[] toArray(IntFunction generator) { You probably at least need @inheritDoc for the unchecked exception throws (as I've forgotten many times) On Mon, Dec 4, 2017 at 7:20 PM, Stuart Marks wrote: > Hi all, >

Re: RFR (JDK10) 8183743: Umbrella: add overloads that take a Charset parameter

On 12/3/17, 11:34 AM, Alan Bateman wrote: On 01/12/2017 20:35, Joe Wang wrote: : I think URLDecoder.decode methods should have @throws IllegalArgumentException. I realize it's implementation specific as to whether IAE is thrown with bad input but given that the RI does throw IAE then

RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll

https://bugs.openjdk.java.net/browse/JDK-8193031 http://cr.openjdk.java.net/~martin/webrevs/jdk/Collections-addAll/

RFR(s): 8060192: Add default method Collection.toArray(generator)

Hi all, Please review this small enhancement to add a default method Collection.toArray(generator) that takes a function that creates the destination array. This is analogous to Stream.toArray(generator). Bug: https://bugs.openjdk.java.net/browse/JDK-8060192 Webrev:

Re: RFR: 8176188: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java failing since 9-b93

On 2017-12-05 00:46, Martin Buchholz wrote: Thanks, Claes. I think we're in agreement! Great! I did that shared String optimization for StringJoiner. It's a lot harder to justify in the new String world because we have to handle non-ASCII, and the non-ASCII case is actually fairly

Re: RFR: 8176188: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java failing since 9-b93

> On Dec 4, 2017, at 3:46 PM, Martin Buchholz wrote: > > The code in Long.fastUUID is indeed ugly. I've never heard of UUID > creation being a bottleneck. At Google it sometimes seems all our java > performance problems are with zip file manipulation. At $MY_WORK, we

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

If you don't like my alternative, fine; it has its own set of tradeoffs that might be net positive or negative. If you want to proceed with the current approach, then I won't stand in the way. At the very least there should be some boilerplate added to EnumSet that makes it clear

Re: RFR: 8176188: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java failing since 9-b93

+1 On 12/3/17, 11:53 AM, Claes Redestad wrote: Hi, the compact strings JEP changed semantics of the package-private String(char[], boolean) constructor to do the same as the public String(char[]) constructor. Previously the former was used in trusted, internal code to avoid copying the

Re: RFR: 8176188: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java failing since 9-b93

Thanks, Claes. I think we're in agreement! I did that shared String optimization for StringJoiner. It's a lot harder to justify in the new String world because we have to handle non-ASCII, and the non-ASCII case is actually fairly likely. Does it make sense to keep COMPACT_STRINGS as an option

RFR JDK-8187485: Update Zip implementation to use Cleaner, not finalizers

Hi Please review the revision to the change for JDK-8187485: Update Zip implementation to use Cleaner, not finalizers For compatibility with previous jdk releases, in this proposed revision the corresponding close()/end() methods will be called when the ZipFile/Inflater/Deflater object has

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

On Mon, Dec 4, 2017 at 1:46 PM, Roger Riggs wrote: > > If you don't like my alternative, fine; it has its own set of tradeoffs > that might be net positive or negative. If you want to proceed with the > current approach, then I won't stand in the way. At the very least

Re: RFR: 8176188: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java failing since 9-b93

Hi Martin, On 2017-12-04 22:06, Martin Buchholz wrote: I'm rather sad about what happened to our non-copying String constructions for trusted code.  This is a performance regression with the change in String representation that should have blocked that change IMO.  I think we should have a

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

Hi Stuart, On 12/4/2017 4:23 PM, Stuart Marks wrote: On 12/4/17 12:36 PM, Martin Buchholz wrote: On Mon, Dec 4, 2017 at 12:12 PM, Roger Riggs wrote: The java.time APIs refined the pattern used for Serialization proxies to document the relationship between the

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

On 12/4/17 12:36 PM, Martin Buchholz wrote: On Mon, Dec 4, 2017 at 12:12 PM, Roger Riggs wrote: The java.time APIs refined the pattern used for Serialization proxies to document the relationship between the original class and its serialization proxies methods.

Re: RFR: 8176188: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java failing since 9-b93

I'm rather sad about what happened to our non-copying String constructions for trusted code. This is a performance regression with the change in String representation that should have blocked that change IMO. I think we should have a plan for moving in the opposite direction. I don't think we

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

Keep the comment, I didn't notice it had only been relocated. Thanks, On 12/4/2017 3:36 PM, Martin Buchholz wrote: Hi Roger, On Mon, Dec 4, 2017 at 12:12 PM, Roger Riggs > wrote: Hi Martin, The java.time APIs refined the

Re: RFR: 8176188: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java failing since 9-b93

+1 Paul. > On 3 Dec 2017, at 11:53, Claes Redestad wrote: > > Hi, > > the compact strings JEP changed semantics of the package-private > String(char[], boolean) > constructor to do the same as the public String(char[]) constructor. > > Previously the former was

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

Hi Roger, On Mon, Dec 4, 2017 at 12:12 PM, Roger Riggs wrote: > Hi Martin, > > The java.time APIs refined the pattern used for Serialization proxies to > document the relationship between > the original class and its serialization proxies methods. > Right. I was aware

Re: RFR 8187222 : ClassLoader.getSystemClassLoader not clear if recursive initialization leads to ISE or unspecified error

On 12/4/17 12:11 PM, Brent Christian wrote: So rethrow RuntimeExceptions directly, whether they're the cause of an InvocationTargetException or not. Updated webrev: http://cr.openjdk.java.net/~bchristi/8187222/webrev.02/ Looks good. Thanks Mandy

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

Correction below. On 12/4/2017 3:12 PM, Roger Riggs wrote: Hi Martin, The java.time APIs refined the pattern used for Serialization proxies to document the relationship between the original class and its serialization proxies methods. It is important the EnumSet appear in the serialized

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

Hi Martin, The java.time APIs refined the pattern used for Serialization proxies to document the relationship between the original class and its serialization proxies methods. It is important the EnumSet appear in the serialized form to document the behavior that it should no appear in the

Re: RFR 8187222 : ClassLoader.getSystemClassLoader not clear if recursive initialization leads to ISE or unspecified error

On 12/1/17 5:22 PM, Mandy Chung wrote: > > I think should also rethrow the cause if the cause is an Error > (why not) Alright. The instanceof RuntimeException check should be moved outside to the if-statement when it’s an instance of InvocationTargetException. So rethrow RuntimeExceptions

Re: Android and Log4j

On Sun, Dec 3, 2017 at 11:02 AM, Remi Forax wrote: > Ask Google to fix dx, > dx should ignore the module-info.class and everything inside > META-INF/versions (at least it's a first simple patch). > Hi, I'm "Google", sort of. Friends tell me that dx is getting fixed.

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

Interesting. You are trying to define a new Best Practice for the Serialization Proxy Pattern. Serialization is weird/broken in many ways - one of its weirdnesses is documenting behavior indirectly by publishing javadoc for private (!) methods (and fixing that would be a huge project (and I'm

Re: Android and Log4j

Hi, I'd also suggest to place the module-info.class inside the versions folder. So it should be ignored once the meta-inf bug is fixed. Java 9 should also read the module info from the versioned folder. Uwe Am 3. Dezember 2017 20:19:34 MEZ schrieb Alan Bateman : >On

Re: RFR 8192958 [JDK10] : TEST.groups: group jdk_util_other: file not found: jdk/internal/util

Looks good.  Thanks for cleaning it up. The test case was actually removed by JDK-8189611 whereas the class was removed by JDK-8192879. Mandy On 12/3/17 10:30 PM, Muneer Kolarkunnu wrote: Hi, Please review the fix for JDK- 8192958. Bug: https://bugs.openjdk.java.net/browse/JDK-8192958

Re: [10] RFR 8187551: MessageFormat.setFormat(int, Format) AIOOBE not thrown when documented

+1 Naoto On 12/3/17 10:36 PM, Nishit Jain wrote: Thanks Roger, Updated the webrevto add the new test case in MessageRegression.java http://cr.openjdk.java.net/~nishjain/8187551/webrev.03/ Regards, Nishit Jain On 01-12-2017 20:40, Roger Riggs wrote: Hi Nishit, Please add the new test to

Re: Fwd: Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

Hi Peter, I'd like to keep the code recognizably simple; (in the absence of a known performance issue). It would be interesting to know how the streams versions compares to the exception versions. Something for a rainy day... Roger On 12/4/2017 8:29 AM, Peter Levart wrote: Sending

Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

Hi Peter, Thanks for reviewing. This is a transition step to removing the finalize method completely while giving subclasses notice to upgrade their cleanup activities and yet gain the performance benefits sooner. Later, finalize() and related compatibility mechanisms will be removed.

Re: RFR JDK-8191918: tomcat gzip-compressed response bodies appear to be broken in update 151

Looks good to me. Regards, Sean. On 02/12/17 01:04, Xueming Shen wrote: On 12/1/17, 3:40 PM, Paul Sandoz wrote: On 30 Nov 2017, at 14:46, Xueming Shen wrote: Hi, Please help review the change for JDK-8191918: issue:

Re: [10] RFR 8187551: MessageFormat.setFormat(int, Format) AIOOBE not thrown when documented

Hi Nishit, Looks good, Thanks, Roger On 12/4/2017 1:36 AM, Nishit Jain wrote: Thanks Roger, Updated the webrevto add the new test case in MessageRegression.java http://cr.openjdk.java.net/~nishjain/8187551/webrev.03/ Regards, Nishit Jain On 01-12-2017 20:40, Roger Riggs wrote: Hi Nishit,

Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

Hi Roger, On 12/04/2017 03:09 PM, Peter Levart wrote: On 12/04/2017 02:25 PM, Peter Levart wrote: Hi Rogger, On 12/04/2017 02:17 PM, Peter Levart wrote: Hi Rogger, Interesting approach. Conditional finalization. You use finalization to support cases where user overrides finalize() and/or

Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

On 12/04/2017 02:25 PM, Peter Levart wrote: Hi Rogger, On 12/04/2017 02:17 PM, Peter Levart wrote: Hi Rogger, Interesting approach. Conditional finalization. You use finalization to support cases where user overrides finalize() and/or close() and Cleaner when he doesn't. I wonder if it

Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

This is a nice exercise in compatible migration from finalize() to Cleaner. The compatibility would be even better with a little tweak to the VM. Currently VM ignores empty finalize() method(s) and does not register the instance for finalization if it has empty finalize() (just return

Fwd: Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

Sending previous message to the list also (forgot to mention it in CC)... Hi Rogger, Interesting approach. Conditional finalization. You use finalization to support cases where user overrides finalize() and/or close() and Cleaner when he doesn't. I wonder if it is the right thing to use

Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

Hi Rogger, On 12/04/2017 02:17 PM, Peter Levart wrote: Hi Rogger, Interesting approach. Conditional finalization. You use finalization to support cases where user overrides finalize() and/or close() and Cleaner when he doesn't. I wonder if it is the right thing to use AltFinalizer when

Re: RFR (XXS): 8192961: Remove some double semicolons

On 2017-12-04 09:47, Langer, Christoph wrote: Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8192961.0/ Looks good. /Claes

RFR (XXS): 8192961: Remove some double semicolons

Hi, can I please have a review for this small cleanup. I spotted some double semicolons at a few import statements. Bug: https://bugs.openjdk.java.net/browse/JDK-8192961 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8192961.0/ Thanks Christoph