February 2017 - core-libs-dev

RFR 8174151: URLClassLoader no longer uses custom URLStreamHandler for jar URLs
by Paul Sandoz 14 Feb '17

14 Feb '17

Hi, Please review. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8174151-url-class-path-loader/… 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 of ClassLoader.findResource such that the to be returned jar: URLs would not be operated on, and therefore the jar: URLStreamHandler would not be queried [*]. If the returned jar: URL is operated on by the caller then the jar: URLStreamHandler would (of course) be queried. This is arguably an implementation detail but it does change long term established behaviour in a very delicate area. While i find it unpalatable to do so this patch restores the previous behaviour, if a custom jar: URLStreamHandler is registered. The compromise is such a custom jar: URLStreamHandler needs to explicitly support multi-release JAR files. Paul. [*] Note that there are already such optimisations for file: URLs.

3 4

RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself
by Volker Simonis 14 Feb '17

14 Feb '17

Hi, I want to finally resolve this long standing issue (or close it as "will not fix" if that's not possible): http://cr.openjdk.java.net/~simonis/webrevs/2017/8033909/ This change has already been discussed in length on the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.h… and in the bug comments: https://bugs.openjdk.java.net/browse/JDK-8033909 So I'll give just a short summary here: - Objects.requireNonNull(T, Supplier) does not check for the Supplier argument being null. Instead it relies on the fact, that the VM will implicitly throw a NullPointerException when it calls .get on the Supplier argument during the creation of the explicit NullPointerException which it is supposed to throw. - this behavior slightly differs from Objects.requireNonNull(T, String) which simply creates a NullPointerException with a null message in the case where the String argument is null. - the difference is not evident in the OpenJDK, because the HotSpot VM creates a NPE with a null message by default if we call a method on a null object. - however creating such a NPE with a null message when invoking a method on a null object is not enforced by the standard, and other implementations can do better :) For the following trivial program: public class NonNull { public static void main(String[] args) { Supplier<String> ss = null; Object o = Objects.requireNonNull(null, ss); } } the current OpenJDK implementation returns: Exception in thread "main" java.lang.NullPointerException at java.util.Objects.requireNonNull(Objects.java:290) at NonNull.main(NonNull.java:8) but the SAP JVM will print: Exception in thread "main" java.lang.NullPointerException: while trying to invoke the method java.util.function.Supplier.get() of a null object loaded from local variable 'messageSupplier' at java.util.Objects.requireNonNull(Objects.java:290) at NonNull.main(NonNull.java:8) which is at least confusing for a call to Objects.requireNonNul() with a null Supplier. We think the exception should be the same like the one we get when invoking Objects.requireNonNul() with a null String. - because of this difference (and because we like our extended Exception messages :) the JCK test for Objects.requireNonNul(T, Supplier) (i.e. api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was removed from TCK 8 and is still commented out in TCK 9 (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java). 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() overloads for String and Supplier behave the same (which I think was the initial intention). - doesn't require documentation changes - makes it possible to write a simple and conforming TCK test If we can't agree on this quickly, I suggest to close the issue as "will-not-fix" and leave it untested by the TCK. Thank you and best regards, Volker PS: the 'XS' obviously only applies to the fix, not to this message :)

5 10

Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input
by Langer, Christoph 13 Feb '17

13 Feb '17

