February 2017 - core-libs-dev

ByteBuffer to CharBuffer
by Jay 24 Feb '17

24 Feb '17

java.nio.ByteBuffer provides a method asCharBuffer() which returns a "view" of the ByteBuffer as a character buffer. It however does not take any arguments. And there is no mention in the Javadocs as to how it converts from bytes to chars. 1. There should be a method ByteBuffer.asCharBuffer(CharSet) and/or ByteBuffer.asCharBuffer(String charSet) which allows the user to explicitly specify the character set to be used for conversion. 2. The method ByteBuffer.asCharBuffer() should mention that this method uses the platform default charset for bytes-to-chars conversion. I can provide a patch with these two changes. What do you guys think? -- Regards Jay

7 7

RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes JDK under test
by Mark Sheppard 24 Feb '17

24 Feb '17

Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8175177/webrev/ for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8175177 the test now explicitly removes the orb.properties file created by the test. regards Mark

4 5

Future plans for sun.misc.Contended
by Vitaly Davidovich 23 Feb '17

23 Feb '17

Hi all, I'm curious if anyone knows the future plans for this annotation, specifically if it's slated to become officially supported in Java SE and if so, what the timeline looks like (if that exists). My understanding was it's in sun.misc as an experimental/"unstable" annotation, but that it was incubating there before being made supported (and moved out of that package) as it's a legitimately useful feature (the manual padding one does today with class hierarchy and unused padding fields is atrocious, as some of you may know). Thanks

2 2

RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar
by Baesken, Matthias 23 Feb '17

23 Feb '17

Here is the webrev for jdk9 : http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/ ? And btw I really wonder - is jexec still needed in future jdk's like jdk10 ? Seems it is not used much . ? In case jexec will stay in the jdk I might add a test for the tool as well, if there is interest ( could not really find one that tests execution of a simple jar-file with jexec). Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 23. Februar 2017 07:39 To: 'core-libs-dev(a)openjdk.java.net' <core-libs-dev(a)openjdk.java.net> Cc: Langer, Christoph <christoph.langer(a)sap.com>; Erik Joelsson (erik.joelsson(a)oracle.com) <erik.joelsson(a)oracle.com> Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hello, probably I should add the info that the fix is needed in jdk9 as well , not only jdk10 . Without the fix jdk9/10 show this error when executing a small example jar : /myjdk9/images/jdk/lib/jexec /java_test/hellojar/helloworld.jar invalid file (bad magic number): Exec format error with the fix : jdk/lib/jexec /java_test/hellojar/helloworld.jar Hello world from a jar file And btw I really wonder - is jexec still needed in future jdk's like jdk10 ? Seems it is not used much . Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 22. Februar 2017 18:16 To: core-libs-dev(a)openjdk.java.net<mailto:core-libs-dev@openjdk.java.net> Cc: Langer, Christoph <christoph.langer(a)sap.com<mailto:christoph.langer@sap.com>>; Erik Joelsson (erik.joelsson(a)oracle.com<mailto:erik.joelsson@oracle.com>) <erik.joelsson(a)oracle.com<mailto:erik.joelsson@oracle.com>> Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hello , when looking into the jexec build I noticed that execution of a simple helloworld.jar with jexec does not work any more. I did a little patch for this which adjusted the addition done with CR 8156478: 3 Buffer overrun defect groups in jexec.c<https://javapartner.oracle.com/mproxy/repository/technology/java2/jdk9/jdk/…> . Could I have a review ( just a diff this time is provided because of infrastructure issues) for it ? Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8175000 Diff for jdk10 : # HG changeset patch # User mbaesken # Date 1487782485 -3600 # Wed Feb 22 17:54:45 2017 +0100 # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 # Parent 884872263accabd4ab68d005abd4e5393144aa4f 8175000: jexec fails to execute simple helloworld.jar diff --git a/src/java.base/unix/native/launcher/jexec.c b/src/java.base/unix/native/launcher/jexec.c --- a/src/java.base/unix/native/launcher/jexec.c +++ b/src/java.base/unix/native/launcher/jexec.c @@ -331,8 +331,9 @@ off_t end = start + xlen; if (end <= count) { - end -= 4; // make sure there are 4 bytes to read at start - while (start < end) { + // make sure there are 4 bytes to read at start + end -= 3; + while ((start < end) && (start < count-3)) { off_t xhid = SH(buf, start); off_t xdlen = SH(buf, start + 2);

1 0

RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar
by Baesken, Matthias 23 Feb '17

23 Feb '17

