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

Hello! PS With reuse it becomes more compelling :-) In both cases of PS singleton/nCopies the spliterator characteristics can be the same PS and that of the already existing singleton spliterator implementation. The only difference is the DISTINCT characteristic. I think it's good to report it

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

Seems that the patch attachment was filtered out. Just for the case here it is: diff --git a/src/java.base/share/classes/java/util/Collections.java b/src/java.base/share/classes/java/util/Collections.java --- a/src/java.base/share/classes/java/util/Collections.java +++

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

Hello! Current implementation of Collections.nCopies().stream() is as follows: http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/Collections.java#l5066 public StreamE stream() { return IntStream.range(0, n).mapToObj(i - element); } @Override

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

Hello! Although it's not the part of public API, there are references to non-existing methods in SliceOps.java and Streams.java: http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/stream/SliceOps.java#l141 // @@@ OOMEs will occur for

Re: RFR Collector.finisher refers to IDENTITY_TRANSFORM rather than INDENTITY_FINISH

Hello! Seems that you have an extra parenthesis here: diff -r 4e3135fac8cc src/java.base/share/classes/java/util/stream/SliceOps.java --- a/src/java.base/share/classes/java/util/stream/SliceOps.javaFri Jul 24 15:33:13 2015 -0700 +++

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

life when PS inverting control with lambdas. What we really require is a better way to specialise the hot loops. PS Paul. PS On 28 Jul 2015, at 10:37, Tagir F. Valeev amae...@gmail.com wrote: Hello! Current implementation of Collections.nCopies().stream() is as follows: http

Re: Possible long overflow in Collectors.averagingLong and LongStream.average

Hello! Just for information: as finite stream size is very unlikely to exceed Long.MAX_VALUE (and even if exceeds it will take enormous CPU time to process such stream), the problem can be fixed just by tracking 128 bit sum instead of 64 bit. It's not very difficult to implement it: just two long

Possible long overflow in Collectors.averagingLong and LongStream.average

Hello! The following code prints -1 twice, while users would normally expect something like 9.223372036854776E18: double avg1 = Stream.of(Long.MAX_VALUE, Long.MAX_VALUE).collect( Collectors.averagingLong(Long::valueOf)); System.out.println(avg1); double avg2 =

Re[2]: Speed optimization of Spliterators.spliteratorUnknownSize for parallel case

be reused. PS On Jul 10, 2015, at 8:01 PM, Tagir F. Valeev amae...@gmail.com wrote: Hello! The problem of ineffective parallelization of spliteratorUnknownSize for low-N/high-Q tasks was already discussed in the thread Exploiting concurrency with IteratorSpliterator of unknown size

[PATCH] Re: Incomplete JavaDoc for Collections.synchronizedXYZ

= Collections.synchronizedNavigableMap(new TreeMap()); * ... PS> Hi Tagir, PS> Agreed. If you wanna send a patch to this list with updates to PS> the other synchronized* methods i can review push it for you. PS> Paul. >> On 12 Oct 2015, at 15:18, Tagir F. Valeev <ama

Re: Collections.emptyList().spliterator() is not ORDERED

Hello! >> PS> In this case we should fix Stream.concat to check if a >> PS> spliterator reporting SIZED is empty, which will allow us to optimize >> the concatenation [1]. >> PS> [1] https://bugs.openjdk.java.net/browse/JDK-8022805 I tried to fix this issue, but stuck into subtle behavior

Re: Questions about Stream/Iterable/Files / FOLDING Collector

Hello! PS> I have a preference to first consider a Stream.foldLeft, and from PS> that maybe consider a LEFT_FOLDING characteristic, with PS> appropriate factories. But then people may ask for RIGHT_FOLDING, PS> to which i will say, first we have to consider Stream.reverse, and PS> then that pulls

Re: [PATCH] Incomplete JavaDoc for Collections.synchronizedXYZ

java/util/Collections.java.sdiff.html PS> <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8141630-Collections-synchronized/webrev/src/java.base/share/classes/java/util/Collections.java.sdiff.html> PS> Paul. >> On 25 Oct 2015, at 10:29, Tagir F. Valeev <amae...@gmail.com> wrote: >> >&

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

Hello! >>> https://bugs.openjdk.java.net/browse/JDK-8141608 >>> >> >> Thanks to Remi and Paul for the complete explanation. Concerning >> JDK-8141608, I lile Peter Levart's comment about making a specific Collector. PS> There is a problem