Hi Joe, I've updated my webrev for 8172974 after pulling out the refactoring of javax/xml/jaxp/unittest/transform/TransformerTest.java to Bug 8173602: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1/ After exchanging some off-list mails with Lance and Daniel, we came to the conclusion that you should decide about this one when you are back. The changes are merely cleanups apart from com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.startElement(), which to me seem natural after 8169631, though. Thanks, Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 18. Januar 2017 22:55 > To: 'huizhe wang' <huizhe.wang(a)oracle.com>; core-libs-dev(a)openjdk.java.net > Subject: RE: RFR 8172974 [JAXP] XALAN: Wrong result when transforming > namespace unaware StAX Input > > Hi Joe, > > generally, you are right, XSLT requires namespace support. For parsing the > stylesheet, it is definitely a hard requirement. Otherwise this would not make > sense at all. For instance xsl directives are in the xsl namespace. That > requirement is what the FAQ you are referencing [1] is talking about. > > As for the InputSource which is to be processed, it is probably also not a right to > use non namespace aware parsing. But still it's not forbidden. For instance, the > JavaDoc for SAXSource [2] states this: > "Note that XSLT requires namespace support. Attempting to transform an input > source that is not generated with a namespace-aware parser may result in > errors. Parsers can be made namespace aware by calling the > SAXParserFactory.setNamespaceAware(boolean awareness) method." > > So, I agree, we are in the error space here. But still I think the result of non > namespace aware parsing should be the same for all types of input source. And > at the moment it is the same for DOMSource and SAXSource but not for > StAXSource. From that point of view I think my fix makes sense (along with the > other cleanups). > > Best regards > Christoph > > [1] https://xml.apache.org/xalan-j/faq.html#faq-N10207 > [2] > https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource > .html > > > > -----Original Message----- > > From: huizhe wang [mailto:huizhe.wang@oracle.com] > > Sent: Mittwoch, 18. Januar 2017 22:12 > > To: Langer, Christoph <christoph.langer(a)sap.com>; core-libs- > > dev(a)openjdk.java.net > > Subject: Re: RFR 8172974 [JAXP] XALAN: Wrong result when transforming > > namespace unaware StAX Input > > > > Hi Christoph, > > > > Xalan requires the underlying parser to be namespace aware. Please refer > > to https://xml.apache.org/xalan-j/faq.html#faq-N10207 > > > > Thanks, > > Joe > > > > On 1/18/2017 8:26 AM, Langer, Christoph wrote: > > > Hi, > > > > > > please review a change for JAXP. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172974 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/ > > > > > > When enhancing the test for https://bugs.openjdk.java.net/browse/JDK- > > 8023653, I saw that there's still an issue with StAXInputSource which is not > > namespace aware. This needs a small update in > > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dt > > m/SAX2DTM2.java. Furthermore, I added the fixed warnings and formattings > > from the proposal http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to > > this webrev, as 8023653 is an enhancement and might not go in in the near > > future. > > > > > > I also enhanced the TransformerTest to utilize data providers now and test > a > > comprehensive matrix of XALAN input. > > > > > > Thanks in advance and Best regards > > > Christoph > > >

3 6

RFR: 8174831: Reduce number of Charset classes loaded on bootstrap
by Claes Redestad 13 Feb '17

13 Feb '17

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 reflection use), plus a couple of other nits: Webrev: http://cr.openjdk.java.net/~redestad/8174831/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8174831 Testing: jdk-tier1 tests Thanks! /Claes

3 3

RFR: JDK-8173094 Error in API documentation for SwingWorker
by Abhijit Roy 13 Feb '17

13 Feb '17

Hi all, Please review the java doc fix for the below Bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8173094 Description: Error in API documentation for SwingWorker Webrev-http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.00/ I have addressed some other doc issues which I included into the same webrev, please find those links below. Bug: https://bugs.openjdk.java.net/browse/JDK-8173751 Description: Syntax error in ZipFile.getComment() method Bug: https://bugs.openjdk.java.net/browse/JDK-8173752 Description: Syntax error in ZipEntry.setCompressedSize(long) method documentation Bug: https://bugs.openjdk.java.net/browse/JDK-8173755 Description: The word input should be replaced by output in FilterOutputStream.write(byte[],int,int) method documentation Bug: https://bugs.openjdk.java.net/browse/JDK-8173802 Description: Incorrect argument name in java.io.FilterInputStream.read(byte[]) method documentation Regards, Abhijit

3 5

RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
by Frank Yuan 13 Feb '17

13 Feb '17

Hi All Would you like to review http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/? Bug: https://bugs.openjdk.java.net/browse/JDK-8174025 JDK-8087303 introduced 2 issues: 1. Flaw when xlst uses disable-output-escaping attribute 2. Eat the whitespace between html inline elements This patch fixed the issues. To fix the second issue, we decide to keep the compatibility with JDK 8 on the whitespace handling, that is only LSSerializer cleans the extra whitespaces in if pretty-print is on, but XSLT doesn't. I modified the behavior of getIndent() method in class ToStream, to make LSSerializer be sensitive of current state from ToStream. This should be safe because ToStream is an internal class and getIndent() method is never used before. Thanks Frank

3 4

Re: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an empty file
by Denis Kononenko 13 Feb '17

13 Feb '17

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 works with ByteBuffer and > always relies on that there's enough data to inspect the image. This > results in IAE inside of BasicImageReader.slice method when the buffer > is smaller then it's expected. > > I added a few checks to avoid IAE and throw IOException with a more > descriptive text. > > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169715 > WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.01 > > Thank you, > Denis. Thank you, Denis.

3 2

RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only
by Langer, Christoph 13 Feb '17

13 Feb '17

