Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

All, I'll sponsor this. Best, Michael > Am 19.02.2016 um 12:37 schrieb Paul Sandoz : > > >> On 19 Feb 2016, at 06:32, shilpi.rast...@oracle.com wrote: >> >> Hi All, >> >> Please see the updated webrev >> http://cr.openjdk.java.net/~srastogi/8144931/webrev.03/ >> > > +1 > > Paul. -- <

Re: RFR:JDK-8032051:"ZonedDateTime" class "parse" method fails with short time zone offset ("+01")

Gentle Reminder On 2/12/2016 1:52 AM, nadeesh tv wrote: Hi all, Please review a fix for Bug Id https://bugs.openjdk.java.net/browse/JDK-8032051 webrev http://cr.openjdk.java.net/~ntv/8032051/webrev.01/ -- Thanks and Regards, Nadeesh TV

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

Hi Tagir, > On 21 Feb 2016, at 13:15, Tagir Valeev wrote: > > Thank you for valueable coments, here's updated webrev: > > http://cr.openjdk.java.net/~tvaleev/webrev/8072727/r2/ > > Changes: > - Spec updated according to Brian Goetz suggestion > - Predicate wildcard > - two-arg versions of iter

Collectors.minBy/maxBy behavior for null value

Hello! Consider the following code: Comparator cmp = Comparator.nullsFirst(Comparator.naturalOrder()); System.out.println(Stream.of("a", "b", null).collect(Collectors.minBy(cmp))); It prints Optional.empty, so the result is indistinguishable from empty Stream (siimlar for maxBy). This behavior i

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

Hello! Here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8072727/r3/ All mentioned issues were fixed. I agree that using new features like List.of is better, because this way it's easier to find problems with them prior to release. With best regards, Tagir Valeev. On Mon, Feb 22,

RFR(S): 8150360: augment/correct MethodHandle API documentation

Dear all, please review this (doc-only) fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8150360 Webrev: http://cr.openjdk.java.net/~mhaupt/8150360/webrev.00 The fix addresses one contradiction in the API documentation of MethodHandles.tryFinally(), and adds the following note to the API docu

JDK 9 RFR of JDK-8149154: tools/pack200/Pack200Test.java failed with NullPointerException

Please help to review this minor fix to post-test clean-up where NullPointerException should be avoided. bug: https://bugs.openjdk.java.net/browse/JDK-8149154 webrev: http://cr.openjdk.java.net/~amlu/8149154/webrev.00/ Thanks, Amy --- old/test/tools/pack200/Pack200Test.java 2016-02-20 19:1

RFR(S): 8143410: augment pseudo-code descriptions in MethodHandles API

Dear all, please review this (doc-only) fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8143410 Webrev: http://cr.openjdk.java.net/~mhaupt/8143410/webrev.00 The change documents the type variables used in the pseudo-code in the API documentation of the following methods in MethodHandles: catc

Re: Collectors.minBy/maxBy behavior for null value

On 02/22/2016 11:06 AM, Tagir Valeev wrote: Hello! Consider the following code: Comparator cmp = Comparator.nullsFirst(Comparator.naturalOrder()); System.out.println(Stream.of("a", "b", null).collect(Collectors.minBy(cmp))); It prints Optional.empty, so the result is indistinguishable from e

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

> On 22 Feb 2016, at 11:08, Tagir Valeev wrote: > > Hello! > > Here's updated webrev: > http://cr.openjdk.java.net/~tvaleev/webrev/8072727/r3/ > > All mentioned issues were fixed. Many thanks, i will start an internal compatibility revi

Re: JDK 9 RFR of JDK-8149154: tools/pack200/Pack200Test.java failed with NullPointerException

Hi Amy, Thanks for doing this. Looks good. Kumar Please help to review this minor fix to post-test clean-up where NullPointerException should be avoided. bug: https://bugs.openjdk.java.net/browse/JDK-8149154 webrev: http://cr.openjdk.java.net/~amlu/8149154/webrev.00/ Thanks, Amy --- old/t

Re: RFR 8124977 cmdline encoding challenges on Windows

Hi Naoto, Sherman, can you please take a look. I tested with the jprt build and test all tests pass. Hi Vladimir, et. al., It appears that there has been more simplifications from the previous webrev.04. :-) It would've helped if you highlight the changes you have made from the previous r

Re: RFR 8124977 cmdline encoding challenges on Windows

Few more comments on the tests: UnicodeCmdTestRun.java: The summary is fine, but it would be good to add a comment explaining what this test really does, random folks look at the tests when a test failure occurs, such a comment should help, similar to what you have in UnicodeCmdTest.java Unico

RE: RFR 8124977 cmdline encoding challenges on Windows

Hi Kumar, We posted another web review here: http://cr.openjdk.java.net/~kshoop/8124977/webrev.05/ The patch was successfully tested. Test details: * Regression tests folder: jdk/test/tools/launcher/ * Builds were used: windows-x86_64-normal-server-fastdebug, windows-x86_64-normal-server-relea

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

2016/1/28 9:25 -0800, g...@azul.com: > This thread seems to have "hopped away" to the concurrency-interest > list in mid-Dec-2015. This posting is intended to capture a summary of > reasoning and some of the discussion there so that we have it in the > record in core-libs-dev. Mostly by including t

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On 02/22/2016 12:11 PM, mark.reinh...@oracle.com wrote: 2016/1/28 9:25 -0800, g...@azul.com: This thread seems to have "hopped away" to the concurrency-interest list in mid-Dec-2015. This posting is intended to capture a summary of reasoning and some of the discussion there so that we have it in

RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Hello! When the capacity of a StringBuilder needs to be increased (either due to append() or due to explicit call to ensureCapacity()), the new capacity is calculated as "twice the old capacity, plus 2", rounded down to Integer.MAX_VALUE: http://docs.oracle.com/javase/8/docs/api/java/lang/Str

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Can you make the code look more like the recently optimized code in ArrayList and Vector? On Mon, Feb 22, 2016 at 11:20 AM, Ivan Gerasimov wrote: > Hello! > > When the capacity of a StringBuilder needs to be increased (either due to > append() or due to explicit call to ensureCapacity()), the new

Re: RFR(S): 8150360: augment/correct MethodHandle API documentation

> On 22 Feb 2016, at 12:40, Michael Haupt wrote: > > Dear all, > > please review this (doc-only) fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8150360 > Webrev: http://cr.openjdk.java.net/~mhaupt/8150360/webrev.00 > > The fix addresses one contradiction in the API documentation of > Me

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

165 final int SAFE_BOUND = (MAX_ARRAY_SIZE >> coder); 166 if (((SAFE_BOUND - newCapacity) | newCapacity) < 0) { Do the hotspot compiler engineers know you guys are doing manual branch elimination like this? :) On Mon, Feb 22, 2016 at 2:20 PM, Ivan Gerasimov wrote: > Hello! > > When

Re: RFR(S): 8143410: augment pseudo-code descriptions in MethodHandles API

> On 22 Feb 2016, at 15:08, Michael Haupt wrote: > > Dear all, > > please review this (doc-only) fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8143410 > Webrev: http://cr.openjdk.java.net/~mhaupt/8143410/webrev.00 > > The change documents the type variables used in the pseudo-code in th

Re: RFR:JDK-8032051:"ZonedDateTime" class "parse" method fails with short time zone offset ("+01")

Hi Nadeesh, Sorry for the delay. DateTimeFrmatterBuilder.java: 3387: avoid testing isStrict twice. - refactor the if's so there is an outer if for context.isStrict == false and inner if's (or tertiary ?: assignment) for the replacement parseType. if (context.isStrict() == false) {

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Feb 21, 2016, at 10:55 AM, Peter Levart wrote: > > Hi Kim, Roger, > > I have prepared another webrev which addresses your outstanding concerns: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.04/ > MethodHandleNatives.java line 71-74 Nit: can you break t

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Mandy, On 2/22/2016 4:41 PM, Mandy Chung wrote: On Feb 21, 2016, at 10:55 AM, Peter Levart wrote: I added new method to Cleaner: public boolean helpClean() { } I’m in two minds of making this a public method. An explicit way to enqueue pending references as well as invoke Cleanab

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

> On Feb 22, 2016, at 1:56 PM, Roger Riggs wrote: > > Hi Mandy, > > On 2/22/2016 4:41 PM, Mandy Chung wrote: >>> On Feb 21, 2016, at 10:55 AM, Peter Levart wrote: >>> > >>> I added new method to Cleaner: >>> >>>public boolean helpClean() { } >>> >> I’m in two minds of making this a pub

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

On 22.02.2016 22:49, Martin Buchholz wrote: Can you make the code look more like the recently optimized code in ArrayList and Vector? Sure. Please find the updated webrev below. Of course, there are nuances, as we need to deal with the compact strings, so the code isn't quite the same as in

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

On 22.02.2016 23:43, Vitaly Davidovich wrote: 165 final int SAFE_BOUND = (MAX_ARRAY_SIZE >> coder); 166 if (((SAFE_BOUND - newCapacity) | newCapacity) < 0) { Do the hotspot compiler engineers know you guys are doing manual branch elimination like this? :) Well, both these checks will be per

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Yes, but my hope would be that code could be written in the natural/"canonical" manner and the JIT could then optimize accordingly (possibly based on the target). I looked at 8u60 C2 generated asm and it does not do a transformation similar to the manual elimination in your code; I played around w

Re: RFR(S): 8150360: augment/correct MethodHandle API documentation

Hi Paul, > Am 22.02.2016 um 21:22 schrieb Paul Sandoz : > Looks good. Minor thing, no need for another webrev round. > > MethodHandles > — > > 3849 * The {@code target} and {@code cleanup} handles must have the same > corresponding argument and return types, except > 3850 * that the {

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Thanks, Ivan. I see that the capacity growth x -> 2*x + 2 is mandated by the spec, so we can't change that. Growing by more than a factor of two may mean that the "overflow-conscious" code I originally wrote may need more checks than ArrayList, where growing by 3/2 provides some sanity. --- Loo

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

In your test you refer to "Utf8" but there's no UTF-8 in use here. You probably mean UTF-16? You could port Vector/ArrayManagement that I wrote when fixing ArrayList/Vector, but I see there are more existing tests for capacity of StringB*er

Re: RFR(S): 8143410: augment pseudo-code descriptions in MethodHandles API

Hi Paul, thank you. I'm holding off on pushing; a new webrev is at http://cr.openjdk.java.net/~mhaupt/8143410/webrev.01. See below for two specific comments. > Am 22.02.2016 um 21:45 schrieb Paul Sandoz : >> Webrev: http://cr.openjdk.java.net/~mhaupt/8143410/webrev.00 >> >> The change document

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

On 2/22/16 10:23 PM, Martin Buchholz wrote: Thanks, Ivan. I see that the capacity growth x -> 2*x + 2 is mandated by the spec, so we can't change that. Growing by more than a factor of two may mean that the "overflow-conscious" code I originally wrote may need more checks than ArrayList, where