<div dir="ltr">One of the meanings is debug. <div><br></div><div>Now it is even difficult to detect whether a list has these features through assertions.</div><div>We want to see exceptions, but when we actually call unsupported methods, the wrong object </div><div>may have been propagated to other methods or even threads, so that we can't see the problematic method on the stack frame.<br></div><div><br></div><div>Secondly, understanding the characteristics of the collection can help us optimize.<br></div><div>Although "Premature Optimization Is the Root of All Evil", stupid defensive replication is everywhere and is not what I want to see.<br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">RandomAccess you can check by instanceof java.util.RandomAccess<br></blockquote><div><br></div><div>I think that using interfaces to express the characteristics of collection support is an ancient design left over for historical reasons, right?</div></div><div><br></div><div>Is there any difference between the operations supported by Collections.UnmodifiableList and Collections.UnmodifiableRandomAccessList?</div><div>If we use a method to express these characteristics, we just need to delegate the method to the original collection.<br></div><div>However, because RandomAccess is an interface, we have to create two classes, even if they are not different.<br></div><div><br></div><div>It also eliminates the possibility of creating other similar interfaces, because the number of collection wrappers will grow exponentially.<br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And if you are going to support this for Collection, people also want this for<br>queues, map, sets, etc. Further complicating a Collection API that is already<br>complex enough.<br></blockquote><div><br></div><div>Shouldn't they be supported? </div><div><br></div><div>I don't think the Java collection framework is complex enough, nor do I think adding such a method will significantly increase complexity.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 30, 2023 at 6:23 PM Kasper Nielsen <<a href="mailto:kasperni@gmail.com">kasperni@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 30 Jan 2023 at 09:11, Glavo <<a href="mailto:zjx001202@gmail.com" target="_blank">zjx001202@gmail.com</a>> wrote:<br>
> 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:<br>
><br>
> public record CollectionFeature(String name) {<br>
>     public enum Status {<br>
>         SUPPORTED, UNSUPPORTED, UNKNOWN<br>
>     }<br>
> }<br>
><br>
> public interface Collection<E> extends Iterable<E> {<br>
>     CollectionFeature ADD_ELEMENT = new CollectionFeature("ADD_ELEMENT");<br>
><br>
>     // ...<br>
><br>
>     default CollectionFeature.Status supports(CollectionFeature feature) {<br>
>         return UNKNOWN;<br>
>     }<br>
> }<br>
><br>
> public interface List<E> extends Collection<E> {<br>
>     CollectionFeature RANDOM_ACCESS = new CollectionFeature("RANDOM_ACCESS");<br>
>     CollectionFeature UPDATE_ELEMENT = new CollectionFeature("UPDATE_ELEMENT");<br>
><br>
>     // ...<br>
><br>
>     @Override<br>
>     default CollectionFeature.Status supports(CollectionFeature feature) {<br>
>         if (feature == RANDOM_ACCESS)<br>
>             return this instanceof RandomAccess ? SUPPORTED : UNSUPPORTED;<br>
>         else<br>
>             return UNKNOWN;<br>
>     }<br>
> }<br>
><br>
><br>
> Is there anything preventing us from doing this?<br>
<br>
Not anything other than this is a solution looking for a problem.<br>
<br>
What are you going to do with this information at runtime? Not insert the<br>
element in a collection if it doesn't support Update? In 99% of all cases,<br>
this is a failure scenario, and you will want to throw an exception. Which<br>
Collection#add() will do for you by throwing an<br>
UnsupportedOperationException.<br>
<br>
RandomAccess you can check by instanceof java.util.RandomAccess<br>
<br>
And best you could use such a feature for debugging. Instead, just print out<br>
the class name and go read the Javadocs for the class.<br>
<br>
And if you are going to support this for Collection, people also want this for<br>
queues, map, sets, etc. Further complicating a Collection API that is already<br>
complex enough.<br>
<br>
/Kasper<br>
</blockquote></div>