Re: RFR(s): 8072726: add adapter to convert Enumeration to Iterator

Hi Stuart, I would like to suggest some tweaks to the specification to get across this method is transitioning control of traversal from enumeration to iterator. How about: Returns an iterator that traverses the remaining elements covered by this enumeration. Traversal is undefined if

Re: PriorityQueue

On May 15, 2015, at 6:15 PM, Louis Wasserman lowas...@google.com wrote: http://lcm.csa.iisc.ernet.in/dsa/node139.html suggests an algorithm for heapifying an unsorted array in O(n), corroborated elsewhere at http://courses.csail.mit.edu/6.006/fall10/handouts/recitation10-8.pdf . Any

Re: JEP 238: Multi-Version JAR Files

On Apr 15, 2015, at 2:03 PM, Remi Forax fo...@univ-mlv.fr wrote: Of course we cannot feasibly backport every new API in N to N-1, N-2 etc. In selective cases that might be possible, but for the core of the JDK it's like pulling on a string of public dependencies, internal dependencies and

Re: JEP 238: Multi-Version JAR Files

Hi Remi, On Apr 15, 2015, at 1:58 PM, Remi Forax fo...@univ-mlv.fr wrote: Hi Paul, I think you're seriously underestimate the cost of this JEP. That is why we are asking for feedback :-) I want to understand the impact and get some concrete reasons why certain aspects are difficult.

Re: Places we should use the new ByteBuffer intrinsics

On Apr 16, 2015, at 12:56 PM, Andrew Haley a...@redhat.com wrote: We discussed where we should be using the new Unsafe unaligned intrinsics. I found these: They look like good candidates. I did a quick search in the JDK src code (usages of getByte/Short/Int/Long) and could not find any

Re: JEP 238: Multi-Version JAR Files

Hi Markus, Sorry for the late reply i have been away for the last 3 weeks. You and your colleagues might be interested in discussion of JEP 238 on org.apache.maven.dev: http://markmail.org/thread/v5ywgdpuprntrvfu#query:+page:1+mid:v5ywgdpuprntrvfu+state:results especially when it gets to

Re: RFR(s): 8072726: add adapter to convert Enumeration to Iterator

On May 19, 2015, at 6:19 PM, Chris Hegarty chris.hega...@oracle.com wrote: On 19 May 2015, at 17:13, Daniel Fuchs daniel.fu...@oracle.com wrote: On 19/05/15 12:07, Paul Sandoz wrote: Should anything be said also about default remove() method inherited from Iterator interface? Are custom

Re: RFR(s): 8072726: add adapter to convert Enumeration to Iterator

On May 19, 2015, at 12:41 PM, Tomasz Kowalczewski tomasz.kowalczew...@gmail.com wrote: Is there a plan to override the default method asIterator() in specific implementations of Enumeration to avoid creating new object? JarFile::entries already returns JarEntryIterator which is both. I

Re: RFR 8080623 CPU overhead in FJ due to spinning in awaitWork

On May 20, 2015, at 11:46 AM, David Holmes david.hol...@oracle.com wrote: On 20/05/2015 7:28 PM, Paul Sandoz wrote: On May 20, 2015, at 9:07 AM, David Holmes david.hol...@oracle.com wrote: On 20/05/2015 3:55 AM, Paul Sandoz wrote: Hi, https://bugs.openjdk.java.net/browse/JDK-8080623

Re: RFR(s): 8072726: add adapter to convert Enumeration to Iterator

are potential candidates to consider for additional stream returning methods. A little more care is probably required for ClassLoader. Paul. On Tue, May 19, 2015 at 2:26 PM, Paul Sandoz paul.san...@oracle.com wrote: On May 19, 2015, at 12:41 PM, Tomasz Kowalczewski tomasz.kowalczew

Re: RFR (XXS) 8080535: (ch) Expected size of Character.UnicodeBlock.map is not optimal

On May 19, 2015, at 9:40 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Hi everyone! What about this variant: http://cr.openjdk.java.net/~igerasim/8080535/02/webrev/ 45 int mapSize = map.size(); Not used. 49 int INITIAL_CAPACITY = 680; //(int)(510 / 0.75f +

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

On May 20, 2015, at 9:14 AM, Roland Westrelin roland.westre...@oracle.com wrote: What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.04 Still looks good to me. And to me. Injected fields seem a little magical but safer. Paul.

