File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes final Vs lazy initialization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "final Vs lazy initialization" Watch "final Vs lazy initialization" New topic

final Vs lazy initialization

Srikanth Basa
Ranch Hand

Joined: Jun 06, 2005
Posts: 241
Which one of the following is the better option from the performance point of view

Option 1

Option 2

Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Well, option 1 creates an unnecessary ArrayList object when you call the second constructor. In most cases that won't make much of a difference, but still - I don't like it, if only from an esthetical point of view.

But what I would actually use is

Option 3

BTW, neither option 2 nor option 3 have anything to do with lazy initialization. That would be option 4:

In most cases that is total overkill.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
I think there's a more subtle issue which is quite possibly far more significant. All the code so far is accepting a List argument, exact type unknown, and then using that same List for... something. We don't know. What operations are going to be performed on it? None are shown. I would have to guess that add() is one, because otherwise, what possible use would there be for creating an instance with an empty list? So, you want to add() at least - but how do you know that the List you've been passed even supports add()? It's an optional method, after all. Maybe the user used Arrasy.asList(), or Collections.unmodifiableList(), to create a List that you can't add to. Oops.

Alternately, what if they passed you a LinkedList, and you need to use get(int) frequently? (LinkedList's get(int) gives very poor performance if the list is large.) Or what if they gave you an ArrayList, and you need to insert or remove many things at the beginning of the list? (Here, ArrayList is very poor, but LinkedList works well.)

So I'd say it's a potentially serious problem if this class is accepting an unknown list and simply using it. Maybe you know for sure what kind of List is being passed in - or think you do. But another programmer may try to do something different with the code tomorrow. Or you may, a few weeks later when you don't remember all the details of this class.

I think a better solution overall is to create a List of your own - for now, assume ArrayList is indeed the best option - and copy the content of any other list into the ArrayList:

This is actually a little slower than the other options, initially, as it spends a little extra time to copy content from one List to another. But this effect is still probably minor - and the advantage is, now you know what kind off List you have inside your class, and it supports all the opional methods you may need (like add()). And if you need to change the type later, you can, because it's defined here inside this class, not outside in client code somewhere.

"I'm not back." - Bill Harding, Twister
I agree. Here's the link:
subject: final Vs lazy initialization
It's not a secret anymore!