headers
Alex Tkachman | 25 Jun 18:19

[groovy-dev] sun.reflect.Reflection usage

I noticed that we now use sun.reflect.Reflection.
Did I missed discussion how we will workaround on non-Sun platforms?

Alex

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Guillaume Laforge | 25 Jun 18:31

Re: [groovy-dev] sun.reflect.Reflection usage

On Wed, Jun 25, 2008 at 6:21 PM, Alex Tkachman
<alex.tkachman@...> wrote:
> I noticed that we now use sun.reflect.Reflection.
> Did I missed discussion how we will workaround on non-Sun platforms?

Where is it being used?
It's not a good idea to have such a tight dependency on one specific JVM.

--

-- 
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Chanwit Kaewkasi | 25 Jun 18:58

Re: [groovy-dev] sun.reflect.Reflection usage

Hi,

I ran grep through the trunk, and didn't find any place reference this class.

Chanwit

2008/6/25 Guillaume Laforge <glaforge@...>:
> On Wed, Jun 25, 2008 at 6:21 PM, Alex Tkachman
<alex.tkachman@...> wrote:
>> I noticed that we now use sun.reflect.Reflection.
>> Did I missed discussion how we will workaround on non-Sun platforms?
>
> Where is it being used?
> It's not a good idea to have such a tight dependency on one specific JVM.
>
> --
> Guillaume Laforge
> Groovy Project Manager
> G2One, Inc. Vice-President Technology
> http://www.g2one.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
(Continue reading)

Permalink | Reply |
headers
Alex Tkachman | 25 Jun 20:01

Re: [groovy-dev] sun.reflect.Reflection usage

newly create ReflectionsUtil

On Wed, Jun 25, 2008 at 8:58 PM, Chanwit Kaewkasi <chanwit@...> wrote:
> Hi,
>
> I ran grep through the trunk, and didn't find any place reference this class.
>
> Chanwit
>
> 2008/6/25 Guillaume Laforge <glaforge@...>:
>> On Wed, Jun 25, 2008 at 6:21 PM, Alex Tkachman
<alex.tkachman@...> wrote:
>>> I noticed that we now use sun.reflect.Reflection.
>>> Did I missed discussion how we will workaround on non-Sun platforms?
>>
>> Where is it being used?
>> It's not a good idea to have such a tight dependency on one specific JVM.
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> G2One, Inc. Vice-President Technology
>> http://www.g2one.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
(Continue reading)

Permalink | Reply |
headers
Guillaume Laforge | 25 Jun 20:47

Re: [groovy-dev] sun.reflect.Reflection usage

Yup, I see it:

http://svn.groovy.codehaus.org/browse/groovy/trunk/groovy/groovy-core/src/main/org/codehaus/groovy/reflection/ReflectionUtils.java?r=12878#l63

On Wed, Jun 25, 2008 at 8:01 PM, Alex Tkachman
<alex.tkachman@...> wrote:
> newly create ReflectionsUtil
>
> On Wed, Jun 25, 2008 at 8:58 PM, Chanwit Kaewkasi <chanwit@...> wrote:
>> Hi,
>>
>> I ran grep through the trunk, and didn't find any place reference this class.
>>
>> Chanwit
>>
>> 2008/6/25 Guillaume Laforge <glaforge@...>:
>>> On Wed, Jun 25, 2008 at 6:21 PM, Alex Tkachman
<alex.tkachman@...> wrote:
>>>> I noticed that we now use sun.reflect.Reflection.
>>>> Did I missed discussion how we will workaround on non-Sun platforms?
>>>
>>> Where is it being used?
>>> It's not a good idea to have such a tight dependency on one specific JVM.
>>>
>>> --
>>> Guillaume Laforge
>>> Groovy Project Manager
>>> G2One, Inc. Vice-President Technology
>>> http://www.g2one.com
>>>
(Continue reading)

Permalink | Reply |
headers
Chanwit Kaewkasi | 25 Jun 21:00

Re: [groovy-dev] sun.reflect.Reflection usage

OK, I've found it.

Cheers,

Chanwit

2008/6/26 Alex Tkachman <alex.tkachman@...>:
> newly create ReflectionsUtil
>
> On Wed, Jun 25, 2008 at 8:58 PM, Chanwit Kaewkasi <chanwit@...> wrote:
>> Hi,
>>
>> I ran grep through the trunk, and didn't find any place reference this class.
>>
>> Chanwit
>>
>> 2008/6/25 Guillaume Laforge <glaforge@...>:
>>> On Wed, Jun 25, 2008 at 6:21 PM, Alex Tkachman
<alex.tkachman@...> wrote:
>>>> I noticed that we now use sun.reflect.Reflection.
>>>> Did I missed discussion how we will workaround on non-Sun platforms?
>>>
>>> Where is it being used?
>>> It's not a good idea to have such a tight dependency on one specific JVM.
>>>
>>> --
>>> Guillaume Laforge
>>> Groovy Project Manager
>>> G2One, Inc. Vice-President Technology
>>> http://www.g2one.com
(Continue reading)

