[vmi] Reflection support for generics

[Paulex Yang <pa...@gmail.com>]

Hi, all

I found that IBM VME's kernel class implementation don't fully support 
generics related reflection, more specifically, the methods below always 
return null: (Oli? would you like to confirm?)

j.l.r.Constructor.getGenericParameterTypes()
j.l.r.Constructor.getGenericExceptionTypes()
j.l.r.Field.getGenericType()
j.l.r.Method.getGenericReturnType()
j.l.r.Method.getGenericParameterTypes()
j.l.r.Method.getGenericExceptionTypes()
java.lang.Class.GetGenericInterfaces()
java.lang.Class.GetGenericSuperclass()

So I looked at DRLVM's j.l.r.Constructor implementation, seems most 
codes related generics reflection are VM neutral, such as classes in 
o.a.h.l.r.parser, except several small native methods locate in 
o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't looked 
into other classes but I won't be surprised if they aren't in similar 
case. If so, it makes sense to me to extract the VM independent part 
into class library codes as utilities, so that IBM VME(and other Harmony 
compatible VM) can also benefit from them, one obvious drawback may be 
some new VMI methods needed to access the VM implementation details. 
Because lack of enough knowledge on either IBM VME or DRLVM 
implementation, I'm not sure if it is a good idea. So any comments from 
DRL gurus and others?

-- 
Paulex Yang
China Software Development Lab
IBM

Re: [vmi] Reflection support for generics

[Alexey Varlamov <al...@gmail.com>]

2007/1/12, Yang Paulex <pa...@gmail.com>:
> inline.
>
> 2007/1/11, Alexey Varlamov <al...@gmail.com>:
> >
> > Hello Paulex,
> >
> > Actually I thought about reversed order of steps, i.e. clean up impl
> > first then move it.
> > The point is that current impl is spaghetti-like, entangled with
> > internals of kernel classes. The very 1st step I suggest to get rid of
> > all o.a.h.l.reflect.** import clauses in j.l.Class except the Parser
> > itself (currently there are 16(!) imported classes). After that we'll
> > have more neat API and will better understand really needed
> > dependencies. Please ask if you need any assistance, I'm happy to take
> > part.
>
>
> Sounds reasonable, so I'll look into the implementation now, and I'll raise
> my thoughts here after then.
OK, thank you. Good luck ;)

[snip]
>
> The 2) looks reasonable, except I do not think one ever needs
> > getSignature(AccessibleObject). Signatures of members are only needed
> > as input parameters to the parser.
> > And probably even getSignature(Class) is not needed, parser could do
> > just with public reflection API - though I did not try to verify this
> > speculation. So if the latter is true, we also have other option:
>
>
> I did think the signature can be got by public API, but I didn't find it:(.
That's right, the signature is specific to class file format and is
not exposed anywhere. My speculation was it could be possible to go
with recursive callbacks to public API instead of VMI extension, but
it seems tricky to verify without going deeper into implementation
details. So I'm OK with the 2) as it enables more impl freedom.

> About the getSignature(AccessibleObject), it's needed by ConstructorData,
> etc, but not by the reflection parser classes.
I see, and my suggestion to sort out the parser first is still valid :)

>
> 3) Don't change VMI, export an API from classlib like this:
> > Type o.a.h.l.reflect.GenericsParser.getType(String sig, Class owner);
> > TypeVariable[] o.a.h.l.reflect.GenericsParser.getTypeParameters(String
> > sig, Class owner);
> > ...
>
>
> I agree this is the objective:).
>
> As for sharing other classes like Class.GACache,
> > Constructor.ConstructorData, it may also be reasonable but would
> > certainly require further VMI extension. Let's do it step by step and
> > manage the parser first.
>
>
> So far I only found one more external dependency related to generics, i.e.,
> the VMGenericsAndAnnotations.getSignature(long), but as inner classes, maybe
> they had some coupling with their wrapper classes.
The inner classes also handle annotations and other reflection data so
have other dependencies as well, though indeed not related to
generics.
But don't be confused by finding generics-related code in those
classes, such code should belong to the parser actually - this is just
an example of spaghetti-ness which I talked above.
[snip]

--
Alexey

Re: [vmi] Reflection support for generics

[Yang Paulex <pa...@gmail.com>]

inline.

2007/1/11, Alexey Varlamov <al...@gmail.com>:
>
> Hello Paulex,
>
> Actually I thought about reversed order of steps, i.e. clean up impl
> first then move it.
> The point is that current impl is spaghetti-like, entangled with
> internals of kernel classes. The very 1st step I suggest to get rid of
> all o.a.h.l.reflect.** import clauses in j.l.Class except the Parser
> itself (currently there are 16(!) imported classes). After that we'll
> have more neat API and will better understand really needed
> dependencies. Please ask if you need any assistance, I'm happy to take
> part.