Hello, probably I should add the info that the fix is needed in jdk9 as well , not only jdk10 . Without the fix jdk9/10 show this error when executing a small example jar : /myjdk9/images/jdk/lib/jexec /java_test/hellojar/helloworld.jar invalid file (bad magic number): Exec format error with the fix : jdk/lib/jexec /java_test/hellojar/helloworld.jar Hello world from a jar file And btw I really wonder - is jexec still needed in future jdk's like jdk10 ? Seems it is not used much . Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 22. Februar 2017 18:16 To: core-libs-dev(a)openjdk.java.net Cc: Langer, Christoph <christoph.langer(a)sap.com>; Erik Joelsson (erik.joelsson(a)oracle.com) <erik.joelsson(a)oracle.com> Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hello , when looking into the jexec build I noticed that execution of a simple helloworld.jar with jexec does not work any more. I did a little patch for this which adjusted the addition done with CR 8156478: 3 Buffer overrun defect groups in jexec.c<https://javapartner.oracle.com/mproxy/repository/technology/java2/jdk9/jdk/…> . Could I have a review ( just a diff this time is provided because of infrastructure issues) for it ? Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8175000 Diff for jdk10 : # HG changeset patch # User mbaesken # Date 1487782485 -3600 # Wed Feb 22 17:54:45 2017 +0100 # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 # Parent 884872263accabd4ab68d005abd4e5393144aa4f 8175000: jexec fails to execute simple helloworld.jar diff --git a/src/java.base/unix/native/launcher/jexec.c b/src/java.base/unix/native/launcher/jexec.c --- a/src/java.base/unix/native/launcher/jexec.c +++ b/src/java.base/unix/native/launcher/jexec.c @@ -331,8 +331,9 @@ off_t end = start + xlen; if (end <= count) { - end -= 4; // make sure there are 4 bytes to read at start - while (start < end) { + // make sure there are 4 bytes to read at start + end -= 3; + while ((start < end) && (start < count-3)) { off_t xhid = SH(buf, start); off_t xdlen = SH(buf, start + 2);

1 0

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

23 Feb '17

Hi Joe, please finally review this fix for JDK10: http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.1/ This version contains the Java property "jdk.xml.generatePrefix" which we should have no matter on which default we decide. In my customer base I have customers that need it either way - depending from where their legacy apps or custom developments come, XALAN XSLTC or other XML frameworks. This proposal sets the prefix generation default for xsl:element to false - maybe we should try it for 10? Also, do we need a ccc for 10? I would appreciate if I could get this item completed soon as I want to get it out of my backlog. Thanks and best regards Christoph From: Langer, Christoph Sent: Montag, 13. Februar 2017 16:15 To: 'huizhe wang' <huizhe.wang(a)oracle.com> Cc: core-libs-dev(a)openjdk.java.net; Aleksej Efimov <aleksej.efimov(a)oracle.com> Subject: 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 test/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java needs to go then as it would be obsolete and would fail. Other than that, I ran the jtreg tests and found no other issues. Thanks Christoph From: huizhe wang [mailto:huizhe.wang@oracle.com] Sent: Donnerstag, 9. Februar 2017 17:25 To: Langer, Christoph <christoph.langer(a)sap.com<mailto:christoph.langer@sap.com>> Cc: core-libs-dev(a)openjdk.java.net<mailto:core-libs-dev@openjdk.java.net>; Aleksej Efimov <aleksej.efimov(a)oracle.com<mailto:aleksej.efimov@oracle.com>> Subject: Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only On 2/7/2017 11:28 PM, Langer, Christoph wrote: Hi Joe, welcome back. Thanks! This sounds reasonable. I'll prepare a change for JDK10. Hopefully it'd open soon so that you don't have to keep it for too long. Best, Joe Thanks Christoph From: Joe Wang [mailto:huizhe.wang@oracle.com] Sent: Mittwoch, 8. Februar 2017 01:39 To: Langer, Christoph <christoph.langer(a)sap.com><mailto:christoph.langer@sap.com> Cc: core-libs-dev(a)openjdk.java.net<mailto:core-libs-dev@openjdk.java.net>; Aleksej Efimov <aleksej.efimov(a)oracle.com><mailto:aleksej.efimov@oracle.com> Subject: Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only Hi Christoph, As we discussed, let's target this for JDK 10 as a spec change at this stage for JDK 9 is too late. Removing the namespace generation would be another reason to do this in JDK 10 since then, we wouldn't need the additional property. Thanks, Joe On 1/31/17, 11:02 AM, Langer, Christoph wrote: Hi Joe, evenutally I have updated my webrev for this issue: http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/<http://cr.openjdk.java.net/%7Eclanger/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<mailto:core-libs-dev@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/<http://cr.openjdk.java.net/%7Eclanger/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 2

RFR 8175360 Error in Collectors.averagingXXX Java Doc
by Paul Sandoz 22 Feb '17

22 Feb '17

