March 2016 - core-libs-dev

RFR: 8134111: Unmarshaller unmarshalls XML element which doesn't have the expected namespace
by Aleksej Efimov 31 Mar '16

31 Mar '16

Hi, Please, help to review the fix for JDK-8134111 [1]. This bug was already resolved in standalone JAXB project and was integrated to JDK9 as part of JAXWS/B sync process [2]. The changes that fixed the incorrect unmarshalling behavior are located in StructureLoader class [3]. JDK9 change that needs review is the addition of regression test for this issue: http://cr.openjdk.java.net/~aefimov/8134111/9/00/ I will be requesting approval for partially backporting the source fix [3] to JDK8u-dev. Please, help to review JDK8 changes too: http://cr.openjdk.java.net/~aefimov/8134111/8/00/ Both JDK8/9 changes were tested with JCK/JTREG tests and no failures were observed. Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8134111 [2] https://bugs.openjdk.java.net/browse/JDK-8150174 [3] http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/ebff1bd3627a#l2.1

2 1

JAXP default implementation and JDK-8152063
by David M. Lloyd 31 Mar '16

31 Mar '16

This message is in reference to the aforementioned issue [1] that I've requested my colleague Andrew Hughes to open on my behalf. As expressed in that issue, the means of specifying a JAXP default provider (via system property which specifies a class name on the application class path) is relatively antiquated at this point. It is actually quite difficult for containers which ship their own JAXP implementation to use the JDK APIs and, at the same time, ship their own implementations, especially without polluting the class path of applications which use JAXP. This situation is made worse by Jigsaw in the respect that removing direct access to the default JDK implementation classes consequently eliminates one of the few possible workarounds to this problem (not to mention the dissonance between the system property approach and modules in general), which is the motivation for opening this issue. I propose that there be made available a mechanism by which a default implementation Class<xx> (or a Supplier<xx>) can be established programmatically by sufficiently privileged code. In the absence of dissent or other discussion, I intend to propose a webrev which implements this functionality against the jdk9/jdk9 tree. Any preliminary feedback is greatly appreciated. [1] https://bugs.openjdk.java.net/browse/JDK-8152063 -- - DML

7 34

RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors
by Paul Sandoz 31 Mar '16

31 Mar '16

Hi, Please pre-emptively review a fix to update the buffer implementations to leverage the Unsafe unaligned accessors: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligne… http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligne… The JDK changes depend on those for the following which is in CCC review: https://bugs.openjdk.java.net/browse/JDK-8149469 ByteBuffer API and implementation enhancements for VarHandles http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149469-byte-buffer-align-and-… The changes in this webrev take advantage of those for JDK-8149469 and apply the unsafe double addressing scheme so certain byte buffer view implementations can work across heap and direct buffers. This should improve the performance on x86 for: 1) direct ByteBuffers using the wider unit size method accessors; and 2) wider unit size views over heap ByteBuffers. As a consequence Bits.java has greatly reduced in size :-) The HotSpot changes update the test that was originally added when the heap ByteBuffer method accessors were updated to utilise unsafe unaligned access. I split the test out so as to reduce the execution time, since I doubled the amount of tests. These tests could be improved for views at various unaligned/unaligned positions in the byte buffer, but i left that for now. I plan to push through hs-comp since JDK-8149469 will go through hs-comp. Later on today i will kick of a JPRT hotspot test run. — This is a small step towards unifying the buffer implementations using the unsafe double addressing scheme: https://bugs.openjdk.java.net/browse/JDK-6509032 Thanks, Paul.

5 12

RFR: 8079136: Accessing a nested sublist leads to StackOverflowError
by Ivan Gerasimov 31 Mar '16

31 Mar '16

