Instantiating and populating a list or collection

In Java it always irks me when I have to create a collection and then populate it in separate steps as follows:

List states = new ArrayList();

Then today I read about using an anonymous subclass with instance initializer to initialize a collection which appeals to the block loving Rubyist in me:

List states = new ArrayList() {{ add(State.CA); add(State.WY); }};

Another approach shown to me by a new co-worker specific to Lists (that involves creating an extra array) but is also quite short is:

List states = Arrays.asList(new State[]{State.CA, State.WY});

Update: Ricky Clarkson pointed out the best solution so far in my opinion (requires JDK 5 or higher) using varargs and generics:

List<String> list=Arrays.asList("rocks","my","world");
This entry was posted in Java, Ruby, Software Engineering. Bookmark the permalink.

12 Responses to Instantiating and populating a list or collection

  1. afsina says:

    Java is about code reuse and modularity. Usually this kind of initializations are not needed in real code. it is rather used in tests. so best way is to prepare some simple helpers (maybe in test base class or as a static method) using varargs such as :

    public List makeAList(T… elements) {
    return Arrays.asList(elements);

    public Set makeHSet(T… elements) {
    return new HashSet(makeAList(elements));

    then call:

    List l = makeList(State.CA, State.NY, State.WY)

    i dont know but it seems pretty neat and clear to me.

  2. afsina says:

    sorry it was suppose ot be :

    List l = makeAList(State.CA, State.NY, State.WY)

  3. afsina says:

    oh by the way, blog ate my (greater, smaller) symbols..

  4. Todd Huss says:

    afsina, I disagree that those types of initializations are not needed in real code, tests are real code. If you’re creating a helper method just to create a simple data structure like an array more elegantly, then I’d say the language is coming up short on that front whether it’s in a test or production code and let’s face it, it’s just lame that Java won’t let us construct a collection with its contents!

  5. Pingback: Daniel Schneller's Weblog

  6. afsina says:

    i did not say tests are not real code, however, it is easy to introduce those methods in a test base class, which is cleaner then the solutions you offered.

    i dont think there is a shortcoming of Java on this. This is the Java way, if writing a two line method will give you more or less the same result, it is better then introducing a new syntax to the language.

  7. afsina says:

    actually, i saw that i did wirte “real code” my intention was to say “real business logic” pardon my english 😛

  8. [] for generics, as there’s no preview button:

    I wonder what’s wrong with List[String] list=asList(“rocks”,”my”,”world”);

  9. afsina says:

    Ricky, you got me there.. i totally forget that. should be Arrays.asList(…) tough. maybe using static import, the way you write is fine..

  10. Yes, using a static import it’s fine. I half-meant Arrays.asList, but which asList you use isn’t so important to the meaning of my post. Arrays.asList returns a read-only list, so you might prefer to write your own asList implementation.

    It’s odd that after three years or so of static imports people still look at them oddly. Blog posters don’t expect me to qualify the package part, but they do expect the class part. 😉

    Sorry for the diversion, but I think static methods really belong outside classes; they’re not OO, so they shouldn’t look like they are. Not that being non-OO is a problem, mind..

    import static java.util.asList; //would suit me.

  11. Pingback: Java Tips: Initializing Collection « satukubik

  12. Pingback: Martial Java / Initializing Collection

Leave a Reply

Your email address will not be published. Required fields are marked *