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

Hi Claes, Peter, Vladimir, all, I really support Peter's latest proposal: it reduces the amounts of code, synchronisation, and complication, and actually addresses the problem at hand too. What's more to wish for? :-) I propose to adopt this solution:

Re: RFR 8141409 Arrays.equals accepting a Comparator

> On 4 Nov 2015, at 22:41, Paul Sandoz wrote: > >> The null handling choice seems arbitrary. > > I wanted Arrays.equals to be consistent with the Comparable accepting > Arrays.compare and Arrays.mismatch, so it was a coin toss between nulls first > and nulls last,

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

On 11/05/2015 12:09 AM, Claes Redestad wrote: 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/

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

Thanks David and Staffan! Chris On 11/4/15 11:25 PM, Staffan Larsen wrote: 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/

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

On 2015-11-05 08:00, Peter Levart wrote: Ok, here it is: http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.03/ I just moved CACHE registration into SpeciesData.initForBootstrap() method, so no new method is needed. Note that patched source now contains the same number of lines

Re: RFR (S): 8141536, 8141539: Minor java.lang.invoke improvements

On 2015-11-05 16:02, Vladimir Ivanov wrote: Looks good. Best regards, Vladimir Ivanov Thanks! /Claes On 11/5/15 5:07 PM, Claes Redestad wrote: Hi, looking for reviews for two trivial improvements to java.lang.invoke: 8141536: MethodType field offset calculation could be lazy Webrev:

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

Hi Peter, but this is more like a separate RFE for improving the testing infrastructure, right? Or am I missing something? Unless this is important for the fix to 8131129, I'd like to keep it separate. Best, Michael > Am 05.11.2015 um 17:25 schrieb Peter Levart : > >

Re: RFR: 8141546 Fix typo in javadoc for Connection

On 05/11/2015 16:04, Lance Andersen wrote: Hi, Need a quick review to fix a javadoc issue that I missed (thought I ran -Xdoclint but did not) Looks fine.

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

On 11/05/2015 02:16 PM, Michael Haupt wrote: Hi Claes, Peter, Vladimir, all, I really support Peter's latest proposal: it reduces the amounts of code, synchronisation, and complication, and actually addresses the problem at hand too. What's more to wish for? :-) I propose to adopt this

RFR: 8141546 Fix typo in javadoc for Connection

Hi, Need a quick review to fix a javadoc issue that I missed (thought I ran -Xdoclint but did not) Best Lance [ljanders-mac:classes/java/sql] ljanders% javac -Xdoclint Connection.java [ljanders-mac:classes/java/sql] ljanders% hg diff Connection.java diff -r 67d91e7479c1

Re: RFR (S): 8141536, 8141539: Minor java.lang.invoke improvements

Hi Claes, lower-case (not a Reviewer) thumbs up on both. Best, Michael > Am 05.11.2015 um 15:07 schrieb Claes Redestad : > > Hi, > > looking for reviews for two trivial improvements to java.lang.invoke: > > 8141536: MethodType field offset calculation could be

Re: RFR 8136496 Connection.begin/endRequest

Hi Lance, Looks fine except for a few editorial fixes. Editorial: - Update copyrights to 2015. src/java.sql/share/classes/java/sql/Connection.java: - about 1515: "." on a separate line. - several places: missing "." after "no-op" - later: missing "." after "{@code beginRequest} is a

Re: RFR (S): 8141536, 8141539: Minor java.lang.invoke improvements

Looks good. Best regards, Vladimir Ivanov On 11/5/15 5:07 PM, Claes Redestad wrote: Hi, looking for reviews for two trivial improvements to java.lang.invoke: 8141536: MethodType field offset calculation could be lazy Webrev: http://cr.openjdk.java.net/~redestad/8141536/webrev.01 Bug:

Re: RFR (S): 8141536, 8141539: Minor java.lang.invoke improvements

Both improvements look good. Thanks, -Aleksey On 11/05/2015 05:07 PM, Claes Redestad wrote: > looking for reviews for two trivial improvements to java.lang.invoke: > > 8141536: MethodType field offset calculation could be lazy > > Webrev: http://cr.openjdk.java.net/~redestad/8141536/webrev.01

Re: RFR: 8141546 Fix typo in javadoc for Connection

Looks good! /Claes On 2015-11-05 17:04, Lance Andersen wrote: Hi, Need a quick review to fix a javadoc issue that I missed (thought I ran -Xdoclint but did not) Best Lance [ljanders-mac:classes/java/sql] ljanders% javac -Xdoclint Connection.java [ljanders-mac:classes/java/sql] ljanders% hg

RFR (S): 8141536, 8141539: Minor java.lang.invoke improvements

Hi, looking for reviews for two trivial improvements to java.lang.invoke: 8141536: MethodType field offset calculation could be lazy Webrev: http://cr.openjdk.java.net/~redestad/8141536/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8141536 8141539: Avoid calculating string

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

Hi, Here’s a new webrev that addresses the issues Paul brought up. The versioned entry cache has been removed, the search space has been reduced, the documentation for setVersioned(int) and setRuntimeVersioned() has been updated to clarify when IllegalStateException is thrown, and the tests

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

Hi Chris, The langtools and jaxp repos also have TEST.ROOT files with a requiredVersion clause. I'd prefer if the files in those repos were updated at the same to b12. Thanks, -Joe On 11/4/2015 6:25 PM, Chris Plummer wrote: Please review the following changes:

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

Hi Michael, The test failure exposed a weakness in the BMH subclass generation and initialization which is fixed by a patch to BMH. OTOH the test will still fail next time with a different exception but that is another issue, I agree. Regards, Peter On 11/05/2015 05:34 PM, Michael Haupt

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

