April 2016 - core-libs-dev

RFR 8153928, test/lib/share/classes/jdk/test/lib/Utils.java introduced dependency to java.base/jdk.internal.misc
by Felix Yang 11 Apr '16

11 Apr '16

Hi there, please review the following bug fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8153928 Webrev: http://cr.openjdk.java.net/~xiaofeya/8153928/webrev.00/ After changes in JDK-8153737 <https://bugs.openjdk.java.net/browse/JDK-8153737>, it introduced new dependency of java.base/jdk.internal.misc in test/lib/share/classes/jdk/test/lib/Utils.java. This leads to two test compilation failures. See changeset: http://hg.openjdk.java.net/jdk9/dev/rev/1d992540870f Thanks, Felix

4 7

JDK 9 Build 111 seems to miss some locale data, Lucene tests fail with Farsi and Thai language
by Uwe Schindler 11 Apr '16

11 Apr '16

Hi, after also testing the separate "Jigsaw" build on jdk9.java.net I see the same problems. So both builds 111 are wrong. To me it looks like the Unicode data files are missing some information - which could again be a packaging bug. As said before, build 110 does not have this problem, so it seems to be a side-effect of Jigsaw merging. The following stuff does not work: (1) Thai's locale does not have working dictionary-based BreakIterator available. The following "check" in Lucene for this fails, because it cannot detect a boundary correctly: /** * True if the JRE supports a working dictionary-based breakiterator for Thai. * If this is false, this tokenizer will not work at all! */ public static final boolean DBBI_AVAILABLE; private static final BreakIterator proto = BreakIterator.getWordInstance(new Locale("th")); static { // check that we have a working dictionary-based break iterator for thai proto.setText("ภาษาไทย"); DBBI_AVAILABLE = proto.isBoundary(4); } After this static initializer, DBBI_AVAILABLE is false. This makes some tests to be ignored, but 2 fail because of this (which might be an oversight on our side). But nevertheless, this is a bug in build 111. (2) The collator for Arabic (Farsi) language fails to work correctly. This also looks like missing data. Collator collator = Collator.getInstance(new Locale("ar")); This one fails some tests that have worked before (in any previous Java 9 build and any previous Java version 1.4+). I have to revert to build 110, because we cannot make our tests pass on the Jenkins server. I hope this can be fixed with the next build! Uwe ----- Uwe Schindler uschindler(a)apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces@openjdk.java.net] On > Behalf Of Uwe Schindler > Sent: Saturday, March 26, 2016 11:49 AM > To: 'Alan Bateman' <Alan.Bateman(a)oracle.com> > Cc: 'Rory O'Donnell' <rory.odonnell(a)oracle.com>; 'Core-Libs-Dev' <core-libs- > dev(a)openjdk.java.net> > Subject: RE: JDK 9 Build 111 still has ManagementFactory problems, but only > on Linux - not on Windows > > Hi Alan, > > It is ok from the management factory perspective - sorry for trouble. But the > first test showed that during language analysis something seems missing, > which did not happen with the b110 one. > > Currently we see the following tests fail: Everything Thai and Farsi language > related. > > It looks like the BreakIterators (at least the Thai one) are missing. I have to > dig into this. I will also compare with the Jigsaw-build 111, if this is different > (what is the difference between both, I only see size is largely different and > Windows has a ZIP file?). Those test failures did not happen with neither > build 110 of Jigsaw and without. > > Here are 2 failures: > http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/253/consoleFull > http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16339/consoleFull > > Uwe > > ----- > Uwe Schindler > uschindler(a)apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > > > -----Original Message----- > > From: Alan Bateman [mailto:Alan.Bateman@oracle.com] > > Sent: Saturday, March 26, 2016 11:27 AM > > To: Uwe Schindler <uschindler(a)apache.org> > > Cc: 'Rory O'Donnell' <rory.odonnell(a)oracle.com>; 'Core-Libs-Dev' <core- > libs- > > dev(a)openjdk.java.net> > > Subject: Re: JDK 9 Build 111 still has ManagementFactory problems, but > only > > on Linux - not on Windows > > > > > > > > On 26/03/2016 09:59, Uwe Schindler wrote: > > > Sorry, > > > > > > false alarm! I missed to change the build number when changing EA build > > paths on the Jenkins server. There was still "b110" in it. :( > > > Sorry for noise, all fine. > > > > > > > > No problem and thanks for confirming that jdk-9+111 is okay. > > > > -Alan

