February 2015 - core-libs-dev

8068680: Move java.transaction to the ext class loader
by Alan Bateman 16 Feb '15

16 Feb '15

Now that the types in the java.corba module are moved to the extension loader, it is time to move java.transaction and further our quest to move all of the EE/upgradeable modules to the ext loader. This one is easy as there isn't any permissions and other security adjustments needed. It's just re-assigning the module to the ext loader. I've used the opportunity to re-sort the boot.modules and ext.modules files used by the build as they seem to have become unsorted with recent edits. -Alan diff --git a/make/src/classes/build/tools/module/boot.modules b/make/src/classes/build/tools/module/boot.modules --- a/make/src/classes/build/tools/module/boot.modules +++ b/make/src/classes/build/tools/module/boot.modules @@ -1,6 +1,6 @@ java.base +java.compiler java.desktop -java.compiler java.instrument java.logging java.management @@ -13,7 +13,6 @@ java.smartcardio java.sql java.sql.rowset -java.transaction java.xml java.xml.crypto jdk.charsets @@ -21,9 +20,9 @@ jdk.deploy.osx jdk.hprof.agent jdk.httpserver +jdk.jfr jdk.naming.rmi jdk.sctp jdk.security.auth jdk.security.jgss -jdk.jfr jdk.snmp diff --git a/make/src/classes/build/tools/module/ext.modules b/make/src/classes/build/tools/module/ext.modules --- a/make/src/classes/build/tools/module/ext.modules +++ b/make/src/classes/build/tools/module/ext.modules @@ -1,8 +1,10 @@ -java.corba java.activation java.annotations.common +java.corba +java.transaction java.xml.bind java.xml.ws +jdk.accessbridge jdk.crypto.ec jdk.crypto.mscapi jdk.crypto.pkcs11 @@ -11,4 +13,3 @@ jdk.naming.dns jdk.scripting.nashorn jdk.zipfs -jdk.accessbridge

3 2

RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
by Staffan Larsen 16 Feb '15

16 Feb '15

Hi, Please review this patch for hiding the lambda proxy frame in stack traces: bug: https://bugs.openjdk.java.net/browse/JDK-8025636 <https://bugs.openjdk.java.net/browse/JDK-8025636> webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/ <http://cr.openjdk.java.net/~sla/8025636/webrev.00/> This is a straightforward addition of the LambdaForm$Hidden annotation to the generated methods. What is surprising is that this works even if LambdaForm$Hidden is a package-private class in java.lang.invoke and thus not accessible from most of the generated classes. There is some discussion of and answers to this in the bug, but essentially this works because the annotation class is never resolved and the code in Hotspot that looks for the annotation amounts to nothing more than string comparisons. Hidden stack frames can be shown by running with “-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames”. For an example of what this patch does, consider this code: Runnable r = () -> { throw new RuntimeException(); }; r.run(); Previously, this would output: java.lang.RuntimeException at pkg.Foo.lambda$main$0(Foo.java:5) at pkg.Foo$$Lambda$1/2001112025.run(<Unknown>:1000000) at pkg.Foo.main(Foo.java:15) With the patch it looks like this: java.lang.RuntimeException at pkg.Foo.lambda$main$0(Foo.java:5) at pkg.Foo.main(Foo.java:15) Thanks, /Staffan

4 4

RFR(S): JDK-8073175, 8073174: Fix native warnings in libjli and libfdlibm
by Dmitry Samersoff 15 Feb '15

15 Feb '15

Hi Everyone, It's my $0.02 to the warning cleanup work. Please review: http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01 http://cr.openjdk.java.net/~dsamersoff/JDK-8073174/webrev.01 Notes: 1. There are two common ways to cast pointer to int: intptr_t (perfectly safe, more-or-less portable) and size_t (perfectly portable, more-or-less safe) So I use size_t in shared code, intptr_t in UNIX specific code. 2. I didn't fix "format not a string literal" warnings. It requires to set per-compiler pragmas. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

2 1

RFR 8064924: Update java.net.URL to work with modules
by Chris Hegarty 13 Feb '15

13 Feb '15