Sounds reasonable, so I'll look into the implementation now, and I'll raise
my thoughts here after then.

I do not quite understood 1), because the AuxiliaryChecker does not
> belong to public API so cannot stay as kernel class. Regarding its'
> purpose, I guess it implements some reflectionAPI-mandated checks,
> e.g. this is the only code throwing
> MalformedParameterizedTypeException, which is declared to be thrown by
> public javadocs.


I see, thank you:)

The 2) looks reasonable, except I do not think one ever needs
> getSignature(AccessibleObject). Signatures of members are only needed
> as input parameters to the parser.
> And probably even getSignature(Class) is not needed, parser could do
> just with public reflection API - though I did not try to verify this
> speculation. So if the latter is true, we also have other option:


I did think the signature can be got by public API, but I didn't find it:(.
About the getSignature(AccessibleObject), it's needed by ConstructorData,
etc, but not by the reflection parser classes.

3) Don't change VMI, export an API from classlib like this:
> Type o.a.h.l.reflect.GenericsParser.getType(String sig, Class owner);
> TypeVariable[] o.a.h.l.reflect.GenericsParser.getTypeParameters(String
> sig, Class owner);
> ...


I agree this is the objective:).

As for sharing other classes like Class.GACache,
> Constructor.ConstructorData, it may also be reasonable but would
> certainly require further VMI extension. Let's do it step by step and
> manage the parser first.


So far I only found one more external dependency related to generics, i.e.,
the VMGenericsAndAnnotations.getSignature(long), but as inner classes, maybe
they had some coupling with their wrapper classes.

--
> Alexey
>
> 2007/1/11, Yang Paulex <pa...@gmail.com>:
> > Hi, sorry for the delay, I've just got some time to look at this issue
> now.
> >
> > I tried to move generic reflection support out from kernel class to LUNI
> at
> > first, then look at the implementation itself, like JIRA-2052 requested.
> >
> > Currently I see four packages can be moved out:
> > o.a.h.l.reflect.implementation
> > o.a.h.l.reflect.parser
> > o.a.h.l.reflect.repository
> > o.a.h.l.reflect.support
> >
> > But there is one utility class o.a.l.r.s.AuxiliaryChecker, which depends
> on
> > DRLVM specific
> org.apache.harmony.vm.VMGenericsAndAnnotations.getSignature(Class),
> > so we have two options:
> >
> > 1. Don't add VMI methods, and keep AuxiliaryChecker in kernel class,
> this
> > option is relative simple. According to class comments, AuxiliaryChecker
> is
> > to check the correspondence of the formal parameter number and the
> actual
> > argument number, I'm not sure yet about its purpose to check this during
> > generics reflection.
> >
> > 2. Add VMGenericsAndAnnotations.getSignature(Class) and
> > getSignature(AccessibleObject) to VMI kernel class contract, please note
> > that the latter method needs to be refactored from getSignature(long).
> This
> > option can enable more code sharing between different VMs, because
> several
> > wrapped class, say Class.GACache, Constructor.ConstructorData, etc, and
> > several other methods can be VM independent.
> >
> > I've tried run tests sucessfully for both options.
> >
> > From modularity perspective, I think the latter one seems more elegant,
> but
> > it needs new API of VMI (although trivial refactory to DRLVM), so I'd
> like
> > to hear about others' comments. And also please let me know if I missed
> > something in DRLVM. Thank you all.
> >
> > 2006/12/27, Alexey Varlamov <al...@gmail.com>:
> > >
> > > There is HARMONY-2052 expressing exactly the same idea.
> > > Paulex, are you going to work on this?
> > >
> > > --
> > > Alexey
> > >
> > > 2006/12/27, Geir Magnusson Jr. <ge...@pobox.com>:
> > > >
> > > > On Dec 27, 2006, at 6:00 AM, Tim Ellison wrote:
> > > >
> > > > > Paulex Yang wrote:
> > > > >> Hi, all
> > > > >>
> > > > >> I found that IBM VME's kernel class implementation don't fully
> > > > >> support
> > > > >> generics related reflection, more specifically, the methods below
> > > > >> always
> > > > >> return null: (Oli? would you like to confirm?)
> > > > >>
> > > > >> j.l.r.Constructor.getGenericParameterTypes()
> > > > >> j.l.r.Constructor.getGenericExceptionTypes()
> > > > >> j.l.r.Field.getGenericType()
> > > > >> j.l.r.Method.getGenericReturnType()
> > > > >> j.l.r.Method.getGenericParameterTypes()
> > > > >> j.l.r.Method.getGenericExceptionTypes()
> > > > >> java.lang.Class.GetGenericInterfaces()
> > > > >> java.lang.Class.GetGenericSuperclass()
> > > > >>
> > > > >> So I looked at DRLVM's j.l.r.Constructor implementation, seems
> most
> > > > >> codes related generics reflection are VM neutral, such as classes
> in
> > > > >> o.a.h.l.r.parser, except several small native methods locate in
> > > > >> o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't
> > > > >> looked
> > > > >> into other classes but I won't be surprised if they aren't in
> similar
> > > > >> case. If so, it makes sense to me to extract the VM independent
> part
> > > > >> into class library codes as utilities, so that IBM VME(and other
> > > > >> Harmony
> > > > >> compatible VM) can also benefit from them, one obvious drawback
> > > > >> may be
> > > > >> some new VMI methods needed to access the VM implementation
> details.
> > > > >> Because lack of enough knowledge on either IBM VME or DRLVM
> > > > >> implementation, I'm not sure if it is a good idea. So any
> comments
> > > > >> from
> > > > >> DRL gurus and others?
> > > > >
> > > > > I know that you were asking for DRL gurus, but...
> > > > >
> > > > > this makes sense to me, looking at the logic in the DRLVM-specific
> > > > > types
> > > > > it appears that we can share that non-trivial logic across VM's
> and
> > > > > reduce the VM-specific parts to retrieving the raw data and
> calling
> > > > > those helpers.
> > > > >
> > > > > The logic place for such shared types would be in
> > > > > o.a.h.luni.internal.reflect.  Of course, it does not preclude VMs
> > > > > dealing with the API entirely themselves and not delegating to the
> > > > > helpers if they so choose.
> > > >
> > > > +1
> > > >
> > > > >
> > > > > Regards,
> > > > > Tim
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Labotary
> > IBM
> >
> >
>