3 8

RFR: 8149450: LdapCtx.processReturnCode() throwing Null Pointer Exception
by Sean Coffey 10 Apr '16

10 Apr '16

Looking to fix this issue. Better checks for the referrrals field. bugID : https://bugs.openjdk.java.net/browse/JDK-8149450 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8149450.jdk9/webrev/ regards, Sean.

2 1

RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value
by Steve Drach 10 Apr '16

10 Apr '16

I’ve put up a new webrev that addresses the issue of having spaces before (and after) the value “true” in the Multi-Release attribute. > Hi, > Please review this simple fix to require that the jar manifest Multi-Release attribute has a value of “true" in order to be effective, i.e. to assert the jar is a multi-release jar. > issue: https://bugs.openjdk.java.net/browse/JDK-8153213 <https://bugs.openjdk.java.net/browse/JDK-8153213> > webrev: http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html <http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html> > Thanks > Steve

3 9

RFR 8151198: VarHandle factory-specific exceptions
by Paul Sandoz 09 Apr '16

09 Apr '16

Hi Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151198-VH-factory-exceptions/… <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151198-VH-factory-exceptions/…> The patch tweaks the specification: 1) noting that factory methods may document additional undeclared exceptions that may be thrown by access methods e.g. IllegalSateException for VarHandles to ByteBuffer for misaligned access. 2) add the throwing of ClassCastException to each method, which i neglected to add when switching from invokeExact to invoke semantics. Paul.

6 10

Review request 8153665: URLClassLoader.definePackage() not throwing expected IAE
by Mandy Chung 08 Apr '16

08 Apr '16

The spec of java.lang.Package and ClassLoader::definePackage have been changed in jdk-9+111 such that Package objects are defined per class loader and no longer inspect what packages are defined in the class loader hierarchy. The spec of URLClassLoader::definePackage(String name, Manifest man, URL url) should also be changed accordingly. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153665/webrev.00/ Mandy

2 3

RFR 8153123 : Streamline StackWalker code
by Brent Christian 08 Apr '16

08 Apr '16

Hi, I'd like to check in some footprint and code reduction changes to the java.lang.StackWalker implementation. Webrev: http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8153123 A summary of the changes: * remove the "stackwalk.newThrowable" system property and "MemberNameInStackFrame" VM flag, originally left in to aid benchmarking * Streamline StackFrameInfo fields * Refactor/streamline StackStreamFactory (no more separate classes[]/StackFrame[] arrays, remove unneeded (for now) StackStreamFactory.StackTrace class) Given the hotspot changes, I plan to push this through hs-rt. Thanks, -Brent

4 5

JDK 9 RFR of JDK-8153722: Mark java/nio/channels/Selector/SelectAndClose.java as intermittently failing
by Amy Lu 08 Apr '16

08 Apr '16

java/nio/channels/Selector/SelectAndClose.java This test is known to fail intermittently (JDK-8152814). This patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8153722 webrev: http://cr.openjdk.java.net/~amlu/8153722/webrev.00/ Thanks, Amy --- old/test/java/nio/channels/Selector/SelectAndClose.java 2016-04-08 18:36:17.000000000 +0800 +++ new/test/java/nio/channels/Selector/SelectAndClose.java 2016-04-08 18:36:17.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 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 @@ -23,6 +23,7 @@ /* @test * @bug 5004077 + * @key intermittent * @summary Check blocking of select and close */

3 2

RFR: jsr166 jdk9 integration wave 6
by Martin Buchholz 07 Apr '16

07 Apr '16

Easy changes to review, up to April Fools day, in part to make room for later unfinished more exciting changes. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

5 11

RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )
by Chris Hegarty 07 Apr '16

07 Apr '16

sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should be moved out of sun.misc and placed into a more appropriate package, where it can be encapsulated. Since GC is only used by RMI, I proposed to move it to the java.rmi module. Since it has a native component, and no other code in java.rmi has, then a new small native library is required. http://cr.openjdk.java.net/~chegar/8153286/ https://bugs.openjdk.java.net/browse/JDK-8153286 -Chris.

4 4