Re: RFR: JDK-8152690: main thread does not have native thread name

Hi Yasumasa, Thanks for persevering with this to get it into the current form. Sorry I haven't been able to do a detailed review until now. On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: Hi Gerard, 2016/04/19 3:14 "Gerard Ziemski"

Re: RFR: JDK-8154498: fix to 8154403 results in failure of UserModuleTest.java on all platforms

+1 -Sundar On 4/19/2016 8:28 AM, Xueming Shen wrote: > Hi, > > Please help review the test case only change for JDK-8154498 > > issue: https://bugs.openjdk.java.net/browse/JDK-8154498 > webrev: http://cr.openjdk.java.net/~sherman/8154498/webrev/ > > A "empty" map need to be passed in as the

Re: RFR: JDK-8154498: fix to 8154403 results in failure of UserModuleTest.java on all platforms

Looks fine Sherman; thanks, -Joe On 4/18/2016 7:58 PM, Xueming Shen wrote: Hi, Please help review the test case only change for JDK-8154498 issue: https://bugs.openjdk.java.net/browse/JDK-8154498 webrev: http://cr.openjdk.java.net/~sherman/8154498/webrev/ A "empty" map need to be passed in

RFR: JDK-8154498: fix to 8154403 results in failure of UserModuleTest.java on all platforms

Hi, Please help review the test case only change for JDK-8154498 issue: https://bugs.openjdk.java.net/browse/JDK-8154498 webrev: http://cr.openjdk.java.net/~sherman/8154498/webrev/ A "empty" map need to be passed in as the parameter for FileSystems.newFileSystem(), instead of "null".

Multi-Release JAR runtime support

Hi OpenJDK Core Developers, Today, to prepare a conference talk on Java 9 (DevoxxFR, on wednesday 20th), I tested once again Maven proposed layout to produce Multi-Release JARs: https://github.com/hboutemy/maven-jep238 And I added a little script (. run-demo.sh) to run the build then execute

Re: RFR: 8154470: defines.h confused about PROGNAME and JAVA_ARGS

Hi Martin, Tested with jprt, seems to be ok, the changes are ok with me. Unless Alan has some reservations. Thanks Kumar Hi Kumar and Alan, I'd like you to do a code review. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PROGNAME/ https://bugs.openjdk.java.net/browse/JDK-8154470

Re: RFR: JDK-8152690: main thread does not have native thread name

Hi Gerard, 2016/04/19 3:14 "Gerard Ziemski" : > > hi Yasumasa, > > Nice work. I have 2 questions: > > > File: java.c > > #1 Shouldn’t we be checking for “(*env)->ExceptionOccurred(env)” after every single JNI call? In this example instead of NULL_CHECK, should

Re: RFR: JDK-8152690: main thread does not have native thread name

Oops on my part, Gerard is right. We need to make SetNativeThreadName exit, if there is an error, otherwise it would enter the VM with an exception at the call site. So I think CHECK_EXCEPTION_NULL_LEAVE is the right thing to do, or we need to have a check and exit at the call site. Kumar

Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

On 4/17/16 10:31 AM, joe darcy wrote: With talk of deprecation in the air [1], I thought it would be a fine time to "In the Spring a young man's fancy lightly turns to thoughts of deprecation." -- apologies to Tennyson examine one of the bugs on my list JDK-6850612: Deprecate

Re: RFR(m): 8145468u1 deprecations for java.lang

> On Apr 18, 2016, at 3:30 PM, Stuart Marks wrote: > > On 4/17/16 7:06 AM, Dave Brosius wrote: >> Along these lines, is there a reason not to deprecate the >> >> String(String s) >> >> constructor? Now that substring doesn't glom off the original string, i see >> no

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

2016/4/8 1:41:47 -0700, paul.san...@oracle.com: > On 8 Apr 2016, at 00:03, Dohrmann, Steve wrote: >> Just to clarify, it is incidental that the proposed Memory interface >> has only one method. We see the value of the interface as >> nominative; a new type that can be

Re: RFR(m): 8145468u1 deprecations for java.lang

On 4/17/16 7:06 AM, Dave Brosius wrote: Along these lines, is there a reason not to deprecate the String(String s) constructor? Now that substring doesn't glom off the original string, i see no reason for this constructor. It's a fair point. But I think that historically there's been much

Re: RFR(m): 8145468 deprecations for java.lang

On 4/17/16 4:05 PM, David Holmes wrote: On 14/04/2016 11:50 AM, Stuart Marks wrote: The methods being deprecated with forRemoval=true are listed below. All of these methods have already been deprecated. They are all ill-defined, or they don't work, or they don't do anything useful.

Re: JDK 9 RFR of 8154183: (spec) {Data, }InputStream.read(byte[], int, int) - spec of offset argument confusing

