Indeed. We can blur the distinction between I and QInteger$val at the
_language_ level -- where it matters -- but there's no return trying to
do so at the VM level. Except in the cases we already described --
array types -- where we cannot effectively blur it in the language.
On 6/19/2020
> 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
- Mail original -
> De: "daniel smith"
> À: "Remi Forax"
> Cc: "Brian Goetz" , "valhalla-spec-experts"
>
> Envoyé: Vendredi 19 Juin 2020 22:16:48
> Objet: Re: Evolving the wrapper classes
>> On Jun 19, 2020, a
> On Jun 19, 2020, at 2:16 PM, Dan Smith wrote:
>
>> 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
> 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 thes
- 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 y
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 d
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 t
>
> 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 a
> 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
[] <: Obje
> 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
> > [java/lang/I
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 use
> 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
> `"foo".hashCode()
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 thin
> 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 a
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 operati
22 matches
Mail list logo