June 2018 - core-libs-dev

(trivial) RFR: 8204589: ProblemList failing launcher tests
by David Holmes 08 Jun '18

08 Jun '18

Bug: https://bugs.openjdk.java.net/browse/JDK-8204589 webrev: http://cr.openjdk.java.net/~dholmes/8204589/webrev/ After the push for: JDK-8201274 Launch Single-File Source-Code Programs there are a few test failures in our CI testing, so they are being ProblemListed to keep tiers 1 and 2 clean. Thanks, David

2 2

(XS) Review Request JDK-8204584: jdeps generates illegal dot file containing ranksep=0,600000
by mandy chung 07 Jun '18

07 Jun '18

The dot files are generated and used as module graph in the docs build. The format of double should use no localization; otherwise an illegal ranksep attribute. Mandy diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java b/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java @@ -44,6 +44,7 @@ import java.util.Deque; import java.util.HashSet; import java.util.List; +import java.util.Locale; import java.util.Map; import java.util.Objects; import java.util.Set; @@ -329,7 +330,7 @@ out.format("digraph \"%s\" {%n", name); out.format(" nodesep=.5;%n"); - out.format(" ranksep=%f;%n", attributes.rankSep()); + out.format((Locale)null, " ranksep=%f;%n", attributes.rankSep()); out.format(" pencolor=transparent;%n"); out.format(" node [shape=plaintext, fontcolor=\"%s\", fontname=\"%s\"," + " fontsize=%d, margin=\".2,.2\"];%n",

2 1

Locale languageTag anomaly
by Jonathan Gibbons 07 Jun '18

07 Jun '18

Regarding Locale.toLanguageTag, Locale.forLanguageTag Should I be surprised (i.e. is it a bug) that out of 736 installed locales in a standard build of JDK, exactly 1 locale fails the following round-trip test: locale.equals(Locale.forLanguageTag(locale.toLanguageTag())) The locale "no_NO_NY" comes back as "nn_NO". Attached is a test program. Here is the output from the test program: $ /opt/jdk/1.9.0/bin/java -cp play/locales/classes Locales test locale: no_NO_NY [no,NO,NY] nn-NO forLanguageTag: nn_NO Tested 736 locales Mismatch 1 locales -- Jon

2 2

Re: RFR: 8196990 :Resolve disabled warnings for libjli
by Srinivas Dama 07 Jun '18

07 Jun '18

Ok. Thank you Jim. Please find revised webrev at http://cr.openjdk.java.net/~sdama/8196990/webrev.01/. Regards, Srinivas ----- Original Message ----- From: james.laskey(a)oracle.com To: srinivas.dama(a)oracle.com, core-libs-dev(a)openjdk.java.net Sent: Thursday, 7 June, 2018 7:37:48 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: Re: RFR: 8196990 :Resolve disabled warnings for libjli traditionally there is a space after // simplify comment to something like (rest is redundant) // initialize to avoid -Werror=maybe-uninitialized issues from gcc 7.3 onwards. > On Jun 7, 2018, at 11:01 AM, Srinivas Dama <srinivas.dama(a)oracle.com> wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8196990/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8196990 > > Regards, > Srinivas

2 1

RFR: 8196990 :Resolve disabled warnings for libjli
by Srinivas Dama 07 Jun '18

07 Jun '18

Hi, Please review http://cr.openjdk.java.net/~sdama/8196990/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8196990 Regards, Srinivas

2 1

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
by Ichiroh Takiguchi 07 Jun '18

07 Jun '18

Hello. 8202322 was integrated into jdk-11+15. I'm using XLC 13.1.3 on AIX 7.1.4. Build was failed because of "-qvisibility=hidden" on make/lib/LibCommon.gmk. According to "XL C/C++ for AIX 13.1.3" documentation [1], "-qvisibility=hidden" cannot create shared libraries entry points. For example, libverify.so was there, but entry points were not resolved by "-lverify" option. I think it should be "-qvisibility=default" (I tried, it worked) or "-qvisibility=protected" (I had not tried) ? I'm not familiar with -qvisibility option, but I'd like to find out right way. [1] https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm.xlcpp1313… On 2018-05-16 16:08, Langer, Christoph wrote: > Hi Matthias, > > yes, reviewed. > > Best regards > Christoph > > From: Baesken, Matthias > Sent: Mittwoch, 16. Mai 2018 09:06 > To: Langer, Christoph <christoph.langer(a)sap.com>; > 'build-dev(a)openjdk.java.net' <build-dev(a)openjdk.java.net>; > ppc-aix-port-dev(a)openjdk.java.net; core-libs-dev(a)openjdk.java.net > Cc: Lindenmaier, Goetz <goetz.lindenmaier(a)sap.com> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > xlc 12.1 > > Hi Christoph can I add you as second reviewer (other reviewer was > Erik Joelsson) can push the change ? > > Best regards, Matthias > > > > From: Langer, Christoph > Sent: Donnerstag, 26. April 2018 16:38 > To: Baesken, Matthias > <matthias.baesken(a)sap.com<mailto:matthias.baesken@sap.com>>; > 'build-dev(a)openjdk.java.net' > <build-dev(a)openjdk.java.net<mailto:build-dev@openjdk.java.net>>; > ppc-aix-port-dev(a)openjdk.java.net<mailto:ppc-aix-port-dev@openjdk.java.net>; > core-libs-dev(a)openjdk.java.net<mailto:core-libs-dev@openjdk.java.net> > Cc: Simonis, Volker > <volker.simonis(a)sap.com<mailto:volker.simonis@sap.com>> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > xlc 12.1 > > Hi Matthias, > > to me the change in principal looks good. > > I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. > extract major number before the first dot, then compare numerically) - > but maybe it is too complicated and the current single version compare > suits our needs ? > > Best regards > Christoph > > From: Baesken, Matthias > Sent: Donnerstag, 26. April 2018 16:14 > To: 'build-dev(a)openjdk.java.net' > <build-dev(a)openjdk.java.net<mailto:build-dev@openjdk.java.net>>; > ppc-aix-port-dev(a)openjdk.java.net<mailto:ppc-aix-port-dev@openjdk.java.net>; > 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>>; Simonis, > Volker <volker.simonis(a)sap.com<mailto:volker.simonis@sap.com>> > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc > 12.1 > > Hello , could you please review this small adjustment to the symbol > visibility compilation settings on AIX ? > Currently we use XLC 12.1 to compile JDK on AIX . > > However XLC 12.1 does not support the "-qvisibility=hidden" > setting currently set on AIX. > It was introduced with XLC 13.1 . Christoph found some info about it > here : > > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-par… > > Setting it only generates hundreds of warnings in the build log , > warnings look like this : > XlC12.1 > > bash-4.4$ xlC -qversion > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > Version: 12.01.0000.0019 > > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list > of valid options. > > Compare to XLC13.1 > > bash-3.00$ xlC -qversion > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > Version: 13.01.0000.0008 > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > > > So it is better to avoid setting these flags when using xlc12.1 . > Please review : > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8202322 > > Change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > > > Best regards, Matthias

3 4

RFR: JDK8U Backport of 8186171: HashMap: Entry.setValue may not work after Iterator.remove() called for previous entries
by Deepak Kejriwal 07 Jun '18

07 Jun '18

Hi all, Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/browse/JDK-8186171 Webrev: http://cr.openjdk.java.net/~rpatil/8186171/webrev.00/ Summary(also added to backport bug description): The back port for test files is not clean back port as all tests files are extending JSR166TestCase.java which was added to JDK 9 as part of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8146467"JDK-8146467: Integrate JSR 166 jck tests into JDK repo. This is not present in JDK8 version. Therefore, I have extracted test are relevant to the fix done JDK-8186171 and created a new test file Bug8186171Test.java that contains below two test methods: . testBug8186171NonDeterministic : This method is copy of "testBug8186171" present in "MapTest.java" of original changeset http://hg.openjdk.java.net/jdk10/master/rev/3f5f9bc0bdc2. As it is based on randomization and runs 1000 times, the method name is suffixed with "NonDeterministic". . testBug8186171Deterministic : This is a new method that runs single time as it produces the exact scenario mentioned in JDK-8186171. Therefore, it is not needed to run multiple times to produce the scenario mentioned in bug. Hence the method name is suffixed with "Deterministic" Regards, Deepak

2 5

Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)
by Stuart Marks 07 Jun '18

