> From: "Glavo"
> To: "Stuart Marks"
> Cc: "John Hendrikx" , "core-libs-dev"
>
> Sent: Tuesday, January 31, 2023 10:12:24 PM
> Subject: Re: NPE throwing behavior of immutable collections
> I understand that null is prohibited by def
I understand that null is prohibited by default, but can we also provide a
set of factory methods that accept null?
They can be named like List.ofNullable/copyOfNullable.
On Tue, Jan 31, 2023 at 10:13 AM Stuart Marks
wrote:
> In this reply I'll focus on the null handling issues in collections.
>
Hello!
I agree that collection factories should not throw on contains(null).
This issue actually reduces their
adoption. Imagine that I always returned from some method
Collections.unmodifiableSet(new HashSet<>(Arrays.asList(non, null, values)));
It's a verbose construct that creates inefficient d
In this reply I'll focus on the null handling issues in collections.
As you've noted, there are really (at least) two distinct issues here: whether a
collection permits nulls, and the behavior of contains(null) queries. There have
been continual complaints about both, and the issues are somewha
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 prob
On Mon, 30 Jan 2023 at 09:11, Glavo 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, UNSUPP
Thank you for your reply, which explains why there are so few interfaces in
the collection framework.
But I think it still doesn't answer my question: Why doesn't it provide a
means to judge the features supported by the collection?
Now that we have the interface default method, can we add a new m
On 30/01/2023 3:37 am, Glavo wrote:
I quite agree with you. I think the collection framework is in a very
puzzling state.
The hostility of the new collection factory method introduced by Java 9
to null has brought us trouble.
I can understand that this is to expect users to explicitly decla
I quite agree with you. I think the collection framework is in a very
puzzling state.
The hostility of the new collection factory method introduced by Java 9 to
null has brought us trouble.
I can understand that this is to expect users to explicitly declare that
the elements of the list cannot be
I tend to agree.
Presumably it is similar reasoning that led to Collection.contains() to take
Object rather than E.
> On Jan 29, 2023, at 7:28 AM, John Hendrikx wrote:
>
> TLDR; why does contains(null) not just return false for collections that
> don't allow nulls. Just because the interface
TLDR; why does contains(null) not just return false for collections that
don't allow nulls. Just because the interface allows it, does not mean
it should do it as it devalues the usefulness of the abstraction
provided by the interface.
Background:
I'm someone that likes to check correctness o
11 matches
Mail list logo