Re: RFR(s): 8072726: add adapter to convert Enumeration to Iterator

On May 19, 2015, at 6:13 PM, Daniel Fuchs daniel.fu...@oracle.com wrote: On 19/05/15 12:07, Paul Sandoz wrote: Should anything be said also about default remove() method inherited from Iterator interface? Are custom asIterator() implementations allowed to return an Iterator that implements

Re: RFR (XXS) 8080535: (ch) Expected size of Character.UnicodeBlock.map is not optimal

On May 20, 2015, at 7:32 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Just had an idea... I believe static intializers are executed in textual order. So you could have a static code block after all static UnicodeBlock instances have been defined that asserts the size == 510 (or is =

Re: RFR 8072773 (fs) Files.lines needs a better splitting implementation for stream source

On Jun 3, 2015, at 9:19 PM, Xueming Shen xueming.s...@oracle.com wrote: On 06/03/2015 08:53 AM, Paul Sandoz wrote: Hi, Please review an optimization for Files.lines for certain charsets: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072773-File-lines/webrev/ If a charset is say US

Re: RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

On Jun 3, 2015, at 9:27 PM, Alan Bateman alan.bate...@oracle.com wrote: On 03/06/2015 17:47, Paul Sandoz wrote: : Ok, i removed it but added an assert for the array being non-null and containing at least one element. I also refined the documentation of the stream returning method in light

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

On Jun 1, 2015, at 8:53 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: On 01.06.2015 11:33, Paul Sandoz wrote: On May 31, 2015, at 6:03 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Which is right here: http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/ Much better

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

On Jun 2, 2015, at 10:56 AM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: You could simplify the data provider sourceTargetReplacementWithNull, there is no point testing with a null source. String.replace accepts two arguments, each can be either null or non-null. Thats 2 bits of state,

Re: RFR 8072773 (fs) Files.lines needs a better splitting implementation for stream source

On Jun 5, 2015, at 12:57 AM, Stefan Zobel splitera...@gmail.com wrote: With respect to the 'stream test library not closing streams' bug: would you mind to create a separate bugtracker issue for that, or do you think it's too special to carry that weight? Not too special just more more

Re: Patch to improve primitives Array.sort()

On May 26, 2015, at 11:54 AM, Paul Sandoz paul.san...@oracle.com wrote: Here is an updated webrev: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080945-nearly-sorted-primitives/webrev/ Updated with some contributed JMH benchmarks located in the test area. To be moved when

Re: RFR 8071597 Add Stream dropWhile and takeWhile operations

On Jun 6, 2015, at 1:20 AM, Stuart Marks stuart.ma...@oracle.com wrote: On 6/3/15 9:21 AM, Paul Sandoz wrote: I had prepared an alternative rendition stashed away just in case this came up :-) I still want to retain a punchy short first paragraph. What do you think about the following

Re: RFR 8071597 Add Stream dropWhile and takeWhile operations

HI Stefan, On Jun 7, 2015, at 10:07 PM, Stefan Zobel splitera...@gmail.com wrote: I'm still trying to wrap my head around the test logic for the (par !ord) (op == WhileOp.Drop) case in the whileResultAsserter() method in WhileOpTest. Wouldn't it be possible that, for an unordered

Re: RFR 8072773 (fs) Files.lines needs a better splitting implementation for stream source

On Jun 3, 2015, at 6:18 PM, Alan Bateman alan.bate...@oracle.com wrote: As this code path is only for the default provider case then there's a good chance that it will be a FileChannelImpl, in which case you can call its unmap method (directly or via a shared secret). It is possible to

RFR 8072773 (fs) Files.lines needs a better splitting implementation for stream source

Hi, Please review an optimization for Files.lines for certain charsets: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072773-File-lines/webrev/ If a charset is say US-ASCII or UTF-8 it is possible to implement an efficient splitting Spliterator that scans bytes from a mid-point to search for

Re: RFR 8071597 Add Stream dropWhile and takeWhile operations

On Jun 2, 2015, at 8:58 PM, Chris Hegarty chris.hega...@oracle.com wrote: Very nice. I just looked over the spec, for now. * @param predicate a a href=package-summary.html#NonInterferencenon-interfering/a, * a href=package-summary.html#Statelessnessstateless/a

