Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!
  • 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
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Modern Java Recipes: Simple Solutions to Difficult Problems in Java 8 and 9 --Design Problems

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do you address how to design entities with Streams API in the book "Modern Java Recipes"?
 
Marshal
Posts: 74067
332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What exactly do you mean by designing entities? A Stream is used as part of an algorithm, so it is usually used as a local variable, so it wouldn't necessarily form part of any entity at all.
 
Narendran Sridharan
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, you are right. I am just wondering if there is a way to create entities with the stream API usage, one use case may be as below. But I also wonder whether Stream can replace Collection classes in Entities, or is there any designing good practices. In general, whether any recipes shared about designing general classes (not methods & algorithms) with Stream is covered in this book?

 
gunslinger & author
Posts: 158
11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Many methods in the API return Stream, but there's a risk involved. Once a stream has been used (i.e., it has a terminal method like collect or findFirst), you can't call any more methods on it. That means if your method is going to return a Stream, it better create one in the first place. Otherwise somebody might call the method twice and throw an exception.

It's certainly doable, especially since the alternative is to convert to a collection and return that, but you need to make sure the stream exists and is viable when you do it.

On a somewhat related note, the latest version of Hibernate can now return entities as a stream, and it's not just getting a collection and calling stream() on it. It's windowed and everything. Hopefully those methods will migrate themselves into JPA at some point.
 
Campbell Ritchie
Marshal
Posts: 74067
332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Narendran Sridharan wrote:. . . one use case may be as below. . . .

Because you are not exposing a mutable reference type field to the outside world, that looks considerably better than simply returning the Collection<Address>. I think you will get a new Stream object every time that method is called.
But I am worried about the setAddresses method, which allows any code to alter the Person's addresses, and accepts a mutable reference type without a defensive copy, so other code can potentially breach the invariants of the Person object.
 
Narendran Sridharan
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Kousen & Campbell.

1. It is better to create new Stream all the time. Because stream can be traveled only once unlike collections which can be traversed many times.
2. Stream existence check is required
3. Certainly, mutability creates a problem and a defensive copy is required before creating stream Objects.
4. While designing Java APIs, I think, we have to consider many risks and carefully expose Stream inputs and outputs for consumers of the API.

I understood above 4 points from your posts.

It's windowed and everything


I did not get the above-quoted statement. A brief explanation will be greatly helpful.

I also like to know. which part of this books will be interesting for a person like me looking for designing techniques with streams & lambdas?
 
Campbell Ritchie
Marshal
Posts: 74067
332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Narendran Sridharan wrote:Thank you Kousen & Campbell.

That's a pleasure



1. It is better to create new Stream all the time. Because stream can be traveled only once unlike collections which can be traversed many times.

Agree. But the mechanism is different. You iterate a Collection directly by creating an Iterator for it. You create a Stream with the stream method (or otherwise) and the Stream uses the collection's Iterator behind the scenes, so look on the Stream the way you look on Iterators rather than the way you look on the Collection itself. As you know, you have to create Iterators anew every time you want to use them; the same applies to Streams.

2. Stream existence check is required

I am not convinced; I don't believe the Stream can ever be null.

3. Certainly, mutability creates a problem and a defensive copy is required before creating stream Objects.

No, a defensive copy is required whenever mutable reference types which are fields enter your object (e.g. via the constructor or a setXXX method) or whenever they leave your object (e.g. via a getXXX method). I do not believe you need to take defensive copies of the Stream because the Stream cannot modify the original Collection. The elements in that Collection may however be mutable themselves, so you will have to decide whether it is necessary to take deep defensive copies or shallow defensive copies.

4. While designing Java APIs, I think, we have to consider many risks and carefully expose Stream inputs and outputs for consumers of the API.

We have had a look at some of the risks caused by exposing fields of any kind.

. . .

It's windowed and everything

. . .

I think that means that Hibernate shows GUI windows when you use that functionality, but I am not certain.
 
Kenneth A. Kousen
gunslinger & author
Posts: 158
11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Streams do not modify their sources, so no defensive copies are needed.

The Hibernate API now has a stream() method that I believe lets you specify a window of elements to return rather than grabbing all of them and converting the resulting collection to a Stream. I'd have to check the details on that, though -- I only heard about it recently and it's not (yet) in JPA.
 
Narendran Sridharan
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, I agree with both Campbell & Kousen on the Defensive copy.

On "Stream existence check" - since it can be traversed only once, I think we just need to validate whether it is already traversed (not the usual null check).

Kenneth A. Kousen wrote:The Hibernate API now has a stream() method that I believe lets you specify a window of elements to return rather than grabbing all of them and converting the resulting collection to a Stream. I'd have to check the details on that, though -- I only heard about it recently and it's not (yet) in JPA.

- Thanks for the clarification.

Thanks Campbell for taking time to give your comment for each point.
 
Campbell Ritchie
Marshal
Posts: 74067
332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Narendran Sridharan wrote:. . . Thanks Campbell . . . .

That's a pleasure and I am sure that would speak for Ken Kousen too.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic