Re: RFR: 8236634: Memory Access API tests fail on 32-bit

Hi Maurizio, On 07/01/2020 19:06, Maurizio Cimadamore wrote: As for integrating this - what are your plans? JDK 14 or panama repo? I see you have targeted 14 in the issue, which is fine, but the priority is P4. Needs to be at least a P3 to be pushed in the RDP1 period (and I think a case can

Re: RFR 8234362: k_standard.c is not needed and should be removed

Hello, On 1/7/2020 5:04 AM, Alan Bateman wrote: Joe - is it still on your radar to port the remaining usages of fdlibm to Java? Yes; addressing JDK-8171407 "Port fdlibm to Java, part 2" remains on my to-do list. That bug is currently targeted to JDK 15, but it has been re-targeted before.

Re: [NEW BUG] Fix duplicated word in Lookup#in documentation

Hi Christoph, I'll sponsor this typo fix. Mandy On 1/7/20 9:32 AM, Christoph Dreis wrote: Hi, I just noticed that a duplicated "the" slipped into the docs of Lookup.in(). The change seems to have been introduced in https://bugs.openjdk.java.net/browse/JDK-8226916. In case this is

[NEW BUG] Fix duplicated word in Lookup#in documentation

Hi, I just noticed that a duplicated "the" slipped into the docs of Lookup.in(). The change seems to have been introduced in https://bugs.openjdk.java.net/browse/JDK-8226916. In case this is considered worthwhile I would need someone to sponsor the trivial change below: diff --git

Re: JDK 14 RFR of JDK-8236695: java.lang.Record should be declared with an explicit constructor

On 1/7/2020 4:26 AM, Chris Hegarty wrote: On 6 Jan 2020, at 23:22, Joe Darcy wrote: Hello, The initial implementation of java.lang.Record uses a default constructor; an explicit constructor should be added instead. Please review the code change and CSR for this: JDK-8236695:

Re: RFR JDK-8236688 Clarify String::indent javadoc (CSR)

I'm going to withdraw this change. It's been very painful to describe how String::indent this works in simple terms. The fact that it took 8 precise steps to describe in the JEP is an indication that simplification needs more thought. The submitter was trying to clarify what happens when the

Re: RFR JDK-8236688 Clarify String::indent javadoc (CSR)

Thanks Roger. Will apply your suggestions. > On Jan 7, 2020, at 11:02 AM, Roger Riggs wrote: > > Hi Jim, > > The nature of the problem should be apparent from the summary and problem > descriptions. > > The CSR/diff does not identify the methods modified. > > The new 3rd bullet seems more

Re: RFR JDK-8236688 Clarify String::indent javadoc (CSR)

Hi Jim, The nature of the problem should be apparent from the summary and problem descriptions. The CSR/diff does not identify the methods modified. The new 3rd bullet seems more like a consequence of the first 2 actions, not an independent step. The word 'implies' seems out of place in a

Re: RFR 8234362: k_standard.c is not needed and should be removed

Joe - is it still on your radar to port the remaining usages of fdlibm to Java? -Alan On 07/01/2020 12:37, Florian Weimer wrote: * Andrew Haley: On 11/18/19 9:49 PM, Florian Weimer wrote: I think the file should just be removed. Bug:

RFR JDK-8236688 Clarify String::indent javadoc (CSR)

Please review this CSR to clarify the javadoc details of String::indent (proposed by Andrew Leonard). webrev: http://cr.openjdk.java.net/~jlaskey/8230800/webrev.00/index.html csr: https://bugs.openjdk.java.net/browse/JDK-8236688

Re: RFR 8234362: k_standard.c is not needed and should be removed

* Andrew Haley: > On 11/18/19 9:49 PM, Florian Weimer wrote: >> I think the file should just be removed. >> >> Bug: >> Webrev: >> >> As usual, I'll need a sponsor for this. > > This is

Re: RFR: JDK-8236683 StringBuilder / StringBuffer capacity() doc is misleading (CSR)

Thank you Brent. > On Jan 6, 2020, at 5:42 PM, Brent Christian > wrote: > > Looks reasonable to me - reviewed. > -Brent > > On 1/6/20 10:29 AM, Jim Laskey wrote: >> Please review the following CSR intended to clarify the true meaning of >> StringBuilder::capacity and StringBuffer::capacity.

Re: JDK 14 RFR of JDK-8236695: java.lang.Record should be declared with an explicit constructor

> On 6 Jan 2020, at 23:22, Joe Darcy wrote: > > Hello, > > The initial implementation of java.lang.Record uses a default constructor; an > explicit constructor should be added instead. Please review the code change > and CSR for this: > > JDK-8236695: java.lang.Record should be

Re: RFR: 8236634: Memory Access API tests fail on 32-bit

Hi Nick, thanks for the fixes - this generally looks good - the only bit I'm less sure of is the Unsafe::allocateMemory change. It looks good per se, but I guess a more targeted fix is also possible (e.g. by checking for size > Integer.MAX_VALUE in case address size is 4 when we allocate the

RFR: 8236634: Memory Access API tests fail on 32-bit

Hi, Please review this set of fixes for the new memory access API on 32-bit Arm/x86. Bug: https://bugs.openjdk.java.net/browse/JDK-8236634 Webrev: http://cr.openjdk.java.net/~ngasson/8236634/webrev.0/ libNativeAccess.c fails to build with warnings enabled due to casting pointers to integers