June 2018 - core-libs-dev

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

06 Jun '18

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 >

1 0

Implementations of PrimitiveIterator.OfInt#forEachRemaining(IntConsumer) doesn't check IntConsumer for null
by Андрей Турбанов 06 Jun '18

06 Jun '18

Hello. I observe that implementations of `forEachRemaining` method inside java.lang.CharSequence doesn't always compare IntConsumer parameter with null. Is there any reason why there is no nonNull check? Performance? Andrey Turbanov.

2 1

RFR: 8201608 fix broken links in javax/sql/rowset/package.html and javax/sql/rowset/spi/package.html
by Lance Andersen 06 Jun '18

06 Jun '18

Hi, Bug 8201608 highlights a few broken links in javax/sql/rowset/package.html and javax/sql/rowset/spi/package.html As part of this fix, I took the liberty to move from package.html to package-info.java The webrev can be found at http://cr.openjdk.java.net/~lancea/8201608/webrev.00/ <http://cr.openjdk.java.net/~lancea/8201608/webrev.00/> I have also attached a diff of the changes as it is less obvious of the webrev prior to the migration to package-info.java 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>

3 7

RFR: JDK-8203891: Upgrade JOpt Simple to 5.0.4
by Jan Lahoda 05 Jun '18

05 Jun '18

Hi, I'd like to upgrade the JOpt Simple library we are using to version 5.0.4. Bug: https://bugs.openjdk.java.net/browse/JDK-8203891 Complete webrev: http://cr.openjdk.java.net/~jlahoda/8203891/webrev.00/complete/ Delta webrev only showing (all) JDK changes in JOpt Simple and related changes in tests needed for the upgrade, etc.: http://cr.openjdk.java.net/~jlahoda/8203891/webrev.00/joptsimple.delta/ Probably the biggest issue with this upgrade is that for two subsequent parameters: "--libs=", "/tmp" "/tmp" used to be interpreted as the parameter of "libs", but now the "libs" parameter is empty (as there's nothing behind the '='). See the changes to test/jdk/tools/jmod/JmodTest.java for an example. Hopefully, this is a reasonable change. How does this look? Thanks, Jan

4 6

RFR JDK-8203872: Upgrading JDK with latest available LSR data from IANA
by Nishit Jain 05 Jun '18

05 Jun '18

Hi, Please review the fix for JDK-8203872. Bug: https://bugs.openjdk.java.net/browse/JDK-8203872 Webrev: http://cr.openjdk.java.net/~nishjain/8203872/webrev.01/ Fix: Updated the LSR data to the version 2017-08-15 Regards, Nishit Jain

2 1

RFR 8203768 : Avoid reallocation in java.base/unix/classes/java/lang/ProcessImpl.java
by Ivan Gerasimov 05 Jun '18

05 Jun '18

Hello! When closing a Process, its stdout and stderr are drained: The remaining bytes are copied into an array, and then the out/err stream is replaced with ByteArrayInputStream(). In a case when a fewer number of bytes were read then the Stream.available() suggested, the array is reallocated with Arrays.copyOf(). It is possible to avoid reallocation, and use three-args ByteArrayInputStream() constructor to specify a portion of the array used. Would you please help review this trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8203768 WEBREV: http://cr.openjdk.java.net/~igerasim/8203768/00/webrev/ All existing tests pass on all supported platforms. Thanks in advance! -- With kind regards, Ivan Gerasimov

2 3

[11] RFR: 8202026 8193552 : ISO 4217 Amendment #165 # 166 Update
by Leo Jiang 05 Jun '18

05 Jun '18

Hi, Please review the changes to address the ISO 4217 Amendment 165 166 update. Bug: https://bugs.openjdk.java.net/browse/JDK-8193552 165 https://bugs.openjdk.java.net/browse/JDK-8202026 166 CR: http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/ Detail: #165 From: MAURITANIA Ouguiya MRO 478 2 To: MAURITANIA Ouguiya MRU 929 2 #166 From: VENEZUELA (BOLIVARIAN REPUBLIC OF) Bolívar VEF 937 2 To: VENEZUELA (BOLIVARIAN REPUBLIC OF) Bolívar Soberano VES 928 2 Thanks, Leo

4 7

RFR JDK-8200530: '\r' is not supported as "newline" in java.util.jar.Manifest.
by Xueming Shen 05 Jun '18

05 Jun '18

Hi, Please help review the changeset for JDK-8200530. "newline" is specified as |CR LF | LF | CR|(/not followed by/|LF|) in Jar spec [1] from the very beginning but our implementation actually never supports "\r"/CR (not followed by LF) case. The proposed change here is to add CR as an individual supported "newline"/line separator. issue: https://bugs.openjdk.java.net/browse/JDK-8200530 webrev: http://cr.openjdk.java.net/~sherman/8200530/webrev Thanks, Sherman [1] https://docs.oracle.com/javase/10/docs/specs/jar/jar.html

2 2

RFR: 8196988 (Resolve disabled warnings for implicit-fallthrough gcc option)
by Srinivas Dama 04 Jun '18

04 Jun '18

Hi, Please review http://cr.openjdk.java.net/~sdama/8196988/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8196988 Note: gcc 7.3 compiler emits warnings for implicit fall-through switch cases,but these warnings are disabled earlier.I have enabled these warnings and fixed in sources. Regards, Srinivas

1 0

RFR: implementation for JEP 334: JVM Constants API
by Vicente Romero 03 Jun '18

03 Jun '18

Hi all, Please review the proposed implementation for JEP 334 [1]. The webrev can be found at [2] and the javadoc at [3]. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8203252 [2] http://cr.openjdk.java.net/~vromero/constant.api/webrev.07/constants.api.pa… [3] http://cr.openjdk.java.net/~vromero/constant.api/javadoc.07/overview-summar… PS. We are offering a MacBook Wheel to the authors of the first 5 comments :)

5 9