February 2018 - core-libs-dev

RFR: JDK-8197594: String#repeat
by Jim Laskey 03 Mar '18

03 Mar '18

Introduction of a new instance method String::repeat to allow an efficient and concise approach for generating repeated character sequences as strings. Performance information in JBS. Thank you. Cheers, — Jim JBS: https://bugs.openjdk.java.net/browse/JDK-8197594 <https://bugs.openjdk.java.net/browse/JDK-8197594> CSR: https://bugs.openjdk.java.net/browse/JDK-8198296 <http://cr.openjdk.java.net/~jlaskey/8197594/String.html> Webrev: http://cr.openjdk.java.net/~jlaskey/8197594/webrev-02/index.html <http://cr.openjdk.java.net/~jlaskey/8197594/webrev-02/index.html> JavaDoc: http://cr.openjdk.java.net/~jlaskey/8197594/String.html <http://cr.openjdk.java.net/~jlaskey/8197594/String.html>

10 16

RFR 8198697: Simplify platform encoding initialization tweak
by Roger Riggs 02 Mar '18

02 Mar '18

Hi, In an effort to untangle some of the issues with property initialization I was looking at the platform encoding initialization and found a simplification. Currently, the initialization occurs as a side effect of the first call to JNU_NewStringPlatform and involves a upcall to get sun.jnu.encoding from the system properties. The value is cached for later use. The native System.initProperties determines the platform specific encoding via java_props_md.c and does an upcall to set the sun.jnu.encoding system property, taking care to do it before the first string that needs platform encoding. The change directly initializes the platform encoding fast path before it is needed to encode platform strings. And moves the setting sun.jnu.encoding system property after the command line arguments are inserted keeping it from being overridden by -D on the command line that can only confuse confusion with code that later reads the property. Please review and comment. webrev: http://cr.openjdk.java.net/~rriggs/webrev-simplify-jnu-8198697/ Issue: https://bugs.openjdk.java.net/browse/JDK-8198697 Thanks, Roger

3 5

RFR JDK-8187653: Lock in CoderResult.Cache becomes performance bottleneck
by Xueming Shen 02 Mar '18

02 Mar '18

Hi, Please help review the proposed change to remove the potential performance bottleneck in CoderResult caused by the "over" synchronization the cache mechanism. issue: https://bugs.openjdk.java.net/browse/JDK-8187653 webrev: http://cr.openjdk.java.net/~sherman/8187653/webrev Notes: While the original test case (new String/String.getBytes() with UTF8 as showed in the stacktrace) described in the bug report might no longer be reproducible in jdk9, as we have been optimizing lots of String related char[]/byte[] coding path away from the paths that use CoderResult. But it is still a concern/issue for the "general" CharsetDe/Encoder.de/encode() operation, in which the malformed or unmappable CoderResult object is returned. As showed in the "[synchronized]" section in bm.scores [1], which is from the simple jmh benchmark test CoderResultBM.java [2], the sores are getting significant worse when the number of concurrent de/encoding threads gets bigger. It appears the easy fix is to replace the sync mechanism from "method synchronized + HashMap" to "ConcurrentHashMap" solves the problem, as showed in the same bm result [1] in [ConcurrentHashMap] section, because most of the accesses to the caching HashMap is read operation. The ConcurrentHahsMap's "almost non-block for retrieval operation" really helps here. There is another fact that might help us optimize further here. For most of our charsets in JDK repository (with couple exceptions), the length of malformed and unmappable CoderResult that these charsets might trigger actually is never longer than 4. So we might not need to access the ConcurrentHashMap cache at all in normal use scenario. I'm putting a CoderResult[4] on top the hashmap cache in proposed webrev. It does not improve the performance significantly, but when the thread number gets bigger, a 10%+ improvement is observed. So I would assume it might be something worth doing, given its cost is really low. Thanks, Sherman [1] http://cr.openjdk.java.net/~sherman/8187653/bm.scores [2] http://cr.openjdk.java.net/~sherman/8187653/CoderResultBM.java [3] http://cr.openjdk.java.net/~sherman/8187653/bm.scores.ms932

6 10

RFR: Here are some URLClassPath patches
by Martin Buchholz 02 Mar '18

02 Mar '18

At Google I spend a lot of time staring unproductively at classloader code, and it's always hard for me to resist the urge to clean it up. So here are some patches that should be relatively uncontroversial, and may prepare for more radical changes later. 8198480: Improve ClassLoaders static init block http://cr.openjdk.java.net/~martin/webrevs/jdk/ClassLoaders-static/ https://bugs.openjdk.java.net/browse/JDK-8198480 8198481: Coding style cleanups for src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java http://cr.openjdk.java.net/~martin/webrevs/jdk/loader-style/ https://bugs.openjdk.java.net/browse/JDK-8198481 8198482: The URLClassPath field "urls" should be renamed to "unopenedUrls" http://cr.openjdk.java.net/~martin/webrevs/jdk/URLClassPath-rename-urls/ https://bugs.openjdk.java.net/browse/JDK-8198482 8198484: URLClassPath should use an ArrayDeque instead of a Stack http://cr.openjdk.java.net/~martin/webrevs/jdk/URLClassPath-ArrayDeque/ https://bugs.openjdk.java.net/browse/JDK-8198484 8198485: Simplify a URLClassPath constructor http://cr.openjdk.java.net/~martin/webrevs/jdk/URLClassPath-simplify-constr… https://bugs.openjdk.java.net/browse/JDK-8198485