Re: Optional.or name Re: RFR 8080418 Add Optional.or()

Hello! If my opinion matters, I'm perfectly fine with Optional.or name, no need to change. With best regards, Tagir Valeev. >> On 25 Sep 2015, at 12:58, Paul Sandoz wrote: >> >> Hi, >> >> Please review this change to add a method Optional.or that allows one to >>

Incomplete JavaDoc for Collections.synchronizedXYZ

Hello! With the introduction of Stream API the JavaDoc for Collections.synchronizedCollection was updated (as part of work on JDK-8023275): * It is imperative that the user manually synchronize on the returned * collection when traversing it via {@link Iterator}, {@link Spliterator} * or

JDK-8071597: close original Stream in default implementation?

Hello, I was looking at default implementation of new Stream takeWhile/dropWhile methods: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071597-take-drop-while/webrev/src/java.base/share/classes/java/util/stream/Stream.java.cdiff.html I think in order to make this default behavior more

Speed optimization of Spliterators.spliteratorUnknownSize for parallel case

Hello! The problem of ineffective parallelization of spliteratorUnknownSize for low-N/high-Q tasks was already discussed in the thread Exploiting concurrency with IteratorSpliterator of unknown size [ http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011968.html ] It was proposed to

Re: Collections.emptyList().spliterator() is not ORDERED

ing so long,i will get to them in the next couple of PS> weeks, but i need to process some other stuff first. No problems, I'm not in a hurry. With best regards, Tagir Valeev. PS> On 6 Sep 2015, at 12:21, Tagir F. Valeev <amae...@gmail.com> wrote: >> Hello! >> &g

Collections.emptyList().spliterator() is not ORDERED

