On 10/7/15 2:30 AM, Stephen Colebourne wrote:
Given what we know now vs when the collections library ws created, I
think it would be a mistake to allow nulls. Developers that
desperately want null in there have other mechanisms to achieve that,
not just Optional. I too would argue against Optio
The current guideline seems to be that new collections introduced after Java 4
should not allow null.
ArrayDeque is an example of such collections.
This proposal introduces new static methods on both interfaces and
implementations.
Interface static methods use new immutable collections, if those
On 7 Oct 2015, at 10:30, Stephen Colebourne wrote:
> On 7 October 2015 at 01:13, Stuart Marks wrote:
>> My question is, is this enough of a problem that we should allow nulls in
>> these collections? I would prefer not to do this, but if there is evidence
>> that this would be a mistake, I'd lik
On 7 October 2015 at 01:13, Stuart Marks wrote:
> My question is, is this enough of a problem that we should allow nulls in
> these collections? I would prefer not to do this, but if there is evidence
> that this would be a mistake, I'd like to hear it.
>
> And if disallowing nulls will cause deve
On 10/3/15 7:16 AM, fo...@univ-mlv.fr wrote:
"Kevin Bourrillion" wrote:
We have ~1800 occurrences of Optional-valued Maps or Caches in Google. They
do this for an actual reason: a negative result is meaningfully different
from no result. This is addressed in our Optional javadoc .
mapped-to
Hi Kevin,
i'm glad you ask,
- Mail original -
> De: "Kevin Bourrillion"
> À: "Remi Forax"
> Cc: "Core Libs Dev"
> Envoyé: Vendredi 2 Octobre 2015 18:22:00
> Objet: Re: JEP 269: Convenience Factory Methods for Collections
> Tan
On 9/29/15 11:32 PM, Stephen Colebourne wrote:
In my view, the proposal is pretty good. I too use Guava's immutable
classes as types, because of the extra value obtained. But that does
not mean these methods should not be in the JDK. (Not every project
uses Guava).
Hi Stephen,
Thanks for looki
In my view, the proposal is pretty good. I too use Guava's immutable
classes as types, because of the extra value obtained. But that does
not mean these methods should not be in the JDK. (Not every project
uses Guava).
I'd argue for two changes to the JEP.
Map.fromEntries() -> Map.ofEntries()
In
De: "mark reinhold"
À: "stuart marks"
Cc: core-libs-dev@openjdk.java.net
Envoyé: Jeudi 24 Septembre 2015 02:02:17
Objet: JEP 269: Convenience Factory Methods for Collections
New JEP Candidate: http://openjdk.java.net/jeps/269
- Mark
Hi all, I've been on vacation for a few days. Did anything happen while I was
away? :-)
I see this JEP was posted as a Candidate, and Kevin and Remi had some comments.
I'll reply to Kevin's comments here and to Remi's separately.
Kevin,
I'm glad you don't think the proposal is bad. :-)
I de
Hi Kevin,
- Mail original -
> De: "Kevin Bourrillion"
> À: "Core Libs Dev"
> Envoyé: Vendredi 25 Septembre 2015 17:33:02
> Objet: Re: JEP 269: Convenience Factory Methods for Collections
>
> I don't think the proposal is bad, but for whateve
.entry("bar", 2));
The builder pattern let us to avoid to create intermediary entry objects.
regards,
Rémi
- Mail original -
> De: "mark reinhold"
> À: "stuart marks"
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Jeudi 24 Septembre 2015
New JEP Candidate: http://openjdk.java.net/jeps/269
- Mark
13 matches
Mail list logo