-- 
Paulex Yang
China Software Development Labotary
IBM

Re: [vmi] Reflection support for generics

[Alexey Varlamov <al...@gmail.com>]

Hello Paulex,

Actually I thought about reversed order of steps, i.e. clean up impl
first then move it.
The point is that current impl is spaghetti-like, entangled with
internals of kernel classes. The very 1st step I suggest to get rid of
all o.a.h.l.reflect.** import clauses in j.l.Class except the Parser
itself (currently there are 16(!) imported classes). After that we'll
have more neat API and will better understand really needed
dependencies. Please ask if you need any assistance, I'm happy to take
part.

I do not quite understood 1), because the AuxiliaryChecker does not
belong to public API so cannot stay as kernel class. Regarding its'
purpose, I guess it implements some reflectionAPI-mandated checks,
e.g. this is the only code throwing
MalformedParameterizedTypeException, which is declared to be thrown by
public javadocs.

The 2) looks reasonable, except I do not think one ever needs
getSignature(AccessibleObject). Signatures of members are only needed
as input parameters to the parser.
And probably even getSignature(Class) is not needed, parser could do
just with public reflection API - though I did not try to verify this
speculation. So if the latter is true, we also have other option:
3) Don't change VMI, export an API from classlib like this:
Type o.a.h.l.reflect.GenericsParser.getType(String sig, Class owner);
TypeVariable[] o.a.h.l.reflect.GenericsParser.getTypeParameters(String
sig, Class owner);
...

As for sharing other classes like Class.GACache,
Constructor.ConstructorData, it may also be reasonable but would
certainly require further VMI extension. Let's do it step by step and
manage the parser first.

--
Alexey