Hello! As Paul Sandoz pointed out in the "Custom spliterator for Collections.nCopies(n, obj).stream()" discussion, the List.spliterator() is specified to be ORDERED. However Collections.emptyList().spliterator() violates this specification: System.out.println(Collections.emptyList()

Re: RFR(m) 2: 8072722: add stream support to Scanner

Hello! In tokens() JavaDoc: * {@code * List result = new Scanner("abc,def,,ghi").useDelimiter(","). * .tokens().collect(Collectors.toList()); * } Here the dot is duplicated after "useDelimiter()" and before "tokens()" on the next line. Everything else looks good to me.

[PATCH] Collectors.counting() does unnecessary boxing on every accumulation

Hello! Could you please consider the following very simple patch to Collectors.counting() implementation? diff --git a/src/java.base/share/classes/java/util/stream/Collectors.java b/src/java.base/share/classes/java/util/stream/Collectors.java ---

Re: [PATCH] Collectors.counting() does unnecessary boxing on every accumulation

if source is not already distinct and encounter order is PS> // preserved or not PS> On 17 Sep 2015, at 08:02, Tagir F. Valeev <amae...@gmail.com> wrote: >> Hello! >> >> Could you please consider the following very simple patch to >> Collectors.cou

Re: RFR 8080418 Add Optional.or()

Hello! >> Quite interesting and long awaited features (at least according to >> StackOverflow questions). PS> All of them? or just the first? The first one is definitely the most requested feature. However, additional methods for primitive optionals were requested at least twice:

Re: Array equality, comparison and mismatch

Hello! Quite interesting feature. Isn't it a typo here? http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html 419if (!Float.isNaN(a[aFromIndex + i]) || !Float.isNaN(b[aFromIndex + i])) 487

Re: RFR 8080418 Add Optional.or()

Hello! Quite interesting and long awaited features (at least according to StackOverflow questions). Isn't it a good idea to provide also a way to transfer between Optional types like "mapToInt", "mapToObj", etc., like it's done in Stream API? PS> 2) add to all variants a mapOrElseGet (otherwise

Re: Pattern.splitAsStream JavaDoc doubt

Hello, Chris, Paul! Thank you for the review. >> Tagir, >> >> It would seem most useful to update the implementation to >> match the current spec. PS> Yes, it’s an oversight and lacked a test for such case. PS> Tagir, thanks for finding this. Would it be possible for you to PS> also add a

Pattern.splitAsStream JavaDoc doubt

Hello! Currently Pattern.splitAsStream JavaDoc says [1]: * If the input sequence is mutable, it must remain constant during the * execution of the terminal stream operation. Otherwise, the result of the * terminal stream operation is undefined. However in reality the sequence must remain

Re: RFR 8144675: Add a filtering collector

Hello! Sounds reasonable. I already have such collector in my library [1]. As an alternative solution for your problem I have groupingBy collector with domain parameter [2], so you can specify the set of possible keys and all keys are guaranteed to be created: Set getAllDepartmentsSet() {...}

Producing streams in java.time?

Hello! Currently it seems that java.time package does not use Stream API in any way. I think it would be nice to add some methods which produce the streams. For example: - in class Year: // Returns sequential ordered stream of all months within this Year: Stream months(); // Returns sequential

Re: RFR:8146218: Producing streams in java.time?

am instantsUntil(Instant endExclusive, Duration step); SC> Stream instantsUntil(Instant endExclusive, Duration step); SC> ... SC> I think the place to start is the two methods on LocalDate which are SC> tricky enough to be justified. Then perhaps the methods on SC> Year/YearMonth. SC> S

Re: Producing streams in java.time?

Fix for the previous letter: TFV> IntStream.range(1, YearMonth.now().lengthOfMonth()) TFV> .mapToObj(YearMonth.now()::atDay) TFV> .map(...).forEach(...) Of course I meant IntStream.rangeClosed instead of IntStream.range in every code sample. This just demonstrates that manual implementation

Re: Producing streams in java.time?

duce the number of methods. It's possible to omit months() and days() and replace year.months() with something like this: year.atMonth(1).monthsUntil(year.plusYears(1).atMonth(1)) But it's even worse than not using the new API at all: IntStream.range(1, 12).mapToObj(year::atMonth) With best regards, Tagi

Re: RFR: Implement RandomAccess spliterator

Hello! (disclaimer: I'm not an official reviewer) > ((AbstractList) lst).modCount; Raw-type casts should be replaced with AbstractList to avoid warning. > public RandomAccessSpliterator trySplit() Covariant return type seems to be unnecessary here as this spliterator is not public and

Re: Map.Entry methods for streams

Hello! SC> Finally, the Collectors class could do with a new method entriesToMap() SC> that collects a stream of Map.Entry back into a Map. I was thinking about adding such collector into my library and checked StackOverflow to understand the useful scenarios. Seems that having entriesToMap()

Re: Map.Entry methods for streams

Hello! Note that having single swap() method which just swaps key and value in addition to withKey/withValue covers this use case: Map gad = dag.entrySet() .stream() .flatMap(e -> e.getValue().stream().map(e.swap()::withKey)) .collect(groupingBy(Entry::getKey,

Clarification of BaseStream.onClose() behavior

Hello! Current documentation for BaseStream.onClose() does not specify explicitly how the stream would behave if additional close handlers are registered after the stream is consumed or even closed. The implementation actually allows registering the additional close handlers after consumption or

Re: RFR-8148838: Stream.flatMap(...).spliterator() cannot properly split after tryAdvance()

seems I have no other choice. Here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8148838/r3/ With best regards, Tagir Valeev. [1] https://twitter.com/BrianGoetz/status/694985109628387328 PS> Paul. >> On 3 Feb 2016, at 12:19, Tagir F. Valeev <amae...@gmail.com> wrote:

Re: RFR-8148748: ArrayList.subList().spliterator() is not late-binding

ped page-fault). Well, >> ok, I'm not a Hotspot expert (probably for C1 this still matters). I >> will keep this code as is. >> >> Webrev was not changed: >> http://cr.openjdk.java.net/~tvaleev/webrev/8148748/r1/ >> Any more reviews, please? >> >

Re: RFR-8148838: Stream.flatMap(...).spliterator() cannot properly split after tryAdvance()

Hello! PS> Would you mind updating the date in the license headers and the PS> test with the bug id. Then i will push. I forgot to tell you about PS> those little things, see the following for one of your fixes i PS> pushed with such updates (to avoid any email/review latency): Ah, sorry. I saw

Re: RFR-8148838: Stream.flatMap(...).spliterator() cannot properly split after tryAdvance()

Hello! PS> 188 public Spliterator trySplit() { PS> 189 if (isParallel && !finished) { PS> 190 init(); PS> 191 PS> 192 if (buffer != null && buffer.count() > 0) // partial traversal started PS> 193 return null; PS> Why

Re: RFR-8148748: ArrayList.subList().spliterator() is not late-binding

/~tvaleev/webrev/8148748/r1/ Any more reviews, please? With best regards, Tagir Valeev. MB> On Wed, Feb 3, 2016 at 4:20 AM, Tagir F. Valeev <amae...@gmail.com> wrote: >> Some more thoughts about forEachRemaining: >> >> To me it seems that >> if ((a = lst.elementData)

RFR-8148250: Stream.limit parallel ordered performance

Hello! Here's webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8148250/r1/ With best regards, Tagir Valeev. >> On 26 Jan 2016, at 16:51, Tagir F. Valeev <amae...@gmail.com> wrote: >> >> Hello! >> >> Thank you for review! Here's the issue: >> https:

Re: RFR 8148115: Stream.findFirst for unordered source optimization

t correctly. "Add tests for unordered primitive sources for Stream operations"? "Refine test data sets for Stream API"? Probably it would be better if you open an issue by yourself :-) With best regards, Tagir Valeev. PS> — PS> I will take this and other patches (clo

Stream.foldLeft, one more time (8133680)

Hello! What do you think, is it still reasonable to add foldLeft operation to JDK-9 Stream API (foldLeft only, no foldRight)? I propose the following signatures: interface Stream { public U foldLeft(U seed, BiFunction accumulator); public Optional foldLeft(BinaryOperator

Re: RFR-8148838: Stream.flatMap(...).spliterator() cannot properly split after tryAdvance()

sets with .small alternatives (I think it's ok here as WrappingSpliterator behavior does not differ much for various sources) and removed all .map tests. Now the test works faster (like 25 sec -> 17 sec on by box). Please check. With best regards, Tagir Valeev. PS. PS> Paul. >&

RFR-8148838: Stream.flatMap(...).spliterator() cannot properly split after tryAdvance()

Please review and sponsor this fix: https://bugs.openjdk.java.net/browse/JDK-8148838 http://cr.openjdk.java.net/~tvaleev/webrev/8148838/r1/ When buffer traversal is already started, and split is requested, then the existing buffer should be carefully transferred to the prefix part. The only

RFR-8148748: ArrayList.subList().spliterator() is not late-binding

; * a fashion that iterations in progress may yield incorrect results.) PS> Paul. >> On 29 Jan 2016, at 05:32, Tagir F. Valeev <amae...@gmail.com> wrote: >> >> Hello! >> >> When reviewing 8079136 I noticed that >> ArrayList.subList().spliterator() is not l

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

Hello! AbstractList::subListRangeCheck could be replaced with new Objects::checkFromToIndex for consistency with other methods. Also AbstractList::rangeCheck could be replaced with Obejcts::checkIndex. The same for ArrayList class. Otherwise looks good to me. With best regards, Tagir Valeev.

ArrayList.subList().spliterator() is not late-binding

Hello! When reviewing 8079136 I noticed that ArrayList.subList().spliterator() is not late-binding: List list = new ArrayList<>(Arrays.asList(1,2,3,4)).subList(0, 3); Stream s = list.stream(); list.add(5); s.findFirst(); --> Exception in thread "main" java.util.ConcurrentModificationException

Re: RFR:8146218: Producing streams in java.time?

Hello! It should be noted that there's already a precedent in JDK where method returning stream is subclassed and returns the stream of more concrete objects. I'm speaking about ZipFile and JarFile: public class ZipFile { public Stream stream() {...} } public class JarFile extends ZipFile {

Re: RFR:8146218: Producing streams in java.time?

SC> will be a useful addition. SC> I'll let the Oracle team chime in to do a further review. SC> thanks SC> Stephen SC> On 16 January 2016 at 13:31, Tagir F. Valeev <amae...@gmail.com> wrote: >> Hello! >> >> Thanks for review! Here's the updated pat

Stream.findFirst for unordered source optimization

Hello! Seems that currently Stream.findFirst is not optimized for unordered source. I think it should work as findAny in this case. Here's a small patch which fixes this: http://cr.openjdk.java.net/~tvaleev/patches/findFirst/find_patch.txt Simple JMH test:

RFR 8148115: Stream.findFirst for unordered source optimization

method. PS> Then change FindOp.mustFindFirst to be an int of the opFlags calculated in the constructor: PS> this.opFlags = StreamOpFlag.IS_SHORT_CIRCUIT | (mustFindFirst ? 0 : StreamOpFlag.NOT_ORDERED); PS> Paul. >> On 22 Jan 2016, at 07:19, Tagir F. Valeev <amae...@gmail.com>

RFR 8147505: Clarification of BaseStream.onClose() behavior

ugs.openjdk.java.net/browse/JDK-8147505 TFV> Thanks, TFV> Tagir Valeev. PS>> Thanks, PS>> Paul. >>> On 15 Jan 2016, at 05:35, Tagir F. Valeev <amae...@gmail.com> wrote: >>> >>> Hello! >>> >>> Current documentation for Ba

Stream.limit parallel ordered performance

Hello! I'm investigating Stream.limit() performance for parallel ordered streams when no SUBSIZED optimization is performed. Consider the following code, for example: AtomicInteger counter = new AtomicInteger(); int[] result = IntStream.range(0, 1_000_000).parallel().filter(x -> true)

Re: 8148250 Stream.limit parallel ordered performance

till applies but now for larger n, so we should refine it. Should we replace "regardless of the value of n" with "when n*parallelismLevel is sufficiently large"? With best regards, Tagir Valeev. PS> Paul. >> On 24 Jan 2016, at 12:36, Tagir F. Valeev <amae..

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

Hello! I wanted to work on foldLeft, but Brian asked me to take this issue instead. So here's webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8072727/r1/ I don't like iterator-based Stream source implementations, so I made them AbstractSpliterator-based. I also implemented manually

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

End of stream occurs SM> when the advancer doesn't call the consumer. SM> -- SM> Stream produce(Supplier<Stream>) SM> A variation of Supplier<Optional> where the supplier returns a stream SM> containing zero or more elements. The stream terminates if the supplier return

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

g(1) PL>     //  reason: inference variable S has incompatible PL> equality constraints String,CharSequence PL>     //  where S,T are type-variables: PL>     //    S extends T declared in method PL> <T,S>iterate2(S,Predicate,UnaryOperator) PL&

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

that the termination condition is SM> separate from the values that go into the stream. In particular there's no SM> "seed" value to which a termination condition can be applied. (And "iterate" SM> might not be the best name for this method, either.) SM> Oh well, I thin

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

ng int values from a Scanner into an IntStream, until SM>>> there are no more, leaving the scanner at a known state. Suppose there were an SM>>> iterate(Supplier) overload. Then something like this would work: SM>>> Scanner sc = new Scanner("1 2 3 4 foo"

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

() -> sc.hasNextInt() ? OptionalInt.of(sc.nextInt()) SM>>: OptionalInt.empty()) SM>> .forEach(System.out::println); SM>> assert sc.hasNext(); SM>> System.out.println(sc.next()); // prints "foo" SM>&

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

== point)) { PL> end = true; PL> } else if (point == 0) { PL> point = roll; PL> } PL> } PL> return !end; PL> } PL> }.stream().forEach

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

Looks good for me, thank you! With best regards, Tagir Valeev. >> I think they are important, more so the test update. >> >> If we can roll ‘em to Ivan’s patch that would be the most efficient. Ivan >> are you ok with that? >> IG> Sure! IG> Here's the webrev, updated with those changes: IG>

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

lse(LongStreams.of(1, 10).boxed().spliterator() SZ> .hasCharacteristics(Spliterator.SORTED)); SZ> The asserts for IntStreams.range(1, 10).asDoubleStream() would have SZ> to be changed to account for DISTINCTness, of course. SZ> Regards, SZ> Stefan SZ> 2016-0

Re: Expecting Integer.valueOf(String) to accept Literal format ...

Strictly speaking there are many more ways to specify integer constant in Java. Like int x = 045; int x = 0x34; int x = 0b11101; So why should we support "4_5_6" only, but not "0x456"? Note that "045" is already parsed by Integer.valueOf, but as decimal number, not as octal. Thus I don't think

Re: default random access list spliterator

Hello! I thought about such possibility. One problem which would arise is that such spliterator will not be able to properly track modCount and throw ConcurrentModificationException. As a consequence it might produce silently inconsistent result if the structural changes were performed on your

Re: RFR-8148748: ArrayList.subList().spliterator() is not late-binding

Hello! >> I'm just worrying a little that my changes might conflict with Ivan >> Gerasimov's pending 8079136 issue, so probably it would be better to >> wait till it's reviewed and pushed… Ivan said that 8079136 is stalled for a while, so I decided to continue working on 8148748. Here's updated

Re: RFR-8148748: ArrayList.subList().spliterator() is not late-binding

Hello! Thank you for the review! Here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8148748/r3/ PS> Looks good. I especially like: PS> 125 addCollection(l.andThen(list -> list.subList(0, list.size(; PS> Can you also update

Re: Stream API: Fuse sorted().limit(n) into single operation

clearly a word). LW> On Sat, Mar 5, 2016 at 12:32 PM Tagir F. Valeev <amae...@gmail.com> wrote: LW> Hello! LW> LW> One of the popular bulk data operation is to find given number of LW> least or greatest elements. Currently Stream API provides no dedicated LW> op

RFR: 8151123 - Collectors.summingDouble/averagingDouble unnecessarily call mapper twice

Hello! Please review and sponsor this small change: https://bugs.openjdk.java.net/browse/JDK-8151123 http://cr.openjdk.java.net/~tvaleev/webrev/8151123/r1/ User-supplied mapper function is unnecessarily called twice on each accumulation event in summingDouble and averagingDouble. This function

Re: Stream API: Fuse sorted().limit(n) into single operation

eliminates allocation of PL> temporary array for merging for the cost of pre-merge step PL> which just derives the end indices. There's a chance that this PL> might improve performance because it trades memory writes for reads. PL> What do you think? PL> Reg

Stream API: Fuse sorted().limit(n) into single operation

Hello! One of the popular bulk data operation is to find given number of least or greatest elements. Currently Stream API provides no dedicated operation to do this. Of course, it could be implemented by custom collector and some third-party libraries already provide it. However it would be quite

Re: RFR-8148748: ArrayList.subList().spliterator() is not late-binding

re. So user will see NPE instead of CME. Probably it could be logged as separate issue. My patch does not cause any regression here (at least, I hope so). Probably some other collections should be checked for similar corner cases as well. With best regards, Tagir Valeev. >> On 4 Mar 2016, at 15:

RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

Hello! Please review and sponsor the following patch: http://cr.openjdk.java.net/~tvaleev/webrev/8153293/r1/ The patch preserves more characteristics on primitive stream operations: IntStream/LongStream/DoubleStream.boxed() preserves SORTED and DISTINCT IntStream.asLongStream() preserves SORTED

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

07/webrev/ >> >> The fix was built/tested successfully on all supported platforms. >> >> Sincerely yours, >> Ivan >> >> On 02.02.2016 9:55, Martin Buchholz wrote: >>> On Mon, Feb 1, 2016 at 10:19 PM, Tagir F. Valeev <amae...@gmail.com>

RFR: 8153332 - Stream API: Fuse sorted().limit(n) into single operation

Hello! Please review the following enhancement: https://bugs.openjdk.java.net/browse/JDK-8153332 http://cr.openjdk.java.net/~tvaleev/webrev/8153332/r1/ It was earlier discussed here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039308.html The motivation and algorithm are

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

Thank you for reviews! Here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r2/ AS> *) Does EA break if you make ArrayItr inner class to gain the access to AS> E[] a? No, I checked, it still allocates. AS> *) next(): Missing braces in throw new NSEE() block; Fixed AS>

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

Hello! Thank you for comments. Update: http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r3/ AS> Test: AS> *) Formatting: "i=0", "i *) Formatting: "} catch (NSEE ex)" should be on the same line; Done. AS> *) What does the "for (int i=0;

Re: RFR(m): 8140281 deprecate Optional.get()

Hello! While I'm not a reviewer, I agree with Stephen. While I understand the rationale, such renaming would cause even more confusion and pain. Also I think this is not the worst part of Java API, so if we start to rename things, where should we stop then? With best regards, Tagir Valeev.

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! webrev is updated in-place (just added parentheses): http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r1/ Updated benchmark source and results are available here: http://cr.openjdk.java.net/~tvaleev/webrev/8154387/jmh/ In general I observe that for low-Q filter (x -> true) the results

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

t for limit = 2000 the performance is the same as I have 4 CPU machine and 2000 is greater than 128*4. On the other hand, 200 is less than 128*4, so this case is also improved (though not so drastically as less limits). With best regards, Tagir Valeev. SZ> Regards, SZ> Stefan SZ> 2016-04-16 15:0

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! Thank you for review! PS> 913 UnorderedSliceSpliterator(T_SPLITR s, long skip, long limit) { PS> 914 this.s = s; PS> 915 this.unlimited = limit < 0; PS> 916 this.skipThreshold = limit >= 0 ? limit : 0; PS> 917 this.chunkSize =

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! PS> Thinking some more about this, i think it would be preferable. It PS> reduces the explicit referral to PS> ForkJoinPool.getCommonPoolParallelism(). No problems, here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r2/ All tests pass. With best regards, Tagir

RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! Please review and sponsor the following patch: https://bugs.openjdk.java.net/browse/JDK-8154387 http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r1/ The rationale is to speed-up the parallel processing for unordered streams with low limit value. Such problems occur when you want to

RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

Hello! Please review and sponsor the following patch: https://bugs.openjdk.java.net/browse/JDK-8155600 http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r1/ It appears that custom implementation of Arrays.asList().iterator() is noticeably more performant than the AbstractList implementation

Collectors.toSet() small performance improvement

Hello! I'd like to propose a simple performance patch for Collectors.toSet(): --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 02 07:19:06 2016 +0530 +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 09 11:47:20 2016 +0700 @@ -295,7

Re: Collectors.toSet() small performance improvement

Hello, Aleksey! Thank you for review. AS> Good trick, but does it work properly with the sets that care about the AS> add order, e.g. LinkedHashSet? I guess our saving grace here is AS> Collector.toSet() is declared UNORDERED, so we can disturb the encounter AS> order without violating the API

Exceptional behavior of parallel stream

Hello! I found no information in Stream API documentation on how it behaves in case if exception occurs during the stream processing. While it's quite evident for sequential stream (stream processing is terminated and exception is propagated to the caller as is), the behavior for parallel streams

Re: Collectors.toSet() small performance improvement

PS> Paul. >> On 8 Aug 2016, at 22:31, Tagir F. Valeev <amae...@gmail.com> wrote: >> >> Hello! >> >> I'd like to propose a simple performance patch for Collectors.toSet(): >> >> --- a/src/java.base/share/classes/java/util/stream/Collecto

Re: Make iterators cloneable?

Hello! As your keys are comparable, you can create normal iterators and filter the results like this: for(String v1 : s) { for(String v2 : s) { if(v1.compareTo(v2) < 0) { System.out.println(v1 + " <-->" + v2); } } } Or using Stream API: s.stream().flatMap(v1 -> s.stream()

Re: Exceptional behavior of parallel stream

Hello, Doug! Thank you for your response. DL> In your example, you can witness the delayed termination of other threads DL> upon exception in another because you add side-effecting operations DL> (here, just printing). Avoiding all this would force sequential processing. DL> But if the supplied

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

Hello! Is it necessary to report SIZED characteristic and calculate the cardinality in advance making two-pass traversal? This improves bitSet.stream().toArray() performance (also bitSet.stream().count(), but it's rare case in practice). However this is just waste of time for any other stream

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

Looks good. PS> Hi, PS> Please review the following JavDoc fix for PS> j.u.stream.Collectors:: collectingAndThen. PS> Thanks, PS> Paul. PS> diff -r 2e076c7e72d6 PS> src/java.base/share/classes/java/util/stream/Collectors.java PS> --- PS>

Re: JDK 10 RFR of 8176894: Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute in TreeMap

Hello! Great and long-awaited feature, thanks! I don't see that modCount is checked after calling mappingFunction in compute/computeIfAbsent/computeIfPresent. Is it possible to break the Map if mappingFunction changes the Map content? See similar problems in HashMap:

Re: RFR: 8251989: Hex formatting and parsing utility [v2]

On Tue, 13 Oct 2020 19:51:30 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, >> prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with >> modified

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Wed, 28 Oct 2020 15:56:48 GMT, Alan Bateman wrote: >> Kim Barrett has updated the pull request incrementally with one additional >> commit since the last revision: >> >> improve wording in refersTo javadoc > > The API looks good, thanks for getting this in. Hello! As an IDE developer,

Re: RFR: 8180352: Add Stream.toList() method

On Wed, 4 Nov 2020 08:50:49 GMT, Zheka Kozlov wrote: >> This change introduces a new terminal operation on Stream. This looks like a >> convenience method for Stream.collect(Collectors.toList()) or >> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this >> method

Re: RFR: 8259622: TreeMap.computeIfAbsent deviates from spec [v2]

> Handle TreeMap::computeIfAbsent when previous mapping with null value existed > (in this case spec requires to overwrite the existing mapping) Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Copyright year u

  1   2   >