"Model 2" prototype status

Vitaly Davidovich vitalyd at gmail.com
Fri Aug 7 21:01:56 UTC 2015


>
> In the current prototype, they are shared across instantiations and are
> stored as static members on the erased class (Foo).  The compiler
> translates a static field access Foo<int>.x as "getfield Foo.x". Reflection
> on Foo.class will find these members; reflection on Foo<int>.class will not
> currently.  This is good enough for purposes of our current prototype.


Where does it store the generic _t? And what is its type? Is it Object (or
erased upper bound) with a checkcast at the callsite?

On Fri, Aug 7, 2015 at 2:29 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> But my question stands: given the scenario, where do _t and _x live?
>> Foo<String>._t vs Foo<int>._t and Foo<String>_x and Foo<int>._x? How
>> would it work with reflection?
>>
>
> In the current prototype, they are shared across instantiations and are
> stored as static members on the erased class (Foo).  The compiler
> translates a static field access Foo<int>.x as "getfield Foo.x". Reflection
> on Foo.class will find these members; reflection on Foo<int>.class will not
> currently.  This is good enough for purposes of our current prototype.
>
> We're investigating (that's code for "that's all I'm ready to say about it
> for now") some less ad-hoc ways of representing static members, as well as
> investigating how we're going to address the issue of per-instantiation
> values.  Stay tuned.
>
>


More information about the valhalla-dev mailing list