Permalink | Reply |
headers
Danno Ferrin | 25 Jun 23:34

Re: [groovy-dev] sun.reflect.Reflection usage

ReflectionUtils is used in griffon and grape modules, and it is also sensitive to the callsite refactorings on occasion, which i why I put it in core (so I can see when the fail, and not wonder weeks later what happened when I get time to work on them again).

As for the "sun spcific" part every JVM out there I can get my hands on has this API, so it's not really a sun specific JVM feature, just a sun specific name.

Furthermore, the usage is wrapped inside of a catch Exception, so class loading failrues won't through spurious exceptions (the null fro the call, however, is something that should be anticipated wether or not the call can succeed).

--Danno

On Wed, Jun 25, 2008 at 10:31 AM, Guillaume Laforge <glaforge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Wed, Jun 25, 2008 at 6:21 PM, Alex Tkachman <alex.tkachman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I noticed that we now use sun.reflect.Reflection.
> Did I missed discussion how we will workaround on non-Sun platforms?

Where is it being used?
It's not a good idea to have such a tight dependency on one specific JVM.

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
------------------------------------------------------
I'm Danno Ferrin, and I approved this message.
Permalink | Reply |
headers
Alex Tkachman | 26 Jun 00:06

Re: [groovy-dev] sun.reflect.Reflection usage

Could you please provide the list of JVMs you checked? I always was
wondered how wide is spread of this sun.* apis

The trick is it doesn't matter if it is wrapped in try/catch or not.
If the class not present in JVM you will have trouble. BTW, I am
almost sure that it is not enough to catc h Exception here - I would
suggest to catch Throwable.

If you really need this code could you please instead of using
non-standard class directly find it by reflection and use it if
present. It will be much more secure. The main problem here is
philosophical - if we start use it like this we will never stop :)

On Thu, Jun 26, 2008 at 1:34 AM, Danno Ferrin <danno.ferrin@...> wrote:
> ReflectionUtils is used in griffon and grape modules, and it is also
> sensitive to the callsite refactorings on occasion, which i why I put it in
> core (so I can see when the fail, and not wonder weeks later what happened
> when I get time to work on them again).
>
> As for the "sun spcific" part every JVM out there I can get my hands on has
> this API, so it's not really a sun specific JVM feature, just a sun specific
> name.
>
> Furthermore, the usage is wrapped inside of a catch Exception, so class
> loading failrues won't through spurious exceptions (the null fro the call,
> however, is something that should be anticipated wether or not the call can
> succeed).
>
> --Danno
>
> On Wed, Jun 25, 2008 at 10:31 AM, Guillaume Laforge <glaforge@...>
> wrote:
>>
>> On Wed, Jun 25, 2008 at 6:21 PM, Alex Tkachman <alex.tkachman@...>
>> wrote:
>> > I noticed that we now use sun.reflect.Reflection.
>> > Did I missed discussion how we will workaround on non-Sun platforms?
>>
>> Where is it being used?
>> It's not a good idea to have such a tight dependency on one specific JVM.
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> G2One, Inc. Vice-President Technology
>> http://www.g2one.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> ------------------------------------------------------
> I'm Danno Ferrin, and I approved this message.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Danno Ferrin | 26 Jun 06:42

Re: [groovy-dev] sun.reflect.Reflection usage


On Wed, Jun 25, 2008 at 4:06 PM, Alex Tkachman <alex.tkachman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Could you please provide the list of JVMs you checked? I always was
wondered how wide is spread of this sun.* apis

Well, some surprising results, which makes the reflection approach valid

J9 - has s.r.Reflection and it works
GCJ - Has s.r.Reflection but I cannot get it to run Groovy... :(
Harmony - does not have s.r.Reflection.  Crashed on ubuntu running the console anyway.
JRockit... ?? can't get my hands on it.  It's gone AWOL since the big O bought BEA out.  Somthing about paying customers...

So if groovy actually runs (since it pushes the limits of reflection and classloading) then it looks like ReflectionUtils will work.

 

The trick is it doesn't matter if it is wrapped in try/catch or not.
If the class not present in JVM you will have trouble. BTW, I am
almost sure that it is not enough to catc h Exception here - I would
suggest to catch Throwable.

It's been re-worked, the one place I reflect it I catch Throwable.
 

If you really need this code could you please instead of using
non-standard class directly find it by reflection and use it if
present. It will be much more secure. The main problem here is
philosophical - if we start use it like this we will never stop :)

