July 2016 - core-libs-dev

JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace
by Langer, Christoph 26 Jul '16

26 Jul '16

Hi, I have a customer reporting the following phenomena which I believe is an issue. Consider the following xsl: ---------------------XSL--------------------- <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:template match="/"> <root xmlns="ns1"> <xsl:call-template name="transform"/> </root> </xsl:template> <xsl:template name="transform"> <test xmlns=""/> </xsl:template> </xsl:stylesheet> ---------------------End of XSL--------------------- This is the XML snippet where the XSL gets applied (just a dummy): <?xml version="1.0" encoding="UTF-8"?><aaa></aaa> The result with the current XSLTC is: <?xml version="1.0" encoding="UTF-8"?><root xmlns="ns1"><test/></root> But this would not undeclare the default namespace "ns1" from the element named "root" for the element named "test" which was the intention of the xsl. So I believe it should be: <?xml version="1.0" encoding="UTF-8"?><root xmlns="ns1"><test xmlns=""/></root> Looking at the coding I came up with the following: http://cr.openjdk.java.net/~clanger/webrevs/xsltc-namespaceissue/ With that, XSLTC would also emit the namespace attribute for an empty namespace. It works for my example but I'm not sure if it is the right thing to do or if it breaks things at other places and violates specs elsewhere. Comparing with the Apache Xalan, I can see that the Apache XSLTC matches the JDK XSLTC behavior to suppress the namespace declaration but the interpretative transformer (org.apache.xalan.processor.TransformerFactoryImpl) would emit the namespace attribute. Please give me some comments before I open a Bug... Thanks a lot in advance Christoph

4 8

JDK 9 RFR of JDK-8162539: Test fails because it expects a blank between method signature and throws exception
by joe darcy 26 Jul '16

26 Jul '16

Hello, Please review the changes to address JDK-8162539: Test fails because it expects a blank between method signature and throws exception http://cr.openjdk.java.net/~darcy/8162539.0/ In brief, recent refactorings of the toString output in core reflection (JDK-8161500 Use getTypeName and StringJoiner in core reflection generic toString methods) omitted a space character between the closing ")" and "throws" for toString output, but correctly included the space in toGenericString output. The simple fix is to add the space character; regression tests are suitably augmented and slightly refactored. Thanks, -Joe

2 3

[9] RFR: 8162343: non-ASCII characters in source code comments (.hpp)
by Naoto Sato 26 Jul '16

26 Jul '16

Hello, Please review the change to the following issue: https://bugs.openjdk.java.net/browse/JDK-8162343 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8162343/webrev.00/ It's a trivial fix following the bug 8161937. Naoto

3 3

RFR (JAXP): 8021787: javax.xml.datatype.XMLGregorianCalendar.getMonth() return is documented wrong
by Svetlana Nikandrova 26 Jul '16

26 Jul '16

Hello all, please review this javadoc fix for javax.xml.datatype.XMLGregorianCalendar.getMonth() Webrev: http://cr.openjdk.java.net/~snikandrova/8021787/webrev.00/ <http://cr.openjdk.java.net/%7Esnikandrova/8021787/webrev.00/> JBS: https://bugs.openjdk.java.net/browse/JDK-8021787 Thank you, Svetlana

3 9

RFR: jsr166 jdk9 integration wave 8
by Martin Buchholz 26 Jul '16

26 Jul '16

Time for the next round. No spec changes! http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

3 4

[JAXP] RFR: 8153082: Update XSTL compiler to generate classes that invoke addReads
by Daniel Fuchs 26 Jul '16

26 Jul '16

Hi, Please find below a fix for 8153082: Update XSTL compiler to generate classes that invoke addReads https://bugs.openjdk.java.net/browse/JDK-8153082 This fix removes a dependency from java.xml to an internal java base API. http://cr.openjdk.java.net/~dfuchs/webrev_8153082/webrev.00/ It changes FunctionCall.java to generate an additional addReads statement before invoking a method on an external class. Namely, where the generated translet class used to have a call to: com.foo.Bar.func(...); (resp: new com.foo.Bar(....)) it will now also contain an additional call to Module.addReads to add the external's class module to the list of modules that the generated translet's module can read. So the generated code now looks like: <TransletClass>.class.getModule().addReads( Class.forName("com.foo.Bar").getModule()); com.foo.Bar.func(...); (resp: new com.foo.Bar(....)) best regards, -- daniel

