Re: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12

Looks good! Thanks, /Staffan > On 5 nov. 2015, at 03:25, Chris Plummer wrote: > > Please review the following changes: > > http://cr.openjdk.java.net/~cjplummer/8141489/ > https://bugs.openjdk.java.net/browse/JDK-8141489 > > The changes I did for 8140189 require that version 4.1 b12 of jtreg

Re: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12

Looks good to me Chris! Thanks, David On 5/11/2015 12:25 PM, Chris Plummer wrote: Please review the following changes: http://cr.openjdk.java.net/~cjplummer/8141489/ https://bugs.openjdk.java.net/browse/JDK-8141489 The changes I did for 8140189 require that version 4.1 b12 of jtreg be used, s

[RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12

Please review the following changes: http://cr.openjdk.java.net/~cjplummer/8141489/ https://bugs.openjdk.java.net/browse/JDK-8141489 The changes I did for 8140189 require that version 4.1 b12 of jtreg be used, so TEST.ROOT has been updated to reflect this. Testing with JPRT right now. I also

Re: Proposed API for JEP 259: Stack-Walking API

> On Nov 4, 2015, at 12:21 AM, Peter Levart wrote: > >> >> I was not thinking of calling StackWalker::getCallerClass from native, but >> calling some method from native, which then calls >> StackWalker::getCallerClass. The method itself can not anticipate how it >> will be called. Most metho

Re: Proposed API for JEP 259: Stack-Walking API

Sorry for the delay getting back to this. > On Nov 2, 2015, at 4:46 AM, David M. Lloyd wrote: > > I think there are two problems with the current approach: > > 1. The function for getting the next batch size is not coupled to the > function actually doing the work. I think it is just as lik

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

Hi Claes, On 11/04/2015 09:12 PM, Claes Redestad wrote: Hi, On 2015-11-04 13:18, Peter Levart wrote: Here's what I am thinking, in code: http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.02/ Now that definition of BMH subclass is atomic, caching of SpeciesData can be simplified.

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

On 2015-11-04 23:31, Peter Levart wrote: Hi Claes, On 11/04/2015 09:12 PM, Claes Redestad wrote: Hi, On 2015-11-04 13:18, Peter Levart wrote: Here's what I am thinking, in code: http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.02/ Now that definition of BMH subclass is atomic, c

Re: RFR 8141409 Arrays.equals accepting a Comparator

> On 4 Nov 2015, at 17:51, Mike Duigou wrote: > >> Date: Wed, 4 Nov 2015 15:32:25 +0100 >> From: Paul Sandoz >> To: core-libs-dev >> Subject: RFR 8141409 Arrays.equals accepting a Comparator >> Please review: >> In addition i added an Objects.compare method, which simplifies the >> implementat

JDK 9 RFR of JDK-8141454: Move java/lang/ProcessHandle/TreeTest.java until stability improves

Hello, Please review the simple patch below which addresses JDK-8141454: Move java/lang/ProcessHandle/TreeTest.java until stability improves In summary, the patch moves the test java/lang/ProcessHandle/TreeTest.java from tier 1 to tier 2; the test can be moved back to tier 1 once better

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

Hi, On 2015-11-04 13:18, Peter Levart wrote: Here's what I am thinking, in code: http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.02/ Now that definition of BMH subclass is atomic, caching of SpeciesData can be simplified. We don't need special placeholder instances as locks and

Re: JDK 9 RFR of JDK-8141454: Move java/lang/ProcessHandle/TreeTest.java until stability improves

Hi Joe, Looks fine. Roger On 11/4/15 12:23 PM, joe darcy wrote: Hello, Please review the simple patch below which addresses JDK-8141454: Move java/lang/ProcessHandle/TreeTest.java until stability improves In summary, the patch moves the test java/lang/ProcessHandle/TreeTest.java fro

Re: RFR 8141409 Arrays.equals accepting a Comparator

Date: Wed, 4 Nov 2015 15:32:25 +0100 From: Paul Sandoz To: core-libs-dev Subject: RFR 8141409 Arrays.equals accepting a Comparator Please review: In addition i added an Objects.compare method, which simplifies the implementations of some object-bearing methods. Why not put the method on Compa

Re: [8u-dev] Request for review and approval: 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev

Sorry for the delay Michael, I had understood the subject to mean you were waiting on another explicit review. Approved. -Rob On 04/11/15 08:39, Michael Haupt wrote: All, the code in question has been reviewed already: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-Februa

Re: JDK 9 RFR of JDK-8141359: @Deprecated on packages should be clarified

Hi Joe, Looks fine. Roger On 11/3/2015 9:48 PM, joe darcy wrote: Hello, Please review the short patch below to address JDK-8141359: @Deprecated on packages should be clarified --- a/src/java.base/share/classes/java/lang/Deprecated.javaTue Nov 03 17:41:38 2015 -0800 +++ b/src/java.

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On Nov 4, 2015, at 1:01 AM, Paul Sandoz wrote: > > Hi Steve, > > Hi Steve, > > I don’t think we need to cache versioned entries (as we discussed a while > back). For class loading it’s likely to increase memory costs without any > performance benefit (if anything a performance decrease). I

Re: [8u-dev] Request for review and approval: 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev

Hi Rob, my bad. Thanks a lot! Michael > Am 04.11.2015 um 16:09 schrieb Rob McKenna : > > Sorry for the delay Michael, I had understood the subject to mean you were > waiting on another explicit review. > > Approved. > > -Rob > > On 04/11/15 08:39, Michael Haupt wrote: >> All, >> >> t

OT: working directory of another drive on cygwin

In Windows, there is a concept called working directory of another drive. For example, in a cmd.exe windows, you can call cd d:\xyz and although you are now still in C:, but if you call "D:" to go to the D: drive, you will find yourself in d:\xyz. In fact, Paths.get("d:").toAbsolutePath()

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 11/03/2015 10:42 PM, Roger Riggs wrote: I’m in two minds that it sounds sensible for this Cleaner API to extend for soft/weak references whereas I am not certain of the use cases. Anyone can share the known use cases that would be helpful. Besides the cases already mentioned on the thr

RFR 8141409 Arrays.equals accepting a Comparator

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8141409-Arrays-equals-comparator/webrev/ https://bugs.openjdk.java.net/browse/JDK-8141409

Re: Proposed API for JEP 259: Stack-Walking API

- Mail original - > De: "Paul Sandoz" > Cc: core-libs-dev@openjdk.java.net > Envoyé: Mercredi 4 Novembre 2015 10:57:41 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > > > On 4 Nov 2015, at 10:03, Remi Forax wrote: > > > > Hi Paul, > > > > The use of BaseStream was just an

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

Hi Michael, Vladimir, I have finally managed to look at the code on a bigger screen and I think your latest webrev is correct now. But it feels like it works around the fact that BMH subclass definition (just definition, not initialization) is not atomic. I asked myself why normal class loadin

RE: Proposed API for JEP 259: Stack-Walking API

Hi, I tested your version of the wildcard counter and it appears to be incompatible with one possible signature of the StackWalker.walk method. Here’s my code. Please see the line with ERROR comment: static class StackWalker { static class StackFrame implements CharSeq

Re: Proposed API for JEP 259: Stack-Walking API

On 04/11/15 02:59, Mandy Chung wrote: > >> On Nov 3, 2015, at 2:08 PM, David M. Lloyd >> wrote: >> >>> I considered Optional>. I believe it is rare to have a >>> JNI attached thread calling StackWalker::getCallerClass from >>> native. Most common cases will find a caller class. Returning >>>

Re: jmx-dev RFR 6425769: jmx remote bind address

Hi, Updated webrev with jtreg test in Java: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ bug: https://bugs.openjdk.java.net/browse/JDK-6425769 I believe this updated webrev addresses all concerns and incorporates suggestions brought up by Jaroslav and Daniel. I'm still looking fo

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, Hi Steve, I don’t think we need to cache versioned entries (as we discussed a while back). For class loading it’s likely to increase memory costs without any performance benefit (if anything a performance decrease). It’s easy to add back later on if we have data that suggests otherwi

Re: Proposed API for JEP 259: Stack-Walking API

Hi Paul, The use of BaseStream was just an example, here is another one that works only if the function first parameter type is declared as '? super Stream'. static Function, Integer> counter() { return stream::count; } ... StackWalker walker = ... int count = walker.walk(counter()); regard

Re: Proposed API for JEP 259: Stack-Walking API

> On 4 Nov 2015, at 10:03, Remi Forax wrote: > > Hi Paul, > > The use of BaseStream was just an example, here is another one that works > only if the function first parameter type is declared as '? super > Stream'. > > static Function, Integer> counter() { > return stream::count; > } > > .

Re: Proposed API for JEP 259: Stack-Walking API

> On 4 Nov 2015, at 04:50, Mandy Chung wrote: > > >> On Nov 3, 2015, at 3:28 AM, Paul Sandoz wrote: >> >> Hi Mandy, >> >> This is very nice work. >> >> Comments below, mostly minor stuff. >> > > Thanks for the review. > > I fixed most of the comments below. One question: > > Is the na

Re: Proposed API for JEP 259: Stack-Walking API

On 11/04/2015 09:06 AM, Peter Levart wrote: What would it be if getCallerClass() returned just Optional> and was left to the user to decide what to do in corner cases when there is no Java caller? I considered Optional>. I believe it is rare to have a JNI attached thread calling StackWalker

Re: [8u-dev] Request for review and approval: 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev

All, the code in question has been reviewed already: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031871.html Best, Michael > Am 02.11.2015 um 09:12 schrieb Michael Haupt : > > (Apologies for multiple posts with wrong subject lines.) > >> Dear all, >> >> cross-posted t

Re: Proposed API for JEP 259: Stack-Walking API

On 11/03/2015 10:33 PM, Mandy Chung wrote: On Nov 3, 2015, at 4:45 AM, Peter Levart wrote: Hi Mandy, Great API. One thing I noticed is method StackWalker.getCallerClass() which is described as equivalent to the following: walk((s) -> s.map(StackFrame::getDeclaringClass)