RE: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml declaration

Hi Joe, this looks right to me, quite straightforward. I just have some formatting nits for the test: 1. Line 107 (XMLInputFactory xif=): space missing before '=' 2. Method comments on test methods would look nicer if formatted like: /* * line 1 * line 2 * ... */ ... I want to say that the '*'

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

On 14/02/2017 07:36, Volker Simonis wrote: : Finally somebody who understands me :) As this seems a very controversial topic, I'll wait for a second positive review before I'll push this. If you are going to push this change then best to do it with another JIRA issue as JDK-8033909 is a

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

On Tue, Feb 14, 2017 at 12:56 AM, David Holmes wrote: > On 14/02/2017 2:57 AM, Alan Bateman wrote: >> >> On 09/02/2017 16:18, Volker Simonis wrote: >> >>> : >>> >>> I really think that the simplest and most natural fix for this problem >>> is to simply check for a null

RFR (JAXP) 8169450: StAX parse error if there is a newline in xml declaration

A quick fix for the error parsing xml declaration. This is one of the three outstanding issues in the xml area that must be addressed for the coming development deadline. JBS: https://bugs.openjdk.java.net/browse/JDK-8169450 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

On 14/02/2017 2:57 AM, Alan Bateman wrote: On 09/02/2017 16:18, Volker Simonis wrote: : I really think that the simplest and most natural fix for this problem is to simply check for a null Supplier argument and create the NPE with an explicit null message in that case (as outlined in the

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

On 13/02/2017 7:10 PM, Volker Simonis wrote: On Mon, Feb 13, 2017 at 9:27 AM, David Holmes wrote: FWIW I think a null Supplier should simply be ignored. What do you mean by ignored? Do you mean "ignored" in the sense of my proposed changes (i.e. throw a NPE with a

RFR 8174151: URLClassLoader no longer uses custom URLStreamHandler for jar URLs

Hi, Please review. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8174151-url-class-path-loader/webrev/index.html This is a nasty edge case when a URLStreamHandler is registered (via the system property) to process jar: URLs. The support for multi-release JAR files changed the implementation

Re: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

On 2/13/2017 11:21 AM, huizhe wang wrote: Hi Christoph, The negatives were actually across all platforms, although the benchmark system picked up that it thinks were significant (high probability of a regression). There were negatives numbers that were bigger than the two. One

Re: RFR: 8174831: Reduce number of Charset classes loaded on bootstrap

On 2017-02-13 20:12, Alan Bateman wrote: On 13/02/2017 19:03, Claes Redestad wrote: Hi, this patch addresses a few tiny startup regressions incurred mostly by the fact that Compact Strings eagerly loads more Charsets early. java.nio.charset.StandardCharsets is dropped from the early

Re: RFR: 8174831: Reduce number of Charset classes loaded on bootstrap

On 13/02/2017 19:03, Claes Redestad wrote: Hi, this patch addresses a few tiny startup regressions incurred mostly by the fact that Compact Strings eagerly loads more Charsets early. java.nio.charset.StandardCharsets is dropped from the early bootstrap, load fastpaths are added for the 3

Re: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

Hi Christoph, The negatives were actually across all platforms, although the benchmark system picked up that it thinks were significant (high probability of a regression). There were negatives numbers that were bigger than the two. One possibility, if you look at the code change, is that the

Re: RFR: 8174831: Reduce number of Charset classes loaded on bootstrap

On 02/13/2017 11:03 AM, Claes Redestad wrote: Hi, this patch addresses a few tiny startup regressions incurred mostly by the fact that Compact Strings eagerly loads more Charsets early. java.nio.charset.StandardCharsets is dropped from the early bootstrap, load fastpaths are added for the 3

RFR: 8174831: Reduce number of Charset classes loaded on bootstrap

Hi, this patch addresses a few tiny startup regressions incurred mostly by the fact that Compact Strings eagerly loads more Charsets early. java.nio.charset.StandardCharsets is dropped from the early bootstrap, load fastpaths are added for the 3 eagerly used Charsets (which avoids some early

Re: RFR: JDK-8173094, 8173751, 8173752, 8173755, 8173802

Hi Sean, Yes, It would be great if you could push it for me. For that, I will send you a new webrev link with the below update. Thanks, Abhijit On 2/13/2017 9:44 PM, Seán Coffey wrote: Updated the subject line. Looks fine. Minor nit with FilterOutputStream.java * write method of its

should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303

Note that the bug id was incorrect, it should have been 8174025. 8170192 was a test bug fix. -Joe On 2/13/2017 1:35 AM, Frank Yuan wrote: Hi Joe and Daniel Thank you very much for your review! Frank -Original Message- From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent:

Re: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an empty file

Looks good > On 13 Feb 2017, at 20:58, Denis Kononenko wrote: > > > Hi, > > Optimized buffer's capacity checks. > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02 > > >> >> Could

Re: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an empty file

+1 > On Feb 13, 2017, at 1:58 PM, Denis Kononenko > wrote: > > > Hi, > > Optimized buffer's capacity checks. > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02 > > >> >> Could

Re: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an empty file

Hi, Optimized buffer's capacity checks. WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02 > > Could please someone review the fix for JDK-8169715. > > The problem occurs when jimage tool is attempting to read an empty or > incomplete image. The current implementation

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

On 09/02/2017 16:18, Volker Simonis wrote: : I really think that the simplest and most natural fix for this problem is to simply check for a null Supplier argument and create the NPE with an explicit null message in that case (as outlined in the webrev). This: - makes the two requireNonNul()

Re: RFR: JDK-8173094, 8173751, 8173752, 8173755, 8173802

Updated the subject line. Looks fine. Minor nit with FilterOutputStream.java * write method of its underlying output stream with the single * argument b. You're gone over 80 chars in length here. You can bring a word or two down to the last line. Do you want me to push this

Re: RFR: JDK-8173094 Error in API documentation for SwingWorker

On 10/02/17 19:18, Abhijit Roy wrote: Hi Sean, As per your suggestion, I have corrected those points. Please find the link below for further review. http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.01/ This looks good. Please include all the relevant bugIds in the changeset comment.

RE: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

Hi Joe, this is an updated webrev with only the change in namespace handling and the testcase: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1-SAX2DTM2only/ I'd really be interested in the performance results for that one before I turn to JDK10. Thanks Christoph > -Original

RE: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi Joe, here is the change, rebased for JDK10: http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.0/ This version would never generate prefixes for xsl:element and hence I removed the check for the property. Also Aleksej's test

RE: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303

Hi Joe and Daniel Thank you very much for your review! Frank -Original Message- From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent: Saturday, February 11, 2017 5:52 AM To: Daniel Fuchs; Frank Yuan; core-libs-dev@openjdk.java.net Subject: Re: RFR [JAXP] JDK-8170192 Regression in

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

On Mon, Feb 13, 2017 at 9:27 AM, David Holmes wrote: > FWIW I think a null Supplier should simply be ignored. > What do you mean by ignored? Do you mean "ignored" in the sense of my proposed changes (i.e. throw a NPE with a a null message) or do you mean "ignored" in

RE: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

Hi > FWIW I think a null Supplier should simply be ignored. ...which is what Volker's change does. After reading through all the discussion, I'm pro adding the null check as proposed in Volker's webrev. Best regards Christoph > On 13/02/2017 6:04 PM, Volker Simonis wrote: > > Ping... > > > >

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

FWIW I think a null Supplier should simply be ignored. David On 13/02/2017 6:04 PM, Volker Simonis wrote: Ping... On Thu, Feb 9, 2017 at 5:32 PM, Jeff Dinkins wrote: Adding Mike’s current email. -jeff On Feb 9, 2017, at 10:18 AM, Volker Simonis

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

Ping... On Thu, Feb 9, 2017 at 5:32 PM, Jeff Dinkins wrote: > > Adding Mike’s current email. > > -jeff > >> On Feb 9, 2017, at 10:18 AM, Volker Simonis wrote: >> >> Hi, >> >> I want to finally resolve this long standing issue (or close it as >>