This is phase 1, of getting java.net.URL work with modules. Being able to effectively specify URL protocol handler factories as fully qualified class names, through the 'java.protocol.handler.pkgs' system property is problematic. It requires the protocol handler factory implementation class to be public and accessible, as the current implementation tries to instantiate it through core reflection. Since the protocol handler factory must be an implementation of a URLStreamHandlerFactory, it lends itself to being retrofitted with a ServiceLoader lookup. Note, the 'java.protocol.handler.pkgs' system property mechanism predates ServiceLoader. URL protocol handlers would most likely have used service loader if it were available at the time. Some URL protocol handlers are fundamental to the platform itself, like 'file' and 'jar', it is not appropriate to attempt a service loader lookup for these, as they may lead to recursive initialization issues. However, Java Plugin, Webstart, and possibly other containers, do override the 'jar' handler. A new API will be provided for this purpose. Providing an API solution should not interfere with system initialization as it will only be called after the system comes up and user code is executing. The 'file' protocol handler factory will no longer be overridable, and the system property will no longer be consulted. Webrev and spec diffs: http://cr.openjdk.java.net/~chegar/8064924/00/ I want to agree the approach and spec first, so that the spec changes can be submitted for approval. A comprehensive test will be added before the code changes are finalised. -Chris.

6 34

Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold
by David Holmes 13 Feb '15

13 Feb '15

Hi Tom, If you are potentially messing with the (identity) hash of all Java objects in the 32-bit case then this needs a broader discussion eg on core-libs-dev (cc'd) as this will impact end-user code the most! The rest seems okay but I'm still mulling over it. :) Thanks, David H. On 13/02/2015 6:14 AM, Tom Benson wrote: > Hi, > I need reviewers and a commit sponsor for changes for bug 6764713, which > will increase the size of the age field in an object header from 4 bits > to 5. This will allow a maximum MaxTenuringThreshold of 31, though the > default will remain at the current value of 15. > > This includes the same change to the 32-bit version, which would close > bug 6719225 as well. In that case, the hash field in the header is > affected, losing one bit (25 bits -> 24), so I have asked for review > from hotspot-runtime-dev as well as gc-dev. > > Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713 > Testing: JPRT and reference server performance tests > > Notes: > Contrary to what earlier notes in the JBS entry said, this does not > require stronger alignment for the JavaThread structure for when biased > locking stores that pointer in the header. The JavaThread* was already > being aligned 1 power of 2 more strongly than it needed to be, so there > was an unused bit that could be stolen. > > In the 32-bit version, it does require taking one bit from the hash > field, which goes from 25 to 24 bits. This is something I'd especially > like feedback on. Running reference server performance tests, I saw no > impact from this change. We *could* make this change 64-bit-only, and > leave the age field at 4 bits for the 32-bit version. If we did so, we > could also decrease the alignment required for the JavaThread* to 512 > from the current 1024. > > The comment changes imply that the bits available for the JavaThread* > have been reduced by 1, and that the alignment is now stronger, but > neither is true. The comments have been corrected to match the > alignment that was already enforced. > > Three tests needed to be corrected to match the new limits. These check > the maximum valid values, what value represents NeverTenure, and so on. > > Thanks, > Tom >

8 10

8069325: Pattern.splitAsStream does not return input if it is empty and there is no match
by Paul Sandoz 13 Feb '15

13 Feb '15

Hi, http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8069325-Pattern-splitAsStream-… This patch fixes an edge case in Pattern.splitAsStream for matching against an empty input string, which deviated from the behaviour of Pattern.split. When there are no matches a stream containing the input string should be returned rather than an empty stream. -- I have kept compatibility with Pattern.split(String ) but i noticed another an edge case. What should the following return: Pattern.compile("").split("") [] or [""]? There is a zero-width match at the beginning and an empty remaining segment both of which should be discarded, as such i would expect the result to be [] rather than as [""], as currently produced result. If people agree that this is an issue i suggest we log a new one independent of fixing 8069325. Thanks, Paul.

2 5

RFR(XS): 8072770: [TESTBUG] Some Introspector tests fail with a Java heap bigger than 4GB
by Volker Simonis 13 Feb '15

13 Feb '15

Hi, the three Introspector test: java/beans/Introspector/7064279/Test7064279.java java/beans/Introspector/Test7172865.java java/beans/Introspector/Test7195106.java provoke an OutOfMemory situation by repeatedly allocating constantly growing arrays with the following loop: int[] array = new int[1024]; while (true) { array = new int[array.length << 1]; } However if we're running on a machine with plenty of RAM the default Java heap will be bigger than ~4GB and we will get a NegativeArraySizeException instead of an OutOfMemoryError because the array length which is a signed int will wrap around and become negative. The fix is easy - just specify a concrete -Xmx value for the test: http://cr.openjdk.java.net/~simonis/webrevs/2015/8072770/ https://bugs.openjdk.java.net/browse/JDK-8072770 Thank you and best regards, Volker

1 1

Re: RFR 8071670: java.util.Optional: please add a way to specify if-else behavior
by Louis Wasserman 13 Feb '15

13 Feb '15

