Re: [8u] RFR: [JDK 8u] JapanEraNameCompatTest fails

On 13/05/2020 20:26, Severin Gehwolf wrote: > Hi Andrew, > > Thanks for looking at this. > No problem. Thanks for taking it on. > On Wed, 2020-05-13 at 17:37 +0100, Andrew Hughes wrote: >> On 13/05/2020 15:59, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review this fix for the

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

I think you have it covered. Thanks for the feedback it for sure helped me understand the approach. So on a lighthearted note I did figure out a way (tongue in cheek) to test if Collection::contains is expensive. You could even figure out if the membership semantics of each collection are the s

Re: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory

Ah, it's unrelated to JDK-8155659. The change looks okay.  Minor: it might worth adding the getClassName method in BSBS class. I also agree with Paul that we should examine if it's time to remove the non-default strategies if they are mostly unused. Mandy On 5/14/20 2:27 PM, Claes Redestad

Re: RFR JDK-8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2

On 5/14/20 1:52 PM, Chris Hegarty wrote: Hi Mandy, On 14 May 2020, at 21:12, Mandy Chung wrote: MethodHandles::privateLookupIn should prepare for being called during early startup when the module of java.base classes are not yet assigned. This bug is uncovered by panama prototype conver

Re: RFR: (CSR) JDK-8236688 Clarify String::stripIndent javadoc when string ends with line terminator

On 5/14/20 5:26 AM, Jim Laskey wrote: Are you looking at the text by Andrew in the bug? It would seem so. I found the prettyprint markup in the CSR distracting, so I was looking at my own javadoc build, but used the older diff. I've rebuilt using the diff in the CSR. I have a few minor s

Re: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory

Hi Mandy, I haven't looked at JDK-8155659 in years - and lambda bootstrap has been simplified a lot since. Maybe there's a way to pre-initializate a few classes to avoid the issues similarly now. It's not been a priority to fix since it isn't a regression in behavior like JDK-8155090 was - "just"

Re: RFR JDK-8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2

Hi Mandy, > On 14 May 2020, at 21:12, Mandy Chung wrote: > > MethodHandles::privateLookupIn should prepare for being called during early > startup when the module of java.base classes are not yet assigned. This bug > is uncovered by panama prototype converting NIO to use memory access API. >

Re: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory

Hi Claes, Is the bootstrapping issue contributed by Class::getDeclaredConstructors call in InnerClassLambdaMetafactory::buildCallSite? I wonder how much performance gain compared to using Lookup::findConstructor for non-capturing lambda case.   If LMF uses Lookup::findConstructor, it does no

RFR JDK-8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2

MethodHandles::privateLookupIn should prepare for being called during early startup when the module of java.base classes are not yet assigned.  This bug is uncovered by panama prototype converting NIO to use memory access API. The fix is very simple and move the call to Module::isNamed only if

Re: RFR(XS): 8244981: jpackage error due to missing final newline in Debian control file

Looks good. - Alexey On 5/14/2020 4:18 AM, Nick Gasson wrote: Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8244981 Webrev: http://cr.openjdk.java.net/~ngasson/8244981/webrev.0/ Several jpackage jtreg tests fail on Debian/Ubuntu with this error: Running [fakeroot, dpkg-deb, --verbos

Mismatch between spec and implementation of DataInputStream.readFully(byte[], int, int)

Found a small mismatch between the specification of DataInputStream.readFully(byte[] b, int off, int len) and its implementation. In particular, it doesn't throw an IndexOutOfBoundsException if offset is negative and len is 0. Reproducer below. I suggest changing the specification of this m

Re: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java

+1 Joe On 5/14/2020 2:14 AM, Daniel Fuchs wrote: Hi Fernando, That looks good to me. best regards, -- daniel On 12/05/2020 11:46, Fernando Guallini wrote: Thanks for your comments. Below you can find a new web rev version that includes a test description in a comment: http://cr.openjdk.ja

Re: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory

On 2020-05-14 17:28, Paul Sandoz wrote: Looks good. Thanks! — Separately, not for this issue, the code changes you made impact what is mostly unused code. I don’t recall us ever changing the default strategy, nor I am aware of others changing it via a system property (except for our tests

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

You have said: I'm trying to fix semantic bugs in the way various collection operations handle situations with mixed membership semantics I believe this statement is misleading and is at the root of our apparently irreconcilable differences. Many if not most of the problematic examples of mi

Re: BigInteger.squareToLen() can be wrong (when called directly)

Hi Jeff, I filed https://bugs.openjdk.java.net/browse/JDK-8245038 to track this. Thanks, Brian > On May 11, 2020, at 7:33 AM, Jeff Hain wrote: > > While trying to use BigInteger.squareToLen(x, len, z) directly > (with reflection), I saw that its pure Java implementation > computed wrong resul

Re: Mismatch between spec and implementation of DataInputStream.readFully(byte[], int, int)

> On May 14, 2020, at 8:25 AM, Brian Burkhalter > wrote: > >> This change should also affect DataInput, where care has to be taken that >> both behaviors are legal. > > I’ll file an issue. Filed: https://bugs.openjdk.java.net/browse/JDK-8245036 Thanks, Brian

Re: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory

Looks good. — Separately, not for this issue, the code changes you made impact what is mostly unused code. I don’t recall us ever changing the default strategy, nor I am aware of others changing it via a system property (except for our tests), are you? At the time when we introduced this feat

Re: Mismatch between spec and implementation of DataInputStream.readFully(byte[], int, int)

Hi Johannes, > On May 14, 2020, at 7:24 AM, Johannes Kuhn wrote: > > Found a small mismatch between the specification of > DataInputStream.readFully(byte[] b, int off, int len) and its implementation. > > In particular, it doesn't throw an IndexOutOfBoundsException if offset is > negative and

Re: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory

On 2020-05-14 17:05, Jim Laskey wrote: Will this have an effect on JDK-8218173  ? Interesting that you ask, since this cleanup was extracted from an attempted fix for 8218173. _Potentially_ this helps. But it won't fix it. Ensuring SCF.clas

Re: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory

Will this have an effect on JDK-8218173 ? > On May 14, 2020, at 11:39 AM, Claes Redestad > wrote: > > Hi, > > JDK-8155090 added some measures to StringConcatFactory to prevent > certain bootstrapping issues. I think we should consider eagerly

RFR: 8245024: Simplify and eagerly initialize StringConcatFactory

Hi, JDK-8155090 added some measures to StringConcatFactory to prevent certain bootstrapping issues. I think we should consider eagerly initializing the StringConcatFactory base class during bootstrap instead. Doing so will add a tiny bit of class loading overhead to bootstrap (which of course wi

Re: RFR: 8244853 - The static build of libextnet is missing the JNI_OnLoad_extnet function

On 14/05/2020 14:09, Andrew Dinn wrote: : I was unaware that this was a spec requirement for static libs. Can you point me at any discussion that explains why this is required and what the function might be expected to do? or even tell me when it was added to the spec? The macro appears to implem

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

> HashSet/TreeSet could do what ConcurrentHashMap/ConcurrentSkipListSet do by > using the "this contains that and that contains this" logic. Yes, at the cost of yet another performance regression. But how about this problem: Comparator cc = String.CASE_INSENSITIVE_ORDER; Set s1 = new TreeSet<>(

Re: RFR: 8244853 - The static build of libextnet is missing the JNI_OnLoad_extnet function

> On May 14, 2020, at 9:09 AM, Andrew Dinn wrote: > > Hi Alan, > > On 12/05/2020 19:57, Alan Bateman wrote: >> Looks okay to me. > > I am glad to hear that and also to see this fixed quickly (thanks Bob > for posting the patch). I'd like to see it backported to jdk11u (via > jdk14u, of course

Re: RFR: 8244853 - The static build of libextnet is missing the JNI_OnLoad_extnet function

Hi Alan, On 12/05/2020 19:57, Alan Bateman wrote: > Looks okay to me. I am glad to hear that and also to see this fixed quickly (thanks Bob for posting the patch). I'd like to see it backported to jdk11u (via jdk14u, of course) if possible in order to allow stock jdk14u/11u to be used to build Gr

Re: RFR: (CSR) JDK-8236688 Clarify String::stripIndent javadoc when string ends with line terminator

Brent, Are you looking at the text by Andrew in the bug? I reworked the in the CSR. Cheers, -- Jim > On May 13, 2020, at 7:21 PM, Brent Christian > wrote: > > Hi, Jim > > I have a few comments on the new wording (hopefully my understanding is > correct): > > ! * If the block ends w

Re: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java

Hi Fernando, That looks good to me. best regards, -- daniel On 12/05/2020 11:46, Fernando Guallini wrote: Thanks for your comments. Below you can find a new web rev version that includes a test description in a comment: http://cr.openjdk.java.net/~fyuan/fernando/8209774/webrev.01/

RFR(XS): 8244981: jpackage error due to missing final newline in Debian control file

Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8244981 Webrev: http://cr.openjdk.java.net/~ngasson/8244981/webrev.0/ Several jpackage jtreg tests fail on Debian/Ubuntu with this error: Running [fakeroot, dpkg-deb, --verbose, -b, <..snip..>] dpkg-deb: error: parsing file '/tmp/<..snip.