2007/1/11, Yang Paulex <pa...@gmail.com>:
> Hi, sorry for the delay, I've just got some time to look at this issue now.
>
> I tried to move generic reflection support out from kernel class to LUNI at
> first, then look at the implementation itself, like JIRA-2052 requested.
>
> Currently I see four packages can be moved out:
> o.a.h.l.reflect.implementation
> o.a.h.l.reflect.parser
> o.a.h.l.reflect.repository
> o.a.h.l.reflect.support
>
> But there is one utility class o.a.l.r.s.AuxiliaryChecker, which depends on
> DRLVM specific org.apache.harmony.vm.VMGenericsAndAnnotations.getSignature(Class),
> so we have two options:
>
> 1. Don't add VMI methods, and keep AuxiliaryChecker in kernel class, this
> option is relative simple. According to class comments, AuxiliaryChecker is
> to check the correspondence of the formal parameter number and the actual
> argument number, I'm not sure yet about its purpose to check this during
> generics reflection.
>
> 2. Add VMGenericsAndAnnotations.getSignature(Class) and
> getSignature(AccessibleObject) to VMI kernel class contract, please note
> that the latter method needs to be refactored from getSignature(long). This
> option can enable more code sharing between different VMs, because several
> wrapped class, say Class.GACache, Constructor.ConstructorData, etc, and
> several other methods can be VM independent.
>
> I've tried run tests sucessfully for both options.
>
> From modularity perspective, I think the latter one seems more elegant, but
> it needs new API of VMI (although trivial refactory to DRLVM), so I'd like
> to hear about others' comments. And also please let me know if I missed
> something in DRLVM. Thank you all.
>
> 2006/12/27, Alexey Varlamov <al...@gmail.com>:
> >
> > There is HARMONY-2052 expressing exactly the same idea.
> > Paulex, are you going to work on this?
> >
> > --
> > Alexey
> >
> > 2006/12/27, Geir Magnusson Jr. <ge...@pobox.com>:
> > >
> > > On Dec 27, 2006, at 6:00 AM, Tim Ellison wrote:
> > >
> > > > Paulex Yang wrote:
> > > >> Hi, all
> > > >>
> > > >> I found that IBM VME's kernel class implementation don't fully
> > > >> support
> > > >> generics related reflection, more specifically, the methods below
> > > >> always
> > > >> return null: (Oli? would you like to confirm?)
> > > >>
> > > >> j.l.r.Constructor.getGenericParameterTypes()
> > > >> j.l.r.Constructor.getGenericExceptionTypes()
> > > >> j.l.r.Field.getGenericType()
> > > >> j.l.r.Method.getGenericReturnType()
> > > >> j.l.r.Method.getGenericParameterTypes()
> > > >> j.l.r.Method.getGenericExceptionTypes()
> > > >> java.lang.Class.GetGenericInterfaces()
> > > >> java.lang.Class.GetGenericSuperclass()
> > > >>
> > > >> So I looked at DRLVM's j.l.r.Constructor implementation, seems most
> > > >> codes related generics reflection are VM neutral, such as classes in
> > > >> o.a.h.l.r.parser, except several small native methods locate in
> > > >> o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't
> > > >> looked
> > > >> into other classes but I won't be surprised if they aren't in similar
> > > >> case. If so, it makes sense to me to extract the VM independent part
> > > >> into class library codes as utilities, so that IBM VME(and other
> > > >> Harmony
> > > >> compatible VM) can also benefit from them, one obvious drawback
> > > >> may be
> > > >> some new VMI methods needed to access the VM implementation details.
> > > >> Because lack of enough knowledge on either IBM VME or DRLVM
> > > >> implementation, I'm not sure if it is a good idea. So any comments
> > > >> from
> > > >> DRL gurus and others?
> > > >
> > > > I know that you were asking for DRL gurus, but...
> > > >
> > > > this makes sense to me, looking at the logic in the DRLVM-specific
> > > > types
> > > > it appears that we can share that non-trivial logic across VM's and
> > > > reduce the VM-specific parts to retrieving the raw data and calling
> > > > those helpers.
> > > >
> > > > The logic place for such shared types would be in
> > > > o.a.h.luni.internal.reflect.  Of course, it does not preclude VMs
> > > > dealing with the API entirely themselves and not delegating to the
> > > > helpers if they so choose.
> > >
> > > +1
> > >
> > > >
> > > > Regards,
> > > > Tim
> > >
> > >
> >
>
>
>
> --
> Paulex Yang
> China Software Development Labotary
> IBM
>
>

Re: [vmi] Reflection support for generics

[Yang Paulex <pa...@gmail.com>]

Hi, sorry for the delay, I've just got some time to look at this issue now.

I tried to move generic reflection support out from kernel class to LUNI at
first, then look at the implementation itself, like JIRA-2052 requested.

Currently I see four packages can be moved out:
o.a.h.l.reflect.implementation
o.a.h.l.reflect.parser
o.a.h.l.reflect.repository
o.a.h.l.reflect.support

But there is one utility class o.a.l.r.s.AuxiliaryChecker, which depends on
DRLVM specific org.apache.harmony.vm.VMGenericsAndAnnotations.getSignature(Class),
so we have two options:

1. Don't add VMI methods, and keep AuxiliaryChecker in kernel class, this
option is relative simple. According to class comments, AuxiliaryChecker is
to check the correspondence of the formal parameter number and the actual
argument number, I'm not sure yet about its purpose to check this during
generics reflection.

2. Add VMGenericsAndAnnotations.getSignature(Class) and
getSignature(AccessibleObject) to VMI kernel class contract, please note
that the latter method needs to be refactored from getSignature(long). This
option can enable more code sharing between different VMs, because several
wrapped class, say Class.GACache, Constructor.ConstructorData, etc, and
several other methods can be VM independent.

I've tried run tests sucessfully for both options.

>From modularity perspective, I think the latter one seems more elegant, but
it needs new API of VMI (although trivial refactory to DRLVM), so I'd like
to hear about others' comments. And also please let me know if I missed
something in DRLVM. Thank you all.

2006/12/27, Alexey Varlamov <al...@gmail.com>:
>
> There is HARMONY-2052 expressing exactly the same idea.
> Paulex, are you going to work on this?
>
> --
> Alexey
>
> 2006/12/27, Geir Magnusson Jr. <ge...@pobox.com>:
> >
> > On Dec 27, 2006, at 6:00 AM, Tim Ellison wrote:
> >
> > > Paulex Yang wrote:
> > >> Hi, all
> > >>
> > >> I found that IBM VME's kernel class implementation don't fully
> > >> support
> > >> generics related reflection, more specifically, the methods below
> > >> always
> > >> return null: (Oli? would you like to confirm?)
> > >>
> > >> j.l.r.Constructor.getGenericParameterTypes()
> > >> j.l.r.Constructor.getGenericExceptionTypes()
> > >> j.l.r.Field.getGenericType()
> > >> j.l.r.Method.getGenericReturnType()
> > >> j.l.r.Method.getGenericParameterTypes()
> > >> j.l.r.Method.getGenericExceptionTypes()
> > >> java.lang.Class.GetGenericInterfaces()
> > >> java.lang.Class.GetGenericSuperclass()
> > >>
> > >> So I looked at DRLVM's j.l.r.Constructor implementation, seems most
> > >> codes related generics reflection are VM neutral, such as classes in
> > >> o.a.h.l.r.parser, except several small native methods locate in
> > >> o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't
> > >> looked
> > >> into other classes but I won't be surprised if they aren't in similar
> > >> case. If so, it makes sense to me to extract the VM independent part
> > >> into class library codes as utilities, so that IBM VME(and other
> > >> Harmony
> > >> compatible VM) can also benefit from them, one obvious drawback
> > >> may be
> > >> some new VMI methods needed to access the VM implementation details.
> > >> Because lack of enough knowledge on either IBM VME or DRLVM
> > >> implementation, I'm not sure if it is a good idea. So any comments
> > >> from
> > >> DRL gurus and others?
> > >
> > > I know that you were asking for DRL gurus, but...
> > >
> > > this makes sense to me, looking at the logic in the DRLVM-specific
> > > types
> > > it appears that we can share that non-trivial logic across VM's and
> > > reduce the VM-specific parts to retrieving the raw data and calling
> > > those helpers.
> > >
> > > The logic place for such shared types would be in
> > > o.a.h.luni.internal.reflect.  Of course, it does not preclude VMs
> > > dealing with the API entirely themselves and not delegating to the
> > > helpers if they so choose.
> >
> > +1
> >
> > >
> > > Regards,
> > > Tim
> >
> >
>



-- 
Paulex Yang
China Software Development Labotary
IBM

Re: [OT] Earthquake in Taiwan (Re: [vmi] Reflection support for generics)

[Andrew Zhang <zh...@gmail.com>]

On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> On Dec 27, 2006, at 10:51 PM, Paulex Yang wrote:
>
> > Alexey Varlamov wrote:
> >> There is HARMONY-2052 expressing exactly the same idea.
> >> Paulex, are you going to work on this?
> > Sure, I'm very happy to...but unfortunately I got some serious
> > network problem to access ASF infrastructure(Jira/SVN, etc...)
> > recently(it is said that due to the earthquake in Taiwan yesterday,
> > wish the people involved good luck...)...so I may need a little
> > more time to look at it....
>
> I heard about this - it was reported as offshore and main effect was
> cutting of fibre optic cables?  Was anyone hurt?


It's reported that 2 people were killed, and 47 people were injured.

I heard it will take weeks to fix the fibre...


I can't access Harmony website, svn ... It's a good execuse for taking a
rest. :)

geir
>
> >>
> >> --
> >> Alexey
> >>
> >> 2006/12/27, Geir Magnusson Jr. <ge...@pobox.com>:
> >>>
> >>> On Dec 27, 2006, at 6:00 AM, Tim Ellison wrote:
> >>>
> >>> > Paulex Yang wrote:
> >>> >> Hi, all
> >>> >>
> >>> >> I found that IBM VME's kernel class implementation don't fully
> >>> >> support
> >>> >> generics related reflection, more specifically, the methods below
> >>> >> always
> >>> >> return null: (Oli? would you like to confirm?)
> >>> >>
> >>> >> j.l.r.Constructor.getGenericParameterTypes()
> >>> >> j.l.r.Constructor.getGenericExceptionTypes()
> >>> >> j.l.r.Field.getGenericType()
> >>> >> j.l.r.Method.getGenericReturnType()
> >>> >> j.l.r.Method.getGenericParameterTypes()
> >>> >> j.l.r.Method.getGenericExceptionTypes()
> >>> >> java.lang.Class.GetGenericInterfaces()
> >>> >> java.lang.Class.GetGenericSuperclass()
> >>> >>
> >>> >> So I looked at DRLVM's j.l.r.Constructor implementation, seems
> >>> most
> >>> >> codes related generics reflection are VM neutral, such as
> >>> classes in
> >>> >> o.a.h.l.r.parser, except several small native methods locate in
> >>> >> o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't
> >>> >> looked
> >>> >> into other classes but I won't be surprised if they aren't in
> >>> similar
> >>> >> case. If so, it makes sense to me to extract the VM
> >>> independent part
> >>> >> into class library codes as utilities, so that IBM VME(and other
> >>> >> Harmony
> >>> >> compatible VM) can also benefit from them, one obvious drawback
> >>> >> may be
> >>> >> some new VMI methods needed to access the VM implementation
> >>> details.
> >>> >> Because lack of enough knowledge on either IBM VME or DRLVM
> >>> >> implementation, I'm not sure if it is a good idea. So any
> >>> comments
> >>> >> from
> >>> >> DRL gurus and others?
> >>> >
> >>> > I know that you were asking for DRL gurus, but...
> >>> >
> >>> > this makes sense to me, looking at the logic in the DRLVM-specific
> >>> > types
> >>> > it appears that we can share that non-trivial logic across VM's
> >>> and
> >>> > reduce the VM-specific parts to retrieving the raw data and
> >>> calling
> >>> > those helpers.
> >>> >
> >>> > The logic place for such shared types would be in
> >>> > o.a.h.luni.internal.reflect.  Of course, it does not preclude VMs
> >>> > dealing with the API entirely themselves and not delegating to the
> >>> > helpers if they so choose.
> >>>
> >>> +1
> >>>
> >>> >
> >>> > Regards,
> >>> > Tim
> >>>
> >>>
> >>
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
> >
>
>