Re: RFR 8071597 Add Stream dropWhile and takeWhile operations

, Stuart Marks stuart.ma...@oracle.com wrote: Hi Paul, Some comments on the spec. On 6/2/15 6:13 AM, Paul Sandoz wrote: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071597-take-drop-while/webrev/ I opted to weight the documentation of the operations towards ordered streams in the first

Re: RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

, at 9:37 AM, Paul Sandoz paul.san...@oracle.com wrote: Hi, Please review a follow up to Stuart's Enumeration.asIterator patch that adds some Stream return methods to classes where there is only Enumeration returning methods to support traversal: http://cr.openjdk.java.net/~psandoz/jdk9

Re: RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

On Jun 3, 2015, at 12:46 PM, Alan Bateman alan.bate...@oracle.com wrote: On 02/06/2015 14:37, Paul Sandoz wrote: : There is one small area of uncertainty with NetworkInterface. Can the following method ever return null? 342 public static EnumerationNetworkInterface

Re: RFR [9]: Better failure output for test/java/util/Arrays/ParallelPrefix.java

On Jun 4, 2015, at 4:09 PM, Chris Hegarty chris.hega...@oracle.com wrote: On 4 Jun 2015, at 13:37, Paul Sandoz paul.san...@oracle.com wrote: ... If you wanna go the extra mile it's useful for the data provider to supply a string description argument summarizing the test data. Added. I

Re: RFR 8071597 Add Stream dropWhile and takeWhile operations