I'm not sure I can share hard numbers, but the ratio of if (optional.isPresent()) { // non-returning statements here } to if (optional.isPresent()) { // or negated // non-returning statements here } else { // non-returning statements here } is ~5.5x in favor of the no-else case. Both patterns have large numbers of hits, though, so I'm satisfied that this is not an unreasonable thing to do. I can possibly try to extract statistics on how many of these cases would be easily converted to method references and other things that might be easier to express with functional interfaces, but I'm not sure how necessary that actually is. On Thu Feb 12 2015 at 10:40:23 AM Daniel Fuchs <daniel.fuchs(a)oracle.com> wrote: > The new version looks good Paul! > > -- daniel > > On 2/12/15 6:50 PM, Paul Sandoz wrote: > > On Feb 12, 2015, at 3:50 PM, Daniel Fuchs <daniel.fuchs(a)oracle.com> > wrote: > > > >> Hi Paul, > >> > >> This looks good - I have noticed one copy/paste error in the javadoc > >> though: > >> > >> OptionalInt.java: > >> > >> looks like the throws clause of ifPresent and ifPresentOrElse have been > >> interverted: > >> > >> 138 * @throws NullPointerException if a value is present and > {@code action} is > >> 139 * null, or a value is not present and {@code emptyAction} is > null. > >> 140 */ > >> 141 public void ifPresent(IntConsumer action) { > >> 142 if (isPresent) { > >> 143 action.accept(value); > >> 144 } > >> 145 } > >> 146 > >> 147 /** > >> 148 * If a value is present, perform the given action with the > value, > >> 149 * otherwise perform the given empty-based action. > >> 150 * > >> 151 * @param action the action to be performed if a value is > present > >> 152 * @param emptyAction the empty-based action to be performed if > a value is > >> 153 * not present > >> 154 * @throws NullPointerException if value is present and {@code > action} is > >> 155 * null > >> 156 * @since 1.9 > >> 157 */ > >> 158 public void ifPresentOrElse(IntConsumer action, Runnable > emptyAction) { > >> > > Oops. Fixed. > > > > > >> Concerning the test, should there be a test that verifies that NPE > >> is thrown when null is passed - as specified in the javadoc? > >> > > Done. > > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071670-Optiona > l-ifPresentOrElse/webrev/ > > > > Thanks, > > Paul. > >

2 3

[9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to XML storage, causing loss of all preferences
by Brian Burkhalter 12 Feb '15

12 Feb '15

This is a request for comment only, at this point. There is no associated formal test but there is one in the issue description. Issue: https://bugs.openjdk.java.net/browse/JDK-8068373 Patch: http://cr.openjdk.java.net/~bpb/8068373/webrev.02/ I mostly want to know how out to lunch this approach is, for the moment only in the context of FileSystemPreferences, not exporting/importing to/from XML in general from generic Preferences. Two things should be noted here. The Preferences (and Properties) can be exported to and imported from an XML format on all platforms. In the case of Unix (Linux and Solaris, I believe) this is also the format used to store the Preferences whereas on other platforms that is not the case. Therefore for these Unix cases there is the possibility of loss if things are not losslessly round trip encoded into XML. The present issue is one such case with dire consequences. The main problems as I see them are 1) how to maintain compatibility across Java versions, and 2) how to preserve what can be added as a Preference. With respect to the latter item, this should not be constrained because the datum happens to be cached in XML. This particular solution is data-preserving with respect to the issue addressed if the same or later version of a JVM is used, and does not cause older Java versions reading the XML cache to fail. Thanks, Brian

3 11

RFR 8071670: java.util.Optional: please add a way to specify if-else behavior
by Paul Sandoz 12 Feb '15

12 Feb '15

Hi, http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071670-Optional-ifPresentOrEl… Here is another tweak to Optional (and primitives) that has some weight: /** * If a value is present, perform the given action with the value, * otherwise perform the given empty-based action. * * @param action the action to be performed if a value is present * @param emptyAction the empty-based action to be performed if a value is * not present * @throws NullPointerException if a value is present and {@code action} is * null, or a value is not present and {@code emptyAction} is null. * @since 1.9 */ public void ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction) { if (value != null) { action.accept(value); } else { emptyAction.run(); } } (In hindsight we should have been consistent and thrown NPEs regardless of the optional state. The exception throwing behaviour is consistent with ifPresent.) Previously it was kind of awkward if one had two lambdas or method refs handy, one had to do: o.ifPresent(v -> ...); if (!o.ifPresent()) { ... } Or just: if (o.ifPresent()) { ... } else { ... } I also updated the language of the ifPresent methods to be more consistent with Collection/Stream.forEach. Paul.

4 9