RFR 8148115: Stream.findFirst for unordered source optimization

Paul Sandoz paul.sandoz at oracle.com
Fri Jan 29 15:45:45 UTC 2016


> On 29 Jan 2016, at 15:20, Tagir F. Valeev <amaembo at gmail.com> wrote:
> 
> Here's updated webrev:
> 
> http://cr.openjdk.java.net/~tvaleev/webrev/8148115/r2/
> 

Thanks, reviewed and in my queue.


> PS>  293             if (!this.mustFindFirst) {
> PS>  310             if (this.mustFindFirst) {
> PS> Small thing, no need for “this”.
> 
> Done.
> 
> 
> PS> You can now use Optional.ifPresentOrElse, which was added in 9:
> 
> PS>   ifPresentOrElse(
> PS>     t -> { …},
> PS>     () -> assertFalse(it.hasNext()):
> 
> Done. I also added printing of the searched value if it's not found:
> 
> assertTrue(contained, "Not found: "+r);
> 
> Hopefully additional toString() and string concatenation does not eat
> much time. Alternatively it could be rewritten as
> 
> if(!contained)
>  fail("Not found: "+r);
> 
> PS> For primitive streams, you are correct there are no unordered
> PS> providers of data. in certain cases unordered is induced e.g. forEach testing.
> 
> PS> A focused fix would be to exercise with say
> PS> s.filter().unordered(), a more general fix would be as you say to
> PS> add another provider for int, long and double (backed by say
> PS> HashSet, or more simply/efficiently using unordered()).
> 
> PS> We have to carefully review that because that may increase test
> PS> times. We don’t have to apply to all data sets, plus we could also
> PS> refine the ref data sets too in that regard, thus keep the overall actions similar or even smaller.
> 
> PS> Shall we separate that in a new issue?
> 
> Yes, I guess it would be better to log a new issue. Though I don't
> know how to formulate it 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 :-)
> 

https://bugs.openjdk.java.net/browse/JDK-8148615 <https://bugs.openjdk.java.net/browse/JDK-8148615>

Thanks,
Paul.



More information about the core-libs-dev mailing list