-- 
Best regards,
Andrew Zhang

[OT] Earthquake in Taiwan (Re: [vmi] Reflection support for generics)

["Geir Magnusson Jr." <ge...@pobox.com>]

On Dec 27, 2006, at 10:51 PM, Paulex Yang wrote:

> Alexey Varlamov wrote:
>> There is HARMONY-2052 expressing exactly the same idea.
>> Paulex, are you going to work on this?
> Sure, I'm very happy to...but unfortunately I got some serious  
> network problem to access ASF infrastructure(Jira/SVN, etc...)  
> recently(it is said that due to the earthquake in Taiwan yesterday,  
> wish the people involved good luck...)...so I may need a little  
> more time to look at it....

I heard about this - it was reported as offshore and main effect was  
cutting of fibre optic cables?  Was anyone hurt?

I heard it will take weeks to fix the fibre...

geir

>>
>> -- 
>> Alexey
>>
>> 2006/12/27, Geir Magnusson Jr. <ge...@pobox.com>:
>>>
>>> On Dec 27, 2006, at 6:00 AM, Tim Ellison wrote:
>>>
>>> > Paulex Yang wrote:
>>> >> Hi, all
>>> >>
>>> >> I found that IBM VME's kernel class implementation don't fully
>>> >> support
>>> >> generics related reflection, more specifically, the methods below
>>> >> always
>>> >> return null: (Oli? would you like to confirm?)
>>> >>
>>> >> j.l.r.Constructor.getGenericParameterTypes()
>>> >> j.l.r.Constructor.getGenericExceptionTypes()
>>> >> j.l.r.Field.getGenericType()
>>> >> j.l.r.Method.getGenericReturnType()
>>> >> j.l.r.Method.getGenericParameterTypes()
>>> >> j.l.r.Method.getGenericExceptionTypes()
>>> >> java.lang.Class.GetGenericInterfaces()
>>> >> java.lang.Class.GetGenericSuperclass()
>>> >>
>>> >> So I looked at DRLVM's j.l.r.Constructor implementation, seems  
>>> most
>>> >> codes related generics reflection are VM neutral, such as  
>>> classes in
>>> >> o.a.h.l.r.parser, except several small native methods locate in
>>> >> o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't
>>> >> looked
>>> >> into other classes but I won't be surprised if they aren't in  
>>> similar
>>> >> case. If so, it makes sense to me to extract the VM  
>>> independent part
>>> >> into class library codes as utilities, so that IBM VME(and other
>>> >> Harmony
>>> >> compatible VM) can also benefit from them, one obvious drawback
>>> >> may be
>>> >> some new VMI methods needed to access the VM implementation  
>>> details.
>>> >> Because lack of enough knowledge on either IBM VME or DRLVM
>>> >> implementation, I'm not sure if it is a good idea. So any  
>>> comments
>>> >> from
>>> >> DRL gurus and others?
>>> >
>>> > I know that you were asking for DRL gurus, but...
>>> >
>>> > this makes sense to me, looking at the logic in the DRLVM-specific
>>> > types
>>> > it appears that we can share that non-trivial logic across VM's  
>>> and
>>> > reduce the VM-specific parts to retrieving the raw data and  
>>> calling
>>> > those helpers.
>>> >
>>> > The logic place for such shared types would be in
>>> > o.a.h.luni.internal.reflect.  Of course, it does not preclude VMs
>>> > dealing with the API entirely themselves and not delegating to the
>>> > helpers if they so choose.
>>>
>>> +1
>>>
>>> >
>>> > Regards,
>>> > Tim
>>>
>>>
>>
>
>
> -- 
> Paulex Yang
> China Software Development Lab
> IBM
>
>

