Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation

On 3/20/19 9:03 PM, Dan Smith wrote: http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ AbstractValidatingLambdaMetafactory.java + throw new LambdaConversionException("implementation is not direct or cannot be cracked"); It may help to print implementation method handle: throw new

RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation

http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ Please review this update to java.lang.invoke.LambdaMetafactory. Adds some argument validation with tests; improves documentation; renames some variables. JBS: https://bugs.openjdk.java.net/browse/JDK-8174222 —Dan

Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

On 3/20/19 1:54 AM, Lindenmaier, Goetz wrote: Should I move the JEP to status 'submitted'? Per the Process states section  [1] Draft --- In circulation by the author for initial review and consensus-building I certainly don't want to be the bottleneck.   Others can help do the initial

Re: RFR 8211941 : Enable checking/ignoring of non-conforming Class-Path entries

Hi Brent, The change looks fine. Can you file a JBS issue to follow up a place to document this JDK-specific property? thanks Mandy On 3/20/19 2:01 PM, Brent Christian wrote: Hi, JDK-8216401[1][2] added code to improve JAR spec conformance (WRT relative URLs in the Class-Path attribute),

RFR: JDK-8215019: Allow --install-dir on windows

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Added support for --install-dir on Windows. It should be relative path to "Program Files" or "AppData". - If --install-dir is invalid we will use

Re: RFR: docs JDK-8220261: fix headings in java.base

I looked through the webrev and this looks fine to me. Mandy On 3/20/19 2:50 PM, Jonathan Gibbons wrote: Please review a medium-sized but conceptually simple patch to fix most of the headings in the generated documentation for java.base, as described in [1]. This does not address the headings

Re: [PATCH] Some improvements for java.lang.Class

Hi Sergei, I don't know if you are aware that the new invokedynamic based translation of string concatenation expressions introduced in JDK 9 (http://openjdk.java.net/jeps/280) only applies to code outside java.base module. java.base module is still compiled with old-style StringBuilder

Re: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails

I agree, this is not a test of locale-sensitive number parsing, it's a test of Scanner. Thus I think it's reasonable to keep the focus on the Scanner methods. To step back a bit, this bug is about fixing the "intermittent" failure of this test. This isn't case where the test fails randomly

Re: RFR: docs JDK-8220261: fix headings in java.base

Thanks. -- Jon On 03/20/2019 03:16 PM, Lance Andersen wrote: Hi Jon, I went through the patch and it looks good (matches what i did for java.sql.rowset and java.naming :-) ) On Mar 20, 2019, at 5:50 PM, Jonathan Gibbons mailto:jonathan.gibb...@oracle.com>> wrote: JDK-8220248

Re: RFR: docs JDK-8220261: fix headings in java.base

Hi Jon, I went through the patch and it looks good (matches what i did for java.sql.rowset and java.naming :-) ) > On Mar 20, 2019, at 5:50 PM, Jonathan Gibbons > wrote: > > JDK-8220248

RFR: docs JDK-8220261: fix headings in java.base

Please review a medium-sized but conceptually simple patch to fix most of the headings in the generated documentation for java.base, as described in [1]. This does not address the headings in java.util.concurrent which are reported separately, in JDK-8220248. The intent is to ensure that the

RFR 8211941 : Enable checking/ignoring of non-conforming Class-Path entries

Hi, JDK-8216401[1][2] added code to improve JAR spec conformance (WRT relative URLs in the Class-Path attribute), while maintaining some key compatibility aspects (entries using "file:" URLs are not relative, but are used by some libraries). This code was disabled by default, but we would

Re: java.lang.CharSequence#compare - lexicographical ordering of custom Comparable CharSequence(s)

* Jason Mehrens: > The initial implementation was only optimized to call into > String.compare if the arguments were string [1]. I proposed the > current code a general form to catch java.nio.CharBuffer and any new > JDK implementations of CharSequence + Comparable. > > Naively, I lean towards

Re: [PATCH] Some improvements for java.lang.Class

I had a brief conversation with Brian Goetz which has left off the mailing list for some reason. Here's the text: --- Brian: These enhancements seem reasonable; these are exactly the cases that String::repeat was intended for. (This is a “is this a reasonable idea”

RE: RFR 8213031: (zipfs) Add support for POSIX file permissions

Hi Alan, I now found time to get back to the POSIX file permissions in zipfs. The goal would be to get it done for JDK13  I went through your mail in details, please see my comments: > 1. By default, a zip file system will have no support for the "posix" > and "owner" views of file

Re: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux

On 3/20/19 8:02 AM, Langer, Christoph wrote: > Hi Andrew, > >> Thanks. I get that, I'm just questioning the need to backport it to 11. >> No matter, I've approved it now. > > What do you mean by that? The bug JDK-8220362 [0] still has jdk11u-fix-no. No it doesn't. JDK-8212828 still had a

RE: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails

Hi Goetz, this test is specifically for java.util.Scanner. Generally, it could probably be overhauled to make it run with any Locale. However, then the input data for scanning will need to be written in the Locale that the scanner uses. This is a bit out of scope for me at this point... But

RE: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails

Hi, if it is only about parsing floats, why not use NumberFormat.getInstance().parse(value)? I did 8205108: [testbug] Fix pattern matching in jstatd tests. http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1637a4e50fc9?revcount=80 some while ago, because we had wrong float parsing on mac in our

RE: RFR(S): 8172695: (scanner) java/util/Scanner/ScanTest.java fails

Hi Stuart, thanks for consulting with Naoto and providing the update. So I'll run the fix through jdk-submit and our test system at SAP with Locale.US. Provided I don't see issues, I'll push it thereafter... Best regards Christoph > -Original Message- > From: Stuart Marks > Sent:

RE: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

Hi Mandy, > Sorry I have been busy on other time-critical things. I will > get to it hopefully next week. No problem, I have been improving the text slightly anyways. I also pushed my change and a follow up needed to the sandbox repos so it can be played with. Should I move the JEP to status

Re: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux

On Tue, Mar 19, 2019 at 5:10 PM Martin Buchholz wrote: > I'm the one who introduced vfork for process spawning, and I support > Thomas' plan to switch to posix_spawn. > (although I have not seen a crash attributed to using vfork on Linux) > Thanks Martin. I think for a long time vfork was the

RE: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux

Hi Andrew, > Thanks. I get that, I'm just questioning the need to backport it to 11. > No matter, I've approved it now. What do you mean by that? The bug JDK-8220362 [0] still has jdk11u-fix-no. In case you approve JDK-8220362, I'll set the CSR (JDK-8220362 [1]) to finalized, referring to your