Point taken.  Code has been re-worked.
 

------------------------------------------------------
I'm Danno Ferrin, and I approved this message.
Permalink | Reply |
headers
Alex Tkachman | 26 Jun 09:11

Re: [groovy-dev] sun.reflect.Reflection usage

Thank you Danno

On Thu, Jun 26, 2008 at 8:42 AM, Danno Ferrin <danno.ferrin@...> wrote:
>
> On Wed, Jun 25, 2008 at 4:06 PM, Alex Tkachman <alex.tkachman@...>
> wrote:
>>
>> Could you please provide the list of JVMs you checked? I always was
>> wondered how wide is spread of this sun.* apis
>
> Well, some surprising results, which makes the reflection approach valid
>
> J9 - has s.r.Reflection and it works
> GCJ - Has s.r.Reflection but I cannot get it to run Groovy... :(
> Harmony - does not have s.r.Reflection.  Crashed on ubuntu running the
> console anyway.
> JRockit... ?? can't get my hands on it.  It's gone AWOL since the big O
> bought BEA out.  Somthing about paying customers...
>
> So if groovy actually runs (since it pushes the limits of reflection and
> classloading) then it looks like ReflectionUtils will work.
>
>
>>
>> The trick is it doesn't matter if it is wrapped in try/catch or not.
>> If the class not present in JVM you will have trouble. BTW, I am
>> almost sure that it is not enough to catc h Exception here - I would
>> suggest to catch Throwable.
>
> It's been re-worked, the one place I reflect it I catch Throwable.
>
>>
>> If you really need this code could you please instead of using
>> non-standard class directly find it by reflection and use it if
>> present. It will be much more secure. The main problem here is
>> philosophical - if we start use it like this we will never stop :)
>
> Point taken.  Code has been re-worked.
>
> ------------------------------------------------------
> I'm Danno Ferrin, and I approved this message.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Danno Ferrin | 26 Jun 02:01

Re: [groovy-dev] sun.reflect.Reflection usage

Ok, I wrapped the usage inside of a reflected method, and return null in all cases the method is absent.  This shuold work for gcj and harmony (if harmony needs it).

On Wed, Jun 25, 2008 at 3:34 PM, Danno Ferrin <danno.ferrin-uuMoq9TLNRJBDgjK7y7TUQ@public.gmane.org> wrote:
ReflectionUtils is used in griffon and grape modules, and it is also sensitive to the callsite refactorings on occasion, which i why I put it in core (so I can see when the fail, and not wonder weeks later what happened when I get time to work on them again).

As for the "sun spcific" part every JVM out there I can get my hands on has this API, so it's not really a sun specific JVM feature, just a sun specific name.

Furthermore, the usage is wrapped inside of a catch Exception, so class loading failrues won't through spurious exceptions (the null fro the call, however, is something that should be anticipated wether or not the call can succeed).

--Danno


On Wed, Jun 25, 2008 at 10:31 AM, Guillaume Laforge <glaforge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Wed, Jun 25, 2008 at 6:21 PM, Alex Tkachman <alex.tkachman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I noticed that we now use sun.reflect.Reflection.
> Did I missed discussion how we will workaround on non-Sun platforms?

Where is it being used?
It's not a good idea to have such a tight dependency on one specific JVM.

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
------------------------------------------------------
I'm Danno Ferrin, and I approved this message.



--
------------------------------------------------------
I'm Danno Ferrin, and I approved this message.
Permalink | Reply |
headers
Paul King | 26 Jun 03:21

Re: [groovy-dev] sun.reflect.Reflection usage

Danno Ferrin wrote:
> Ok, I wrapped the usage inside of a reflected method, and return null in 
> all cases the method is absent.  This shuold work for gcj and harmony 
> (if harmony needs it).

Were you expecting it to pass on the 1.4 build?

Paul.

