optimization), but that's the less likely case.
>>>
>>> What's the rationale for the value based spec for the empty
>>> implementations?
>>>
>>> Thanks
>>> Moh
>>>
>>>> -Original Message-
>>>> From:
ions?
Thanks
Moh
-Original Message-
From: core-libs-dev [mailto:[email protected]]
On Behalf
Of John Rose
Sent: Tuesday, November 24, 2015 9:08 PM
To: Stuart Marks
Cc: core-libs-dev
Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation
(JDK-
813923
Hi Stuart,
- Mail original -
> De: "Stuart Marks"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Mercredi 25 Novembre 2015 01:07:16
> Objet: Re: RFR(m): JEP 269 initial API and skeleton implementation
> (JDK-8139232)
>
> On 11
On 11/25/15 1:02 PM, Roger Riggs wrote:
Set.java:
- of methods: @throws IAE "if the elements are duplicates" -> "if elements
*contains *duplicates"
That specific wording comes from the two-arg overload, so it's shorthand for "if
the (two) elements are duplicates (of each other)". The ov
-Original Message-
From: core-libs-dev [mailto:[email protected]] On Behalf
Of John Rose
Sent: Tuesday, November 24, 2015 9:08 PM
To: Stuart Marks
Cc: core-libs-dev
Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-
8139232)
On Nov 23, 2015, at
On 11/25/15 8:25 AM, Paul Benedict wrote:
Chris, you raise a good question. Example: JPA entities stored in an immutable
list and the list belongs to a stateful EJB that gets passivated or clustered.
Obviously, serialization would be occuring.
On Wed, Nov 25, 2015 at 10:14 AM, Chris Hegarty mail
On 24 Nov 2015, at 23:27, Stuart Marks wrote:
> ….
>
> But in the hypothetical value-typed future, we might want to return value
> types from at least some of the factory methods. Value types have no notion
> of identity, so we don't want to make any statements that lead to thinking
> about th
Hi Stuart,
Comments:
Set.java:
- of methods: @throws IAE "if the elements are duplicates" -> "if
elements *contains *duplicates"
- in the of() methods, would it be more efficient to add the
individual object to the hashset w/o
the intermediate list; don't create garbage that needs t
Chris, you raise a good question. Example: JPA entities stored in an
immutable list and the list belongs to a stateful EJB that gets passivated
or clustered. Obviously, serialization would be occuring.
Cheers,
Paul
On Wed, Nov 25, 2015 at 10:14 AM, Chris Hegarty
wrote:
> On 24 Nov 2015, at 23:2
ionale for the value based spec for the empty implementations?
Thanks
Moh
>-Original Message-
>From: core-libs-dev [mailto:[email protected]] On Behalf
>Of John Rose
>Sent: Tuesday, November 24, 2015 9:08 PM
>To: Stuart Marks
>Cc: core-libs-dev
&
On Nov 23, 2015, at 10:26 PM, Stuart Marks wrote:
>
> Please review these API and implementation changes that comprise the first
> integration of JEP 269. I intend to push this under the "initial API and
> skeleton implementation" subtask, JDK-8139232.
Please strengthen the specification to as
On 11/24/15 7:03 AM, Remi Forax wrote:
The other way to detect collision instead of checking the size if to use the
return value of put, it should be null if it's a new key,
but the code is maybe less readable.
Yes. This is just a "skeleton" implementation, so I'm not terribly interested in
m
On 11/24/15 8:06 AM, Paul Benedict wrote:
*) List.of() says it returns "the newly created list" but it actually returns
the same empty list regardless. I don't think you want to imply a new list is
actually constructed for each call.
*) Map.of() same comment as above
*) Set.of() same comment as
On 11/24/15 8:55 AM, Peter Levart wrote:
Hi Stuart,
Since those factory methods construct general purpose immutable collections, I
miss methods that act as copy constructors (general purpose collection
implementations should have them, says recommendation):
public static List copyOf(Collect
On Nov 24, 2015, at 3:27 PM, Stuart Marks wrote:
>
> But in the hypothetical value-typed future, we might want to return value
> types from at least some of the factory methods. Value types have no notion
> of identity, so we don't want to make any statements that lead to thinking
> about the
On 11/24/15 3:17 AM, Chris Hegarty wrote:
This is looking very good, and simple. Nice.
Great, thanks.
Sorry if this has come up already, but is the "@return the newly
created xxx” too restrictive? Will it require the implementation to
return a NEW instance of xxx for each invocation, even o
On 11/24/15 3:30 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151123/overview-summary.html
Why do EnumSet.of(...) javadocs get this additional line:
Specified by:
of in interface Set>
Since static interface methods are not inheritable, their spe
Consider:
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#newHashMapWithExpectedSize(int)
On 11/24/15 4:21 AM, Aleksey Shipilev wrote:
On 11/24/2015 09:26 AM, Stuart Marks wrote:
Webrev:
http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151123/
* It is mildly puzzling why the HashMap initial capacity is different
from the number of elements you are about to push
Can the Javadoc for of() (no args) be enhanced to spell out the cost/garbage
semantics? Collections.emptyList() does a great job of that:
* @implNote
* Implementations of this method need not create a separate List
* object for each call. Using this method is likely to have compa
Hi Stuart,
Since those factory methods construct general purpose immutable
collections, I miss methods that act as copy constructors (general
purpose collection implementations should have them, says recommendation):
public static List copyOf(Collection collection);
public static Set copy
My comments:
*) List.of() says it returns "the newly created list" but it actually
returns the same empty list regardless. I don't think you want to imply a
new list is actually constructed for each call.
*) Map.of() same comment as above
*) Set.of() same comment as above
*) Map.of(1/2/3/4/5/6/7/8
Hi Stuart,
The other way to detect collision instead of checking the size if to use the
return value of put, it should be null if it's a new key,
but the code is maybe less readable.
There are several instance of
@SafeVarargs
@SuppressWarnings("varargs")
if you use @SafeVarargs you should
Hi Stuart,
On 11/24/2015 09:26 AM, Stuart Marks wrote:
> Webrev:
>
> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151123/
* It is mildly puzzling why the HashMap initial capacity is different
from the number of elements you are about to push -- need to spell out
that we are ad
Hi Stuart,
API spec (basically List, Map, and Set):
http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151123/
Specdiff:
http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151123/overview-summary.html
Why do EnumSet.of(...) javadocs get this additional line:
Spec
Stuart,
This is looking very good, and simple. Nice.
Sorry if this has come up already, but is the "@return the newly
created xxx” too restrictive? Will it require the implementation to
return a NEW instance of xxx for each invocation, even of() ?
-Chris.
On 24 Nov 2015, at 06:26, Stuart Marks
26 matches
Mail list logo
