Forums Register Login

Functional Porgramming in Java: lazyness

+Pie Number of slices to send: Send
Hello.
I see from the book content that there's a chapter on lazyness.

Since I consider it as one of the traditional fp features that Java doesn't natively support, how do you approach it in the book?
Is there any workaround to the language (like using closures) and how much do the solution impact the runtime performance?

Thank you

Ivano Pagano
+Pie Number of slices to send: Send
Lazy execution is a standard feature of a Stream. Not only does the Stream downstream only execute as many instances are necessary to produce the requisite result, but it stops all the upstream Streams too, because they use lazy execution too.
+Pie Number of slices to send: Send
 

Since I consider it as one of the traditional functional programming features that Java doesn't natively support, how do you approach it in the book?
Is there any workaround to the language (like using closures) and how much do the solution impact the runtime performance?



There is a full chapter in the book about streams. It is not about Java 8 streams, but about implementing streams, which are basically lazy lists. The reason not to use Java 8 streams is that these have been implemented mostly to serve as a basis to automatic parallel processing. It seems that, for this reason, some very important methods of streams have not been implemented. In any case, it is very useful to learn how to implement streams functionally. It is important to note that a functional structure like streams does not indeed need to be implemented functionally. Streams must have a functional interface. What happens inside may be imperative, this does not make streams non functional. Java 8 streams are not implemented functionally, but this is not the problem. They are not functional because they are mutable. Once a stream has been used (by a terminal operation), its state has changed and it can't be used any longer.

But this is not the main reason not to use them (in the book, I mean!) The main reason is that laziness is used everywhere, so it is important to learn how to work with it. By the way, laziness has been used by Java from the start. What could we do without laziness? Can you imagine programming in a language in which both branches of an if...else structure would always be evaluated? Or a language in which you could not escape from a loop until all iterations have been executed? No very useful. Java also has the lazy boolean operators (&& and ||). In Java 8, Optional has lazy methods such as orElseGet() and orElseThrow(). If orElseThrow was not lazy, the exception would always be thrown even when the Optional holds a value!

In Java 8, lazy values are represented by the Supplier interface. In the book, laziness is used in many places. Too many to list them all!
+Pie Number of slices to send: Send
 

Pierre-Yves Saumont wrote:
But this is not the main reason not to use them (in the book, I mean!) The main reason is that laziness is used everywhere, so it is important to learn how to work with it. By the way, laziness has been used by Java from the start. What could we do without laziness? Can you imagine programming in a language in which both branches of an if...else structure would always be evaluated? Or a language in which you could not escape from a loop until all iterations have been executed? No very useful. Java also has the lazy boolean operators (&& and ||). In Java 8, Optional has lazy methods such as orElseGet() and orElseThrow(). If orElseThrow was not lazy, the exception would always be thrown even when the Optional holds a value!


I was thinking more of library support over built-in language features.

Pierre-Yves Saumont wrote:In Java 8, lazy values are represented by the Supplier interface. In the book, laziness is used in many places. Too many to list them all!



Didn't know about Supplier, I'm going to check that for sure. Would you consider it the equivalent of a OO closure intended to make evaluation lazy?
In your experience, is there a significant cost at runtime (caused by instances generated in memory and GCed?). I heard many complain about the performance cost in scala for automatic generation of many "functional objects" used by collections and such.
+Pie Number of slices to send: Send
In fact, lambdas are often inlined by the compiler, in which case no additional object is created. This is an important difference between lambdas (as well method references) and anonymous classes. It is also the reason why this in an anonymous class refers to the anonymous class, whether in a lambda, it refers to the enclosing class.

Of course, this is not true if you explicitly declare a named function. But on the other hand, declaring a named function makes it reusable. To benefit from reusability and inlining, use method references.



It is however unfortunate that we can't write:



What could go wrong in a swell place like "The Evil Eye"? Or with this tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 895 times.
Similar Threads
EJB 3: JPA versus Beginning EJB 3 App Dev
Why Scala?
"Java NIO" - Release Announcement - O'Reilly
Expert .NET Delivery Using NAnt and CruiseControl.NET by Marc Holmes
What should I expect from Head First JavaScript programming.
Thread Boost feature
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 02:11:30.