Re: RFR[9]: 8158169: MethodHandles.dropArgumentsToMatch(...)

Hi Shilpi, in that case, please make sure to give the test that already covers the IAE a @bug annotation for this issue. Thanks, Michael > Am 27.06.2016 um 17:18 schrieb "shilpi.rast...@oracle.com" > : > > Thanks Michael and Paul for comments!! > > Yes we already have negative test cases wh

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

Hi Kim, I like all the removal of the pending-list-locker related code, but can't really comment on the details of how it was replaced and interacts with all the GC code. The interface to the Reference class is fine, it is the GC code that pushes into the reference queue that I can't really c

Re: JDK 9 RFR of JDK-8156536: Remove intermittent key from java/lang/ProcessHandle/TreeTest.java

Hi Amy, Amended change looks fine too :-) Thanks, -Joe On 6/27/2016 8:23 PM, Amy Lu wrote: Thank you Joe! I just realized that this test was moved to tier2 due to stability issue. webrev updated to move the test back to tier1. Please review: http://cr.openjdk.java.net/~amlu/8156536/webrev.

Re: JDK 9 RFR of JDK-8156536: Remove intermittent key from java/lang/ProcessHandle/TreeTest.java

Thank you Joe! I just realized that this test was moved to tier2 due to stability issue. webrev updated to move the test back to tier1. Please review: http://cr.openjdk.java.net/~amlu/8156536/webrev.01/ Thanks, Amy --- old/test/TEST.groups2016-06-28 11:18:13.0 +0800 +++ new/te

Re: JDK 9 RFR of JDK-8156536: Remove intermittent key from java/lang/ProcessHandle/TreeTest.java

Looks good Amy; thanks, -Joe On 6/27/2016 7:28 PM, Amy Lu wrote: java/lang/ProcessHandle/TreeTest.java This test was failing intermittently. With several fixes, the last fix available in JDK9 build 115. Till now (build 124), no open bug (no failure reported). This patch is to remove @key

JDK 9 RFR of JDK-8156536: Remove intermittent key from java/lang/ProcessHandle/TreeTest.java

java/lang/ProcessHandle/TreeTest.java This test was failing intermittently. With several fixes, the last fix available in JDK9 build 115. Till now (build 124), no open bug (no failure reported). This patch is to remove @key intermittent from the test. Please review. bug: https://bugs.openjdk

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

> Webrev: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ make/mapfiles/libjava/mapfile-vers No comments. src/java.base/share/classes/java/lang/ref/Reference.java Much cleaner (pun might have been intended :-)). src/java.base/share/native/include/jvm.h No comments. src/java.

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

On 2016-06-28 00:11, Iris Clark wrote: HI, Claes. Sorry, uploaded the previous diff again by mistake, updated in-place now. I see the expected changes for unmodifiableList() now. Your changeset is ready to go from my point of view. Thanks! Pushed. /Claes

RE: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

HI, Claes. > Sorry, uploaded the previous diff again by mistake, updated in-place now. I see the expected changes for unmodifiableList() now. Your changeset is ready to go from my point of view. Regards, iris -Original Message- From: Claes Redestad Sent: Monday, June 27, 2016 3:07 PM

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

Sorry, uploaded the previous diff again by mistake, updated in-place now. On 2016-06-28 00:04, Mandy Chung wrote: On Jun 27, 2016, at 2:43 PM, Claes Redestad wrote: To accommodate your change request w.r.t. unmodifiableList above I took the liberty of cleaning up VersionBuilder.parse() a bi

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

> On Jun 27, 2016, at 2:43 PM, Claes Redestad wrote: > > To accommodate your change request w.r.t. unmodifiableList above I took the > liberty of cleaning up VersionBuilder.parse() a bit, though. Hope you don't > mind: > > http://cr.openjdk.java.net/~redestad/816/webrev.6/ Moving Collect