Hi Joe, evenutally I have updated my webrev for this issue: http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/ I've implemented your suggestion to add a property "jdk.xml.generatePrefix" which is true by default. I also added a testcase which tests the correct behavior with "-Djdk.xml.generatePrefix=false". Generally, I think namespace prefix generation at this place is not needed. Or would you know of or be able to construct a case where it is really required? If not, I rather think namespace generation at this place should be thrown out unconditionally. Maybe for JDK10? In case it is removed, it would render the test javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java which was implemented recently by Alex for bug https://bugs.openjdk.java.net/browse/JDK-8167179 obsolete in its current form. However, the namespace generation function is still used some place for attribute namespaces. For JDK9 I can imagine the change of this webrev going in - however, as we already discussed, you would have to do a ccc for me. Thanks & Best regards Christoph From: Langer, Christoph Sent: Dienstag, 25. Oktober 2016 15:39 To: core-libs-dev(a)openjdk.java.net Subject: RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only Hi JAXP experts, please review a fix for a new issue regarding namespace handling in Xalan with xsl:element. Bug: https://bugs.openjdk.java.net/browse/JDK-8168664 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/ I'm not 100% sure if this is the right way to go or if it would break some correct behavior elsewhere. But I think the current behavior is either not correct or at least it is not required to generate new xsl namespace prefixes if the namespace comes in as URI only to an xsl:element node. The interpretative transformer from the Apache Xalan project will also produce the expected output, different to the compiled XSLTC here. In the webrev, my changes to XslElement.java are only cosmetical/comments, the behavior does not change. In BasisLibrary.java I also took the opportunity to remove the $Id tag and the unused method "nodeList2IteratorUsingHandleFromNode". If you think my change is good, I'll also add a test that runs the transformation which can be found in the bug... Thanks & best regards Christoph

3 4

RFR 8174728: Mark Java EE modules deprecated and for removal
by Lance Andersen 11 Feb '17

11 Feb '17

Hi all, This is a request to review marking the Java EE based modules as deprecated. The corba module was already updated. Best Lance ———————— ljanders-mac:dev-annotations ljanders$ cd jdk ljanders-mac:jdk ljanders$ hg diff diff -r ed26eebc8c88 src/java.transaction/share/classes/module-info.java --- a/src/java.transaction/share/classes/module-info.java Fri Feb 10 10:26:46 2017 -0800 +++ b/src/java.transaction/share/classes/module-info.java Fri Feb 10 15:54:10 2017 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -31,6 +31,7 @@ * * @since 9 */ +@Deprecated(since="9", forRemoval=true) module java.transaction { requires transitive java.rmi; exports javax.transaction; ljanders-mac:jdk ljanders$ cd ../jaxws ljanders-mac:jaxws ljanders$ hg diff diff -r b7e70e1e0154 src/java.activation/share/classes/module-info.java --- a/src/java.activation/share/classes/module-info.java Fri Feb 10 00:39:51 2017 -0800 +++ b/src/java.activation/share/classes/module-info.java Fri Feb 10 15:54:19 2017 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -28,6 +28,7 @@ * * @since 9 */ +@Deprecated(since="9", forRemoval=true) module java.activation { requires transitive java.datatransfer; requires java.logging; diff -r b7e70e1e0154 src/java.xml.bind/share/classes/module-info.java --- a/src/java.xml.bind/share/classes/module-info.java Fri Feb 10 00:39:51 2017 -0800 +++ b/src/java.xml.bind/share/classes/module-info.java Fri Feb 10 15:54:19 2017 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -28,6 +28,7 @@ * * @since 9 */ +@Deprecated(since="9", forRemoval=true) module java.xml.bind { requires transitive java.activation; requires transitive java.xml; diff -r b7e70e1e0154 src/java.xml.ws.annotation/share/classes/module-info.java --- a/src/java.xml.ws.annotation/share/classes/module-info.java Fri Feb 10 00:39:51 2017 -0800 +++ b/src/java.xml.ws.annotation/share/classes/module-info.java Fri Feb 10 15:54:19 2017 -0500 @@ -29,6 +29,7 @@ * * @since 9 */ +@Deprecated(since="9", forRemoval=true) module java.xml.ws.annotation { exports javax.annotation; } diff -r b7e70e1e0154 src/java.xml.ws/share/classes/module-info.java --- a/src/java.xml.ws/share/classes/module-info.java Fri Feb 10 00:39:51 2017 -0800 +++ b/src/java.xml.ws/share/classes/module-info.java Fri Feb 10 15:54:19 2017 -0500 @@ -29,6 +29,7 @@ * * @since 9 */ +@Deprecated(since="9", forRemoval=true) module java.xml.ws { requires transitive java.activation; requires transitive java.xml; ljanders-mac:jaxws ljanders$ ----------------------- <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com <mailto:Lance.Andersen@oracle.com>

2 2

RFR JDK-8165640: Enhance jar tool to allow module-info in versioned directories but not in base in modular multi-release jar files
by Xueming Shen 11 Feb '17

11 Feb '17

Hi, Please help review the changes for https://bugs.openjdk.java.net/browse/JDK-8165640 http://cr.openjdk.java.net/~sherman/8146486/webrev There are two changes (1) to use the versioned module-info as the module descriptor to validate the versioned entries, if the root/base "/module-info.class" is missing. (2) -d to print out all available module-info entries, versioned included. Thanks, Sherman

3 4