4 ms·

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 .

• _delirium 17y ago
  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/001193.html http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/0...
  • abalashov 17y ago
    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.
    • extension 17y ago
      Because it solves the problem mentioned above i.e. the compiler's choice of which type of container to create becomes straightforward.
      • sesqu 17y ago
        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).
  • mhansen 17y ago
    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.
    • _delirium 17y ago
      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 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.
• vlisivka 17y ago
  Why you worry?
• kentosi 17y ago
  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 ...
  • noss 17y ago
    List<String> list = new LinkedList<>(["ham","eggs"]);