> On Jun 19, 2020, at 2:44 PM, fo...@univ-mlv.fr wrote:
>
> If the VM see I as a subtype of Object, there is no need for a
> Ljava/lang/Integer$val; at all, it's better to have aload/astore/etc to work
> on I directly.
That's initially somewhat attractive, but think about the implications for
> On Jun 19, 2020, at 1:51 PM, fo...@univ-mlv.fr wrote:
>
> covariant return type
> interface I {
> int foo();
> }
> interface J {
> Object foo();
> }
> class A implements I, J {
>int foo();
> }
>
> with I.java compiled a long time ago.
Nothing in this proposal changes how
- Mail original -
> De: "daniel smith"
> À: "Remi Forax"
> Cc: "Brian Goetz" , "valhalla-spec-experts"
>
> Envoyé: Vendredi 19 Juin 2020 21:27:12
> Objet: Re: Evolving the wrapper classes
>> On Jun 19, 2020, at 12:54 PM
> On Jun 19, 2020, at 12:54 PM, Remi Forax wrote:
>
>> Note that [I and [QInteger$val have the exact same layout, so it is really a
>> matter of treating the two type names as referring to the same underlying
>> runtime type.
>
> yes, but at the same time descriptor are matched by name and
lla-spec-experts"
> , "valhalla-spec-experts"
>
> Envoyé: Vendredi 19 Juin 2020 20:59:35
> Objet: Re: Evolving the wrapper classes
>> yes, but at the same time descriptor are matched by name and you need to have
>> the proper descriptor when overriding/imp
I hope to surprise you positively!
On 6/19/2020 3:09 PM, fo...@univ-mlv.fr wrote:
Blindly is perhaps a word too strong, let say we have to come with a
plan, a good plan,
and i fail to see how it can work with only the current bridge
mechanism we have.
yes, but at the same time descriptor are matched by name and you need
to have the proper descriptor when overriding/implementing a method,
so the strategy of blindly replacing every I by QInteger$val; doesn't
really work.
Who said blindly?
> De: "Brian Goetz"
> À: "Tobi Ajila"
> Cc: "valhalla-spec-experts" ,
> "valhalla-spec-experts"
> Envoyé: Vendredi 19 Juin 2020 20:18:09
> Objet: Re: Evolving the wrapper classes
> Zooming out, what we've been trying to do
Zooming out, what we've been trying to do is shake out the places where
the JVM treats primitives and references differently, and aligning them,
so that we are able to broaden the approach of "generics erase T to
Object" to include inlines and primitives. The war cry might be:
Object is
> Date: 2020/06/19 01:32 PM
> Subject: [EXTERNAL] Re: Evolving the wrapper classes
>
>
> > On Jun 19, 2020, at 11:07 AM, Tobi Ajila wrote:
> >
> > I am still a little unclear as to what the motivation is for this.
> Is this solely for specialized generics?
> >
&
PSA: this thread has been polluted with the address:
valhalla-spec-experts
Which just generates admin notifications. Please delete that address from any
replies. :-)
> On Jun 19, 2020, at 11:07 AM, Tobi Ajila wrote:
>
> I am still a little unclear as to what the motivation is for this. Is this
> solely for specialized generics?
>
> In Dan's examples with `I` and `java/lang/Integer$val`, the only places where
> conversions are needed are when primitives
> Because arrays have identity (not to mention potentially large copying
costs), there is simply no reasonable conversion we can define; any
"conversion" would involve copying all the data, changing identity, or
both. Just as with the array subtyping requirements (Point[] <: Point.ref
[] <:
> Given your examples can we assume that the JVM will never need to do an
> implicit `Qjava/lang/Integer$val;` to `I` conversion? And these will always
> be explicit conversions performed by javac?
>
Correct.
> > - The type [I is considered by the verifier to be equivalent to
> >
Hi Dan S.
>>> - Where necessary (depending on the operations being performed), the
compiler generates conversions between 'I' and 'java/lang/Integer$val'. 'I'
is preferred wherever possible.
>>
>> We have to use QInteger$val whenever we use int as a type parameter, the
rest of the time, we can
> On Jun 17, 2020, at 4:30 PM, Kevin Bourrillion wrote:
>
>> - The type 'Integer.val' is equivalent to 'int'. Primitive types are inline
>> types—they have members, support method invocation, etc.
>>
> This at least suggests that `42L.hashCode()` would begin to work just as
>
Hmm, just maybe this will be less confusing than I was fearing. I'm
seeing now that "Integer is the real class, int is alias for
Integer.val" is a whole lot cleaner than "int becomes a val-default
class and Integer is demoted to alias for int.ref", which for some
reason was the way I was
> On Jun 17, 2020, at 4:13 PM, Brian Goetz wrote:
>
>> - Where necessary (depending on the operations being performed), the
>> compiler generates conversions between 'I' and 'java/lang/Integer$val'. 'I'
>> is preferred wherever possible.
>
> We have to use QInteger$val whenever we use int
This is pretty much what I was expecting. A few comments:
Step 1: Warnings
A dynamic warning, initially only activated by opt-in, when someone
attempts to synchronize on an instance of a wrapper class. There's a
changeset in review now for 16.
- Where necessary (depending on the
Here's a concrete proposal for how we'll evolve the wrapper classes (Byte,
Short, Integer, Long, Float, Double, Character, and Boolean) to be inline
classes whose ".val" representations are (in the Java language) the primitive
types.
This has the effect of replacing boxing conversions in the
20 matches
Mail list logo
