Idea how to implement VT/VO compatibility in JVM

Thomas W twhitmore.nz at gmail.com
Sun Feb 1 06:12:10 UTC 2015


Hi Peter,

> There could also be an abbreviation:
> void m3(Collection<any ?> c) { ... }
>
> ...equivalent to m2 above, but used
> only if you don't need T in the
> method

Yes, it would be extremely desirable to be able to generically deal with
collections -- specialized or not -- including iterating them via 'Object'.

I proposed previously that we provide reftype-compatible bridge methods,
and have specialized collections "assignment compatible" to Collection<?>
via this boxed API.

I don't see either why 'remove()' -- or, from a compatible other
collection, 'add(T item)' should not be possible.

T obviously cannot be concretely implemented, but we already have the
concept of erasure -- T essentially erases to a boxed object.

We should also be able to use equals(), hashCode() and toString() on an
'any T'.

Regards,
Thomas
On 29 Jan 2015 19:55, <valhalla-dev-request at openjdk.java.net> wrote:

> Send valhalla-dev mailing list submissions to
>         valhalla-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.openjdk.java.net/mailman/listinfo/valhalla-dev
> or, via email, send a message with subject or body 'help' to
>         valhalla-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
>         valhalla-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of valhalla-dev digest..."
>
>
> Today's Topics:
>
>    1. What's the status of / relation between "JEP 169: Value
>       Objects" /        "Value Types for Java" / "Object Layout" (Volker
> Simonis)
>    2. Re: Idea how to implement VT/VO compatibility in JVM
>       (Peter Levart)
>    3. Re: Idea how to implement VT/VO compatibility in JVM
>       (Vitaly Davidovich)
>    4. Re: Idea how to implement VT/VO compatibility in JVM
>       (Peter Levart)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 28 Jan 2015 21:40:49 +0100
> From: Volker Simonis <volker.simonis at gmail.com>
> To: Da Vinci Machine Project <mlvm-dev at openjdk.java.net>,
>         valhalla-dev at openjdk.java.net
> Subject: What's the status of / relation between "JEP 169: Value
>         Objects" /      "Value Types for Java" / "Object Layout"
> Message-ID:
>         <
> CA+3eh122g3Ax+-PCL3EvX3V-cQkorva2j_c42_i4uRLOqw42Fg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi everybody,
>
> I've recently did some research on Java "value objects" / "value
> types" / "object layout" (I'll be actually giving a short talk on the
> topic at FOSDEM[0] this weekend). I just want to quickly summarize my
> current findings here and gently ask for feedback in case you think
> I've totally misunderstood something. Of course any comments and
> additional information is highly welcome as well.
>
> 1. JEP 169: Value Objects [1]
>  - Created by John Rose in 2012 (last update in Sep. 2014)
>  - Still in "Draft" state
>  - Proposes a new "lockPermanently()" operator which marks objects as
> immutable
>  - Seems to be only a little "helper functionality" to simplify
> automatic boxing/unboxing and escape analysis
>  - Referenced the mlwm mailing list and repository but the mlwm repo
> seems dead since about 15 month now
>
> Question: is JEP 169 still under active development or has it been
> merged into the more general "Value types for Java" proposal below?
>
> 2. "Value types for Java" / "State of the Values" [2]
>  - By J. Rose, B. Goetz and Guy Stele
>  - Based on earlier ideas from "Value Types in the VM" [3]
>  - Newest and most elaborate proposal
>  - Proposes general (i.e. function arguments, return values,
> variables, arrays), "immutable" value types
>  - Requires fundamental changes to the VM as well as to the Java language
>  - Related to the "State of the Specialization" proposal [4] about
> support for generics over primitive and value types by B Goetz.
>  - Discussed and developed in the OpenJDK "Valhalla" [5] project
>  - Still very early stage (i.e. no "code" available yet)
>
> 3. PackedObjects as provided by the IBM J9 [6,7]
>  - Flattens the memory layout of "@Packed" object fields and array
>  - Removes object headers of and references to "@Packed" objects
>  - Object headers can be generated on the fly (kind of "auto-boxing")
>  - Currently the most complete and mature solution
>  - Not Java-compatible (e.g. can not write to a nested "@Packed"
> fields). Must be enabled as an experimental extension.
>
> 4. ObjectLayout [8]
>  - A pure Java, layout-optimized data structure package
>  - Designed similar to "@ValueSafe"/"ValueType" in [3] and "Value-base
> classes" in Java 8 [9]
>  - Designed such that it can be tranparently optimized within the VM
>  - VM can transparently layout "@Intrinsic" objects within other objects
>  - All objects are still complete Java object with valid header
>  - The Java part of the library is mature, first native
> VM-optimizations on the way [10]
>
> The "Value types for Java" approach clearly seems to be the most
> general but also the most complex proposal. It's out of scope for Java
> 9 and still questionable for Java 10 and above. The "PackedObject" and
> "ObjectLayout" approaches are clearly simpler and more limited in
> scope as they only concentrate on better object layout. However the
> "ObjectLayout" proposal demonstrates that this is still possible
> within the current Java specification while the "PackedObjects"
> proposal demonstrated that an optimizing implementation is feasible.
> I've recently built a prototype which intrinsifies/optimizes some
> parts of the "ObjectLayout" proposal in the HotSpot [10].
>
> Question: is there a chance to get a some sort of Java-only but
> transparently optimizable structure package like "ObjectLayout" into
> Java early (i.e. Java 9)?
>
> In my eyes this wouldn't contradict with a more general solution like
> the one proposed in the "Value types for Java" approach while still
> offering quite significant performance improvements for quite a big
> range of problems. And if carefully designed, it could be easily
> retrofitted to use the new, general "Value Types" once they are
> available.
>
> Question: what would be the right place to propose something like the
> "ObjectLayout" library for Java 9/10? Would that fit within the
> umbrella of the Valhalla project or would it be done within its own
> project / under it's own JEP?
>
> Thanks for your patience,
> Volker
>
>
> [0] https://fosdem.org/2015/schedule/event/packed_objects/
> [1] http://openjdk.java.net/jeps/169
> [2] http://cr.openjdk.java.net/~jrose/values/values-0.html
> [3] https://blogs.oracle.com/jrose/entry/value_types_in_the_vm
> [4] http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html
> [5] http://openjdk.java.net/projects/valhalla
> [6]
> http://www.slideshare.net/rsciampacone/javaone-2013-introduction-to-packedobjects?related=1
> [7] http://medianetwork.oracle.com/video/player/2623645005001
> [8] http://objectlayout.org
> [9]
> http://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html
> [10]
> https://github.com/simonis/ObjectLayout/tree/hotspot_intrinsification/hotspot
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 28 Jan 2015 22:56:09 +0100
> From: Peter Levart <peter.levart at gmail.com>
> To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>,       Vitaly
>         Davidovich <vitalyd at gmail.com>, St?phane ?pardaud <
> stef at epardaud.fr>
> Cc: valhalla-dev <valhalla-dev at openjdk.java.net>
> Subject: Re: Idea how to implement VT/VO compatibility in JVM
> Message-ID: <54C95AF9.3090004 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
> On 01/22/2015 02:26 PM, Maurizio Cimadamore wrote:
> >
> > On 22/01/15 13:19, Vitaly Davidovich wrote:
> >> Can you expand a bit on the part where you say frameworks can't
> >> iterate a
> >> Collection<any T> without knowing the instantiation? Do you mean
> >> existing
> >> methods that take Collection<?> won't work without change or
> >> something else?
> > In the current prototype, such methods will work, but they will work
> > with all reference-parameterizations - example:
> >
> > void m(Collection<?> c) { ... }
> >
> > List<String> ls = ...
> > List<Object> lo = ...
> > List<int> li = ...
> > List<MyPointValue> lmpv = ...
> >
> > m(ls); //ok
> > m(lo); //ok
> > m(li); //fail, List<int> is not subtype of Collection<?>
> > m(lmpv); //fail, List<MyPointValue> is not subtype of Collection<?>
> >
> > In other words, Collection<?> means Collection<? extends Object>.
> > Therefore, primitives and values are outside the domain supported by
> > the unbounded wildcard.
> >
> > To fix that, you need to change 'm' as follows:
> >
> > <any T> void m2(Collection<T> c) { ... }
> >
> > m(ls); //ok
> > m(lo); //ok
> > m(li); //ok
> > m(lmpv); //ok
> >
> > Is this what you were asking?
> >
> > Maurizio
>
> There could also be an abbreviation:
>
> void m3(Collection<any ?> c) { ... }
>
> ...which would be equivalent to m2 above, but used only if you don't
> need T in the method (you only invoke methods on 'c' that are not
> mentioning T from Collection<any T> in their signature, such as size(),
> clear(), ...). Maybe you could also call methods, that mention T in
> return type, but you could not assign the result to anything (or maybe
> to Object in certain situations), for example:
>
> class Foo<any T> {
>
>      T getOne() { ... }
>
>      Optional<T> getMaybe() { ... }
>
> }
>
>
> void m4(Foo<any ?> anyFoo) {
>
>      anyFoo.getOne(); // can call, but not use the result
>
>      Object r = anyFoo.getMaybe(); // can assign to Object since
> Optional<?>, Optional<int>, etc. are all Objects
>
> }
>
> (I'm still considering Optional as reference type here)
>
> Peter
>
>
> >
> >>
> >> sent from my phone
> >> On Jan 22, 2015 8:12 AM, "St?phane ?pardaud" <stef at epardaud.fr> wrote:
> >>
> >>> On 01/22/2015 12:18 PM, Maurizio Cimadamore wrote:
> >>>
> >>>> I don't think there's an 'hole' as such in your proposal - but
> >>>> there are
> >>>> 'unknowns'.
> >>>>
> >>> Well, that's already good news. I prefer unknowns to known holes ;)
> >>>
> >>>   Performance-wise, I think the 'risk' is that if we keep the API
> >>> the way
> >>>> they are today (i.e. removeAll(Collection<?>) and friends), the
> >>>> boxing path
> >>>> will pretty much be the norm. Now, in a perfect world, as value
> >>>> types are
> >>>> non-polymorphic (or their polymorphism is very restricted) and
> >>>> immutable,
> >>>> that would suggest that VM should have enough of an hint to perform
> >>>> boxing
> >>>> elimination and such, so that the cost you end up paying is
> >>>> negligible. How
> >>>> much of this is reality? As you, I'm not a VM guru - but I think
> >>>> it's a
> >>>> question worth asking. It seems a likely scenario that the JVM will do
> >>>> great in most cases, and have some bad performance cliffs in others
> >>>> - is
> >>>> that something we are willing to sign up for?
> >>>>
> >>> OK, that's fair. By allowing people to use value types boxed we
> >>> allow them
> >>> to shoot themselves in the foot perf-wise (assuming the VM can't help),
> >>> because we make value types much more accessible. This is mostly due to
> >>> `any T` being opt-in rather than the new default for `T` where `T
> >>> extends
> >>> Object` is not specified. If we also changed `T` to mean `any T`
> >>> (source
> >>> only, so for newly compiled code) then all generics code would be
> >>> specializable by default and that means that users of generic code will
> >>> always be able to use the specialised code as long as they can
> >>> instantiate
> >>> the generic type argument at compile-time (as is already the
> >>> limitation).
> >>> If they can't, well they already have to use `Object` and boxing and
> >>> can't
> >>> traverse collections because they're not `List<Object>` (ATM).
> >>>
> >>> Making it the default has down sides, probably in larger class
> >>> files, but
> >>> as long as it's not the default, there will always be
> >>> incompatibilities in
> >>> libraries that will forget to opt-in, which will mean that either (ATM)
> >>> they can't be used with containers of value types, or that the
> >>> containers
> >>> have to be wrapped to box the value types (unless we fix that as I
> >>> suggest). IMO that's already going to cause compatibility issues and
> >>> there
> >>> may arise a "coding guideline" (remember them from C++ sore points?)
> >>> that
> >>> people will be strongly encourage to use `val T` everywhere just in
> >>> case
> >>> someone wants to use an unboxed value type.
> >>>
> >>> The rift between primitives and Object is already a famous sore
> >>> point in
> >>> Java (not criticising, this was a choice made a long time ago, for
> >>> valid
> >>> reasons, we just have to deal with it) which has been "fixed" in most
> >>> non-Java JVM-languages due to popular demand. I don't think the new
> >>> default
> >>> with value types should be that generics don't accept value types.
> >>>
> >>>   On the language-side unknowns, how much code out there is relying on
> >>>> being able to access fields on Foo<?> or raw Foo types? This is
> >>>> perhaps not
> >>>> common, but I think we need to gather data points on this i.e. by
> >>>> looking
> >>>> at existing open source projects (help welcome here!). Other
> >>>> possible weak
> >>>> points are that this doesn't necessarily address all the issue w.r.t.
> >>>> language uniformity - i.e. how is an ArrayList<int> supposed to
> >>>> answer to a
> >>>> question of the kind 'is instance of List<?>' ?
> >>>>
> >>> Fields that don't involve the `any T` are fine. Fields that do may
> >>> have to
> >>> revert to autoboxing _if_ we feel we _must_ accomodate that to
> >>> autobox not
> >>> just value types but their containers.
> >>>
> >>> `ArrayList<int>` is special, mostly due to the fact that I'm not
> >>> sure we
> >>> can retrofit `Integer` to be a value type, so existing primitives
> >>> may not
> >>> get the `List<int> === List<Integer>` that I suggest for value types
> >>> (though I'd be very interested in making this work).
> >>>
> >>> If we take an easier example assuming a value type named `Date`,
> >>> then yes
> >>> I expect that:
> >>>
> >>> - `List<val Date> instanceof List<?>` == `true`
> >>> - `List<__Boxed Date> instanceof List<?>` == `true`
> >>>
> >>>   I'm not denying there's something there worth exploring (as I have in
> >>>> fact already said), but it seems to me that, while you can go a
> >>>> long way
> >>>> with bridges, there are still questions that bridges alone simply
> >>>> do not
> >>>> have an answer for.
> >>>>
> >>> Thanks, and yes I agree there are still questions remaining, and more
> >>> importantly an implementation lacking, but hopefully if the proposal
> >>> sounds
> >>> decent I can help with the proto.
> >>>
> >>> Thanks for your answers BTW :)
> >>>
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 28 Jan 2015 22:58:35 -0500
> From: Vitaly Davidovich <vitalyd at gmail.com>
> To: Peter Levart <peter.levart at gmail.com>
> Cc: valhalla-dev at openjdk.java.net
> Subject: Re: Idea how to implement VT/VO compatibility in JVM
> Message-ID:
>         <
> CAHjP37GND6b+LyC9uvK5fjfDRqmnbHi-d3mrGN-HUdgFckf1Yg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Sorry Peter, I'm having a hard time understanding what this buys us - could
> you explain what problem this solves exactly? It's certainly not for
> backcompat from the description, so unclear.
>
> sent from my phone
> On Jan 28, 2015 4:56 PM, "Peter Levart" <peter.levart at gmail.com> wrote:
>
> >
> > On 01/22/2015 02:26 PM, Maurizio Cimadamore wrote:
> >
> >
> > On 22/01/15 13:19, Vitaly Davidovich wrote:
> >
> > Can you expand a bit on the part where you say frameworks can't iterate a
> > Collection<any T> without knowing the instantiation? Do you mean existing
> > methods that take Collection<?> won't work without change or something
> > else?
> >
> > In the current prototype, such methods will work, but they will work with
> > all reference-parameterizations - example:
> >
> > void m(Collection<?> c) { ... }
> >
> > List<String> ls = ...
> > List<Object> lo = ...
> > List<int> li = ...
> > List<MyPointValue> lmpv = ...
> >
> > m(ls); //ok
> > m(lo); //ok
> > m(li); //fail, List<int> is not subtype of Collection<?>
> > m(lmpv); //fail, List<MyPointValue> is not subtype of Collection<?>
> >
> > In other words, Collection<?> means Collection<? extends Object>.
> > Therefore, primitives and values are outside the domain supported by the
> > unbounded wildcard.
> >
> > To fix that, you need to change 'm' as follows:
> >
> > <any T> void m2(Collection<T> c) { ... }
> >
> > m(ls); //ok
> > m(lo); //ok
> > m(li); //ok
> > m(lmpv); //ok
> >
> > Is this what you were asking?
> >
> > Maurizio
> >
> >
> > There could also be an abbreviation:
> >
> > void m3(Collection<any ?> c) { ... }
> >
> > ...which would be equivalent to m2 above, but used only if you don't need
> > T in the method (you only invoke methods on 'c' that are not mentioning T
> > from Collection<any T> in their signature, such as size(), clear(), ...).
> > Maybe you could also call methods, that mention T in return type, but you
> > could not assign the result to anything (or maybe to Object in certain
> > situations), for example:
> >
> > class Foo<any T> {
> >
> >     T getOne() { ... }
> >
> >     Optional<T> getMaybe() { ... }
> >
> > }
> >
> >
> > void m4(Foo<any ?> anyFoo) {
> >
> >     anyFoo.getOne(); // can call, but not use the result
> >
> >     Object r = anyFoo.getMaybe(); // can assign to Object since
> > Optional<?>, Optional<int>, etc. are all Objects
> >
> > }
> >
> > (I'm still considering Optional as reference type here)
> >
> > Peter
> >
> >
> >
> >
> > sent from my phone
> > On Jan 22, 2015 8:12 AM, "St?phane ?pardaud" <stef at epardaud.fr>
> > <stef at epardaud.fr> wrote:
> >
> > On 01/22/2015 12:18 PM, Maurizio Cimadamore wrote:
> >
> > I don't think there's an 'hole' as such in your proposal - but there are
> > 'unknowns'.
> >
> >  Well, that's already good news. I prefer unknowns to known holes ;)
> >
> >   Performance-wise, I think the 'risk' is that if we keep the API the way
> >
> > they are today (i.e. removeAll(Collection<?>) and friends), the boxing
> > path
> > will pretty much be the norm. Now, in a perfect world, as value types are
> > non-polymorphic (or their polymorphism is very restricted) and immutable,
> > that would suggest that VM should have enough of an hint to perform
> boxing
> > elimination and such, so that the cost you end up paying is negligible.
> > How
> > much of this is reality? As you, I'm not a VM guru - but I think it's a
> > question worth asking. It seems a likely scenario that the JVM will do
> > great in most cases, and have some bad performance cliffs in others - is
> > that something we are willing to sign up for?
> >
> >  OK, that's fair. By allowing people to use value types boxed we allow
> > them
> > to shoot themselves in the foot perf-wise (assuming the VM can't help),
> > because we make value types much more accessible. This is mostly due to
> > `any T` being opt-in rather than the new default for `T` where `T extends
> > Object` is not specified. If we also changed `T` to mean `any T` (source
> > only, so for newly compiled code) then all generics code would be
> > specializable by default and that means that users of generic code will
> > always be able to use the specialised code as long as they can
> instantiate
> > the generic type argument at compile-time (as is already the limitation).
> > If they can't, well they already have to use `Object` and boxing and
> can't
> > traverse collections because they're not `List<Object>` (ATM).
> >
> > Making it the default has down sides, probably in larger class files, but
> > as long as it's not the default, there will always be incompatibilities
> in
> > libraries that will forget to opt-in, which will mean that either (ATM)
> > they can't be used with containers of value types, or that the containers
> > have to be wrapped to box the value types (unless we fix that as I
> > suggest). IMO that's already going to cause compatibility issues and
> there
> > may arise a "coding guideline" (remember them from C++ sore points?) that
> > people will be strongly encourage to use `val T` everywhere just in case
> > someone wants to use an unboxed value type.
> >
> > The rift between primitives and Object is already a famous sore point in
> > Java (not criticising, this was a choice made a long time ago, for valid
> > reasons, we just have to deal with it) which has been "fixed" in most
> > non-Java JVM-languages due to popular demand. I don't think the new
> > default
> > with value types should be that generics don't accept value types.
> >
> >   On the language-side unknowns, how much code out there is relying on
> >
> > being able to access fields on Foo<?> or raw Foo types? This is perhaps
> > not
> > common, but I think we need to gather data points on this i.e. by looking
> > at existing open source projects (help welcome here!). Other possible
> weak
> > points are that this doesn't necessarily address all the issue w.r.t.
> > language uniformity - i.e. how is an ArrayList<int> supposed to answer to
> > a
> > question of the kind 'is instance of List<?>' ?
> >
> >  Fields that don't involve the `any T` are fine. Fields that do may have
> > to
> > revert to autoboxing _if_ we feel we _must_ accomodate that to autobox
> not
> > just value types but their containers.
> >
> > `ArrayList<int>` is special, mostly due to the fact that I'm not sure we
> > can retrofit `Integer` to be a value type, so existing primitives may not
> > get the `List<int> === List<Integer>` that I suggest for value types
> > (though I'd be very interested in making this work).
> >
> > If we take an easier example assuming a value type named `Date`, then yes
> > I expect that:
> >
> > - `List<val Date> instanceof List<?>` == `true`
> > - `List<__Boxed Date> instanceof List<?>` == `true`
> >
> >   I'm not denying there's something there worth exploring (as I have in
> >
> > fact already said), but it seems to me that, while you can go a long way
> > with bridges, there are still questions that bridges alone simply do not
> > have an answer for.
> >
> >  Thanks, and yes I agree there are still questions remaining, and more
> > importantly an implementation lacking, but hopefully if the proposal
> > sounds
> > decent I can help with the proto.
> >
> > Thanks for your answers BTW :)
> >
> >
> >
> >
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 29 Jan 2015 07:55:16 +0100
> From: Peter Levart <peter.levart at gmail.com>
> To: Vitaly Davidovich <vitalyd at gmail.com>
> Cc: valhalla-dev at openjdk.java.net
> Subject: Re: Idea how to implement VT/VO compatibility in JVM
> Message-ID: <54C9D954.9080209 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 01/29/2015 04:58 AM, Vitaly Davidovich wrote:
> > Sorry Peter, I'm having a hard time understanding what this buys us -
> could
> > you explain what problem this solves exactly? It's certainly not for
> > backcompat from the description, so unclear.
>
> I'm just contemplating about the usefulness of a construct.
>
> Equivalent to relation of:
>
> <T> void m(Collection<T> c) { ... }
>
> vs.
>
> void m(Collection<?> c) { ... }
>
>
> There could also be:
>
> <any T> void m(Collection<T> c) { ... }
>
> vs.
>
> void m(Collection<any ?> c) { ... }
>
>
> Although the later (any ?) is less useful than the former (?), there is
> still some use to be found in the anyfied one. And the language features
> should be orthogonal if at all possible.
>
>
> Regards, Peter
>
> >
> > sent from my phone
> > On Jan 28, 2015 4:56 PM, "Peter Levart" <peter.levart at gmail.com> wrote:
> >
> >> On 01/22/2015 02:26 PM, Maurizio Cimadamore wrote:
> >>
> >>
> >> On 22/01/15 13:19, Vitaly Davidovich wrote:
> >>
> >> Can you expand a bit on the part where you say frameworks can't iterate
> a
> >> Collection<any T> without knowing the instantiation? Do you mean
> existing
> >> methods that take Collection<?> won't work without change or something
> >> else?
> >>
> >> In the current prototype, such methods will work, but they will work
> with
> >> all reference-parameterizations - example:
> >>
> >> void m(Collection<?> c) { ... }
> >>
> >> List<String> ls = ...
> >> List<Object> lo = ...
> >> List<int> li = ...
> >> List<MyPointValue> lmpv = ...
> >>
> >> m(ls); //ok
> >> m(lo); //ok
> >> m(li); //fail, List<int> is not subtype of Collection<?>
> >> m(lmpv); //fail, List<MyPointValue> is not subtype of Collection<?>
> >>
> >> In other words, Collection<?> means Collection<? extends Object>.
> >> Therefore, primitives and values are outside the domain supported by the
> >> unbounded wildcard.
> >>
> >> To fix that, you need to change 'm' as follows:
> >>
> >> <any T> void m2(Collection<T> c) { ... }
> >>
> >> m(ls); //ok
> >> m(lo); //ok
> >> m(li); //ok
> >> m(lmpv); //ok
> >>
> >> Is this what you were asking?
> >>
> >> Maurizio
> >>
> >>
> >> There could also be an abbreviation:
> >>
> >> void m3(Collection<any ?> c) { ... }
> >>
> >> ...which would be equivalent to m2 above, but used only if you don't
> need
> >> T in the method (you only invoke methods on 'c' that are not mentioning
> T
> >> from Collection<any T> in their signature, such as size(), clear(),
> ...).
> >> Maybe you could also call methods, that mention T in return type, but
> you
> >> could not assign the result to anything (or maybe to Object in certain
> >> situations), for example:
> >>
> >> class Foo<any T> {
> >>
> >>      T getOne() { ... }
> >>
> >>      Optional<T> getMaybe() { ... }
> >>
> >> }
> >>
> >>
> >> void m4(Foo<any ?> anyFoo) {
> >>
> >>      anyFoo.getOne(); // can call, but not use the result
> >>
> >>      Object r = anyFoo.getMaybe(); // can assign to Object since
> >> Optional<?>, Optional<int>, etc. are all Objects
> >>
> >> }
> >>
> >> (I'm still considering Optional as reference type here)
> >>
> >> Peter
> >>
> >>
> >>
> >>
> >> sent from my phone
> >> On Jan 22, 2015 8:12 AM, "St?phane ?pardaud" <stef at epardaud.fr>
> >> <stef at epardaud.fr> wrote:
> >>
> >> On 01/22/2015 12:18 PM, Maurizio Cimadamore wrote:
> >>
> >> I don't think there's an 'hole' as such in your proposal - but there are
> >> 'unknowns'.
> >>
> >>   Well, that's already good news. I prefer unknowns to known holes ;)
> >>
> >>    Performance-wise, I think the 'risk' is that if we keep the API the
> way
> >>
> >> they are today (i.e. removeAll(Collection<?>) and friends), the boxing
> >> path
> >> will pretty much be the norm. Now, in a perfect world, as value types
> are
> >> non-polymorphic (or their polymorphism is very restricted) and
> immutable,
> >> that would suggest that VM should have enough of an hint to perform
> boxing
> >> elimination and such, so that the cost you end up paying is negligible.
> >> How
> >> much of this is reality? As you, I'm not a VM guru - but I think it's a
> >> question worth asking. It seems a likely scenario that the JVM will do
> >> great in most cases, and have some bad performance cliffs in others - is
> >> that something we are willing to sign up for?
> >>
> >>   OK, that's fair. By allowing people to use value types boxed we allow
> >> them
> >> to shoot themselves in the foot perf-wise (assuming the VM can't help),
> >> because we make value types much more accessible. This is mostly due to
> >> `any T` being opt-in rather than the new default for `T` where `T
> extends
> >> Object` is not specified. If we also changed `T` to mean `any T` (source
> >> only, so for newly compiled code) then all generics code would be
> >> specializable by default and that means that users of generic code will
> >> always be able to use the specialised code as long as they can
> instantiate
> >> the generic type argument at compile-time (as is already the
> limitation).
> >> If they can't, well they already have to use `Object` and boxing and
> can't
> >> traverse collections because they're not `List<Object>` (ATM).
> >>
> >> Making it the default has down sides, probably in larger class files,
> but
> >> as long as it's not the default, there will always be incompatibilities
> in
> >> libraries that will forget to opt-in, which will mean that either (ATM)
> >> they can't be used with containers of value types, or that the
> containers
> >> have to be wrapped to box the value types (unless we fix that as I
> >> suggest). IMO that's already going to cause compatibility issues and
> there
> >> may arise a "coding guideline" (remember them from C++ sore points?)
> that
> >> people will be strongly encourage to use `val T` everywhere just in case
> >> someone wants to use an unboxed value type.
> >>
> >> The rift between primitives and Object is already a famous sore point in
> >> Java (not criticising, this was a choice made a long time ago, for valid
> >> reasons, we just have to deal with it) which has been "fixed" in most
> >> non-Java JVM-languages due to popular demand. I don't think the new
> >> default
> >> with value types should be that generics don't accept value types.
> >>
> >>    On the language-side unknowns, how much code out there is relying on
> >>
> >> being able to access fields on Foo<?> or raw Foo types? This is perhaps
> >> not
> >> common, but I think we need to gather data points on this i.e. by
> looking
> >> at existing open source projects (help welcome here!). Other possible
> weak
> >> points are that this doesn't necessarily address all the issue w.r.t.
> >> language uniformity - i.e. how is an ArrayList<int> supposed to answer
> to
> >> a
> >> question of the kind 'is instance of List<?>' ?
> >>
> >>   Fields that don't involve the `any T` are fine. Fields that do may
> have
> >> to
> >> revert to autoboxing _if_ we feel we _must_ accomodate that to autobox
> not
> >> just value types but their containers.
> >>
> >> `ArrayList<int>` is special, mostly due to the fact that I'm not sure we
> >> can retrofit `Integer` to be a value type, so existing primitives may
> not
> >> get the `List<int> === List<Integer>` that I suggest for value types
> >> (though I'd be very interested in making this work).
> >>
> >> If we take an easier example assuming a value type named `Date`, then
> yes
> >> I expect that:
> >>
> >> - `List<val Date> instanceof List<?>` == `true`
> >> - `List<__Boxed Date> instanceof List<?>` == `true`
> >>
> >>    I'm not denying there's something there worth exploring (as I have in
> >>
> >> fact already said), but it seems to me that, while you can go a long way
> >> with bridges, there are still questions that bridges alone simply do not
> >> have an answer for.
> >>
> >>   Thanks, and yes I agree there are still questions remaining, and more
> >> importantly an implementation lacking, but hopefully if the proposal
> >> sounds
> >> decent I can help with the proto.
> >>
> >> Thanks for your answers BTW :)
> >>
> >>
> >>
> >>
>
>
>
> End of valhalla-dev Digest, Vol 7, Issue 84
> *******************************************
>


More information about the valhalla-dev mailing list