Hacker News Reader

Comment by lenni | Hacker News Reader

I'm wondering how the implementation is chosen when you do something like

  List<String> list = ["ham","eggs"];

Is it a linked list, an array list, a vector ... ?

View on HN

The compiler chooses, probably based on the type and number of elements. In theory it should know how to do this efficiently, because this syntax returns only immutable collections, so the compiler knows up front exactly what the collection will ever contain.

This is what the proposal says about that decision:

  It is likely to be higher in space and time performance, in that the
  compiler can choose efficient implementations for small collections
  (such as empty collections and singletons).  On the other hand, it is
  less flexible, in that you cannot specify the implementation type.

From: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/0...

Why does it only return immutable collections? Because the spec says so, or because there is some principle suggesting that it should?

Personally, my first instinct was to read the syntax as a form of initialisation, not something that would bar me from adding or deleting elements after the set is instantiated.

Because it solves the problem mentioned above i.e. the compiler's choice of which type of container to create becomes straightforward.

If the choice would be a mutable one, making it expressly immutable after the fact serves no purpose. As it is, the compiler gets to choose an efficient list for the data provided, and then refuse to compromise on that efficiency later. You might as well use an enum. What useful collection implementation would require immutability? Even arrays are more flexible.

Sure, it's nice syntax, but I can come up with more scenarios where I'll want to initialize a collection than scenarios where I want to finalize one (well, excepting for the fact that this is java, where immutability is often considered a virtue).

How does this maintain the List interface, which defines methods for mutating the collection through methods such as add() and remove()?

If I get a variable of type List, I expect to be able to change the list.

The List interface labels all the methods that could change a list as "optional operation", which implementing classes are free to throw an UnsupportedOperationException for: http://java.sun.com/javase/6/docs/api/java/util/List.html

The current API already uses this in a bunch of places to return immutable Lists. For example, the lists you get out of Collections.singletonList() or Collections.nCopies() are immutable.

That's a bit broken from an OO perspective (is the interface an interface or not?), but it's a better solution than the const v. non-const container mess that C++/STL has, at least.

Good point. I see this as a good mechenism for allowing immutable lists (in which case it probably doesn't matter). But for mutable ones, you would probably want control over the datastructure.

The only way of allowing the programmer to do this, that I can think of for now, is by casting perhaps?

List<String> list = (LinkedList)["ham","eggs"];

Just an idea ...

List<String> list = new LinkedList<>(["ham","eggs"]);

Why you worry?

Reply on news.ycombinator.com