AnonymousClassLoader overhaul

[Rémi Forax]

John Rose a écrit :
> On Apr 19, 2008, at 12:09 PM, Rémi Forax wrote:
>
>> Hi all,
>> there are several changes, i would like to apply on 
>> AnonymousClassLoader:
>> - make a clean separation between the classloader,  the constant pool
>> parser and
>>   the patch array.
>> - avoid to iterate over all constant pool entries when applying a patch
>>   on the same base class (remove indexOf() in makePatchArray)
>> - try to make it thread safe
>> - allocate the bytecode array using ByteBuffer instead of byte[]
>>    (not sure it's possible).
>> - generify it (Class => Class<?>)
>
> Those are all good moves on the road from demo to product... Thanks.


The source code is available here:
http://www-igm.univ-mlv.fr/~forax/tmp/davinci-anonk.zip

I've sent a previous message monday to the mlvm list but it seems it
was rejected because its size was too large (codes as attachment).
So i re-sent it now with a link.

The zip contains:
- AnonymousClassLoader: load class (or a patch) as inner-class of a host 
class.
- ClassPatch: a class and its patch array, it is created from a 
ConstantPoolParser
- ConstantPoolParser: parse the constant pool, call a visitor for each 
entry
- ConstantPoolVisitor: called  by  the parser,  can modified  a  patch  
using of of it's
  method put*.

AnonymousTest is a test

Why a visitor ? it avoid to reify the constant pool, i.e to create one 
object by entry,
this approach is not new, ASM use a similar trick.
After hesitation, i've decided to surface constant pool index instead of 
using opaque handle,
so at Java level, it's possible to try to change a constant pool entry 
by an incompatible one.

ClassPatch is now the only class that is mutable, the other are non 
mutable.

I'm not a native english speaker, so doc comments are written in
common (+french)  english, it will cool if someone can fix them :)

>
> When working with the CP parser, consider that we'll be wanting a 
> Java-only emulation of the loader.  For that we'll need to edit class 
> files as well as read them.  Note that ldc of non-string object will 
> require bytecode editing, not just CP editing.
Forward compatibility is cool but i'm not sure emulating an 
AnonymousClassLoader is a good idea.
I think it's not up to language implementors to simuate their features 
because they see the big picture.
Furthermore, bytecode editing is in my opinion too  hard to not use  
library  like  ASM or BCEL.

BTW, i now understand why you want MethodHandle to be impelemented by  
plain Java class.
>
> (Bytecode editing of extended invoke sites might also be a plausible 
> way to manage extensions like method handles...  But it's probably 
> easier to tell the language backend to sniff the JVM version and alter 
> its code generation in the first place.  Except for a few cases like 
> static bytecode compilation.)
yes
>
> -- John
>

Rémi