07 Jun '18

Serguei, great! Thanks. All, I've updated the webrev to with changes to threadPrimitiveDeprecation.html to remove the sections that mention the removed methods. http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.2/ s'marks On 6/6/18 2:37 PM, serguei.spitsyn(a)oracle.com wrote: > Stuart, > > Thank you for explanation! > I'm Okay with the fix it is now. > > Thanks, > Serguei > > > On 6/6/18 14:02, Stuart Marks wrote: >> On 6/6/18 10:58 AM, serguei.spitsyn(a)oracle.com wrote: >>> But the fix below is not clear to me: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.1/src/hotspot/sha… >>> <function id="StopThread" num="7"> >>> <synopsis>Stop Thread</synopsis> >>> <description> >>> - Send the specified asynchronous exception to the specified thread >>> - (similar to <code>java.lang.Thread.stop</code>). >>> + Send the specified asynchronous exception to the specified thread. >>> Normally, this function is used to kill the specified thread with an >>> - instance of the exception <code>ThreadDeath</code>. >>> + instance of the exception <code>ThreadDeath</code>, similar to >>> + <code>java.lang.Thread.stop</code>. >>> </description> >>> A reference to the java.lang.Thread.stop has been removed in one place and >>> added in another. >>> I thought, we wanted to get rid of these references in the spec. >>> Do I miss anything? Could you, explain this a little bit? >> Sure. The current state (through JDK 10) is that there two APIs: >> >> 1. Thread.stop(Throwable) >> 2. Thread.stop() // no-arg >> >> They are both deprecated, but only (1) is deprecated for removal, and it's >> the one being removed by this changeset. Method (2) will remain in the >> platform for the forseeable future. >> >> Method (1) causes the target thread asynchronously to throw the argument, >> which can be an instance of any subtype of Throwable. Method (2) causes the >> target thread to throw ThreadDeath (a subtype of Error) asynchronously. >> >> The wording in the JVMTI doc isn't terribly explicit. The original wording >> actually means "similar to Thread.stop(Throwable)" that is method (1). My >> rewording places the mention of Thread.stop into the context of throwing >> ThreadDeath, implying method (2). Since that will be the only Thread.stop >> method remaining, there's no ambiguity. So yes, the wording change looks odd, >> but there is a subtle shift in the meaning, and I think the meaning is clear >> after (1) has been removed. >> >> But I can remove the "similar to Thread.stop" bit if you prefer. >> >> s'marks >>> >>> Thanks, >>> Serguei >>> >>> On 6/5/18 17:05, Stuart Marks wrote: >>>> [adding serviceability-dev] >>>> >>>> Hi serviceability folks, >>>> >>>> I'm in the process of removing Thread.destroy() and Thread.stop(Throwable) >>>> from the Java SE API. Alan and David have pointed out that there are some >>>> cross-references to Thread.stop(Throwable) in the JDWP and JVMTI specs, as >>>> well as in the JDI ThreadReference API. I've adjusted the relevant files. >>>> >>>> See please review this updated webrev: >>>> >>>> http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.1/ >>>> >>>> For context, please see the full review thread on core-libs-dev: >>>> >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053536.html >>>> >>>> >>>> >>>> On 6/4/18 11:11 PM, Alan Bateman wrote: >>>>> The source file that is used to generate the JDWP protocol code and the >>>>> spec is in make/data/jdwp/jdwp.spec. The JVM TI spec is at >>>>> src/hotspot/share/prims/jvmti.xml. It should be okay to skip those for >>>>> this change-set, assuming it is followed up quickly with another >>>>> change-set to update those specs. >>>> >>>> OK. I took a look at those other files and they seem simple enough to >>>> update as part of this changeset. If there aren't any objections from >>>> anyone, might as well get this all done at once. >>>> >>>> Thanks, >>>> >>>> s'marks >>> >> >