9 38

RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java
by Adam Farley8 02 Mar '18

02 Mar '18

Resending. Bump. :) On 14/02/2018 14:13, Adam Farley8 wrote: >> Hi All, >> >> -- Short version -- >> >> Could a committer please take the fix for JDK-8190187 (full code included >> in the bug) and: >> >> 1) Complete the CSR process for the new JNI Return code. >> 2) Commit the changes that contain (a) the new return code, and (b) the >> non-Hotspot code that handles the new code. > The patches attached to the JIRA issue are missing the changes to the > JVM TI spec (jvmti.xml). I'm not seeing the JNI return codes in that file. Are you after one of those dated updates near the bottom? e.g. ``` <change date="14 February 2018" version="11.0.0"> Added JNI_SILENT_EXIT return code for early exits without errors. java.c's ParseArguments function now sets pret value to 2 for a NULL pwhat. This allows us to clearly identify when no class was set, but no other error has occurred. This is undone in java.c's ContinueInNewThread method, so the surface behaviour does not change. </change> ``` > There is also text to be written for the JNI spec if this proposal goes > ahead. I assume you mean the "RETURNS" section of the JNI_CreateJavaVM bit on the invocation.html web page. Something like this? ``` RETURNS: Returns JNI_OK on success; returns a suitable JNI error code (a negative number) on failure. The sole exception is a silent exit, which returns JNI error code JNI_SILENT_EXIT. This indicates that the VM cannot be used, but that this is the intended behaviour for the arguments used. E.g. -Xlog:help (which prints help output and then destroys the VM) ``` > > I don't agree that the launcher should be looking for > "-agentlib:jdwp=help" in the command line as it's just one of many ways > that the debugger agent might be started (e.g. -Xrunjdwp:<options>, > _JAVA_TOOLS_OPTIONS, ...). We can avoid that by finding a way around this line in ContinueInNewThread (java.c): ``` return (ret != 0) ? ret : rslt; ``` I have devised a means to do this, as outlined in the jvmti.xml change above. I put the changes into a recent clone of jdk/jdk, and attached the hg diff, along with an improved test. If you have Author or Committer privileges, could you add the files to the bug please? > >> Backporting would be appreciated, but is optional. > I don't think these changes are appropriate to backport as they include > specification changes/ > >-Alan This is fair. - Adam Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

2 2

RFR JDK-8197533 move javax.transaction.xa into its own module
by Lance Andersen 02 Mar '18

02 Mar '18

Hi all, This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. There should be no compatibility issues with this change. Any module that `requires java.sql` will continue to have access to the public classes in the javax.transaction.xa package at both compile-time and run-time. The CSR has been approved The webrev can be found at: http://cr.openjdk.java.net/~lancea/8197533/webrev.00/ Best Lance <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>

5 13

Oracle Java 8u161 regression in XML Schema Factory
by Bernd 02 Mar '18

02 Mar '18

Hello, some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and u162) but work with 8u152. I cant reproduce the fault in a stand-alone program so it seems to be related to classloader/reflection magic of those tools, sorry. Is this a regression of 8159240 <http://bugs.java.com/view_bug.do?bug_id=JDK-8159240> (not public?) Here is the stacktrace anyway: com.sun.org.apache.xerces.internal.impl.dv.DVFactoryException: Schema factory class com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl does not extend from SchemaDVFactory. at com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:75) at com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:57) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.reset(XMLSchemaLoader.java:1024) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:556) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:535) at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:254) at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638) at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:654) at com.seeburger.api.test.helpers.BuilderTestHelper.getCRSchemaValidator(BuilderTestHelper.java:57) at com.seeburger.api.test.helpers.BuilderTestHelper.validateAndCompare(BuilderTestHelper.java:73) at com.seeburger.api.test.KSMBuilderTest.testDeletePGP(KSMBuilderTest.java:196) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:68) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:310) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:89) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:97) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:294) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:127) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:82) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:282) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:50) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:207) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:146) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:120) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:122) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:106) at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53) at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:59) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207) on the classpath jaxb-impl-2.2.5.jar but the specific packages are only loaded from rt.jar and redefined. I asume the later is done by Powermock. Line 611: [Loaded com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory from C:\Program Files\Java\jdk1.8.0_161\jre\lib\rt.jar] Line 616: [Loaded com.sun.org.apache.xerces.internal.impl.dv.xs.BaseSchemaDVFactory from C:\Program Files\Java\jdk1.8.0_161\jre\lib\rt.jar] Line 617: [Loaded com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl from C:\Program Files\Java\jdk1.8.0_161\jre\lib\rt.jar] Line 618: [Loaded com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory from __JVM_DefineClass__] Line 619: [Loaded com.sun.org.apache.xerces.internal.impl.dv.xs.BaseSchemaDVFactory from __JVM_DefineClass__] Line 620: [Loaded com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl from __JVM_DefineClass__] Is that something you are concerned? Gruss Bernd <http://bugs.java.com/view_bug.do?bug_id=JDK-8159240>