> On Wed, Jun 25, 2008 at 3:34 PM, Danno Ferrin <danno.ferrin@... 
> <mailto:danno.ferrin@...>> wrote:
> 
>     ReflectionUtils is used in griffon and grape modules, and it is also
>     sensitive to the callsite refactorings on occasion, which i why I
>     put it in core (so I can see when the fail, and not wonder weeks
>     later what happened when I get time to work on them again).
> 
>     As for the "sun spcific" part every JVM out there I can get my hands
>     on has this API, so it's not really a sun specific JVM feature, just
>     a sun specific name.
> 
>     Furthermore, the usage is wrapped inside of a catch Exception, so
>     class loading failrues won't through spurious exceptions (the null
>     fro the call, however, is something that should be anticipated
>     wether or not the call can succeed).
> 
>     --Danno
> 
> 
>     On Wed, Jun 25, 2008 at 10:31 AM, Guillaume Laforge
>     <glaforge@...
<mailto:glaforge@...>> wrote:
> 
>         On Wed, Jun 25, 2008 at 6:21 PM, Alex Tkachman
>         <alex.tkachman@...
<mailto:alex.tkachman@...>> wrote:
>          > I noticed that we now use sun.reflect.Reflection.
>          > Did I missed discussion how we will workaround on non-Sun
>         platforms?
> 
>         Where is it being used?
>         It's not a good idea to have such a tight dependency on one
>         specific JVM.
> 
>         --
>         Guillaume Laforge
>         Groovy Project Manager
>         G2One, Inc. Vice-President Technology
>         http://www.g2one.com
> 
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
> 
>            http://xircles.codehaus.org/manage_email
> 
> 
> 
> 
> 
>     -- 
>     ------------------------------------------------------
>     I'm Danno Ferrin, and I approved this message. 
> 
> 
> 
> 
> -- 
> ------------------------------------------------------
> I'm Danno Ferrin, and I approved this message.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Paul King | 26 Jun 03:22

Re: [groovy-dev] sun.reflect.Reflection usage

Danno Ferrin wrote:
> Ok, I wrapped the usage inside of a reflected method, and return null in 
> all cases the method is absent.  This shuold work for gcj and harmony 
> (if harmony needs it).

Were you expecting it to pass on the 1.4 test build?

Paul.

> On Wed, Jun 25, 2008 at 3:34 PM, Danno Ferrin <danno.ferrin@... 
> <mailto:danno.ferrin@...>> wrote:
> 
>     ReflectionUtils is used in griffon and grape modules, and it is also
>     sensitive to the callsite refactorings on occasion, which i why I
>     put it in core (so I can see when the fail, and not wonder weeks
>     later what happened when I get time to work on them again).
> 
>     As for the "sun spcific" part every JVM out there I can get my hands
>     on has this API, so it's not really a sun specific JVM feature, just
>     a sun specific name.
> 
>     Furthermore, the usage is wrapped inside of a catch Exception, so
>     class loading failrues won't through spurious exceptions (the null
>     fro the call, however, is something that should be anticipated
>     wether or not the call can succeed).
> 
>     --Danno
> 
> 
>     On Wed, Jun 25, 2008 at 10:31 AM, Guillaume Laforge
>     <glaforge@...
<mailto:glaforge@...>> wrote:
> 
>         On Wed, Jun 25, 2008 at 6:21 PM, Alex Tkachman
>         <alex.tkachman@...
<mailto:alex.tkachman@...>> wrote:
>          > I noticed that we now use sun.reflect.Reflection.
>          > Did I missed discussion how we will workaround on non-Sun
>         platforms?
> 
>         Where is it being used?
>         It's not a good idea to have such a tight dependency on one
>         specific JVM.
> 
>         --
>         Guillaume Laforge
>         Groovy Project Manager
>         G2One, Inc. Vice-President Technology
>         http://www.g2one.com
> 
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
> 
>            http://xircles.codehaus.org/manage_email
> 
> 
> 
> 
> 
>     -- 
>     ------------------------------------------------------
>     I'm Danno Ferrin, and I approved this message. 
> 
> 
> 
> 
> -- 
> ------------------------------------------------------
> I'm Danno Ferrin, and I approved this message.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Danno Ferrin | 26 Jun 06:34

Re: [groovy-dev] sun.reflect.Reflection usage



On Wed, Jun 25, 2008 at 7:22 PM, Paul King <paulk-V+QuBFElvc30CCvOHzKKcA@public.gmane.org> wrote:
Danno Ferrin wrote:
Ok, I wrapped the usage inside of a reflected method, and return null in all cases the method is absent.  This shuold work for gcj and harmony (if harmony needs it).

Were you expecting it to pass on the 1.4 test build?

Actually, I was expecting it would work just fine, and this shows the value of unit tests.

The problem is that 1.4 is not reflecting that a class as been marked as 'synthetic.'  When I first fixed this bug in Grape I had to check the super class to make sure it wasn't a callsite generated class.  This seemed inefficient, so I altered the markings on the class access that the call site gerenates at runtime to mark it as synthetic.  Spins like a top in 1.5, but 1.4 doesn't tell me if something is synthetic or not, the 1.4 VM just consumes the flag (or it doesn't reflect it as a bit field, I can't remember how the class file communicates this off hand).  I mean, who would know that?  Someone with way too much intimate knowledge of JVM internals, that's who, and that is not me.

This was suprising, so I had to re-introduce the old superclass checking code to support 1.4 for this API.  It's a slow call anyway, not well suited for tight loops, so more checking won't really hurt execution that much, just more code to look at.

------------------------------------------------------
I'm Danno Ferrin, and I approved this message.
Permalink | Reply |

Gmane