Re: [vmi] Reflection support for generics

[Paulex Yang <pa...@gmail.com>]

Alexey Varlamov wrote:
> There is HARMONY-2052 expressing exactly the same idea.
> Paulex, are you going to work on this?
Sure, I'm very happy to...but unfortunately I got some serious network 
problem to access ASF infrastructure(Jira/SVN, etc...) recently(it is 
said that due to the earthquake in Taiwan yesterday, wish the people 
involved good luck...)...so I may need a little more time to look at it....
>
> -- 
> Alexey
>
> 2006/12/27, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>> On Dec 27, 2006, at 6:00 AM, Tim Ellison wrote:
>>
>> > Paulex Yang wrote:
>> >> Hi, all
>> >>
>> >> I found that IBM VME's kernel class implementation don't fully
>> >> support
>> >> generics related reflection, more specifically, the methods below
>> >> always
>> >> return null: (Oli? would you like to confirm?)
>> >>
>> >> j.l.r.Constructor.getGenericParameterTypes()
>> >> j.l.r.Constructor.getGenericExceptionTypes()
>> >> j.l.r.Field.getGenericType()
>> >> j.l.r.Method.getGenericReturnType()
>> >> j.l.r.Method.getGenericParameterTypes()
>> >> j.l.r.Method.getGenericExceptionTypes()
>> >> java.lang.Class.GetGenericInterfaces()
>> >> java.lang.Class.GetGenericSuperclass()
>> >>
>> >> So I looked at DRLVM's j.l.r.Constructor implementation, seems most
>> >> codes related generics reflection are VM neutral, such as classes in
>> >> o.a.h.l.r.parser, except several small native methods locate in
>> >> o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't
>> >> looked
>> >> into other classes but I won't be surprised if they aren't in similar
>> >> case. If so, it makes sense to me to extract the VM independent part
>> >> into class library codes as utilities, so that IBM VME(and other
>> >> Harmony
>> >> compatible VM) can also benefit from them, one obvious drawback
>> >> may be
>> >> some new VMI methods needed to access the VM implementation details.
>> >> Because lack of enough knowledge on either IBM VME or DRLVM
>> >> implementation, I'm not sure if it is a good idea. So any comments
>> >> from
>> >> DRL gurus and others?
>> >
>> > I know that you were asking for DRL gurus, but...
>> >
>> > this makes sense to me, looking at the logic in the DRLVM-specific
>> > types
>> > it appears that we can share that non-trivial logic across VM's and
>> > reduce the VM-specific parts to retrieving the raw data and calling
>> > those helpers.
>> >
>> > The logic place for such shared types would be in
>> > o.a.h.luni.internal.reflect.  Of course, it does not preclude VMs
>> > dealing with the API entirely themselves and not delegating to the
>> > helpers if they so choose.
>>
>> +1
>>
>> >
>> > Regards,
>> > Tim
>>
>>
>


-- 
Paulex Yang
China Software Development Lab
IBM

Re: [vmi] Reflection support for generics

[Alexey Varlamov <al...@gmail.com>]

There is HARMONY-2052 expressing exactly the same idea.
Paulex, are you going to work on this?

--
Alexey

2006/12/27, Geir Magnusson Jr. <ge...@pobox.com>:
>
> On Dec 27, 2006, at 6:00 AM, Tim Ellison wrote:
>
> > Paulex Yang wrote:
> >> Hi, all
> >>
> >> I found that IBM VME's kernel class implementation don't fully
> >> support
> >> generics related reflection, more specifically, the methods below
> >> always
> >> return null: (Oli? would you like to confirm?)
> >>
> >> j.l.r.Constructor.getGenericParameterTypes()
> >> j.l.r.Constructor.getGenericExceptionTypes()
> >> j.l.r.Field.getGenericType()
> >> j.l.r.Method.getGenericReturnType()
> >> j.l.r.Method.getGenericParameterTypes()
> >> j.l.r.Method.getGenericExceptionTypes()
> >> java.lang.Class.GetGenericInterfaces()
> >> java.lang.Class.GetGenericSuperclass()
> >>
> >> So I looked at DRLVM's j.l.r.Constructor implementation, seems most
> >> codes related generics reflection are VM neutral, such as classes in
> >> o.a.h.l.r.parser, except several small native methods locate in
> >> o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't
> >> looked
> >> into other classes but I won't be surprised if they aren't in similar
> >> case. If so, it makes sense to me to extract the VM independent part
> >> into class library codes as utilities, so that IBM VME(and other
> >> Harmony
> >> compatible VM) can also benefit from them, one obvious drawback
> >> may be
> >> some new VMI methods needed to access the VM implementation details.
> >> Because lack of enough knowledge on either IBM VME or DRLVM
> >> implementation, I'm not sure if it is a good idea. So any comments
> >> from
> >> DRL gurus and others?
> >
> > I know that you were asking for DRL gurus, but...
> >
> > this makes sense to me, looking at the logic in the DRLVM-specific
> > types
> > it appears that we can share that non-trivial logic across VM's and
> > reduce the VM-specific parts to retrieving the raw data and calling
> > those helpers.
> >
> > The logic place for such shared types would be in
> > o.a.h.luni.internal.reflect.  Of course, it does not preclude VMs
> > dealing with the API entirely themselves and not delegating to the
> > helpers if they so choose.
>
> +1
>
> >
> > Regards,
> > Tim
>
>

