Re: [15] RFR: 8246261: TCKLocalTime.java failed due to "AssertionError: expected [18:14:22] but found [18:14:23]"

Looks good.  Thanks for the analysis! -Joe On 6/1/2020 9:13 PM, naoto.s...@oracle.com wrote: Updated webrev: http://cr.openjdk.java.net/~naoto/8246261/webrev.01/ Naoto On 6/1/20 6:30 PM, naoto.s...@oracle.com wrote: Hi Joe, In fact, this bug was possibly revealed by the fix to 8242504,

Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

Hi David, On 01/06/2020 23:43, David Holmes wrote: Sorry the weekend got in the way :) No problem David. I pushed with your suggestion (not using SoftReference) since that appeared to be working too. If it fails again I can revisit :-) best regards, -- daniel

Re: RFR: JDK-8222241 - Example in ServiceLoader API docs should have one provides directive

Sure, added indentation here: http://cr.openjdk.java.net/~pconcannon/fguallin/841/webrevs/webrev.01/ This is how the html is rendered: Thanks > On 29 May 2020, at 19:00, Alan Bateman wrote: > > On

Re: RFR: JDK-8230744 Several classes throw OutOfMemoryError without message

Revised to reflect requested changes. http://cr.openjdk.java.net/~jlaskey/8230744/webrev-01/index.html > On Jun 1, 2020, at 5:40 PM, Martin Buchholz wrote: > > On Mon, Jun 1, 2020 at 1:37 PM Brent Christian > wrote: > >>

RFR: 8246338: Reduce overhead of normalizing file paths

Hi, this patch simplifies and improves performance of UnixFileSystem.normalize and prefixLength, which are used when opening files. The Windows implementation is left untouched, since it's a bit more complicated. Bug:https://bugs.openjdk.java.net/browse/JDK-8246338 Webrev:

Re: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes

thanks to all the reviewers, the code for sealed classes has already been pushed to mainline. Vicente On 5/18/20 6:42 PM, Vicente Romero wrote: Hi, Please review this patch for the compiler, javadoc and javax.lang.model support for the JEP 360 Sealed Classes (Preview). The changes are

Re: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods

Hi Yu Li, I'm happy to sponsor your fix once it's reviewed. Could you just confirm that you have signed the Oracle Contributor Agreement? https://www.oracle.com/technetwork/community/oca-486395.html Cheers, Julia On 30/05/2020 21:00, Rob Spoor wrote: There's still a little regression there

Re: [15] RFR: 8246261: TCKLocalTime.java failed due to "AssertionError: expected [18:14:22] but found [18:14:23]"

The change looks OK also with the loop removed. > On Jun 2, 2020, at 12:13 AM, naoto.s...@oracle.com wrote: > > Updated webrev: http://cr.openjdk.java.net/~naoto/8246261/webrev.01/ > > Naoto > > On 6/1/20 6:30 PM, naoto.s...@oracle.com wrote: >> Hi Joe, >> In fact, this bug was possibly

Re: RFR: 8230743 - StringJoiner does not handle too large strings correctly

Revised with requested changes. http://cr.openjdk.java.net/~jlaskey/8230743/webrev-01 > On Jun 1, 2020, at 5:32 PM, Paul Sandoz wrote: > > > >> On Jun 1, 2020, at 12:44 PM, Jim Laskey > > wrote: >> >>

RFR [15] 8238763: ObjectInputStream readUnshared method handling of Records

This is a small change to ObjectInputStream, for 8238763 [1], to correctly handle readUnshared for records. Webrev: https://cr.openjdk.java.net/~chegar/8238763/webrev.00/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8238763

Re: RFR [15] 8238763: ObjectInputStream readUnshared method handling of Records

Hi Chris, Looks good. Thanks, Roger On 6/2/20 12:54 PM, Chris Hegarty wrote: This is a small change to ObjectInputStream, for 8238763 [1], to correctly handle readUnshared for records. Webrev: https://cr.openjdk.java.net/~chegar/8238763/webrev.00/ -Chris. [1]

Re: RFR(XL) 8198698: Support Lambda proxy classes in dynamic CDS archive