Re: [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper message displaying

I'm not familiar with this area. The changes looks reasonable enough to me. -Brent On 06/27/2016 01:19 PM, Kumar Srinivasan wrote: I am not an expert in this area, if Sergey is ok with it. I am fine with it. Brent ? Kumar Thanks, Sergey. Can someone from the core-libs launcher group pleas

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

On 2016-06-27 22:11, Iris Clark wrote: Hi, Claes. [ Sorry for the premature send, my keyboard started interpreting my shortcuts in unexpected ways. ] http://cr.openjdk.java.net/~redestad/816/webrev.5/ Nice bugid. I can hardly believe my luck! :-) Overall, this change looks good.

Re: [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper message displaying

I am not an expert in this area, if Sergey is ok with it. I am fine with it. Brent ? Kumar Thanks, Sergey. Can someone from the core-libs launcher group please approve? (looks at Kumar) -DrD- Looks fine. On 22.06.16 1:58, David DeHaven wrote: JBS: https://bugs.openjdk.java.net/browse/JD

RFR 8160312: ArrayIndexOutOfBoundsException when comparing strings case insensitive

Hi, Please help codereview the change for JDK-8160312. issue: https://bugs.openjdk.java.net/browse/JDK-8160312 webrev: http://cr.openjdk.java.net/~sherman/8160312/webrev This a regression caused by fix for JDK-8151384, http://cr.openjdk.java.net/~chegar/8151384/webrev.02 in which it over-opti

Re: RFR 8160312: ArrayIndexOutOfBoundsException when comparing strings case insensitive

Hi Sherman, Looks fine. Roger On 6/27/2016 4:04 PM, Xueming Shen wrote: Hi, Please help codereview the change for JDK-8160312. issue: https://bugs.openjdk.java.net/browse/JDK-8160312 webrev: http://cr.openjdk.java.net/~sherman/8160312/webrev This a regression caused by fix for JDK-8151384,

RE: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

Hi, Claes. [ Sorry for the premature send, my keyboard started interpreting my shortcuts in unexpected ways. ] > http://cr.openjdk.java.net/~redestad/816/webrev.5/ Nice bugid. Overall, this change looks good. I just have a few concerns. Have you built this forcing alternative build number

RFR: jsr166 jdk9 integration wave 7

jsr166 has been pervasively modified to use VarHandles, but there are some other pending changes (that cannot be cleanly separated from VarHandle conversion). We expect this to be the last feature integration for jdk9. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

Hi Iris, I've configured and run with various alternative build numbers, such as --with-version-patch=5, which produces 9.0.0.5, and verified it works. There was a bug in webrev.4 and earlier versions where a + 1 had slipped out of the loop, fixed in the latest webrev[1]. What other concern

RE: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

Hi, Claes. http://cr.openjdk.java.net/~redestad/816/webrev.4/ Overall, this change looks good. I just have a few concerns. Have you built this forcing alternative build numbers? I -Original Message- From: Claes Redestad Sent: Sunday, June 26, 2016 12:56 PM To: core-libs-dev Lib

Re: RFR 8054213: Class name repeated in output of Type.toString()

Kindly reminder On 24.06.2016 14:58, Svetlana Nikandrova wrote: Hello, let me try again with updated version of webrev: Webrev: http://cr.openjdk.java.net/~snikandrova/8054213/webrev.01/ Issue: https://bugs.openjdk.java.net/browse

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

On 2016-06-27 18:14, Mandy Chung wrote: On Jun 27, 2016, at 9:10 AM, Claes Redestad wrote: On 2016-06-27 17:22, Mandy Chung wrote: On Jun 27, 2016, at 7:16 AM, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/816/webrev.4/ Looks good in general. Thanks Mandy, I su

Re: RFR 8158023: SocketExceptions contain too little information sometimes

Christoph, I didn't understand your explanation on your message preference. Typically root cause information is printed last, not first. Another reason not to change the ordering of the exception message is that applications may be looking at existing strings. For this example, if I may presume "Ba

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

> On Jun 27, 2016, at 9:10 AM, Claes Redestad wrote: > > > > On 2016-06-27 17:22, Mandy Chung wrote: >> >>> On Jun 27, 2016, at 7:16 AM, Claes Redestad >>> wrote: >>> >>> http://cr.openjdk.java.net/~redestad/816/webrev.4/ >> >> Looks good in general. > > Thanks Mandy, > >> I suggest

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

On 2016-06-27 17:22, Mandy Chung wrote: On Jun 27, 2016, at 7:16 AM, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/816/webrev.4/ Looks good in general. Thanks Mandy, I suggest VersionProps::build to return Optional rather than Optional and make the methods in Version

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

> On Jun 27, 2016, at 7:16 AM, Claes Redestad wrote: > > http://cr.openjdk.java.net/~redestad/816/webrev.4/ Looks good in general. I suggest VersionProps::build to return Optional rather than Optional and make the methods in VersionProps package-private. Mandy

Re: RFR[9]: 8158169: MethodHandles.dropArgumentsToMatch(...)

Thanks Michael and Paul for comments!! Yes we already have negative test cases which throws IAE. This test i have added to test the scenario where pos is equal to newTpes.size() and skip is equal to target.type.parameterList.size(). (positive) Best Regards, Shilpi On 6/27/2016 6:42 PM, Paul S

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

On 2016-06-27 16:36, Remi Forax wrote: BTW, i don't know why you're using Integerr.parseInt() when for the build numbers in Version.parse() but Integer.valueOf() in version(). Oops, but since we're boxing in both cases we end up with the same bytecode. I'll make the arbitrary choice and use p

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

This is a startup optimization, not a bootstrap issue: the Multi-release feature touches Runtime.version() the first time a jar file is loaded, so we'd like to defer lambda usage from this code since a great number of small applications will take a relatively big hit. /Claes On 2016-06-27 16:

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

I'm not sure. The lazy initialization code already defers the init of the version to (maybe) a time where lambdas are available. Rémi - Mail original - > De: "Paul Sandoz" > Cc: "core-libs-dev" > Envoyé: Lundi 27 Juin 2016 16:41:02 > Objet: Re: RFR: 816: Runtime.version() cause st

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

> On 27 Jun 2016, at 16:36, Remi Forax wrote: > > Hi Claes, > > Change looks good to me :) > > just a minor nit > Optional buildNumber = build.isPresent() ? >Optional.of(Integer.valueOf(build.get())) : >Optional.empty(); > can be re-written > Optional buildNumber = build.map(Integer:

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

Hi Claes, Change looks good to me :) just a minor nit Optional buildNumber = build.isPresent() ? Optional.of(Integer.valueOf(build.get())) : Optional.empty(); can be re-written Optional buildNumber = build.map(Integer::parseInt); BTW, i don't know why you're using Integerr.parseInt()

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

> On 27 Jun 2016, at 16:16, Claes Redestad wrote: >> - 957 if (!VersionProps.VERSION_PRE.isEmpty()) { 958 pre = Optional.of(VersionProps.VERSION_PRE); 959 } else { 960 pre = Optional.empty(); 961

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

On 2016-06-27 11:18, Paul Sandoz wrote: On 27 Jun 2016, at 10:39, Claes Redestad wrote: Hi Paul, On 2016-06-27 10:07, Paul Sandoz wrote: On 26 Jun 2016, at 21:55, Claes Redestad wrote: Hi, 9+119 changed java.util.regex to initialize java.lang.invoke early, causing a number of easily

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

On 2016-06-27 11:43, Erik Joelsson wrote: Build changes look good. Thanks!

Re: RFR - 8143640: Showing incorrect result while passing specific argument in the Java launcher tool

Hi Rob, Looks good. Thanks for making this change. Kumar Hi folks, Looking for a review for this simple change: http://cr.openjdk.java.net/~robm/8143640/webrev.01/ Basically the windows command parser was inserting extra slashes under certain circumstances. cmdtoargs.c standalone test pa

Re: RFR 8158023: SocketExceptions contain too little information sometimes

Hi Christoph, thanks for the response ... yes, you do check the getLastErrorString return ... sorry about that! regards Mark On 27/06/2016 14:28, Langer, Christoph wrote: Hi Mark, thanks for looking at this. Please see my comments inline. wrt JNU_ThrowByNameWithMessaheAndLastErro

Re: [jdk9] RFR: 8160264 : Reuse Latin1/UTF16 compare routines

Thank you Paul for your review! On 27.06.2016 10:38, Paul Sandoz wrote: On 24 Jun 2016, at 16:13, Ivan Gerasimov wrote: Hello everyone! StringLatin1 and StringUTF16 helper classes have a few very symmetric methods for comparing. If we reuse them, it will save us a few bytes of generated byt

RE: RFR 8158023: SocketExceptions contain too little information sometimes

Hi Mark, thanks for looking at this. Please see my comments inline. > wrt JNU_ThrowByNameWithMessaheAndLastError, it would appear that it > doesn't allow for malloc to fail and hence > str1 could be null and a problematic input to jio_snprintf which could > result in a de-referencing of zer

Re: RFR[9]: 8158169: MethodHandles.dropArgumentsToMatch(...)

Hi, > On 27 Jun 2016, at 14:22, shilpi.rast...@oracle.com wrote: > > Hi All, > > Please review fix for > > https://bugs.openjdk.java.net/browse/JDK-8158169 > http://cr.openjdk.java.net/~srastogi/8158169/webrev.00/ > The test you added is not testing the constraints you added to the document

Re: RFR[9]: 8158169: MethodHandles.dropArgumentsToMatch(...)

Hi Shilpi, thumbs up, with one remark (see below). It seems this change would require CCC approval; please take care of the process. I will be happy to sponsor the push thereafter. Remark: how about adding negative tests? The documentation change specifies under what circumstances IAE will be

Re: RFR 8158023: SocketExceptions contain too little information sometimes

Hi, wrt JNU_ThrowByNameWithMessaheAndLastError, it would appear that it doesn't allow for malloc to fail and hence str1 could be null and a problematic input to jio_snprintf which could result in a de-referencing of zero. in the call flow would it not be more appropriate to manipulate nat

Re: RFR: JDK-8160348 - jlink should use System.out for usage messages

Thank you > On Jun 27, 2016, at 9:23 AM, Sundararajan Athijegannathan > wrote: > > +1 > > -Sundar > > > On 6/27/2016 5:46 PM, Jim Laskey (Oracle) wrote: >> Trivial patch >> >> http://cr.openjdk.java.net/~jlaskey/8160348/webrev/index.html >>

Re: RFR: JDK-8160348 - jlink should use System.out for usage messages

+1 -Sundar On 6/27/2016 5:46 PM, Jim Laskey (Oracle) wrote: > Trivial patch > > http://cr.openjdk.java.net/~jlaskey/8160348/webrev/index.html > > https://bugs.openjdk.java.net/browse/JDK-8160348 >

RFR[9]: 8158169: MethodHandles.dropArgumentsToMatch(...)

Hi All, Please review fix for https://bugs.openjdk.java.net/browse/JDK-8158169 http://cr.openjdk.java.net/~srastogi/8158169/webrev.00/ Thanks, Shilpi

RFR: JDK-8160348 - jlink should use System.out for usage messages

Trivial patch http://cr.openjdk.java.net/~jlaskey/8160348/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8160348

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

On 24.06.2016 13:47, Daniel Fuchs wrote: Thanks Georgiy! On 24/06/16 11:25, Georgiy Rakov wrote: After some thoughts I agree, redefining createContext would just check that reflection deals with methods overriding properly. BTW if a factory is an instance of JAXBContextFactory it would seem m

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

Build changes look good. /Erik On 2016-06-26 21:55, Claes Redestad wrote: Hi, 9+119 changed java.util.regex to initialize java.lang.invoke early, causing a number of easily reproducible startup regressions. This patch uses the fact that we already maintain the version string constituents d

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

> On 27 Jun 2016, at 10:39, Claes Redestad wrote: > > Hi Paul, > > On 2016-06-27 10:07, Paul Sandoz wrote: >> >>> On 26 Jun 2016, at 21:55, Claes Redestad wrote: >>> >>> Hi, >>> >>> 9+119 changed java.util.regex to initialize java.lang.invoke early, causing >>> a number of easily reproduci

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

Hi Paul, On 2016-06-27 10:07, Paul Sandoz wrote: On 26 Jun 2016, at 21:55, Claes Redestad wrote: Hi, 9+119 changed java.util.regex to initialize java.lang.invoke early, causing a number of easily reproducible startup regressions. This patch uses the fact that we already maintain the versi

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

> On 26 Jun 2016, at 21:55, Claes Redestad wrote: > > Hi, > > 9+119 changed java.util.regex to initialize java.lang.invoke early, causing a > number of easily reproducible startup regressions. > > This patch uses the fact that we already maintain the version string > constituents during buil

Re: RFR: 8155770 Correct URLClassLoader API documentation to explicitly say jar-scheme URL's are accepted

> On 25 Jun 2016, at 01:10, Steve Drach wrote: > > Hi, > > Please review this simple change to the URLClassLoader specification. > > issue: https://bugs.openjdk.java.net/browse/JDK-8155770 > > webrev: http://cr.openjdk.java.net/~sdrach/815577

RE: RFR 8158023: SocketExceptions contain too little information sometimes

Hi, eventually here is the - hopefully final - version of this fix: http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ Now I leave JNU_ThrowByNameWithLastError untouched and I've also added conversion to the new function JNU_ThrowByNameWithMessageAndLastError. I've replaced JNU_ThrowByNameW

Re: [jdk9] RFR: 8160264 : Reuse Latin1/UTF16 compare routines

> On 24 Jun 2016, at 16:13, Ivan Gerasimov wrote: > > Hello everyone! > > StringLatin1 and StringUTF16 helper classes have a few very symmetric methods > for comparing. > If we reuse them, it will save us a few bytes of generated bytecode. > > Would you please help review this? > > BUGURL: h