NPE throwing behavior of immutable collections

[Glavo]

One of the meanings is debug.

Now it is even difficult to detect whether a list has these features
through assertions.
We want to see exceptions, but when we actually call unsupported methods,
the wrong object
may have been propagated to other methods or even threads, so that we can't
see the problematic method on the stack frame.

Secondly, understanding the characteristics of the collection can help us
optimize.
Although "Premature Optimization Is the Root of All Evil", stupid defensive
replication is everywhere and is not what I want to see.

RandomAccess you can check by instanceof java.util.RandomAccess
>

I think that using interfaces to express the characteristics of collection
support is an ancient design left over for historical reasons, right?

Is there any difference between the operations supported by
Collections.UnmodifiableList and Collections.UnmodifiableRandomAccessList?
If we use a method to express these characteristics, we just need to
delegate the method to the original collection.
However, because RandomAccess is an interface, we have to create two
classes, even if they are not different.

It also eliminates the possibility of creating other similar interfaces,
because the number of collection wrappers will grow exponentially.
Expose more characteristics (e.g., whether to support efficient insertion
into the head) to help optimize the collection util methods in the
third-party library.

And if you are going to support this for Collection, people also want this
> for
> queues, map, sets, etc. Further complicating a Collection API that is
> already
> complex enough.
>

Shouldn't they be supported?

I don't think the Java collection framework is complex enough, nor do I
think adding such a method will significantly increase complexity.

On Mon, Jan 30, 2023 at 6:23 PM Kasper Nielsen <kasperni at gmail.com> wrote:

> On Mon, 30 Jan 2023 at 09:11, Glavo <zjx001202 at gmail.com> wrote:
> > Now that we have the interface default method, can we add a new method
> to the Collection to obtain the support status of the feature, like this:
> >
> > public record CollectionFeature(String name) {
> >     public enum Status {
> >         SUPPORTED, UNSUPPORTED, UNKNOWN
> >     }
> > }
> >
> > public interface Collection<E> extends Iterable<E> {
> >     CollectionFeature ADD_ELEMENT = new CollectionFeature("ADD_ELEMENT");
> >
> >     // ...
> >
> >     default CollectionFeature.Status supports(CollectionFeature feature)
> {
> >         return UNKNOWN;
> >     }
> > }
> >
> > public interface List<E> extends Collection<E> {
> >     CollectionFeature RANDOM_ACCESS = new
> CollectionFeature("RANDOM_ACCESS");
> >     CollectionFeature UPDATE_ELEMENT = new
> CollectionFeature("UPDATE_ELEMENT");
> >
> >     // ...
> >
> >     @Override
> >     default CollectionFeature.Status supports(CollectionFeature feature)
> {
> >         if (feature == RANDOM_ACCESS)
> >             return this instanceof RandomAccess ? SUPPORTED :
> UNSUPPORTED;
> >         else
> >             return UNKNOWN;
> >     }
> > }
> >
> >
> > Is there anything preventing us from doing this?
>
> Not anything other than this is a solution looking for a problem.
>
> What are you going to do with this information at runtime? Not insert the
> element in a collection if it doesn't support Update? In 99% of all cases,
> this is a failure scenario, and you will want to throw an exception. Which
> Collection#add() will do for you by throwing an
> UnsupportedOperationException.
>
> RandomAccess you can check by instanceof java.util.RandomAccess
>
> And best you could use such a feature for debugging. Instead, just print
> out
> the class name and go read the Javadocs for the class.
>
> And if you are going to support this for Collection, people also want this
> for
> queues, map, sets, etc. Further complicating a Collection API that is
> already
> complex enough.
>
> /Kasper
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230130/eb7bd629/attachment-0001.htm>