Java – ny reason lazy initialization couldn’t be built into Java

javalanguage-featureslazy-initializationprogramming-languages

Since I'm working on a server with absolutely no non-persisted state for users, every User-related object we have is rolled out on every request.

Consequently I often find myself doing lazy initialization of properties of objects that may go unused.

protected EventDispatcher dispatcher = new EventDispatcher();

Becomes…

protected EventDispatcher<EventMessage> dispatcher;

public EventDispatcher<EventMessage> getEventDispatcher() {
    if (dispatcher == null) {
        dispatcher = new EventDispatcher<EventMessage>();
    }
    return dispatcher;
}

Is there any reason this couldn't be built into Java?

protected lazy EventDispatcher dispatcher = new EventDispatcher();

As mentioned below in the comments, I realize a language could theoretically evolve to include most anything you want. I'm looking for a practical measurement of possibility. Would this conflict with other features? Is the implementation simple enough to work well with the JVM as it exists? And even, is it a good idea?

Best Answer

Here is an eight page answer to your question: http://tinlizzie.org/~awarth/papers/fool07.pdf

If i can try and coarsely summarize the problems with adding laziness, it's the corner cases. There are a lot of caveats around side-effects. Consider, in your example, if the constructor had visible side-effects like bumping a global counter or doing I/O... It's hard to reason about when that would happen. Or consider even uglier side-effects about exceptions (they're thrown ... when you reference the lazy object?)

Just skip to section 6 in the above paper. (And admire all the type system formal logic on the pages you skip ...)

Removing a field

Even without Lazy<T>, you may shorten the code by removing the redundant variable:

public string BrandAbbreviation { get; set; }

private CommonBrand _brand;

public CommonBrand Brand
{
    get
    {
        if (!this._brand == null)
        {
            this._brand = new CommonBrand(this.BrandAbbreviation);
        }

        return this._brand;
    }
}

Removing _brandPopulated has not only the benefit of removing a few LOCs, but also makes the code clearer. By having a separate field which flags whether _brand is set, you could potentially have situations you don't handle in your code (and which are not obvious to handle right):

_brandPopulated is false, but _brand is initialized to a value. Should we forget about the previous value? Should we keep it?
_brandPopulated is true, but _brand is null. How do you handle that? Do you check for null after checking for _brandPopulated? Or maybe you don't, and risk encountering an ugly NullReferenceException?

Introducing (or not) `Lazy<T>`

You can indeed use Lazy<T>, which makes it possible to make the code even shorter:

public string BrandAbbreviation { get; set; }

private readonly Lazy<CommonBrand> _brand;

public ClassName() // Replace by the name of the actual class.
{
    this._brand = new Lazy<CommonBrand>(() => new CommonBrand(this.BrandAbbreviation));
}

public CommonBrand Brand
{
    get
    {
        return this._brand.Value;
    }
}

Best Answer

Related Solutions

Else If Clause – Specific Reasons to Use It in Programming

C# – n easier way to do this with Lazy

Removing a field

Introducing (or not) Lazy<T>

Related Topic

Introducing (or not) `Lazy<T>`