On Jun 4, 2015, at 9:04 AM, Remi Forax fo...@univ-mlv.fr wrote: Thinking a little more about dropWhile(), it can be written using filter() more or less like this: default StreamT dropWhile(Predicate? super T predicate) { return filter(new Predicate() { private boolean

Re: RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

On Jun 3, 2015, at 11:00 PM, Chris Hegarty chris.hega...@oracle.com wrote: Looks good Paul, just a few minor comments. ( looked at all, but *security* and *sql* ) NetworkInterface s/Enumertion/Stream L127 * will be returned in the Enumeration. However, if the caller has the

Re: RFR 8071597 Add Stream dropWhile and takeWhile operations

On Jun 4, 2015, at 10:09 AM, Remi Forax fo...@univ-mlv.fr wrote: On 06/04/2015 09:37 AM, Paul Sandoz wrote: On Jun 4, 2015, at 9:04 AM, Remi Forax fo...@univ-mlv.fr wrote: Thinking a little more about dropWhile(), it can be written using filter() more or less like this: default StreamT

Re: RFR 8071597 Add Stream dropWhile and takeWhile operations

On Jun 4, 2015, at 10:27 AM, Peter Levart peter.lev...@gmail.com wrote: On 06/03/2015 08:53 PM, Peter Levart wrote: Hi Paul, This is a usefull addition to Stream API for sequential ordered streams. But does it have any utility in unordered streams at all? Wouldn't it be better to just

Re: RFR 9: 8129344 : (process) ProcessHandle instances should define equals and be value-based

Hi Roger, It looks ok, just some minor stuff. So basically it is a necessary but not sufficient condition that two equal processes have the same pid? If so Perhaps it might be possible to weave that phrase into the docs? Maybe some wording on getPid is also required? 355 * Returns

Re: [8u60] RFA 8129120 Terminal operation properties should not be back-propagated to upstream operations

this into jdk8u-dev before Friday it should make the pre-RDP2 integration slot. After this week, an 8u60-dev stabilization forest will be created for ramp down purposes. Regards, Sean. On 23/06/2015 09:32, Paul Sandoz wrote: Hi, I would like to backport: https://bugs.openjdk.java.net/browse

Re: JDK 9 RFR of JDK-8129759: Mark two tests from DistinctOpTest.java and SliceOpTest.java as serialization hostile

On Jun 24, 2015, at 10:05 AM, Amy Lu amy...@oracle.com wrote: Testcase testStable was newly introduced in JDK-8129120 in DistinctOpTest, this test should be marked as serialization-hostile. (such tests will ignored by by lambda serialization testing framework).

RFR 8129120 Terminal operation properties should not be back-propagated to upstream operations

Hi, http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8129120-flag-back-propagation/webrev/ I am a little red in the face (of the embarrassed kind) about this fix. We found an issue reported on stack overflow whereby a stream can report incorrect results. I may be wrong but this might be the first

RFR 8085978 LinkedTransferQueueT.spliterator can report LTQ.Node object, not T

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8085978-linked-transfer-queue-traverse/webrev/ The LinkedTransferQueue's spliterator can erroneously report internal nodes when traversing. The fix is cherry picked from the 166 repo (other mostly refactoring-based changes

Re: Spliterators of iterators

On Jun 17, 2015, at 8:10 AM, Martin Buchholz marti...@google.com wrote: On Tue, Jun 16, 2015 at 1:43 AM, Paul Sandoz paul.san...@oracle.com wrote: It's a subtle area. Certain Spliterator characteristics refer to the (element) source namely, NONULL, IMMUTABLE and CONCURRENT. Yes, it's

Re: Spliterators of iterators

On Jun 15, 2015, at 6:34 PM, Martin Buchholz marti...@google.com wrote: Staring at LinkedTransferQueue.java, I see: return Spliterators.spliterator (a, 0, i, (Spliterator.ORDERED | Spliterator.NONNULL |

Re: Spliterators of iterators

On Jun 15, 2015, at 7:31 PM, Martin Buchholz marti...@google.com wrote: On Mon, Jun 15, 2015 at 10:16 AM, Paul Sandoz paul.san...@oracle.com wrote: On Jun 15, 2015, at 6:34 PM, Martin Buchholz marti...@google.com wrote: Staring at LinkedTransferQueue.java, I see: return

Re: RFR 8085978 LinkedTransferQueueT.spliterator can report LTQ.Node object, not T

Iterator.remove. Paul. On Mon, Jun 15, 2015 at 2:47 AM, Paul Sandoz paul.san...@oracle.com wrote: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8085978-linked-transfer-queue-traverse/webrev/ The LinkedTransferQueue's spliterator can erroneously report internal nodes when

Re: RFR [9]: Better failure output for test/java/util/Arrays/ParallelPrefix.java

On Jun 4, 2015, at 12:54 PM, Chris Hegarty chris.hega...@oracle.com wrote: This is a review request to add better test failure output to jdk/test/java/util/Arrays/ParallelPrefix.java Looks ok. Printing the content should give some clues, but i expect it's only with some focused repeated

Re: RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

On Jun 4, 2015, at 10:06 AM, Alan Bateman alan.bate...@oracle.com wrote: On 03/06/2015 21:17, Paul Sandoz wrote: : For the tests then @library ../../util/streambootlib doesn't seem right. Is it time to move some infrastructure to make it easier to get at in other parts of the suite

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

On May 31, 2015, at 6:03 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Which is right here: http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/ Much better. For the test can you use RandomFactory recently added to the test library? Paul.

Re: RFR 8071597 Add Stream dropWhile and takeWhile operations

On Jun 2, 2015, at 3:50 PM, Stefan Zobel splitera...@gmail.com wrote: Hi Paul, Looks good. I was wondering why the truncate method in Node.OfInt / OfLong / OfDouble did not receive the same +if (to == count()) { +spliterator.forEachRemaining(nodeBuilder); +

RFR 8071597 Add Stream dropWhile and takeWhile operations

Hi, Please review this webrev that adds take/dropWhile operations to streams: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071597-take-drop-while/webrev/ I opted to weight the documentation of the operations towards ordered streams in the first paragraph. That is what makes most sense in

RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

Hi, Please review a follow up to Stuart's Enumeration.asIterator patch that adds some Stream return methods to classes where there is only Enumeration returning methods to support traversal: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8081678-enumeration-and-stream/webrev/ I took the

Re: RFR - 8129956: jaxp: CodeSource.getLocation() might return null

On Jun 29, 2015, at 8:06 PM, huizhe wang huizhe.w...@oracle.com wrote: Maybe it's better to live with PrivilegedActionClassLoader and PrivilegedActionString instead? IMO we should not have to wait for IDEs to catch up to leverage new language features. I'm using NetBeans 8.0.2, it looks

Re: RFR: 8050091: LinkedList has incorrect implementation comment

On Jun 26, 2015, at 10:04 PM, Martin Buchholz marti...@google.com wrote: Hi Ivan, I'd like you to do a code review. https://bugs.openjdk.java.net/browse/JDK-8050091 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/LinkedList-invariant/ I would prefer if there was some text with the

Re: RFR - 8129956: jaxp: CodeSource.getLocation() might return null

On Jun 30, 2015, at 10:40 AM, Daniel Fuchs daniel.fu...@oracle.com wrote: On 29/06/15 20:06, huizhe wang wrote: Maybe it's better to live with PrivilegedActionClassLoader and PrivilegedActionString instead? I'm using NetBeans 8.0.2, it looks like it doesn't support source level beyond JDK

Re: Patch to improve primitives Array.sort()

On May 22, 2015, at 1:52 AM, Rezaei, Mohammad A. mohammad.rez...@gs.com wrote: Thanks Paul. Your proposed changes make sense to us and they have no discernable impact on the performance. Great, thanks. I am happy to update the current webrev (and also create an associated issue). Sorry

Re: Patch to improve primitives Array.sort()

On May 22, 2015, at 9:56 PM, O'Leary, Kristen Kristen.O'le...@gs.com wrote: Hi Paul, We've created an additional test based on your suggestion: an array of size 10,000,000, 32 pair flips, a run of zeroes in the middle, and 32 pair flips at the end. Here are the results for int: Benchmark

Re: Patch to improve primitives Array.sort()

On May 26, 2015, at 4:19 AM, Chan, Sunny sunny.c...@gs.com wrote: I have looked at the mailing list archive and so far I haven’t identify any progress on the “space for benchmark” – so we could include the performance test as a part of the patch but it will required JMH access somehow. I

Re: Patch to improve primitives Array.sort()

22, 2015, at 4:23 PM, Paul Sandoz paul.san...@oracle.com wrote: On May 22, 2015, at 3:55 PM, Rezaei, Mohammad A. mohammad.rez...@gs.com wrote: We have a set of JMH tests. Great. I created a bug for this issue: https://bugs.openjdk.java.net/browse/JDK-8080945 We'll work

Re: Patch to improve primitives Array.sort()

On May 22, 2015, at 3:55 PM, Rezaei, Mohammad A. mohammad.rez...@gs.com wrote: We have a set of JMH tests. Great. I created a bug for this issue: https://bugs.openjdk.java.net/browse/JDK-8080945 We'll work with Sunny to make those part of the webrev (where do they go?) and the specific

Re: Patch to improve primitives Array.sort()

/~psandoz/tmp/gs/sort/webrev.2/ Updates: The testcase has been updated to clone the array The redundant constant MAX_RUN_LENGTH has been removed. From: Paul Sandoz [mailto:paul.san...@oracle.com] Sent: 16 May 2015 00:13 To: Chan, Sunny [Tech] Cc: O'Leary, Kristen [Tech]; 'Alan Bateman

RFR 8080623 CPU overhead in FJ due to spinning in awaitWork

Hi, https://bugs.openjdk.java.net/browse/JDK-8080623 diff -r ea3ca5cfc3c6 src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java --- a/src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java Tue May 19 20:04:29 2015 +0300 +++

Re: RFR - 8129956: jaxp: CodeSource.getLocation() might return null

On Jun 29, 2015, at 10:35 AM, Daniel Fuchs daniel.fu...@oracle.com wrote: On 29/06/15 10:06, Paul Sandoz wrote: That's odd i would of expected it to work. Here's Joe's patch to changes in the JDK: http://cr.openjdk.java.net/~darcy/8078467.0/jdk.patch (Search for new PrivilegedAction

Re: RFR - 8129956: jaxp: CodeSource.getLocation() might return null

On Jun 27, 2015, at 2:13 PM, Daniel Fuchs daniel.fu...@oracle.com wrote: On 6/27/15 12:57 PM, Peter Levart wrote: Hi Daniel, Just a question. Would diamonds on anonymous instance creation expressions work in these cases? I tried it - it didn't work. You would have to use a local

Re: RFR: 6260652: (coll) Arrays.asList(x).toArray().getClass() should be Object[].class

On Jun 26, 2015, at 11:54 PM, Martin Buchholz marti...@google.com wrote: 10 years later ... still asking for approval to commit. https://bugs.openjdk.java.net/browse/JDK-6260652 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Arrays.asList.toArray/ +1. This is probably why there is

Re: RFR: JDK-8062849 -- Optimize EnumMap.equals

On 28 Jul 2015, at 18:14, Steve Drach steve.dr...@oracle.com wrote: Please review the following simple fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8062849 https://bugs.openjdk.java.net/browse/JDK-8062849. +1 Paul. - # HG changeset patch #

Re: RFR: JDK-8066013 (prefs) Unused variable in src/java.prefs/share/classes/java/util/prefs/MacOSXPreferences.java

On 23 Jul 2015, at 11:26, Chris Hegarty chris.hega...@oracle.com wrote: Your change [1] looks fine to me Steve. +1 Paul.

RFR Collector.finisher refers to IDENTITY_TRANSFORM rather than INDENTITY_FINISH

Hi, Please review this simple fix to the JavaDoc on j.u.stream.Collector.finisher. I am also opportunistically fixing some internal comments identified by Tagir. Paul. diff -r 4e3135fac8cc src/java.base/share/classes/java/util/stream/Collector.java ---

Re: Spliterator documentation on Priority(Blocking)Queue

On 4 Aug 2015, at 11:18, Tagir Valeev amae...@gmail.com wrote: Hello, Paul. I think I have no access rights to do it. You can do it here: http://bugreport.java.com/ (Write access to the Java Bug System requires OpenJDK author status.) Should I have to sign an OCA for this? No. I

Re: RFR(s): 8132800: clarify stream package documentation regarding sequential vs parallel modes

On 31 Jul 2015, at 23:19, Stuart Marks stuart.ma...@oracle.com wrote: Hi all, The sequential() and parallel() methods on a stream set the execution mode for the entire pipeline. Unfortunately this isn't particularly clear from the documentation. This has been a recurring question. Please

Re: RFR(s): 8132800: clarify stream package documentation regarding sequential vs parallel modes

On 4 Aug 2015, at 01:09, Stuart Marks stuart.ma...@oracle.com wrote: Hi Tagir, Interesting issues. Regarding Stream.concat, it may be that, today, changes to the sequential/parallel execution mode aren't propagated to the streams being concatenated. The execution mode is propagated

Re: Spliterator documentation on Priority(Blocking)Queue

On 4 Aug 2015, at 13:42, Tagir Valeev amae...@gmail.com wrote: Hello! You can do it here: http://bugreport.java.com/ (Write access to the Java Bug System requires OpenJDK author status.) Thank you for the clarification. I filed the issue with Review ID: JI-9023040. Thanks, and

Re: RFR(s): 8132800: clarify stream package documentation regarding sequential vs parallel modes

On 4 Aug 2015, at 09:20, Paul Sandoz paul.san...@oracle.com wrote: On 4 Aug 2015, at 01:09, Stuart Marks stuart.ma...@oracle.com wrote: Hi Tagir, Interesting issues. Regarding Stream.concat, it may be that, today, changes to the sequential/parallel execution mode aren't propagated

Re: Spliterator documentation on Priority(Blocking)Queue

Hi Tagir, Can you log an issue? Thanks, Paul. On 4 Aug 2015, at 06:47, Tagir Valeev amae...@gmail.com wrote: Hello! The PriorityQueue class iterator() returns elements in no particular order. This is explicitly stated in JavaDoc for iterator() method [1] as well as in class description

Re: RFR: JDK-8114832 it.next on ArrayList throws wrong type of Exception after remove(-1)

On 31 Jul 2015, at 04:47, Stuart Marks stuart.ma...@oracle.com wrote: On 7/28/15 5:50 AM, Paul Sandoz wrote: I agree that if we make a policy decision here, we can change it and the compatibility impact is minimal. Since there already exists an implicit policy governed by like 99.9

Re: RFR 8130828: Fix some typos and omissions in the the j.u.stream JavaDoc

script behave differently. Paul. Stefan, Tagir, thanks for spotting these issues. s'marks On 7/30/15 9:32 AM, Paul Sandoz wrote: Hi Stefan, Tagir, Updated: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130828-stream-doc-typos/webrev/ Paul. On 30 Jul 2015, at 18:08, Stefan Zobel

Re: RFR(s): 8132206: move ScanTest.java into OpenJDK

On 29 Jul 2015, at 03:45, Stuart Marks stuart.ma...@oracle.com wrote: Hi all, Please review this small change to add a test for java.util.Scanner into OpenJDK. This test was inadvertently omitted from OpenJDK when the regression tests were migrated into the open. Bug:

Re: RFR: JDK-8114832 it.next on ArrayList throws wrong type of Exception after remove(-1)

On 27 Jul 2015, at 20:53, Martin Buchholz marti...@google.com wrote: On Mon, Jul 27, 2015 at 1:19 AM, Paul Sandoz paul.san...@oracle.com wrote: My guiding principle here was that argument validation should not result in side-effects. Thus the state of a collection should remain unchanged

Re: Custom spliterator for Collections.nCopies(n, obj).stream()

Hi Tagir, I would agree with you out about changing to use unordered() except that it is a List that is returned, whose Spliterator is specified to report ORDERED. I don’t particular want to add a special spliterator for this case to avoid some profile pollution. Will it not just push the

Re: References to non-existing methods in java.util.stream comments

On 28 Jul 2015, at 10:48, Tagir F. Valeev amae...@gmail.com wrote: Hello! Although it's not the part of public API, there are references to non-existing methods in SliceOps.java and Streams.java:

Re: Custom spliterator for Collections.nCopies(n, obj).stream()

On 30 Jul 2015, at 08:08, Tagir F. Valeev amae...@gmail.com wrote: Hello! PS I don’t particular want to add a special spliterator for this PS case to avoid some profile pollution. Will it not just push the PS pollution further down the road to Spliterator.forEachRemaining? or to within

RFR 8130828: Fix some typos and omissions in the the j.u.stream JavaDoc

Hi Stefan, Tagir, Updated: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130828-stream-doc-typos/webrev/ Paul. On 30 Jul 2015, at 18:08, Stefan Zobel splitera...@gmail.com wrote: Hi Paul, perhaps you could take the opportunity and also add the missing @since 1.9 tags to all the new

Re: JDK 9 RFR of JDK-8132854: Adjust tier 1 and 2 definitions for nio-related intrinsics

+1 Paul. On 3 Aug 2015, at 05:19, joe darcy joe.da...@oracle.com wrote: Hello, With the fix for JDK-8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics the sources for the libraries clearly indicate which methods might

Re: RFR: JDK-8114832 it.next on ArrayList throws wrong type of Exception after remove(-1)

On 24 Jul 2015, at 20:30, Martin Buchholz marti...@google.com wrote: Hi Steve, pleased to meet you! (are you a new maintainer of java.util collections?) I suggested that Steve look at some “simple” issues to build up credits for a committer role, so i threw this and some others over the

Re: Stream.generate

Hi Remi, Can you log an issue? Thanks, Paul. On 20 Jul 2015, at 19:08, Remi Forax fo...@univ-mlv.fr wrote: Hi all, hi Paul, I've found that the signature of Stream.generate doesn't to use a wildcard hence some program are rejected even if there are valid, by example: public static void

Re: Stream.generate

On 20 Jul 2015, at 19:08, Remi Forax fo...@univ-mlv.fr wrote: Hi all, hi Paul, I've found that the signature of Stream.generate doesn't to use a wildcard hence some program are rejected even if there are valid, by example: public static void main(String[] args) { SupplierString

Re: RFR [S] 8131034: Cleanup in j.u.regex.Pattern.quote()

On Jul 12, 2015, at 6:32 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Hello! There's a minor issue in the current implementation of Pattern.quote() with possible numeric overflow when calculating initial capacity of StringBuilder. With the fix, some slight optimizations were done

Re: Speed optimization of Spliterators.spliteratorUnknownSize for parallel case

Hi Tagir, Thanks for looking at this. Judging by the results i am guessing your measurements were performed on a 4-core system. My initial inclination for these scenarios is it is likely better for the developer to split the execution in two parts. The first part, low N and low Q, is to

RFR 8131052 Documentation of AbstractSpliterator refers to forEach rather than forEachRemaining

Hi Stefan, thanks. See below for a patch to the documentation of all abstract spliterators. Paul. diff -r a3175de2e354 src/java.base/share/classes/java/util/Spliterators.java --- a/src/java.base/share/classes/java/util/Spliterators.java Tue Jun 09 07:10:03 2015 +0100 +++

Re: RFR 8131052 Documentation of AbstractSpliterator refers to forEach rather than forEachRemaining

On Jul 16, 2015, at 12:07 PM, Daniel Fuchs daniel.fu...@oracle.com wrote: On 16/07/15 12:00, Daniel Fuchs wrote: On 13/07/15 11:19, Paul Sandoz wrote: Hi Stefan, thanks. See below for a patch to the documentation of all abstract spliterators. Looks good to me Paul. Sorry - re

Re: RFR(S): 8062543: Replace uses of MethodHandleImpl.castReference with Class.cast

On Jul 15, 2015, at 10:23 AM, Michael Haupt michael.ha...@oracle.com wrote: Dear all, please review and sponsor this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8062543 Webrev: http://cr.openjdk.java.net/~mhaupt/8062543/webrev.00/ The change removes the no longer needed

Re: Speed optimization of Spliterators.spliteratorUnknownSize for parallel case

Hi Tagir, On Jul 14, 2015, at 4:43 AM, Tagir F. Valeev amae...@gmail.com wrote: Hello! Thank you for the detailed answer. PS Thanks for looking at this. Judging by the results i am guessing PS your measurements were performed on a 4-core system. Yes, quad-core, I mentioned it before.

Re: Speed optimization of Spliterators.spliteratorUnknownSize for parallel case

On Jul 15, 2015, at 2:20 PM, Paul Sandoz paul.san...@oracle.com wrote: By the way currently it's possible to create an IteratorSpliterator with estimated size: Spliterators.spliterator(iterator, estimatedSize, Spliterator.CONCURRENT); Of course it's a misuse of CONCURRENT flag, but it's

Re: 8139891: Prepare Unsafe for true encapsulation

Hi Chris, This looks like a good first step. I am sure hotspot devs will have more concrete review comments, but i like the way the method aliasing (copying the same technique StrictMath -> Math) avoids any changes to the intrinsics, thus the changes are much more localized. It may be worth

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

> On 9 Nov 2015, at 12:20, Alan Bateman wrote: > > > > On 05/11/2015 21:56, Roger Riggs wrote: >> Please review the new ProcessBuilder.startPipeline API, implementation, and >> tests. >> >> : >> >> javadoc of ProcessBuilder: only startPipeline is new: >>

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

> On 9 Nov 2015, at 14:36, Claes Redestad wrote: > > Vladimir, > > thanks for asserting this. Indeed! > The j.l.invoke code is still rather foreign to me, so I took extreme > precautions to not change any semantics. > > Simplified thusly: > >

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

> On 8 Nov 2015, at 16:51, Alan Bateman wrote: > > On 05/11/2015 17:10, Steve Drach wrote: >> 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

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

> On 8 Nov 2015, at 21:21, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 08/11/2015 19:36, Paul Sandoz wrote: >> : >> >> I was wondering if it might be possible to consider this a mostly internal >> contract since the URL class loading functi

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

> On 9 Nov 2015, at 21:53, Steve Drach wrote: > As to whether this is implementation vs. JAR URL spec then I assume it needs to be spec so that libraries can create URLs that will use runtime versioning when access the JAR. >>> >>> Yeah, i don’t

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

> On 9 Nov 2015, at 19:07, Roger Riggs wrote: >> >> Why do you need to use a FileDescriptor rather than an int? AFAICT >> FileDescriptor is used as a box to the underlying descriptor that is >> accessed via shared secrets. > It is a cleaner encapsulation for the file

Re: RFR 8141409 Arrays.equals accepting a Comparator

Hi Roger, I want to keep this review focused and consistent with the existing methods that were previously reviewed. > On 12 Nov 2015, at 17:42, Roger Riggs wrote: > > Hi Paul, > > - A minor point but in the argument names, its a bit inconsistent between > using 'b'

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

> On 12 Nov 2015, at 14:48, Vitaly Davidovich wrote: > > Hi Paul, > > There is a very valid concern, since @Contended changes object layout and > increases object size, liberal use might tickle an overflow in HotSpot code. > Hence why it has remained internal so far. > >

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

> On 12 Nov 2015, at 15:50, Roger Riggs <roger.ri...@oracle.com> wrote: > > Hi Paul, > > > On 11/12/2015 9:45 AM, Paul Sandoz wrote: >> One more thing i forgot to mention, if there is ever a chance that >> ProcessBuilder is changed from final to non-final

8142493: Utility methods to check indexes and ranges doesn't specify behavior when function produces null

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8142493-checkIndex-function-return-null/webrev/ This catches some edge cases for the exception mapping function passed to the

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