Hello! When creating a sublist with List.subList(), it keeps a reference to its parent. Then, when accessing (get(), set(), add(), remove(), etc.) the sublist, it recursively calls the corresponding methods of its parent. This recursion, when deep enough, can cause StackOverflowError. The only reason to do things recursively here, is the need to update modCount and size of all the parents. So, the proposal is to update these fields in a loop. A few cleanups were done along the way. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8079136 WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/0/webrev/ Sincerely yours, Ivan

9 45

Review request 8153035: GenModuleInfoSource strips away the API
by Mandy Chung 31 Mar '16

31 Mar '16

GenModuleInfoSource is a build tool that augments module-info.java with platform-specific declaration such as exports, uses and provides and generates the resulting module-info.java in gensrc directory. This utility should really be a simple one that inserts/appends the extra info to the original module-info.java. The patch replaces the old code and removes the unused files that were used for modules.xml. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153035/webrev.00/ Mandy

3 3

8153118 Remove sun.misc.resources
by Chris Hegarty 31 Mar '16

31 Mar '16

sun.misc.resources claims to contain a ResourceBundle for sun.misc, which has localized versions of messages for "bad" jar files, such as: "optpkg.versionerror", "ERROR: Invalid version format used in {0} JAR file. Check the documentation for the supported version format." "optpkg.attributeerror", "ERROR: The required {0} JAR manifest attribute is not set in {1} JAR file." "optpkg.attributeserror", "ERROR: Some required JAR manifest attributes are not set in {0} JAR file." These error message appear to not be used, either by the JDK itself, or elsewhere. I assume that there was a consumer of these at one point, but has long since been refactored away. http://cr.openjdk.java.net/~chegar/8153118/ https://bugs.openjdk.java.net/browse/JDK-8153118 -Chris.

4 4

JDK 9 RFR of JDK-8153147: Mark java/net/BindException/Test.java as intermittently failing
by Amy Lu 31 Mar '16

31 Mar '16

java/net/BindException/Test.java This test is known to fail intermittently (JDK-8073353). This patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8153147 webrev: http://cr.openjdk.java.net/~amlu/8153147/webrev.00/ Thanks, Amy --- old/test/java/net/BindException/Test.java 2016-03-31 11:26:45.000000000 +0800 +++ new/test/java/net/BindException/Test.java 2016-03-31 11:26:45.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2016, 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 @@ -24,6 +24,7 @@ /* * @test * @bug 4417734 + * @key intermittent * @summary Test that we get a BindException in all expected combinations */ import java.net.*;

2 1

JDK 9 RFR of JDK-8151763; Use more informative format for problem list
by joe darcy 31 Mar '16

31 Mar '16

Hello, As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the bug number in a comment. Please review the webrev to adopt the revised format for the problem list: http://cr.openjdk.java.net/~darcy/8151763.0/ I've verified jtreg produces the same test list with the old and new versions of the problem list. Thanks, -Joe

7 16

JDK 9 (JAXP) RFR JDK-8147431: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
by huizhe wang 30 Mar '16

30 Mar '16

This test is prone to intermittent failures due to the copy of the JDK. I'm adding it to the problem list (jaxp/test/ProblemList.txt). We do have similar tests in this area in the JCK. JBS: https://bugs.openjdk.java.net/browse/JDK-8147431 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8147431/ Thanks, Joe

2 2

RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type
by Joel Borggrén-Franck 30 Mar '16

30 Mar '16

Hi, When reflecting over annotated types, there is currently no way to get the potentially annotated owner of a type. For example, given you have an instance of '@A Outer . @B Inner' you can't traverse it to get '@A Outer' . This API addition fixes this. Because both parameterized and non-generic types can have an owner, this addition goes into the base AnnotatedType interface together with a default implementation. CCC has been filed. The parsing code and annotated type factory had to be fixed to deal with navigating inside nested types. Bug: https://bugs.openjdk.java.net/browse/JDK-8057804 Webrev: http://cr.openjdk.java.net/~rbackman/jbf/8057804/webrev.00/ (OCA is signed and processed). Cheers /Joel

7 14