Re: [vmi] Reflection support for generics

["Geir Magnusson Jr." <ge...@pobox.com>]

On Dec 27, 2006, at 6:00 AM, Tim Ellison wrote:

> Paulex Yang wrote:
>> Hi, all
>>
>> I found that IBM VME's kernel class implementation don't fully  
>> support
>> generics related reflection, more specifically, the methods below  
>> always
>> return null: (Oli? would you like to confirm?)
>>
>> j.l.r.Constructor.getGenericParameterTypes()
>> j.l.r.Constructor.getGenericExceptionTypes()
>> j.l.r.Field.getGenericType()
>> j.l.r.Method.getGenericReturnType()
>> j.l.r.Method.getGenericParameterTypes()
>> j.l.r.Method.getGenericExceptionTypes()
>> java.lang.Class.GetGenericInterfaces()
>> java.lang.Class.GetGenericSuperclass()
>>
>> So I looked at DRLVM's j.l.r.Constructor implementation, seems most
>> codes related generics reflection are VM neutral, such as classes in
>> o.a.h.l.r.parser, except several small native methods locate in
>> o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't  
>> looked
>> into other classes but I won't be surprised if they aren't in similar
>> case. If so, it makes sense to me to extract the VM independent part
>> into class library codes as utilities, so that IBM VME(and other  
>> Harmony
>> compatible VM) can also benefit from them, one obvious drawback  
>> may be
>> some new VMI methods needed to access the VM implementation details.
>> Because lack of enough knowledge on either IBM VME or DRLVM
>> implementation, I'm not sure if it is a good idea. So any comments  
>> from
>> DRL gurus and others?
>
> I know that you were asking for DRL gurus, but...
>
> this makes sense to me, looking at the logic in the DRLVM-specific  
> types
> it appears that we can share that non-trivial logic across VM's and
> reduce the VM-specific parts to retrieving the raw data and calling
> those helpers.
>
> The logic place for such shared types would be in
> o.a.h.luni.internal.reflect.  Of course, it does not preclude VMs
> dealing with the API entirely themselves and not delegating to the
> helpers if they so choose.

+1

>
> Regards,
> Tim

Re: [vmi] Reflection support for generics

[Tim Ellison <t....@gmail.com>]

Paulex Yang wrote:
> Hi, all
> 
> I found that IBM VME's kernel class implementation don't fully support
> generics related reflection, more specifically, the methods below always
> return null: (Oli? would you like to confirm?)
> 
> j.l.r.Constructor.getGenericParameterTypes()
> j.l.r.Constructor.getGenericExceptionTypes()
> j.l.r.Field.getGenericType()
> j.l.r.Method.getGenericReturnType()
> j.l.r.Method.getGenericParameterTypes()
> j.l.r.Method.getGenericExceptionTypes()
> java.lang.Class.GetGenericInterfaces()
> java.lang.Class.GetGenericSuperclass()
> 
> So I looked at DRLVM's j.l.r.Constructor implementation, seems most
> codes related generics reflection are VM neutral, such as classes in
> o.a.h.l.r.parser, except several small native methods locate in
> o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't looked
> into other classes but I won't be surprised if they aren't in similar
> case. If so, it makes sense to me to extract the VM independent part
> into class library codes as utilities, so that IBM VME(and other Harmony
> compatible VM) can also benefit from them, one obvious drawback may be
> some new VMI methods needed to access the VM implementation details.
> Because lack of enough knowledge on either IBM VME or DRLVM
> implementation, I'm not sure if it is a good idea. So any comments from
> DRL gurus and others?

I know that you were asking for DRL gurus, but...

this makes sense to me, looking at the logic in the DRLVM-specific types
it appears that we can share that non-trivial logic across VM's and
reduce the VM-specific parts to retrieving the raw data and calling
those helpers.

The logic place for such shared types would be in
o.a.h.luni.internal.reflect.  Of course, it does not preclude VMs
dealing with the API entirely themselves and not delegating to the
helpers if they so choose.

Regards,
Tim