Comments on: Be Lazy with Java 8 https://speedment.com/be-lazy-with-java-8/ Build Fast Java Applications for the Fastest Business Performance Fri, 01 May 2020 05:21:37 +0000 hourly 1 https://wordpress.org/?v=5.1.1 By: Per Minborg https://speedment.com/be-lazy-with-java-8/#comment-85 Sat, 05 Aug 2017 15:38:54 +0000 https://speedment.com/be-lazy-with-java-8/#comment-85 Lazy can now be found at https://github.com/speedment/speedment/tree/master/common-parent/lazy

]]> By: Per Minborg https://speedment.com/be-lazy-with-java-8/#comment-126 Wed, 09 Mar 2016 22:40:47 +0000 https://speedment.com/be-lazy-with-java-8/#comment-126 I have double-checked the Lazy class and it works for me. Make sure you run Java 8 or else it will not work.

]]> By: Anonymous https://speedment.com/be-lazy-with-java-8/#comment-127 Tue, 08 Mar 2016 22:08:25 +0000 https://speedment.com/be-lazy-with-java-8/#comment-127 Am I seeing things or this Lazy class won't compile? Julian

]]> By: Unknown https://speedment.com/be-lazy-with-java-8/#comment-129 Tue, 02 Feb 2016 11:29:31 +0000 https://speedment.com/be-lazy-with-java-8/#comment-129 My last sentence took from the Java Memory Model article, which contradicts yours.

]]> By: Unknown https://speedment.com/be-lazy-with-java-8/#comment-130 Fri, 29 Jan 2016 13:15:41 +0000 https://speedment.com/be-lazy-with-java-8/#comment-130 Good point, one less reason to do it by oneself.

]]> By: JB https://speedment.com/be-lazy-with-java-8/#comment-131 Thu, 28 Jan 2016 19:40:09 +0000 https://speedment.com/be-lazy-with-java-8/#comment-131 getOrCompute is doing a side effect (not referentially transparent). The get method of Guava's Supplier.memoize is referentially transparent.

So this "Lazy" class is significantly harder to reason about.

]]> By: Unknown https://speedment.com/be-lazy-with-java-8/#comment-132 Thu, 28 Jan 2016 15:57:35 +0000 https://speedment.com/be-lazy-with-java-8/#comment-132 I fail to see difference between this example and Guava's Suppliers.memoize() supplier. Thanks for explanation but I wouldn't encourage others to reinvent the wheel 😉

]]> By: Unknown https://speedment.com/be-lazy-with-java-8/#comment-133 Thu, 28 Jan 2016 15:11:20 +0000 https://speedment.com/be-lazy-with-java-8/#comment-133 The "value" holder variable is a reference and so (as you wrote) it's read and written in an atomic way, regardless of the presence of the volatile keyword. This way a thread can see it only as null or as it's definitive (not null) value.

]]> By: Unknown https://speedment.com/be-lazy-with-java-8/#comment-134 Thu, 28 Jan 2016 13:00:35 +0000 https://speedment.com/be-lazy-with-java-8/#comment-134 I don't think so.
The volatile keyword have another property that isn't mentioned here, a write to a volatile field happens-before every subsequent read of that field. For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write.
Writes and reads of volatile long and double values are always atomic. Writes to and reads of references are always atomic, regardless of whether they are implemented as 32-bit or 64-bit values.
Implementations of the Java Virtual Machine are encouraged to avoid splitting 64-bit values where possible. Hence programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.

]]> By: Unknown https://speedment.com/be-lazy-with-java-8/#comment-135 Thu, 28 Jan 2016 12:59:25 +0000 https://speedment.com/be-lazy-with-java-8/#comment-135 This comment has been removed by the author.

]]>