HI Brian, Looks good, Thanks for making them consistent, Roger On 4/18/2016 4:53 PM, Brian Burkhalter wrote: A new patch generated using the latest version of webrev is here: http://cr.openjdk.java.net/~bpb/8154183/webrev.01/ I have

RE: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

Hi Joe, here is the updated webrev where I incorporated your suggestions: http://cr.openjdk.java.net/~clanger/webrevs/8153781.1/ I also added a testcase. As for the message " DoctypedeclNotClosed ": I did it in several languages but there are some languages where I don't have the knowledge to

Re: JDK 9 RFR of 8154183: (spec) {Data, }InputStream.read(byte[], int, int) - spec of offset argument confusing

A new patch generated using the latest version of webrev is here: http://cr.openjdk.java.net/~bpb/8154183/webrev.01/ I have addressed the various editorial comments except with respect to capitalizing the first word after the exception name and ending the @throws description with a period: I

RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

This change updates the code in the cobra module to use the new Thread constructor that suppresses inheritable-thread-local initial values. http://cr.openjdk.java.net/~chegar/8148863/ https://bugs.openjdk.java.net/browse/JDK-8148863 I’m open to suggestions for better names for the Threads.

Re: JDK 9 RFR of 8154183: (spec) {Data, }InputStream.read(byte[], int, int) - spec of offset argument confusing

Hi Roger, On Apr 18, 2016, at 12:45 PM, Roger Riggs wrote: > Editorial cleanup. > - In the new @throws NullPointerException and IndexOutOfBoundExceptions, > the first word after the exception should not be capitalized. > For example "if" instead of "If" makes it

Re: JDK 9 RFR of 8154183: (spec) {Data, }InputStream.read(byte[], int, int) - spec of offset argument confusing

Hi Brian, Editorial cleanup. - In the new @throws NullPointerException and IndexOutOfBoundExceptions, the first word after the exception should not be capitalized. For example "if" instead of "If" makes it consistent with the existing doc DataInputStream: - "the start offset in*to*

Re: JDK 9 RFR of 8154183: (spec) {Data, }InputStream.read(byte[], int, int) - spec of offset argument confusing

The patch has been updated in place to replace var with {@code var}, @exception with @throws, and align the text where needed only for the methods in question. Brian On Apr 15, 2016, at 3:46 PM, Brian Burkhalter wrote: > Re-posted with correct subject line. > >

Re: RFR: JDK-8152690: main thread does not have native thread name

hi Yasumasa, Nice work. I have 2 questions: File: java.c #1 Shouldn’t we be checking for “(*env)->ExceptionOccurred(env)” after every single JNI call? In this example instead of NULL_CHECK, should we be using CHECK_EXCEPTION_NULL_LEAVE macro? #2 Should the comment for

Re: RFR: JDK-815440: JRT filesystem loaded by JDK8 with URLClassLoader is not closable since JDK-8147460

On 18/04/2016 18:14, Xueming Shen wrote: Hi, Please help review the change for JDK-8154403 issue: https://bugs.openjdk.java.net/browse/JDK-8154403 webrev: http://cr.openjdk.java.net/~sherman/8154403/webrev/ The direct trigger of the failure is that the test case is passing in a null as

RFR: 8154470: defines.h confused about PROGNAME and JAVA_ARGS

Hi Kumar and Alan, I'd like you to do a code review. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PROGNAME/ https://bugs.openjdk.java.net/browse/JDK-8154470 Sorry, I got carried away hacking on the tests. Some changes could be split out. Aside from fixing the logic error in defines.h,

Re: RFR:JDK-8154050:java.time.format.DateTimeFormatter can't parse localized zone-offset

Hi Roger/Stephen, On 4/18/2016 2:40 AM, Stephen Colebourne wrote: The LDML spec indicates that the "GMT" string should be localized: http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Using_Time_Zone_Names The text of appendLocalizedOffset() is written with the intention of the

RFR: JDK-815440: JRT filesystem loaded by JDK8 with URLClassLoader is not closable since JDK-8147460

Hi, Please help review the change for JDK-8154403 issue: https://bugs.openjdk.java.net/browse/JDK-8154403 webrev: http://cr.openjdk.java.net/~sherman/8154403/webrev/ The direct trigger of the failure is that the test case is passing in a null as parameter "env" to create a new jrt filesystem.

Project Jigsaw, Apache Tomcat and RMI related memory leaks

Hi, The Apache Tomcat community was asked by Rory O'Donnell for feedback on JDK 9 + Project Jigsaw. Having provided that feedback we were directed here so I have reproduced that feedback below. I've started testing Tomcat trunk with JDK 9 + Project Jigsaw and it looks like we are going to hit a

Re: 8154159: rmic should not have a supported entry point