6 12

Re: Manifest Related Bugs JDK-6372077, JDK-6202130, JDK-8176843, JDK-4842483, JDK-6443578, JDK-6910466, JDK-4935610, and JDK-4271239
by Sean Mullan 01 Mar '18

01 Mar '18

Hi Phillip, All of these bugs are in the core-libs area, so I am copying the core-libs-dev list since that is where they should be discussed and reviewed. I have -bcc-ed security-dev (where this was originally posted). --Sean On 10/2/17 1:24 PM, Philipp Kunz wrote: > Hi, > > While fixing JDK-6695402 I came across other related bugs to manifests > such as JDK-6372077, JDK-6202130, JDK-8176843, JDK-4842483, and > JDK-6443578 which all relate to manifest reading and writing. Somewhere > bug 7071055 is mentioned but I cannot find anywhere. Another group of > bugs, JDK-6910466, JDK-4935610, and JDK-4271239 concern the mandatory > manifest main attributes Manifest-Version or Signature-Version and at > first glance are duplicates. If you know of more known bugs, not > necessarily present in jira, I'd be glad to get notified. > > There are also some comments about utf handling and line breaking in the > code of Manifest: > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > > Furthermore, Attributes.map should declare appropriate type parameters: > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > The specification would also require that `header names must not start > with _, - or "From"` > (http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Section-…) > but I would opt not to add this as a hard restriction because I guess it > can be assumed that such names are in use now after having been working > for years. A warning to a logger might be conceivable such as in > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > Attribute values are never checked at all and invalid characters such as > line breaks are never detected except that when reading the manifest > again the values are cut off. > The tab character (U+0008) does not work in manifest values. > I suspect that there are also issues regarding the iteration order but I > haven't got a prove yet unlike for the other points above: > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > There is duplicated or very similar code in Attributes and Manifest: > Attributes.write-Manifest.write-Attributes.writeMain and > Attributes.read-Manifest.read. > Resolving JDK-6202130 would have the additional benefit to be able to > view manifests with any utf-8 capable editor even if multi-byte > characters break across lines. > > Fixing these issues individually looks like more complicated work than > fixing them all at once, I guess, also because of a very low current > test coverage. So I'd suggest to add some thorough tests along with > fixing these issues. But before I start I would like to get some > guidance, assistance or at least confirmation on how to proceed. I'm new > to open jdk and have submitted only one patch so far. > > Is it ok to add tests for things that have worked before? > Is it ok to refactor duplicated code just for the added value to reduce > effort for testing? > I assume compatibility to and from existing manifests is the highest > priority, correct? This would also be the hard part in adding as > complete test coverage as possible. What would be acceptable criteria to > meet? > Why does Attributes not extend LinkedHashMap and why does Manifest not > extend HashMap? Any objection? > While I would not want to write code that looks slow or change more than > necessary one can never know before having performance actually > measured. Is there some way this is dealt with or should I wait for such > feedback until after patch submission? > > Would someone sponsor? > > Regards, > Philipp > > > > > ------------------------------------------------------------------------ > > > > Paratix GmbH > St Peterhofstatt 11 > 8001 Zürich > > +41 (0)76 397 79 35 > philipp.kunz(a)paratix.ch <mailto:philipp.kunz@paratix.ch>

5 12

RFR 8196298 Add null Reader and Writer
by Patrick Reinhart 28 Feb '18

28 Feb '18

Hi every boy that reviewed I tried to incorporate all feedback I received so far and updated the webrev accordingly: http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.01 -Patrick

1 0

RFR: 8193660 Check SOURCE line in "release" file for closedjdk
by Randy Crihfield 28 Feb '18

28 Feb '18

I need to revise the resource file test created for JDK-8192837 The new bug is https://bugs.openjdk.java.net/browse/JDK-8193660 The webrev is located at http://cr.openjdk.java.net/~shurailine/8193660/webrev.00/ <http://cr.openjdk.java.net/%7Eshurailine/8193660/webrev.00/> Any comments/suggestions are welcome, also I will need a sponsor for it at the end… Randy

2 3