Hi Please review this small documentation fix to the averaging functions on java.util.stream.Collectors. Paul. diff -r 29059b8ecc7f src/java.base/share/classes/java/util/stream/Collectors.java --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue Feb 21 05:58:23 2017 -0800 +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Wed Feb 22 12:59:06 2017 -0800 @@ -720,8 +720,9 @@ * the result is 0. * * @param <T> the type of the input elements - * @param mapper a function extracting the property to be summed - * @return a {@code Collector} that produces the sum of a derived property + * @param mapper a function extracting the property to be averaged + * @return a {@code Collector} that produces the arithmetic mean of a + * derived property */ public static <T> Collector<T, ?, Double> averagingInt(ToIntFunction<? super T> mapper) { @@ -738,8 +739,9 @@ * the result is 0. * * @param <T> the type of the input elements - * @param mapper a function extracting the property to be summed - * @return a {@code Collector} that produces the sum of a derived property + * @param mapper a function extracting the property to be averaged + * @return a {@code Collector} that produces the arithmetic mean of a + * derived property */ public static <T> Collector<T, ?, Double> averagingLong(ToLongFunction<? super T> mapper) { @@ -769,8 +771,9 @@ * 2<sup>53</sup>, leading to additional numerical errors. * * @param <T> the type of the input elements - * @param mapper a function extracting the property to be summed - * @return a {@code Collector} that produces the sum of a derived property + * @param mapper a function extracting the property to be averaged + * @return a {@code Collector} that produces the arithmetic mean of a + * derived property */ public static <T> Collector<T, ?, Double> averagingDouble(ToDoubleFunction<? super T> mapper) {

2 1

RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar
by Baesken, Matthias 22 Feb '17

22 Feb '17

Hello , when looking into the jexec build I noticed that execution of a simple helloworld.jar with jexec does not work any more. I did a little patch for this which adjusted the addition done with CR 8156478: 3 Buffer overrun defect groups in jexec.c<https://javapartner.oracle.com/mproxy/repository/technology/java2/jdk9/jdk/…> . Could I have a review ( just a diff this time is provided because of infrastructure issues) for it ? Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8175000 Diff for jdk10 : # HG changeset patch # User mbaesken # Date 1487782485 -3600 # Wed Feb 22 17:54:45 2017 +0100 # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 # Parent 884872263accabd4ab68d005abd4e5393144aa4f 8175000: jexec fails to execute simple helloworld.jar diff --git a/src/java.base/unix/native/launcher/jexec.c b/src/java.base/unix/native/launcher/jexec.c --- a/src/java.base/unix/native/launcher/jexec.c +++ b/src/java.base/unix/native/launcher/jexec.c @@ -331,8 +331,9 @@ off_t end = start + xlen; if (end <= count) { - end -= 4; // make sure there are 4 bytes to read at start - while (start < end) { + // make sure there are 4 bytes to read at start + end -= 3; + while ((start < end) && (start < count-3)) { off_t xhid = SH(buf, start); off_t xdlen = SH(buf, start + 2);

1 0

[10] RFR: 8175233: Remove LambdaForm.debugName
by Claes Redestad 22 Feb '17

22 Feb '17

Hi, the LambdaForm.debugName field is useful for debugging, but names are generated and retained in this field also for production code, which is then used to name generated methods and classes. This patch suggests to extract this field and make the debug name an external mapping that is only generated (and used) when actually debugging, while using LambdaForm.Kinds to guide the naming of classes and methods generated in production mode. This also fixes(?) a subtle bug that when transforming a LambdaForm using LambdaFormEditors the debugName was retained through all transformations, which leads to confusing/surprising results (since many transformations starts out with a BMH.reinvoker and is then transformed via editor manipulations, most generated forms appear to be BMH.reinvokers when in fact they aren't). Bug: https://bugs.openjdk.java.net/browse/JDK-8175233 Webrevs: http://cr.openjdk.java.net/~redestad/8175233/jdk.01/ http://cr.openjdk.java.net/~redestad/8175233/hotspot.01/ Testing: - Pre-checkin testing on all platforms - Locally tested java.lang.invoke tests with and without -Djava.lang.invoke.MethodHandle.DEBUG_NAMES=true - Ensured -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true behaves as intended - Made sure the changes don't clash with JDK-8172298 Thanks! /Claes

4 6

SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed
by Pavel Bucek 21 Feb '17

21 Feb '17

Hi all, firstly - please let me know if this is is a wrong place to send this; I wasn't able to find list specific to concurrency. Consider following example: { SubmissionPublisher<String> publisher =new SubmissionPublisher<>(); publisher.subscribe(new Flow.Subscriber<String>() { @Override public void onSubscribe(Flow.Subscription subscription) { } @Override public void onNext(String item) { } @Override public void onError(Throwable throwable) { System.out.println("onError()"); } @Override public void onComplete() { System.out.println("onComplete()"); } }); publisher.submit("item");// if this is commented out, #onComplete is invoked. publisher.close(); } I'd expect that Subscriber#onComplete is invoked after calling publisher.close(), but it is not happening. Curiously, when I comment out 'publisher.submit("item")', Subscriber#onComplete is indeed invoked. SubmissionPublisher#close() javadoc says: /** * Unless already closed, issues {@link * Flow.Subscriber#onComplete() onComplete} signals to current * subscribers, and disallows subsequent attempts to publish. * Upon return, this method does <em>NOT</em>guarantee that all * subscribers have yet completed. */ So it seems like it will be invoked in different thread or something like that, but it is not invoked ever (or more precisely - not during 10 second after the publisher is closed. There is nothing else running on that particular jvm instance). Also, publisher#isClosed() returns true and publisher#getNumberOfSubscribers() returns 0. I'm using Java(TM) SE Runtime Environment (build 9-ea+157-jigsaw-nightly-h6115-20170219) What am I doing wrong? Thanks and regards, Pavel

4 9