Hi,

On 11/15/2017 12:18 PM, Vitaly Davidovich wrote:
On Wed, Nov 15, 2017 at 5:21 AM Andrej Golovnin <andrej.golov...@gmail.com>
wrote:

On 15/11/17 10:03, Andrej Golovnin wrote:
I think we would need to write ugly code in any case as Java 9 has now
two empty list implementations: Collections.emptyList() and List.of().

Collections.emptyList().sort() does not throw an exception.

List.of().sort() throws an exception.
Well, that's a bug.  Sorting an empty list is perfectly valid, and
application
programmers shouldn't have to special-case it.
I don't think so. I would say that the implementation of
Collections.emptyList() is broken. Collections.emptyList() and
List.of() are not only empty lists. They are also immutable per
specification.

Here is another example of an unsortable empty list:

Collections.unmodifiableList(Collections.emptyList()).sort() throws an
exception.
One can argue that since those are empty by construction/design, sorting
them is not a bug.  That’s different from, say, trying to sort an
unmodifiable list that happens to be empty and not failing in that case.

 From a user’s perspective, I agree it’s annoying to have to special case
these.  This is particularly so because immutability is not expressed in
the types or type system.

There are 3 kinds of List(s) in JDK according to which optional methods are supported and which throw UOE:

A - normal mutable lists (ala ArrayList)
B - immutable/unmodifiable lists (ala Collections.unmodifiableList(...), List.of(...))
C - structurally unmodifiable mutable lists (ala Arrays.asList(...))

What is Collections.emptyList()? In terms of the original (as of jdk 1.2 API), it can be either B or C. Additional (default) List methods added later may blur this distinction, but they can only do that "artificially".

Suppose that you have and API where you want to return List(s) of type C to the user, so that user may choose to consume them as-is or sort them 1st in-place. What list would you return when you have 0 elements to return? Would you return Collections.emptyList() and instruct the user that he may not blindly sort any given List he gets, but only those that are not empty? Would you rather return Arrays.asList() and create new object every time? Why can't I have both?

Well, I can have both:

    private static final List<T> EMPTY_LIST = Arrays.asList();

    ...
    return EMPTY_LIST;
}


But this is complicated and has to be done over and over again. It's like the story of empty array(s) that have to be declared as a private static final field in each and every class which wants to optimize empty returns.

Not to mention that changing Collections.emptyList().sort() to throw UOE is an incompatible change. Programs may already use emptyList() as kind C list and depend on it. So why would not Collections.emptyList() be simply declared to be of kind C and that's it. No code to change and no code to break. If one wants to get an empty list of type B, he should use List.of().

Regards, Peter



--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 C
<https://maps.google.com/?q=EF+DB98+C&entry=gmail&source=g>C77 2FAD A5CD
6035 332F A671


Reply via email to