Another Look at Java 8 Lazy Instantiation

First Things First

First off, I’d like to open this article by letting you all know that, as of Sept 9, 2014, I am a certified Java programmer. I passed the level 1 Java SE 7 certification. Pretty soon, I’ll start studying up for the level 2 test, which I’ll probably take early next summer. What this means for all of you is this: I supposedly know what I’m talking, so you should definitely listen to everything I say

Yeah, level 1 isn’t that big of a deal. It mostly just means I know how the language works; it doesn’t mean I’m actually any good at programming with it.

Also, I just wanted to let you all know that I hope to make this blog do a post every week, on Saturdays. Time will tell whether I can keep up that pace, since I work full-time and do 1 or 2 posts in a gaming blog each week already, too. If you’re interesting in tabletop RPGs, you should check it out.

Recap

In an earlier post, I provided a utility (which is also available in my functional-java library on github) which was based on the one described in Venkat Subramaniam’s book, Functional Programming in Java. My version made a change that made the code much simpler, but at the expense of speed, since it kept the block synchronized.

I’ve decided to follow in Venkat’s steps a little more, since I figured out I could keep more of the spirit of his code while still making it a little easier to read.

So, to recap, here’s the code I showed you last time:

Old version

public class LazilyInstantiate implements Supplier
{
   public static  LazilyInstantiate using(Supplier supplier)
   {
      return new LazilyInstantiate(supplier);
   }
      
   public synchronized T get()
   {
      return current.get();
   }
      
   private LazilyInstantiate(Supplier supplier)
   {
      this.supplier = supplier;
      this.current = () -> swapper();
   }
      
   private final Supplier supplier;
   private Supplier current;
      
   private T swapper()
   {
      T obj = supplier.get();
      current = () -> obj;
      return obj;
   }
}

And look at the swapper() method compared to how Venkat’s would have been if he had built this utility:

Venkat’s version

private synchronized T swapper()
{
   class Factory implements Supplier
   {
      private final T instance = supplier.get();
 
      public T get()
      {
         return instance;
      }
   }
   
   if(!Factory.class.isInstance(current))
   {
      current = new Factory();
   }
 
   return current.get();
}

This code is all well and good, but, especially with the inline class definition, I have a difficult time wrapping my head around it. So, I’m going to make a small change to my utility to include a modified version of Venkat’s code.

Updated utility

...
 
   public T get() //No longer synchronized
 
...
 
   private synchronized T swapper()
   {
      if(!Factory.class.isInstance(current))
      {
         T obj = supplier.get();
         current = new Factory(obj);
      }
      return current.get();
   }
}
 
class Factory implements Supplier
{
   public T get()
   {
      return obj;
   }
 
   Factory(T obj)
   {
      this.obj = obj;
   }
 
   private T obj;
}

As you can see, I removed synchronization from the utility’s get() method, but I moved it to swapper(). Swapper is temporary, so that’s not a problem.

The big difference between my code and Venkat’s is that I pulled the Factory class out. Also, I used a constructor to pass in the value, rather than having the Factory do it itself. I could have done it the other way, but I felt that it lost a little bit of its clarity that way. Also, swapper() still shows the steps that are being taken as they were listed in my last article.

Anyway, that’s the new utility! I’ll be releasing the change in my github library very soon. Or you can just copy and paste and use it yourself; I don’t mind.