Charles Oliver Nutter schrieb:
> Attila Szegedi wrote:
>> In my opinion, the vast majority of these woes would be eliminated if
>> Class would have a map for custom values exposed to user code.
>> Something not unlike how ThreadLocal works for per-thread state
>> ("ClassLocal"?)
>
> As with many things in JRuby, I hacked this exact use case using
> reflection on a Sun JDK. Basically I did the following:
>
> 1. Create a "TypeHolder" annotation
> 2. Create a "TypeHolderImpl" class that acts as a reference holder
> 3. Make "TypeHolderImpl" implement the "TypeHolder" annotation interface
> (requires code generation, obviously)
> 3. Using reflection, forcibly insert a "TypeHolderImpl" instance into
> the java.lang.Class annotation table
>
> Once you've done this, you can access the "attached" data by simply
> requesting the TypeHolder.class annotation from the Class object and
> casting it back to TypeHolderImpl.
>
> Hacky, sure. But it worked. I'm not using it for anything at present.
but this works only for classes that you can change. If it is a class
coming from some parent loader, that you have no control over, then it
won't work.. or do I see that wrong?
Maybe the typical usage scenario is different here with Groovy
bye Jochen
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