On 18/04/16 15:57, Alan Bateman wrote: When we brought the module system into JDK 9 then it included a new entry point for the RMI compiler (rmic). This was a mistake (conflicts with the policy for root modules that we have in JEP 261) and should not have been brought into JDK 9. The following

Re: 8154159: rmic should not have a supported entry point

Look fine. On 4/18/2016 10:57 AM, Alan Bateman wrote: When we brought the module system into JDK 9 then it included a new entry point for the RMI compiler (rmic). This was a mistake (conflicts with the policy for root modules that we have in JEP 261) and should not have been brought into

8154159: rmic should not have a supported entry point

When we brought the module system into JDK 9 then it included a new entry point for the RMI compiler (rmic). This was a mistake (conflicts with the policy for root modules that we have in JEP 261) and should not have been brought into JDK 9. The following patch removes it, it has already

Re: RFR: JDK-8152690: main thread does not have native thread name

Hi, Looks ok to me. Thanks Kumar On 17/04/2016 8:38 PM, David Holmes wrote: On 17/04/2016 1:38 PM, Yasumasa Suenaga wrote: Hi David, Need to hear from core-libs and/or launcher folk as this touches a number of pieces of code. I'm waiting more reviewer(s) . BTW, Should I make patches

Re: RFR [9] 8147553: Remove sun.misc.ManagedLocalsThread from java.management

Hi Chris, The changes look good to me. best regards, -- daniel On 18/04/16 12:37, Chris Hegarty wrote: 8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating

Re: RFR [9] 8153158: Remove sun.misc.ManagedLocalsThread from java.logging

On 18/04/16 08:01, Chris Hegarty wrote: 8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating such threads, other areas of the JDK should be updated to use it.

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

> On 18 Apr 2016, at 14:35, Tagir F. Valeev wrote: > > Hello! > > Thank you for review! > > PS> 913 UnorderedSliceSpliterator(T_SPLITR s, long skip, long limit) > { > PS> 914 this.s = s; > PS> 915 this.unlimited = limit < 0; > PS> 916

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! Thank you for review! PS> 913 UnorderedSliceSpliterator(T_SPLITR s, long skip, long limit) { PS> 914 this.s = s; PS> 915 this.unlimited = limit < 0; PS> 916 this.skipThreshold = limit >= 0 ? limit : 0; PS> 917 this.chunkSize =

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hi Tagir, > On 16 Apr 2016, at 15:05, Tagir F. Valeev wrote: > > Hello! > > Please review and sponsor the following patch: > https://bugs.openjdk.java.net/browse/JDK-8154387 Thanks for looking at this, it’s something i intended to get around to but never found the time. I

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

2016-04-18 14:01 GMT+02:00 Tagir F. Valeev : > Hello! > > It was just a quick test not in the clean environment, so you should > not draw any conclusions from the error numbers. It's quite expected > that for limit = 2000 the performance is the same as I have 4 CPU > machine and

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! SZ> I'm a bit surprised about the JMH results for limits 200 and 2000. SZ> limit = 200 is significantly faster than the unpatched code (with SZ> higher variance, though) and limit = 2000 is about the same, but SZ> with a significantly reduced variance. Maybe you'd need to increase SZ> the

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hi Tagir, nice catch. I think this optimization is worthwile. I'm a bit surprised about the JMH results for limits 200 and 2000. limit = 200 is significantly faster than the unpatched code (with higher variance, though) and limit = 2000 is about the same, but with a significantly reduced

RFR [9] 8147553: Remove sun.misc.ManagedLocalsThread from java.management

8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating such threads, other areas of the JDK should be updated to use it. This change updates the code in

Re: RFR: JDK-8152690: main thread does not have native thread name

2016/04/18 13:41 "David Holmes" : > > On 17/04/2016 8:38 PM, David Holmes wrote: >> >> On 17/04/2016 1:38 PM, Yasumasa Suenaga wrote: >>> >>> Hi David, >>> Need to hear from core-libs and/or launcher folk as this touches a number of pieces of code. >>> >>> >>>

Re: RFR [9] 8153158: Remove sun.misc.ManagedLocalsThread from java.logging

Looks good, Chris /Claes On 04/18/2016 08:01 AM, Chris Hegarty wrote: 8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating such threads, other areas of the JDK

Re: RFR: 8151056: ASM enable original deprecated methods. (simple fix)

Thumb up ! Rémi - Mail original - > De: "Sundararajan Athijegannathan" > À: core-libs-dev@openjdk.java.net > Envoyé: Lundi 18 Avril 2016 06:18:37 > Objet: Re: RFR: 8151056: ASM enable original deprecated methods. (simple fix) > > Looks good > >

RFR [9] 8153158: Remove sun.misc.ManagedLocalsThread from java.logging

8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating such threads, other areas of the JDK should be updated to use it. This change updates the code in