Idea how to implement VT/VO compatibility in JVM

[Vitaly Davidovich]

Ok, so the issue is really reflection/late binding here and not <any T> per
say.  In .NET for example, there's reflection support for generics and what
one typically does in such a situation is invoke a generic method via
reflection by specifying the type parameter reflectively.  This all works
because generics are reified in the VM, of course.

Perhaps proper time to ask what the current thoughts are on reflection
support for value types and any T methods.

sent from my phone
On Jan 22, 2015 8:26 AM, "Stéphane Épardaud" <stef at epardaud.fr> wrote:

> On 01/22/2015 02:19 PM, 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?
>>
>>
>>  If you're writing a framework and you want to traverse instances, for
> example to implement JSON serialisation, you're going to have code that
> goes:
>
> private void traverseFields(Object instance){
>  for(Field f : instance.getClass().getFields())
>   traverseField(instance, f);
> }
>
> private void traverseField(Object instance, Field f){
>  if(f.getDeclaringClass() == Collection.class){
>   traverseCollection(f.get(instance));
>  }
> }
>
> private void traverseCollection(Collection<? extends Object> collection){
>  for(Object val : collection)
>   traverseFields(val);
> }
>
> You can see that at compile-time I don't have any idea about which value
> types I could encounter, so the only instantiation of `T` I will have is
> `Object`, never `value Date` which may pop up there, and since (unboxed)
> value types don't have any common superclass I can't traverse collections
> of them without knowing at compile-time what type they are. Which is not
> possible for frameworks.
>