The people who rated this low must have wanted way beyond the basics. Already, I like how clearly he set up in our minds when the Supplier pattern is appropriate. All the places I was already thinking of -- and more. Nice.
Best video I've seen about this topic. Thank you very much. Yet this done before Java 11. Starting with Java 11, peek() will not work as expected in the slides. For example if the terminal operation is a count(), the JVM can infer the result without processing the pipeline, and peek() will not run. That can be helped by preceding the peek with a innocuous filter. That way the terminal function cannot be inferred and the pipeline has to be processed, running the intermediate keep() code.
Is there any resource benefit (in the aspect of memory) with streams compared to traditional external iterations. (Not about performance regarding execution time)
It avoids getMessage to be executed unnecessarily, but it will be necessary to repeat "if" all the time. To avoid this repetition, a function that encapsulates the condition could be created, but this function already exists! It is exactly what the logger.info does. So, I prefer the lambda approach.
This is a much better approach because you can debug it and figure out what it happening in the code. Promises are a disaster and so is this similar lambda expression idea. Give me an if statement every time please - I'm a human and I need to be able to understand that code! :)
@27m - it makes no difference that you check some state in a ternary operator or do it in a function block as you were doing. There's no leak of state. Yes, it's not functional, but this is why functional programming never found practical roots in commercial programming (only academia) and it will die a death (not soon enough) when the companies using it realize that nobody can maintain the awful functional code written by those "bright sparks" who blaze a trail and never stick around to support their own code.
The people who rated this low must have wanted way beyond the basics. Already, I like how clearly he set up in our minds when the Supplier pattern is appropriate. All the places I was already thinking of -- and more. Nice.
Best video I've seen about this topic. Thank you very much. Yet this done before Java 11. Starting with Java 11, peek() will not work as expected in the slides. For example if the terminal operation is a count(), the JVM can infer the result without processing the pipeline, and peek() will not run. That can be helped by preceding the peek with a innocuous filter. That way the terminal function cannot be inferred and the pipeline has to be processed, running the intermediate keep() code.
These is an amazing talk. Very rich and explains the reason behind Supplier, lambda... It help us to know what to use in each situation.
47:24 - 48:01 You can handle the exceptions internally or you can do that in a wrapper lambda, just a much cleaner separation.
Examples were very practical.
1:10 - 1:38 No presentation is complete without an occurrence like that
37:23 - "Accululator"! Sounds about right..
Is there any resource benefit (in the aspect of memory) with streams compared to traditional external iterations. (Not about performance regarding execution time)
Brilliant presentation .... top
Thanks
Uses Mac, surprised the slides freeze up.... bounce
Single Video better 3 units of Oracle MOOC. Focus on concepts. Examples make you think, understand and grasp the concepts.
lambdra expressions
How about `if(logger.levelInfo) {logger.info(getMessage());}`
It avoids getMessage to be executed unnecessarily, but it will be necessary to repeat "if" all the time. To avoid this repetition, a function that encapsulates the condition could be created, but this function already exists! It is exactly what the logger.info does. So, I prefer the lambda approach.
This is a much better approach because you can debug it and figure out what it happening in the code. Promises are a disaster and so is this similar lambda expression idea. Give me an if statement every time please - I'm a human and I need to be able to understand that code! :)
"Rock your java"
*takeWhile* should be named *takeUntil*, but *dropWhile* is ok...
Ternary operator not tertiary.
So basically, learn functional programming to use lambdas correctly.
Misleading title. This is basic stuff
@27m - it makes no difference that you check some state in a ternary operator or do it in a function block as you were doing. There's no leak of state. Yes, it's not functional, but this is why functional programming never found practical roots in commercial programming (only academia) and it will die a death (not soon enough) when the companies using it realize that nobody can maintain the awful functional code written by those "bright sparks" who blaze a trail and never stick around to support their own code.
lol interesting perspective
1. Dont Show the Tutor which is no use.
2. He is chipping his tongue and lips. That sounds annoying