Re: RFR: jsr166 jdk9 integration wave 13

ractions > like shiftTailOverGap and circularClear. Another possibility is to introduce > our own tiny helper method without checks > > nullOutSlice(Object[] a, int from, int to) > > On Tue, Dec 13, 2016 at 5:26 PM, Paul Sandoz <paul.san...@oracle.com > <mailto:paul.s

Re: RFR: jsr166 jdk9 integration wave 13

Working my way through it… One general question: why did you replace Arrays.fill with an explicit loop in many cases? Paul. > On 13 Dec 2016, at 15:13, Martin Buchholz wrote: > > We were supposed to be winding down jdk9, and there are a lot of changes > here, but ...

Re: JDK 9 RFR of JDK-8023898: Consolidate Map tests Collisions and InPlaceOpsCollisions into general Map-based test

> On 11 Dec 2016, at 18:07, Amy Lu wrote: > > Yes :-) > > Fixed for Collisions.testIntegerIteration and Collisions.testStringIteration: > http://cr.openjdk.java.net/~amlu/8023898/webrev.02/ > +1 Paul.

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

> On 11 Dec 2016, at 06:04, Vincent Ryan wrote: > > Unfortunately this feature has arrived a little too late so I’m withdrawing > it from consideration for JDK 9. > Thanks again to those who took time to review it. > +1 to defer to 10 (and review comments are of

Re: JDK 9 RFR of JDK-8023898: Consolidate Map tests Collisions and InPlaceOpsCollisions into general Map-based test

Hi Amy, A nice refactoring and clean up. For some test cases in Collisions you don’t need to obtain the array of keys, you just need to know the key length, which can be obtained from map.size(). Paul. > On 8 Dec 2016, at 19:19, Amy Lu wrote: > > Please review this test

Re: RFR(s): JDK-8170943 Collectors.partitioningBy should specify that false and true entries are always present

+1 I was tempted to saying something more about an associated value if it was not operated on (accumulated and combined), but that’s probably api note territory. Paul. > On 8 Dec 2016, at 14:48, Stuart Marks wrote: > > Hi all, > > Please review this small spec

Re: RFR JDK-8170961: ProblemList tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java due to JDK-8169971

+1 I have not found the cause as to why this test is failing on windows. The test cleans up by deleting directory contents created for jar construction, but for some reason files in the directory become inaccessible so the directory itself cannot be deleted. Paul. > On 8 Dec 2016, at 19:07,

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

Hi, It may take a few iterations to get the API settled. There are other byte sources we may want to consider such as InputStream and ByteBuffer. Comments below. Paul. > On 7 Dec 2016, at 08:32, Vincent Ryan wrote: > > A hexdump facility has been available for

Re: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char

> On 8 Dec 2016, at 01:27, Claes Redestad wrote: > > > > On 2016-12-08 10:01, Ulf Zibis wrote: >> Am 08.12.2016 um 09:28 schrieb Peter Levart: >>> >>> On 12/07/2016 11:28 PM, Roger Riggs wrote: AbstractStringBuilder: I agree with Claes' comment

Re: RFR 9: JDK 8170831: ZipFile implementation no longer caches the last accessed entry/pos

> On 7 Dec 2016, at 11:29, Xueming Shen wrote: > > Hi Paul, > > Thanks for the suggestion. Webrev has been updated accordingly. > > http://cr.openjdk.java.net/~sherman/8170831 > +1 > Sherman >

Re: RFR 9: JDK 8170831: ZipFile implementation no longer caches the last accessed entry/pos

Hi, 334 if (lastEntryName != null && lastEntryName == entry.name) { Can you just do: if (Objects.equals(lastEntryName, entry.name)) { // [*] ? the assumptions being entry.name is never null, which i believe is valid, and one can check the string contents if refs are not equal.

Re: RFR(s): 8166446 SingletonIterator.forEachRemaining doesn't advance before calling action

> On 6 Dec 2016, at 13:28, Stuart Marks wrote: > > Hi all, > > Please review this small fix to adjust the behavior of > SingletonIterator.forEachRemaining in the case where its action throws an > exception: > >

Re: default methods inherited by EnumSet and EnumMap

I logged this issue for EnumSet/EnumMap: https://bugs.openjdk.java.net/browse/JDK-8170826 Paul. > On 6 Dec 2016, at 09:53, Martin Buchholz wrote: > > Almost every core library collection class can benefit from

RFR 8170733: HashMap.HashIterator.remove method does not use cached value for the hash code.

Hi, Please review this small fix to the Linked/HashMap iterators. The remove method can use the cached hash code. Paul. diff -r 5c9389804cbc src/java.base/share/classes/java/util/HashMap.java --- a/src/java.base/share/classes/java/util/HashMap.javaMon Dec 05 12:53:53 2016 +0530 +++

Re: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char

> On 4 Dec 2016, at 08:42, Ivan Gerasimov wrote: > > Thank you Claes for looking into it! > > > On 04.12.2016 16:48, Claes Redestad wrote: >> Hi Ivan, >> >> as this adds a new public API I guess it's too late for 9 at this point, but >> here's a few >> comments

Re: Review Request: JDK-8170633 backslashes in gensrc/module-info.java comments need escaping

> On 2 Dec 2016, at 09:39, Mandy Chung wrote: > > The build tool generating module-info.java includes the path name of the > source files in the comment for diagnosis where backslash character needs > escaping. This patch prints URI rather than file path. > +1

Re: RFR 8170155: StringBuffer and StringBuilder stream methods are not late-binding

> On 1 Dec 2016, at 11:17, Xueming Shen <xueming.s...@oracle.com> wrote: > > On 11/28/2016 11:27 AM, Paul Sandoz wrote: >>> On 25 Nov 2016, at 02:47, Tobias Hartmann<tobias.hartm...@oracle.com> >>> wrote: >>> >>>> I'm not sure

Re: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

> On 30 Nov 2016, at 13:47, Patrick Reinhart wrote: > > Hi Roger, > >> Am 30.11.2016 um 20:01 schrieb Roger Riggs : >> >> Hi Patrick, >> >> I have reservations about trying to get this into JDK 9. Because it is a >> new API, >> it should have some

Re: RFR[9]: 8133719 java.lang.InternalError in java.lang.invoke.MethodHandleImpl$BindCaller.bindCaller

> On 23 Nov 2016, at 22:11, shilpi.rast...@oracle.com wrote: > > Hi All, > > Please review fix for > > https://bugs.openjdk.java.net/browse/JDK-8133719 > http://cr.openjdk.java.net/~srastogi/8133719/webrev.01/ > +1 Paul.

Re: RFR 8170155: StringBuffer and StringBuilder stream methods are not late-binding

> On 25 Nov 2016, at 02:47, Tobias Hartmann wrote: > >> I'm not sure if it is still desired to do the same boundary check in case of >> LATIN1 >> for the benefit of consistency. Assume there might be concurrent >> access/operation >> between val = this.value and

RFR 8170155: StringBuffer and StringBuilder stream methods are not late-binding

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/ This patch: 1) updates the StringBuilder/StringBuffer.chars()/codePoints() so they are late binding. 2) refactors the spliterator late binding and fail fast tests, separating

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

Stuart and I refined the text to mention a concurrent modification policy (e.g. fail-fast or weakly consistent) of any overriding class. Paul. diff -r c7b932897909 src/java.base/share/classes/java/lang/Iterable.java --- a/src/java.base/share/classes/java/lang/Iterable.java Wed Nov 23

Re: RFR 8169808 Stream returning methods should specify if they are late binding

> On 23 Nov 2016, at 07:50, Doug Lea wrote: > > On 11/23/2016 10:05 AM, Martin Buchholz wrote: >> Right now, PBQ's spliterator is in violation of >> >> """A Spliterator that does not report IMMUTABLE or CONCURRENT is >> expected to have a documented policy concerning: when

Re: JDK 9 RFR of JDK-8169479: java.lang.reflect.Constructor class has wrong api documentation

+1 Paul. > On 23 Nov 2016, at 08:10, joe darcy wrote: > > Hello, > > Please review the changes to address > >JDK-8169479: java.lang.reflect.Constructor class has wrong api > documentation >http://cr.openjdk.java.net/~darcy/8169479.0/ > > Patch inline below.

Re: RFR 8169808 Stream returning methods should specify if they are late binding

Hi Tagir, Yes, it applies to all implementations. I think the risk of incompatibility is low for 9. Based on analysis on grepcode most CharSequence implementations don’t override the stream returning methods, those few that do defer to some other sequence. Paul. > On 21 Nov 2016, at 19:44,

Re: 8072784: Better spliterator implementation for BitSet.stream()

> On 21 Nov 2016, at 20:00, Tagir Valeev wrote: > > Hello! > >> Hi Tagir, >> >> In the original issue i was pondering using SIZED for smaller bit sets and >> non-SIZED for larger bit sets, since we stride over the longs themselves >> when calculating the size (should be

Re: RFR 8169808 Stream returning methods should specify if they are late binding

> On 21 Nov 2016, at 14:19, Martin Buchholz <marti...@google.com> wrote: > > > > On Mon, Nov 21, 2016 at 1:06 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > > > The CONCURRENT Spliterators in j.u.c. do not document late-binding, but > > prob

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

> On 21 Nov 2016, at 13:21, Martin Buchholz <marti...@google.com> wrote: > > > > On Mon, Nov 21, 2016 at 1:01 PM, Paul Sandoz <paul.san...@oracle.com > <mailto:paul.san...@oracle.com>> wrote: > > > There's the question of what to promise a

Re: RFR 8169808 Stream returning methods should specify if they are late binding

ctored out as it’s conflating two concepts and is too collection/map focused. Paul. > > > On Mon, Nov 21, 2016 at 12:30 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > Hi, > > Please review this specification clarification for the stream returning > methods on

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

> On 21 Nov 2016, at 12:32, Martin Buchholz wrote: > > Thanks. Seems like progress. > > The spec below seems like it could be improved, but not sure how... > > + * > + * The behavior of an iterator is unspecified if the action performs the > + * following

RFR 8132964 Spliterator documentation on Priority(Blocking)Queue

Hi, Please review specification clarifications to PriorityQueue and PriorityBlockingQueue for the spliterator. Ordinarily i would not specify what spliterator characteristics are not reported, but in this case given what is said about iterator I think it reasonable to say it about spliterator

RFR 8169808 Stream returning methods should specify if they are late binding

Hi, Please review this specification clarification for the stream returning methods on CharSequence and BitStream. Those methods specify that the stream is late-binding for mutable sequences. I think those are the only relevant cases, please tell me if there are more! When looking at

RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

Hi, Please review these specification clarifications to the methods Iterator.forEachRemaining and Iterator.remove. Implementations of Iterator.forEachRemaining should have some wiggle room to optimize traversal. (In hindsight we could have done a better job locking such behaviour down in Java

Re: RFR: jsr166 jdk9 integration wave 12

f you happen to, why such an improvement was gained for explicitly inlining the getFence call. Were you reaching some inlining thresholds in hotspot? Paul. > > On Thu, Nov 17, 2016 at 7:41 PM, Martin Buchholz <marti...@google.com > <mailto:marti...@google.com>&g

Re: 8072784: Better spliterator implementation for BitSet.stream()

Hi Tagir, In the original issue i was pondering using SIZED for smaller bit sets and non-SIZED for larger bit sets, since we stride over the longs themselves when calculating the size (should be intrinsic to count the set bits, at least on x86). Supporting both is fairly simple, but you are

Re: RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0

> On 18 Nov 2016, at 06:52, Claes Redestad wrote: > > Hi, > > having classes ask the security manager for permission to access its own > class loader > when probing for assertion status during class initialization appears > pointless. > > Bug:

Re: RFR: jsr166 jdk9 integration wave 12

I encourage you to look at the experiments in the valhalla repository. Such as: http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/780c8eba356a/src/java.base/share/classes/java/anyutil/ArrayDeque.java

Re: RFR: jsr166 jdk9 integration wave 12

lt;marti...@google.com <mailto:marti...@google.com>> > > À: "Paul Sandoz" <paul.san...@oracle.com <mailto:paul.san...@oracle.com>> > > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net > > <mailto:core-libs-dev@openjdk.java.net>

Re: RFR: jsr166 jdk9 integration wave 12

> On 18 Nov 2016, at 04:52, Doug Lea <d...@cs.oswego.edu> wrote: > > >> On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz <paul.san...@oracle.com >> <mailto:paul.san...@oracle.com>> wrote: >> >> >>Semaphore >>— >>

Re: RFR: jsr166 jdk9 integration wave 12

> On 17 Nov 2016, at 13:58, Martin Buchholz <marti...@google.com> wrote: > > > > On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz <paul.san...@oracle.com > <mailto:paul.san...@oracle.com>> wrote: > > ForkJoin > — > > 69 * tasks that a

Re: RFR: jsr166 jdk9 integration wave 12

69 * tasks that are never joined. All worker threads are initialized 70 * with {@link Thread#isDaemon} set {@code true}. CCC? Thanks, Paul. > > > On Wed, Nov 16, 2016 at 3:34 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > Hi Martin, > > Glad you looked mor

Re: RFR: 8169880: Remove the sun.reflect.noCaches option

+1 Paul. > On 17 Nov 2016, at 07:33, Claes Redestad wrote: > > Hi, > > The undocumented sun.reflect.noCaches option was put in place as a > debugging aid when caching was added to core reflection[1], with the > intent to remove it once overly inefficient uses of

Re: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX()

> On 16 Nov 2016, at 17:02, Brent Christian <brent.christ...@oracle.com> wrote: > > On 11/16/16 3:44 PM, Paul Sandoz wrote: >> Hi Brent, >> >> I think it would be better to use Objects.requireNonNull > > Yes, thank you - forgot about that. > >

RFR 8169838 java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed intermittently

Hi, Please review this small update to the spliterator traversing test to remove test cases for BitSet when the Integer.MAX_VALUE bit (or close to) is set. diff -r 382f7f3a1888 test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java ---

Re: Proposed patch: further wrapping of FileInputStream's native method

> On 16 Nov 2016, at 16:13, Claes Redestad wrote: > > Hi Paul, > > it appears you missed out on all the fun this time: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044628.html > Indeed! I missed that it moved to a separate email thread.

Re: Proposed patch: further wrapping of FileInputStream's native method

Hi Sunny, If you send me an exported patch with the reviewers in the comment etc i can push for you. Thanks, Paul. > On 9 Nov 2016, at 19:02, Chan, Sunny wrote: > > Hello all, > > I proposed a patch to provide wrapping for some native methods in > FileInputStream a while

Re: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX()

Hi Brent, I think it would be better to use Objects.requireNonNull (see other usages in Class etc). IMHO no need to specify a exception message, or test for that (which i think is too brittle). You will need to file a CCC for the change in behaviour of the Enumeration returning getResources.

Re: RFR: jsr166 jdk9 integration wave 12

Hi Martin, Glad you looked more closely at the perf aspects of ArrayDeque. I am struggling to determine what has changed since the last revision. Apart from ArrayDeque what files should i be looking at? Thanks, Paul. > On 16 Nov 2016, at 12:14, Martin Buchholz wrote: >

Re: 8072784: Better spliterator implementation for BitSet.stream()

> On 16 Nov 2016, at 07:21, Martin Buchholz wrote: > > should the spec say that the spliterator is late binding? > I logged this issue: https://bugs.openjdk.java.net/browse/JDK-8169808 We sold also consider

Re: 8072784: Better spliterator implementation for BitSet.stream()

> On 14 Nov 2016, at 17:56, Paul Sandoz <paul.san...@oracle.com> wrote: > > Hi, > > Please review this patch implementing a spliterator for BitSet: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072784-bitset-stream-spliterator/webrev/ > > The s

8072784: Better spliterator implementation for BitSet.stream()

Hi, Please review this patch implementing a spliterator for BitSet: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072784-bitset-stream-spliterator/webrev/ The spliterator is SIZED but not SUBSIZED, the bit set’s cardinality is used (same for the iterator) as the size of the root

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi Peter, Good point about if such support was added it would break the API and also (with Remi) about Ephemerons. You are correct in stating the constraints in more detail regarding classes in the same loader. However, i think that is going into more detail than I would prefer for what i

RFR 8132097: Stream.generate should use a covariant Supplier as parameter

Hi Please review this compatible fix to Stream.generate to accept a covariant Supplier. Paul. diff -r 3e3ca9800322 src/java.base/share/classes/java/util/stream/Stream.java --- a/src/java.base/share/classes/java/util/stream/Stream.java Tue Nov 08 15:37:20 2016 -0800 +++

RFR 8164934: Optional.map() javadoc code example is incorrect

Hi, Please review an update to the api note of Optional.map() which embarrassingly contained erroneous code (labouring under the misapprehension that exception transparency is supported!). I tweaked the example to refer to a Stream where a URI is transformed into a Path. Paul. diff -r

8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi, Please review the addition of an api note to ClassValue.computeValue. There is some history behind this issue. Another issue was logged [1] related to Groovy using ClassValue and there being a memory leak with classes/loaders not being GC’ed, but it turned out the problem was with Groovy's

Re: Proposal for adding O_DIRECT support into JDK 9

; Thank you very much for pointing this out. We did not know about it J > > We will modify the patch accordingly and will send it here for review. > > Thanks, > Lucy > > From: Paul Sandoz [mailto:paul.san...@oracle.com] > Sent: Thursday, November 03, 2016 12:46 PM > To

RFRs for 8166914, 8165782 and 8166735 related to multi-release JAR specification

Hi, Please review these specification clarifications for multi-release JARs. They are small and two are closely interrelated so though it would be best to aggregate them in one email. Thanks, Paul. 8166914 URLClassLoader spec needs to mention that it's MR-aware diff -r 52d732262bfa

Re: Proposal for adding O_DIRECT support into JDK 9

Hi Peter, Thanks for pointing this out, you beat me to it :-) Note that the alignment for a unit size corresponding to page size will only be stable for direct byte buffers, since for heap byte buffers the GC can move the underlying byte array and the alignment properties may change. Paul. >

Re: JDK 9 RFR of JDK-8151511: Test case in CollectionAndMapModifyStreamTest for LinkedHashMap overrides that for HashMap

Hi Amy Oops. Looks good. Paul. > On 1 Nov 2016, at 19:47, Amy Lu wrote: > > Please review the patch for fixing typo in steam tests: > > bug: https://bugs.openjdk.java.net/browse/JDK-8151511 > webrev: http://cr.openjdk.java.net/~amlu/8151511/webrev.00/ > > 1) In

Re: RFR 8167974 MethodHandles.iteratedLoop(...) fails with CCE in the case of iterating over array

> On 31 Oct 2016, at 16:19, Claes Redestad <claes.redes...@oracle.com> wrote: > > Hi, > > On 2016-10-31 22:47, Paul Sandoz wrote: >> Hi, >> >> And… 8167966 MethodHandles.iteratedLoop fails with IAE in the case of >> correct arguments. >>

8168841 The JavaDoc of java.util.stream.Collectors method collectingAndThen has incorrect code snippet

Hi, Please review the following JavDoc fix for j.u.stream.Collectors:: collectingAndThen. Thanks, Paul. diff -r 2e076c7e72d6 src/java.base/share/classes/java/util/stream/Collectors.java --- a/src/java.base/share/classes/java/util/stream/Collectors.java Mon Oct 31 14:51:23 2016 -0700 +++

RFR 8167974 MethodHandles.iteratedLoop(...) fails with CCE in the case of iterating over array

Hi, And… 8167966 MethodHandles.iteratedLoop fails with IAE in the case of correct arguments. The two issues are closely intertwined in terms of the fix. Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167974-mhs-iterated-loop-no-arrays/webrev/ This is cleaning up previous

Re: RFR 8163553 java.lang.LinkageError from test java/lang/ThreadGroup/Stop.java

Gentle reminder. Paul. > On 18 Oct 2016, at 11:41, Paul Sandoz <paul.san...@oracle.com> wrote: > > Hi, > > Please review: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8163553-vh-mh-link-errors-not-wrapped/webrev/ > > This is the issue that motivat

Re: Review Request: JDK-8168205: Should not default class path to CWD if -cp is not specified but -m is specified

> On 26 Oct 2016, at 22:59, Mandy Chung wrote: > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168205/webrev.00/index.html > > If -cp is not specified and -m is not specified, the builtin system > class loader will default the class path to the current

Re: RFR: 8168640: (fc) Avoiding AtomicBoolean in FileInput/-OutputStream improves startup

> On 26 Oct 2016, at 05:11, Claes Redestad wrote: > > Hi, > > does this commentary suffice? > > http://cr.openjdk.java.net/~redestad/8168640/webrev.02/ > +1 > To answer Paul's question about the exact startup gain: > > 20 named classes observable with

Re: Iterator.forEachRemaining and Iterator.remove

> On 25 Oct 2016, at 15:16, Martin Buchholz wrote: > > Actually, the ArrayList implementation updates fields only at the end of the > iteration, so if an action throws in the middle, the iterator is > semi-corrupted (in the sense that remove() will remove the "wrong"

Re: RFR 9: [testbug] 8168613 : CORBA ObjectStreamTest fails with address in use

> On 25 Oct 2016, at 14:28, Roger Riggs wrote: > > Hi Paul, > > Thanks for explanation and suggestions. > > I updated the webrev to use instance methods and fields and using > synchronized. > (And a bit of long-line cleanup.) > > webrev: >

Re: Iterator.forEachRemaining and Iterator.remove

Hi Martin, Hmm… The intent of ArrayList/Vector/LinkedList implementations is clear, leave the iterator in the same state as a last successful next call. I believe ArrayDeque’s iterator (in repo, unsure about your updates) has different behaviour e.g. ad.next(); ad.forEachRemaining(…);

Re: RFR 9: [testbug] 8168613 : CORBA ObjectStreamTest fails with address in use

> On 25 Oct 2016, at 13:50, Roger Riggs <roger.ri...@oracle.com> wrote: > > Hi, > > On 10/25/2016 4:31 PM, Paul Sandoz wrote: >> Hi Roger, >> >> Do you need to use a double-checked locking idiom in getEchoStub? > Probably not, I'm just pract

Re: RFR: 8168640: (fc) Avoiding AtomicBoolean in FileInput/-OutputStream improves startup

> On 25 Oct 2016, at 05:49, Claes Redestad wrote: > > > On 2016-10-25 13:09, Aleksey Shipilev wrote: >> On 10/25/2016 12:51 PM, Claes Redestad wrote: >>> Avoiding AtomicBoolean improves startup and footprint for a sample of >>> small applications: >>> >>> Webrev:

Re: RFR 9: [testbug] 8168613 : CORBA ObjectStreamTest fails with address in use

Hi Roger, Do you need to use a double-checked locking idiom in getEchoStub? I cannot recall the life-cycle of per test execution, but i suspect you might be able to turn the static field and method getEchoStub into a non-static field and just make the method synchronized, but you might ned to

Re: RFR: 8160954: (spec) Runtime.Version regex and $PRE/$OPT issues

> On 20 Oct 2016, at 20:34, Iris Clark wrote: > > Hi. > > Please review changes to address the following closely related bugs: > >8160954: (spec) Runtime.Version regex and $PRE/$OPT issues >https://bugs.openjdk.java.net/browse/JDK-8160954 > >8148822: (spec)

Re: RFR: jsr166 jdk9 integration wave 12

> On 19 Oct 2016, at 19:33, Martin Buchholz <marti...@google.com> wrote: > > > > On Wed, Oct 19, 2016 at 3:44 PM, Paul Sandoz <paul.san...@oracle.com > <mailto:paul.san...@oracle.com>> wrote: > >> On 18 Oct 2016, at 13:58, Martin Buchholz <mar

Re: RFR: jsr166 jdk9 integration wave 12

> On 18 Oct 2016, at 13:58, Martin Buchholz wrote: > > Latest webrev defers potential new methods: >/* TODO: public */ private void trimToSize() Sorry to push back, i know it’s a hassle, but i think such features should be retained in a separate proposed patch. Paul.

Re: RFR: jsr166 jdk9 integration wave 12

> On 18 Oct 2016, at 12:07, Martin Buchholz <marti...@google.com> wrote: > > > > On Tue, Oct 18, 2016 at 10:55 AM, Paul Sandoz <paul.san...@oracle.com> wrote: > > Testing-wise there is always gonna be some overlap. It would be nice to > consolidate, al

RFR 8163553 java.lang.LinkageError from test java/lang/ThreadGroup/Stop.java

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8163553-vh-mh-link-errors-not-wrapped/webrev/ This is the issue that motivated a change in the behaviour of indy wrapping Errors in BootstrapMethodError, JDK-8166974. I plan to push this issue with JDK-8166974 to hs, since

Re: RFR: jsr166 jdk9 integration wave 12

Hi, The j.u.c. changes look ok to me as do the misc changes. The ArrayDeque changes may also change the performance characteristics, a space/time trade-off e.g. in current version array bounds checks are strength reduced to a zero-based test of the array length. Unsure in practice if this

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

> On 17 Oct 2016, at 16:36, John Rose <john.r.r...@oracle.com> wrote: > > On Oct 17, 2016, at 3:38 PM, Paul Sandoz <paul.san...@oracle.com> wrote: >> >> >>> On 17 Oct 2016, at 15:01, Stuart Marks <stuart.ma...@oracle.com> wrote: >>>

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

> On 17 Oct 2016, at 15:33, David Holmes <david.hol...@oracle.com> wrote: > > Hi Paul, > > Looking at hotspot changes only ... > > On 15/10/2016 8:08 AM, Paul Sandoz wrote: >> Hi, >> >> Please review: >> >> >> http://cr.openjdk

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

> On 17 Oct 2016, at 15:01, Stuart Marks wrote: > > Hi Paul, > > I took a look at the jdk changes. They look good to me. > > One section of code gave me pause, which is the throw of ClassCastException > at 339 of CallSite.java, and the throw of the exception returned

Re: RFR: 8168073: Speed up URI creation during module bootstrap

> On 17 Oct 2016, at 14:18, Claes Redestad wrote: > > > > On 2016-10-17 21:35, Alan Bateman wrote: >> >> >> On 17/10/2016 19:45, Claes Redestad wrote: >>> >>> Most other SharedSecrets classes seems to be per-package, so not sure >>> if this case is special enough

Re: RFR: 8168073: Speed up URI creation during module bootstrap

> On 17 Oct 2016, at 10:53, Claes Redestad <claes.redes...@oracle.com> wrote: > > Hi Paul, > > On 2016-10-17 19:39, Paul Sandoz wrote: >> Hi Claes, >> >> This looks good. > > Thanks! > >> >> Did you consider adding asserts to the p

Re: RFR: 8168073: Speed up URI creation during module bootstrap

Hi Claes, This looks good. Did you consider adding asserts to the package private constructor? Paul. > On 17 Oct 2016, at 04:17, Claes Redestad wrote: > > Hi, > > one partial cause for startup regressions due to jigsaw is related to creating > URIs for the

RFR 8166974: invokedynamic implementation should not wrap Errors

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-errors-not-wrapped-jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-errors-not-wrapped-hotspot/webrev/ The JMV spec was recently updated to state the following in the Linkage Exceptions

Re: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

Hi Peter, Nice work here. PublicMethods — I would be inclined to change PublicMethods to encapsulate an instance of LinkedHashMap, since it’s only the consolidate/toArray methods that really matter, and no need for the key/value types to be exposed, then no need to declare serialVersionUID,

RFR 8167524 Rogue character in Stream javadoc

Hi, I accidentally fat fingered the JavaDoc of Stream which got consumed into an unrelated patch that i pushed [1]. Thanks go to Martin for noticing this. Paul. [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e93b7ea55975 diff -r b909daf8fdbc

Re: using jshell in executable UNIX scripts

Hi Peter, I was wondering when this would be discussed :-) This potentially starts moving down the slippery slope of what it means to be Java syntax and what it means to execute. Larger topics to be thought about. Here is some interesting discussion about Go:

Re: RFR: 8166460: jdk/internal/util/jar/TestVersionedStream gets Assertion error

> On 10 Oct 2016, at 14:50, Steve Drach wrote: > > As a consequence of some conversations about this test, I’ve removed the part > that specifically depended on the order of the entries and now just verify > that the order of the versioned entries is the same relative

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

> On 7 Oct 2016, at 12:22, Stuart Marks <stuart.ma...@oracle.com> wrote: > > > > On 10/7/16 11:23 AM, Paul Sandoz wrote: >>> flatMap(Function> mapper) >> >> Optional is final so why do you need to express “? extends Optional” ? > > The

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

> On 7 Oct 2016, at 10:20, Stuart Marks wrote: > > Hi all, > > Please review this small API adjustment to Optional.or and flatMap to add > wildcards. This provides a bit more flexibility to callers about the types of > functions they can provide to these methods. >

Re: RFR: 8163798: Create a JarFile versionedStream method

> On 12 Sep 2016, at 17:14, Steve Drach wrote: > > I guess I’m going to keep doing this until I get it right ;-) Here’s another > webrev that doesn’t use an exception for a common case, and addresses most of > Mandy concerns. > >

Re: RFR: 8163798: Create a JarFile versionedStream method

> On 12 Sep 2016, at 12:36, Steve Drach wrote: > >>> I made a simple change, the new webrev is >>> http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ >>> >>> >> >> I don’t like the state interplay between

Re: RFR: 8163798: Create a JarFile versionedStream method

> On 11 Sep 2016, at 13:12, Steve Drach wrote: > > I made a simple change, the new webrev is > http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ > > I don’t like the state interplay between allowedVersions

Re: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded

> On 12 Sep 2016, at 10:15, Lance Andersen wrote: >> >> Suggestion: >> >> 70 try (BufferedReader reader = new BufferedReader(new >> CharArrayReader(cw.toCharArray( { >> 71 boolean result >> 72 = reader.lines().anyMatch(

Re: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded

> On 12 Sep 2016, at 09:29, Lance Andersen wrote: > > Happy Monday, > > This RFR is to add a test to validate that the DriverManager.println output > is accessible when DriverManager is first loaded. > > The webrev can be found at: >

Re: RFR: jsr166 jdk9 integration wave 10

> On 12 Sep 2016, at 09:57, Martin Buchholz wrote: > > > > On Mon, Sep 12, 2016 at 3:22 AM, Aleksey Shipilev > wrote: > > Minor things: > > CountedCompleter.java: > > 176 * setPendingCount(1); // not off by one !

Re: RFR: 8165723: JarFile::isMultiRelease() method returns false when it should return true

> On 12 Sep 2016, at 08:10, Claes Redestad wrote: > > On 2016-09-12 16:24, Alan Bateman wrote: >> This looks okay. > > Thanks for the review! > >> For the MultiReleaseJarAPI test then you probably should use >> jdk.testlibrary.RandomFactory so that the seed is

Re: RFR: jsr166 jdk9 integration wave 10

> On 10 Sep 2016, at 10:21, Martin Buchholz wrote: > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > +1 CountedCompleter — 176 * setPendingCount(1); // not off by one ! CountedCompleterTest — 1910

RFR 8165731 Reference to removed method in VarHandle JavaDoc

Hi, Please review this simple fix to remove a straggling reference to a previously removed method. Thanks, Paul. diff -r 10d8bdeabfa5 src/java.base/share/classes/java/lang/invoke/VarHandle.java --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java Thu Sep 08 09:59:54 2016

Re: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy

> On 8 Sep 2016, at 12:37, Claes Redestad <claes.redes...@oracle.com> wrote: > >> >>> On 09/08/2016 09:21 PM, Paul Sandoz wrote: >>> Did you consider replacing the if block with an assert? presumably if >>> it is non-zero it is an internal error? &

<    5   6   7   8   9   10   11   12   13   14   >