Styleguide advice on Java stream() apis

[Andrew Grieve]

With M being deprecated, we will soon be able to use Java's stream APIs in Chrome.

This site has great examples of how to use them:

https://www.baeldung.com/java-8-streams

And for googlers, there's some advice at go/java-practices/streams

I think it would be good to add a note about streams to chrome's style guide. Some of the examples are very compelling, but some of the most common uses (afaict) require heavy use of lambdas, which end up being larger in compiled size, and slower at runtime than a boring old loop.

There's also the question of whether or not to allow parallel() / parallelStream(). They don't allow using Chrome's own PostTask-based threadpool, so I suspect we should just say these are banned for now, but should be considered once we have a concrete motivating use-case.

In terms of presubmit checks, I think we should add a warning for code that uses stream(), that tells devs to consult the style guide, but we need to figure out what the style guide advice is first :).

As a starting point, I propose:

* parallel() / parallelStream() are banned but could be unbanned with disucssion.

* reduce() is banned due to be alway being confusing

* stream() without custom lambdas (incl. things like Foo::bar) are fine

* stream() expressions that use filter() or map() with custom lambdas are discouraged, but allowed if they would be comparatively difficult to write as loops.

As an interesting related point, Kotlin sequences appear to have the same problem, in they they are not re-written as loops when possible. It *is* possible that R8 may one day do such re-writing, but I'd propose we update guidance only when that happens and not before.

[Peter Conn]

This is cool - I can't think of anywhere I'd immediately want to update to use streams, but I have found myself at points missing them over the last few years.

For your style points, I agree with the 1st, 3rd and 4th, but not with the outright banning of reduce. You can write hard to read code with it - but that should be caught at the code review stage.

We could add a style point asking people to consider simpler ways of writing things - and pointing out the built-in methods (such as min or max) could be more appropriate.

Peter C

[Tommy Nyquist]

Streams seem useful to me whenever min, max, sum, etc., aren't enough. Providing guidance around how to use those core built-ins would hopefully be part of our documentation though.

We should also mention that the performance characteristics of using Streams vs for-loops could be unfortunate and should be taken into consideration when thinking about the trade-offs.

1) Outright banning parallel() / parallelStream() SGTM.

Re: "Could be unbanned with discussion": That would have to be an incredibly good reason in my opinion. Not just "random third party library uses this and library is cool".

Is there any way we can ensure that if third party code depends on and uses parallel streams, presubmits would fail? Otherwise I'm worried it might sneak in accidentally.

2) Without parallel streams, I don't necessarily think that reduce() is always confusing. With combine, it's definitely confusing, but that's not in use if parallel streams are not in use I think?

3) Sounds OK to me.

4) We should probably explain why they would be discouraged to ensure that's clear when developers are making trade-offs.

--

Tommy

--
You received this message because you are subscribed to the Google Groups "java" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/java/5189bc58-b8b8-43bd-83f0-5816b249c1abn%40chromium.org.

[Andrew Grieve]

Put up a CL for this in case anyone wants to comment. I'll wait a few days to submit it.