RFR 8223193 : PatternSyntaxException need to truncate lengthy pattern strings

Hello! If an error occurred during regexp pattern compilation, PatternSyntaxException.getMessage() can be used to generate a multi-line detailed description. Generally, the description can include a message, the pattern, and the index where the error occurred. If the pattern is too long, th

Re: RFR(trivial): 8222394: HashMap.compute() throws CME on an empty Map if clear() called concurrently

...merely to serve as a discussion point about the policy for throwing ConcurrentModificationException? Yes, for the time being, I want to see and welcome more ideas on this. It seems to me that the policy for throwing CME here is not a unified one, mostly based on experience and testing. C

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I got most of the way through the platform-independent Java code today. Here is my feedback so far. NOTE: I don't think any of these need to be addressed prior to integration, so you can either fix them in a follow-on webrev or file a bug for fixing after integration. GENERAL: * Several fil

Re: RFR: JDK-8219483: j.l.c.ClassDesc::nested(String, String...) doesn't throw NPE if any arg is null

Hi Vicente, Revised version looks good; thanks, -Joe On 5/1/2019 1:08 PM, Vicente Romero wrote: Hi Joe, Thanks for the reviews, I have updated the webrev after you suggestion [1], Vicente [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.02/ On 4/30/19 6:00 PM, Joseph D. Darcy wrote

Re: RFR(JDK 13/java.xml) 8220818: Validator does not find missing match for keyref error

Thanks Lance! --Joe On 5/1/19, 2:23 PM, Lance Andersen wrote: Hi Joe, the change looks OK as does the test. On May 1, 2019, at 12:46 PM, Joe Wang > wrote: Please review a fix for a regression introduced during JDK 9 development. The issue was that a patch por

Re: RFR(JDK 13/java.xml) 8220818: Validator does not find missing match for keyref error

Hi Joe, the change looks OK as does the test. > On May 1, 2019, at 12:46 PM, Joe Wang wrote: > > Please review a fix for a regression introduced during JDK 9 development. The > issue was that a patch ported to the JDK added a counter to count the number > of values found in the XML document,

Re: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem example with map factory methods

On 5/1/2019 11:43 AM, Alan Bateman wrote: On 01/05/2019 17:53, Joe Darcy wrote: : Keeping env to one line also gives a comparably long line length: --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue Apr 30 16:11:42 2019 -0700 +++ b/src/java.base/share/classes/java/nio/file

RFR (CSR) - JDK-8218285 ClassDesc should have a full name method

Please review. Thank you. Cheers, -- Jim Summary: Add the method ClassDesc::displayFullName to return the fully qualified class name from a ClassDesc. Add a second method MethodTypeDesc::displayFullDescriptor which returns the MethodTypeDesc descriptor using fully qualified class names. cs

Re: RFR: JDK-8219483: j.l.c.ClassDesc::nested(String, String...) doesn't throw NPE if any arg is null

Hi Joe, Thanks for the reviews, I have updated the webrev after you suggestion [1], Vicente [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.02/ On 4/30/19 6:00 PM, Joseph D. Darcy wrote: Hi Vicente, CSR reviewed. I suggesting adding a test case for     cd.nested("good", null) Thank

Re: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem example with map factory methods

On 01/05/2019 17:53, Joe Darcy wrote: : Keeping env to one line also gives a comparably long line length: --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue Apr 30 16:11:42 2019 -0700 +++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Wed May 01 09:50:15 201

Re: RFR 8221267 : Document the jdk.net.URLClassPath.showIgnoredClassPathEntries system property

+1 Brian > On May 1, 2019, at 11:15 AM, Brent Christian > wrote: > > Please review this JavaDoc addition. CSR[3] has been approved. > > http://cr.openjdk.java.net/~bchristi/8221267/webrev01/ >

Re: RFR 8221267 : Document the jdk.net.URLClassPath.showIgnoredClassPathEntries system property

Looks good Brent. > On May 1, 2019, at 2:15 PM, Brent Christian > wrote: > > Hi, > > The "jdk.net.URLClassPath.showIgnoredClassPathEntries" system property was > added by 8211941[1]. When enabled, it provides debugging output of invalid > "Class-Path" attributes in JAR manifests (which are o

Re: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem example with map factory methods

> On May 1, 2019, at 9:53 AM, Joe Darcy wrote: > > --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue Apr 30 > 16:11:42 2019 -0700 > +++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Wed May 01 > 00:12:25 2019 -0700 > @@ -252,10 +252,9 @@ > * Suppose the

Re: RFR 8221267 : Document the jdk.net.URLClassPath.showIgnoredClassPathEntries system property

On 01/05/2019 19:15, Brent Christian wrote: Hi, The "jdk.net.URLClassPath.showIgnoredClassPathEntries" system property was added by 8211941[1].  When enabled, it provides debugging output of invalid "Class-Path" attributes in JAR manifests (which are ordinarily silently ignored). The new pr

RFR 8221267 : Document the jdk.net.URLClassPath.showIgnoredClassPathEntries system property

Hi, The "jdk.net.URLClassPath.showIgnoredClassPathEntries" system property was added by 8211941[1]. When enabled, it provides debugging output of invalid "Class-Path" attributes in JAR manifests (which are ordinarily silently ignored). The new property will be mentioned in the JDK 13 Releas

Re: jpackage producing non-working binaries on Windows

When you say "doesn't do anything when run", do you perhaps mean that you have some print statements in your program and you don't see them when you run it from a command shell? If so, then this is expected, and you need to add the "--win-console" option. If it's something else, then Alexey's

Re: jpackage producing non-working binaries on Windows

Hi Tom, What is your jpackage command line? Could you please rerun it with JPACKAGE_DEBUG environment variable set to "true". - Alexey On 4/30/2019 11:15 AM, Tom Anderson wrote: Hello, I am trying out the early-access jpackage tool. It works perfectly on Linux, but on Windows produces a bi

Re: RFR: 8219202: Use Unsynchronized StringBuilder in sun.net.www.ParseUtil

Alan, > On 1 May 2019, at 18:08, Alan Malloy wrote: > > It looks to me like Liam, acting as my sponsor, put noreg-cleanup on this bug > a couple days ago, which seems reasonable to me. Agreed. > Do you suggest an additional label? No. My mistake I missed that there was already a label added.

Re: RFR: 8222895: StackOverflowError in custom security manager that relies on ClassSpecializer

On 24/04/2019 13:49, Claes Redestad wrote: Hi, recent changes to the String concatenation bootstrap sequence[1] accidentally uncovered an issue introduced earlier by changing the ClassSpecializer to use Lookup.defineClass[2]. The issue with this is the introduction of a call to SM.checkPermissi

Re: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem example with map factory methods

Hi Alan, The maximum line length is actually slightly reduced by the proposed patch: --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue Apr 30 16:11:42 2019 -0700 +++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Wed May 01 00:12:25 2019 -0700 @@ -252,10 +252,

RFR(JDK 13/java.xml) 8220818: Validator does not find missing match for keyref error

Please review a fix for a regression introduced during JDK 9 development. The issue was that a patch ported to the JDK added a counter to count the number of values found in the XML document, and then compared with the constraint's field count. The problem was that the counter would get updated

Re: RFR: 8219202: Use Unsynchronized StringBuilder in sun.net.www.ParseUtil

Alan, > On 30 Apr 2019, at 18:53, Alan Malloy wrote: > > Hello. Please review this patch to use StringBuilder instead of > StringBuffer in sun.net.www.ParseUtil, a usage that does not need > synchronization. > > bug: https://bugs.openjdk.java.net/browse/JDK-8219202 > webrev: http://cr.openjdk.j

jpackage producing non-working binaries on Windows

Hello, I am trying out the early-access jpackage tool. It works perfectly on Linux, but on Windows produces a binary which does not do anything when run. I would like to either fix any error i have made, or help you identify a bug, if there is one! Is this the right place to come with this

RFR: 8219202: Use Unsynchronized StringBuilder in sun.net.www.ParseUtil

Hello. Please review this patch to use StringBuilder instead of StringBuffer in sun.net.www.ParseUtil, a usage that does not need synchronization. bug: https://bugs.openjdk.java.net/browse/JDK-8219202 webrev: http://cr.openjdk.java.net/~cushon/8219202/webrev.01/ Testing: All of jtreg:test/jdk/sun

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I have filed JDK-8223189 to address these. /Andy On 4/30/2019 7:02 PM, Kevin Rushforth wrote: I have a couple nit-picky comments: 1. The change to src/jdk.jlink/share/classes/module-info.java is unrelated to jpackage and should be revert

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

I filed task JDK-8223187 to look into (1) and CR JDK-8223188 to address (2). /Andy On 4/30/2019 6:53 PM, Phil Race wrote: A couple of questions / observations :- 1) setlocale http://cr.open

RE: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem example with map factory methods

> -Original Message- > From: core-libs-dev On Behalf > Of Alan Bateman > Sent: Mittwoch, 1. Mai 2019 08:17 > To: Joe Darcy ; nio-dev d...@openjdk.java.net> > Cc: core-libs-dev > Subject: Re: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem > example with map factory methods >