On 11/05/2015 08:05 PM, Peter Levart wrote: Hi Michael, The test failure exposed a weakness in the BMH subclass generation and initialization which is fixed by a patch to BMH. OTOH the test will still fail next time with a different exception but that is another issue, I agree. We can

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

Hi Joe, Here's the updated webrev: http://cr.openjdk.java.net/~cjplummer/8141489/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8141489 These are all the repos that have been updated: >$ grep requiredVersion `find . -name TEST.ROOT` ./hotspot/test/TEST.ROOT:requiredVersion=4.1 b12

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

On 11/04/2015 07:15 PM, Mandy Chung wrote: [...] For short-circuiting, I also think it’s reasonable to expect the user know how many remaining frames it expects to traverse and it may not need to increase the batch size i.e. it might not need to update the remainingNeeded over time. The user

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

- Mail original - > De: "Mandy Chung" > À: "Remi Forax" > Cc: "Paul Sandoz" , core-libs-dev@openjdk.java.net > Envoyé: Jeudi 5 Novembre 2015 22:48:45 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > > > On

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

Hi Chris, Looks fine to me; thanks, -Joe On 11/5/2015 11:12 AM, Chris Plummer wrote: Hi Joe, Here's the updated webrev: http://cr.openjdk.java.net/~cjplummer/8141489/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8141489 These are all the repos that have been updated: >$ grep

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

Peter, Michael, Very good work! I really like how CMH-based BMH & SpeciesData caches shape out in your proposal. http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.04/ Small cleanup suggestion: +static boolean speciesDataCachePopulated() { +Class rootCls =

JEP 279: Improve Test-Failure Troubleshooting

New JEP Candidate: http://openjdk.java.net/jeps/279 - Mark

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

Hi Vladimir, On 11/05/2015 11:06 PM, Vladimir Ivanov wrote: Peter, Michael, Very good work! I really like how CMH-based BMH & SpeciesData caches shape out in your proposal. http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.04/ Small cleanup suggestion: +static boolean

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

Hi Chris, On 11/5/2015 9:26 AM, Chris Plummer wrote: Hi Joe, Is there a reason to upgrade them if the tests don't actually require b12? BTW, there are more than just those two repos. The following all have TEST.ROOT: bash-4.1$ find . -name TEST.ROOT ./hotspot/agent/test/jdi/TEST.ROOT

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

On 11/5/15 10:16 AM, joe darcy wrote: Hi Chris, On 11/5/2015 9:26 AM, Chris Plummer wrote: Hi Joe, Is there a reason to upgrade them if the tests don't actually require b12? BTW, there are more than just those two repos. The following all have TEST.ROOT: bash-4.1$ find . -name TEST.ROOT

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

> On Nov 4, 2015, at 5:00 AM, Remi Forax wrote: > >> >> Good point. Damn, i don’t like wildcards :-) >> >> The following works fine: >> >> static Function counter() { >> return Stream::count; >> } >> >> But there could also cases where one is stuck

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

I had thought the wildcard would get captured and then trivially found to match StackFrame exactly, but I guess that’s available only for the first level wildcards. Which means I’ve been wrongly thinking wildcard typing to be way less constrained than it apparently is. Wow, they had one job, to

Re: RFR: JDK-8140364: JEP 264 Platform Logger API and Service Implementation

Thanks Daniel. I haven’t found the cycle to pull down your updates from the logging sandbox to review If the change is the same as you sent me earlier, your change should be good to go. Mandy > On Nov 3, 2015, at 12:12 PM, Daniel Fuchs wrote: > > Hi Mandy, > > I

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

> On Nov 5, 2015, at 2:43 PM, David M. Lloyd wrote: > > On 11/04/2015 07:15 PM, Mandy Chung wrote: >> [...] >> For short-circuiting, I also think it’s reasonable to expect the user know >> how many remaining frames it expects to traverse and it may not need to >>

Re: Questions about Stream/Iterable/Files - and possibly the compiler

- Mail original - > De: "Fabrizio Giudici" > À: core-libs-dev@openjdk.java.net > Envoyé: Jeudi 5 Novembre 2015 22:12:53 > Objet: Questions about Stream/Iterable/Files - and possibly the compiler > > Hello. Hello Fabrizio, > > My question is for the sake

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

Hi, I tested all 6 combinations of Functions that a simple sanity-check StackWalker can call: Function, [any]> Function, [any]> Function, [any]> Function Function Function Unfortunately there doesn’t appear to be any candidate for the

RFR: updated draft API for JEP 269 Convenience Collection Factories

nue moving it forward. Javadoc: http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151105/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151105/java/util/package-summary.html Webrev: http://cr.openjdk.java.net/~smarks/reviews/jep269/webre

RFR 9: 8132394 : (process) ProcessBuilder support for a pipeline of processes

Please review the new ProcessBuilder.startPipeline API, implementation, and tests. The new method starts a Process for each ProcessBuilder, creating a pipeline of processes linked by their standard output and standard input streams. Each builder can use redirectErrorsream to coalesce error

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

On 04/11/15 11:19, Timo Kinnunen wrote: 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 {

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

> serialization proxies), will come after that. > > I'll be at Devoxx Antwerp next week so there will likely be some delay in my > responses on this list. But I might see some of you there as well. If so, > please > say hi! In any case I'll pick this up mid-November and continue movin

Re: RFR 8136496 Connection.begin/endRequest

Hi Roger, thank you. I made the proposed changes below. Yes I will do a format clean-up separately as there are issues in multiple places Best Lance On Nov 5, 2015, at 10:00 AM, Roger Riggs wrote: > Hi Lance, > > Looks fine except for a few editorial fixes. > >