4 11

RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value
by Joel Borggrén-Franck 26 Jul '16

26 Jul '16

Hi, Can I get a review for this fix and javadoc clarification for https://bugs.openjdk.java.net/browse/JDK-8044629 The problem is with potentially annotated receiver parameters, they only exist for inner class constructors, so this fix makes sure that a ctor is for an inner class or returns null (as for a static method) otherwise. CCC has been approved. Webrev: http://cr.openjdk.java.net/~jfranck/8044629/webrev.00/ cheers /Joel

5 11

RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour
by nadeesh tv 25 Jul '16

25 Jul '16

Hi all, Please review BugId : https://bugs.openjdk.java.net/browse/JDK-8066806 Issue: java.time.format.DateTimeFormatter cannot parse an offset with single digit hour webrev: http://cr.openjdk.java.net/~ntv/8066806/webrev.03/ Solution: Added the suggested patterns but the parsing logic became too complex. Appreciate any suggestion to make the parsing less complicated -- Thanks and Regards, Nadeesh TV

5 26

[8u-dev] RFR (JAXP) 8028363: XmlGregorianCalendarImpl.getTimeZone() bug when offset is less than 10 minutes
by Svetlana Nikandrova 25 Jul '16

25 Jul '16

Hello, please review this fix for 8u-dev. For jdk9 problem has been addressed in JEP 255 <https://bugs.openjdk.java.net/browse/JDK-8044086> (Xerces update). Please note that changeset contains of 2 parts: XMLGregorianCalendarImpl fix in jaxp ws: http://cr.openjdk.java.net/~snikandrova/8028363/jaxp/webrev.00/ <http://cr.openjdk.java.net/%7Esnikandrova/8028363/jaxp/webrev.00/> Regression test in jdk ws: http://cr.openjdk.java.net/~snikandrova/8028363/jdk/webrev.00/ <http://cr.openjdk.java.net/%7Esnikandrova/8028363/jdk/webrev.00/> JBS: https://bugs.openjdk.java.net/browse/JDK-8028363 Description: While concatenating timezone representations string for TimeZone.getTimeZone() XmlGregorianCalendarImpl missed prior "0" in minutes part if minutes value is less then 10 (like "0" in 11:05). Thank you, Svetlana <https://bugs.openjdk.java.net/browse/JDK-8044086>

4 4

RFR JDK-8161942: java.util.zip.ZipEntry.java not covering UpperLimit range of DOS epoch
by Xueming Shen 22 Jul '16

22 Jul '16

Hi, Please help review the change for JDK-8161942 issue: https://bugs.openjdk.java.net/browse/JDK-8161942 webrev: http://cr.openjdk.java.net/~sherman/8161942/webrev The current ZipInputStream/ZipEntry implementation stores the "date-time" into the ZIP file/entry's extended timestamp fields in extra data, when the date-time is out of the MS-DOS range (1980 - 2107.xxx), by using the info-zip's extended timestamp, which by specification is in "unix 32-bit timestamp", which unfortunately has the 2038 problem (the seconds overflow after 2038-...). So when the date-time set for ZipEntry.setTimeLocal() is later than the dos-date-time's upper bound 2107, it also too big for the info-zip's extended timestamp. One approach to solve this problem is simply to update the spec to say if the date-time is too big for the MS-DOS date-time range, the behavior is undefined, given it will take a while for any zip file to have such a timestamp in any real world use scenario :-) But since the other newly added (1.8) set|getLastModified|LastAccess|CreationTime methods are also suffering the same problem when the date-time set is later than 2038, it appears it might be worth putting in an implementation that at least works for such timestamp. The proposed change here is to use the MS NTFS time format to store such timestamps when the unix-32-bit-timestamp is too small to store them. MS NTFS time format is one of the formats supported by our implementation (also supported by zip/unzip command) when reading the zip entry, the only disadvantage is it's a little bigger, take total 36 bytes for three timestamps. But given the fact that we should not see such timestamps for at least another 20 years, I would not be worried about the size difference, for now. Thanks, Sherman

2 1