RFR 8224789 : Parsing repetition count in regex does not detect numeric overflow

Hello! When Pattern.compile() parses the repetition count in the expressions like '.{100}', '.{1,2}' or '.{3,}' it fails to detect numeric overflow if the result is still non-negative. Could you please help review the patch? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8224789 WEBREV: ht

JDK 13 RFR of JDK-8224783: Javadoc of String strip methods uses link where linkplain would be better

Hello, Please review the patch below to address:     JDK-8224783: Javadoc of String strip methods uses link where linkplain would be better Thanks, -Joe diff -r 4947a097db60 src/java.base/share/classes/java/lang/String.java --- a/src/java.base/share/classes/java/lang/String.java    Fri May

Re: RFR (CSR) - JDK-8223776 String::stripIndent (Preview)

Hi, In the description of the re-indentation algorithm, I think it's worth clarifying that the last line is always included. So perhaps: "3. The last line (i.e., the line with the text block closing delimiter) is included in the set of determining lines, even if it is blank. (The indentatio

Re: Thread stack size issue related to glibc TLS bug

* Jiangli Zhou: > Hi Florian, > > On Fri, May 24, 2019 at 2:46 AM Florian Weimer wrote: >> >> * Jiangli Zhou: >> >> > [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/ >> > (contributed by Jeremy Manson) >> >> _dl_get_tls_static_info is an internal symbol (it carries a >> GLIBC_PRI

Re: Thread stack size issue related to glibc TLS bug

Hi Florian, On Fri, May 24, 2019 at 2:46 AM Florian Weimer wrote: > > * Jiangli Zhou: > > > [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/ > > (contributed by Jeremy Manson) > > _dl_get_tls_static_info is an internal symbol (it carries a > GLIBC_PRIVATE symbol version). Its imp

Re: Thread stack size issue related to glibc TLS bug

* Jiangli Zhou: > Hi Florian, > > Thanks for the feedback! > > On Fri, May 24, 2019 at 3:13 AM Florian Weimer wrote: >> >> * David Holmes: >> >> > My thoughts haven't really changed since 2015 - and sadly neither has >> > there been any change in glibc in that time. Nor, to my recollection, >> >

Re: RFR (CSR) - JDK-8223781 String::translateEscapes (Preview)

It's a bit heavy to cite a JLS section in the summary of a method. Recommend: "Returns a string whose value is this string, with escape sequences translated as if in a string literal." [Not mentioning text blocks for simplicity. Plus, if you mention them, then it looks like you forgot charac

Re: RFR (JDK 13/java.xml) 8223658: Performance regression of XML.validation in 13-b19

Thanks Lance! Pushed. Let's hope the performance will be back to normal in the next build. Best, Joe On 5/24/19, 10:18 AM, Lance Andersen wrote: +1 On May 24, 2019, at 1:11 PM, Joe Wang > wrote: Please review a fix to the performance regression introduced by

Re: RFR (JDK 13/java.xml) 8223658: Performance regression of XML.validation in 13-b19

+1 > On May 24, 2019, at 1:11 PM, Joe Wang wrote: > > Please review a fix to the performance regression introduced by Xerces > update. The performance benchmark gives weight to small XML files. Large > chunk sizes are therefore not helpful. Performance tests with the following > patch showed

RFR (JDK 13/java.xml) 8223658: Performance regression of XML.validation in 13-b19

Please review a fix to the performance regression introduced by Xerces update. The performance benchmark gives weight to small XML files. Large chunk sizes are therefore not helpful. Performance tests with the following patch showed that the results are on par with that for JDK 13 b18. https:/

RFR: 8223271: SplashScreen is still shown if defaulting to headless on MacOS

Bug: https://bugs.openjdk.java.net/browse/JDK-8223271 Webrev : http://cr.openjdk.java.net/~prr/8223271/ Whilst working on removing some inappropriate coupling of the java launcher and the desktop module, and testing out the -splash option, I noticed that on MacOS, in the case when we *default*

RFR (CSR) - JDK-8223781 String::translateEscapes (Preview)

Please do a CSR review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content. Thank you. -- Jim csr: https://bugs.openjdk.java.net/browse/JDK-8223781

RFR (CSR) - JDK-8223776 String::stripIndent (Preview)

Please do a CSR review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry. Thank yo

Re: Thread stack size issue related to glibc TLS bug

* David Holmes: > My thoughts haven't really changed since 2015 - and sadly neither has > there been any change in glibc in that time. Nor, to my recollection, > have there been any other reported issues with this. The issue gets occasionally reported by people who use small stacks with large ini

Re: RFR: 8207851: Implement JEP 352

Ping! Any takers for a review? Also, can anyone advise me on what I might need to do to target this JEP to JDK13, other than the obvious reviewing and pushing of the implementation? regards, Andrew Dinn --- On 23/05/2019 11:55, Andrew Dinn wrote: > Hi, > > Could I please have reviews

Re: Thread stack size issue related to glibc TLS bug

* Jiangli Zhou: > [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/ > (contributed by Jeremy Manson) _dl_get_tls_static_info is an internal symbol (it carries a GLIBC_PRIVATE symbol version). Its implementation can change at any time. Please do not do this. Thanks, Florian

[11u] RFR (Backport): 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

Hi, I'd like to bring this fix down to jdk11 updates. Unfortunately, the webrev did not apply cleanly in the imports section of src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java, so I had to resolve this part manually. I also updated the copyright year. Please check. Web