• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Mastering Lambdas Question

 
Ranch Hand
Posts: 462
Scala jQuery Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Can you explain some of the gotchas when switching to using Lambdas in Java? I understand that using a parallel stream in place of a stream for example is not always a good idea but I'm still a little hazy on why, is there anything else we need to keep in mind?
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Parallel streams vs ordinary streams isn't a gotcha, but it might be a performance handicap. If you look at the sort of code Jason Bullers posted earlier today, you can see that many of the gotchas disappear.
 
Ranch Hand
Posts: 115
11
IntelliJ IDE Clojure Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As Campbell said, you could end up with a performance handicap if you choose to use parallel streams when the amount of work you are parallelizing is insufficient to warrant the extra overhead.

The only other "gotcha" I can think of (and that's kind of related to the what vs how idea) is that you have to be careful to solve the problem in a "functional" way when using parallel streams; that is, without introducing side effects such as mutation. If the work you are doing on each element of the stream mutates an external collection, for example, you could end up with incorrect results when you switch from a sequential stream to a parallel stream.
 
Author
Posts: 20
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Will

On the question of parallel vs. sequential streams, Jason is certainly right that there needs to be sufficient parallelizable work to justify the overhead of splitting into parallel streams and later merging the results. It's quite a complicated question, though: you also have to take into account (amongst other things) how splittable the data source is and whether the intermediate operations are truly CPU-intensive.

Actually, the parallel/serial choice is going to be relatively uncommon in practice. More everyday gotchas arise from the design goals of the streams package, which assume that all stream programs are written so that they could be executed in parallel, even if it doesn't happen to be worthwhile to do so. The requirements this imposes are documented in the Stream package summary, under the headings "Non-interference", "Stateless behaviours", and "Side-effects".

I explain all this in the book. But it takes quite a few pages – more space than we have for answering questions on this forum

Regards
Maurice
 
reply
    Bookmark Topic Watch Topic
  • New Topic