Hi Calvin, To recap an offline discussion, I think we should use JDK bootcycle build to test this feature.  For example generating a boot JDK with archived lambda proxy classes for java.base and javac to build itself and also use it to run JDK tier 1-3 tests.  This would serve a good test

Re: RFR: 8246338: Reduce overhead of normalizing file paths

On 02/06/2020 14:56, Claes Redestad wrote: Hi, this patch simplifies and improves performance of UnixFileSystem.normalize and prefixLength, which are used when opening files. The Windows implementation is left untouched, since it's a bit more complicated. Bug:   

Re: RFR: JDK-8222241 - Example in ServiceLoader API docs should have one provides directive

On 02/06/2020 15:06, Fernando Guallini wrote: Sure, added indentation here: http://cr.openjdk.java.net/~pconcannon/fguallin/841/webrevs/webrev.01/ Thanks, that is much clearer. -Alan

Re: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods

Thank you for submitting the fix, Yu Li. (And thanks for the sponsor, Julia). This will be good to fix. I have a few changes to recommend. src/java.base/share/classes/java/util/Properties.java The code change looks fine to me. The ending Copyright year just needs to be changed from 2019 ->

Re: Sometimes constraints are questionable

On Tue, Jun 2, 2020 at 3:09 PM Stuart Marks wrote: > 4) We might want to consider refactoring PriorityBlockingQueue and ArrayDeque > to > use ArraysSupport.newLength, in order to provide a consistent policy for > collections. Other growable-array-based collections (Vector, ArrayList, >

Re: RFR: 8230743 - StringJoiner does not handle too large strings correctly

+1 Paul. > On Jun 2, 2020, at 6:21 AM, Jim Laskey wrote: > > Revised with requested changes. > > > http://cr.openjdk.java.net/~jlaskey/8230743/webrev-01 > > > >> On Jun 1, 2020, at 5:32 PM, Paul Sandoz wrote: >> >> >> >>> On Jun

Re: RFR: 8230743 - StringJoiner does not handle too large strings correctly

One of these error messages is not like the other +OutOfMemoryError("Resulting string is exceeds maximum size"); +OutOfMemoryError("Resulting string exceeds maximum size");

Re: RFR: JDK-8230744 Several classes throw OutOfMemoryError without message

Hi Jim, Given the infrequency of the exception messages being used, can we simplify them and/or reuse the strings? The stack trace would usually show what API was being used so I would simplfy the messages to: "exceeds implementation limit" or "size exceeds implementation limit".   

Re: RFR: JDK-8230744 Several classes throw OutOfMemoryError without message

On 6/2/20 6:52 AM, Jim Laskey wrote: Revised to reflect requested changes. http://cr.openjdk.java.net/~jlaskey/8230744/webrev-01/index.html On this, if all you're doing is changing exception messages, then I don't care

Re: Sometimes constraints are questionable

Hi Jim, This was mentioned previously in this thread but not discussed very much. I suggest you take a look at jdk.internal.util.ArraysSupport.newLength(). Ivan Gerasimov and I worked this over fairly closely last year, and I'm pretty sure it does what Martin is saying, which I also think is

Re: RFR: 8246338: Reduce overhead of normalizing file paths

On 2020-06-02 20:07, Alan Bateman wrote: Webrev: http://cr.openjdk.java.net/~redestad/8246338/open.00/ On the provided microbenchmark, we see a small (5-10%) speed-up in peak performance, while the speed-up is quite large when interpreting, especially in the case where the file path is

Re: RFR(XL) 8198698: Support Lambda proxy classes in dynamic CDS archive

Hi Mandy, On 3/06/2020 4:38 am, Mandy Chung wrote: Hi Calvin, To recap an offline discussion, I think we should use JDK bootcycle build to test this feature.  For example generating a boot JDK with archived lambda proxy classes for java.base and javac to build itself and also use it to run

Re: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods

Hi， Thanks a lot Julia! I have signed OCA and emailed it to Oracle last week. But I haven't seen my name on the contributor list yet. I guess I'll have to wait. And thanks a lot for all the advice, Brent! It's really useful. I'll do as you said. Best regards, Yu On Wed, Jun 3, 2020 at 7:51 AM