3 2

RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)
by Stuart Marks 06 Jun '18

06 Jun '18

Hi all, Please review this changeset to remove the Thread.destroy() and Thread.stop(Throwable) methods. Both of these methods have been deprecated for a long time, and they were deprecated for removal in Java SE 9. Thread.destroy() was never implemented, and has always thrown NoSuchMethodError back to the caller. Thread.stop(Throwable) was made non-functional in JDK 8, throwing UnsupportedOperationException back to the caller. Note that the no-arg Thread.stop() method remains deprecated, not for removal, and is unaffected by this changeset. Note also that ThreadGroup.destroy() doesn't actually destroy any threads -- just thread groups -- and that it is also unaffected by this changeset. Bug: https://bugs.openjdk.java.net/browse/JDK-8204243 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.0/ Thanks, s'marks aka @DrDeprecator

5 19

RFR https://bugs.openjdk.java.net/browse/JDK-8204494
by Xueming Shen 06 Jun '18

06 Jun '18

Hi Please help review the change for JDK-8204494, a regression caused by the fix for JDK-8200530 [1]. It appears that fix fails to deal with the corner case that a pair of \r\n is at the boundary of the internal buf of Manifest.FastInputtStream, which is 8192 for the default. In that scenario, the previous change fails to consume the trailing \n, then triggers the Attributes parser fails to work on the "continuation line" defined by the jar spec. issue: https://bugs.openjdk.java.net/browse/JDK-8204494 webrev: http://cr.openjdk.java.net/~sherman/8204494/webrev/ Fix has been verified by the regression reported in INTJDK-7627771. Thanks, Sherman [1] issue: https://bugs.openjdk.java.net/browse/JDK-8200530 webrev: http://cr.openjdk.java.net/~sherman/8200530/webrev

2 1