Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

e- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] 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 10:26 PM, Stuart Mark

RE: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

s the rationale for the value based spec for the empty >>> implementations? >>> >>> Thanks >>> Moh >>> >>>> -Original Message- >>>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] >>&g

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Hi Stuart, - Mail original - > De: "Stuart Marks" <stuart.ma...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Mercredi 25 Novembre 2015 01:07:16 > Obj

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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:

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

mailto:core-libs-dev-boun...@openjdk.java.net] 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 10:26 PM, Stuart Marks <stuart.ma...@oracle.c

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

RE: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

2015 1:26 AM >To: core-libs-dev >Subject: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232) > >Hi all, > >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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Consider: http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#newHashMapWithExpectedSize(int)

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

e: "Stuart Marks" <stuart.ma...@oracle.com> > À: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Mardi 24 Novembre 2015 07:26:27 > Objet: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232) > > Hi all, > > Please revie

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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:

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

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 *)

RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Hi all, 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. Changes since the previous review: - more precise wording regarding static factory