I don't see this being possible in a current JVM. You can not modify  
the contents of a method. The only way to bring new executable content  
into a running JVM today is through defineClass(). Once defined, you  
can't modify it.

John Rose has a good proposal for solving this with anonymous classes  
in the Da Vinci VM.

Attila.

On 2008.01.28., at 10:40, Yardena wrote:

> Also one more thought - could we create a pool of classes that have
> single method something like invoke(Class[], Object[]), then track the
> references ourselves and instead of creating new class modify the
> contents of the method in existing but unused class?
>
>  Yardena.
>
> On Jan 19, 5:05 am, Charles Oliver Nutter <[EMAIL PROTECTED]>
> wrote:
>> Kresten Krab Thorup wrote:
>>> So what I suggest is to have a new special kind of class loader
>>> (TransientClassLoader maybe) which doesn't have the strong link to
>>> classes loaded by it.  If this was a new class, then no existing  
>>> code
>>> would be broken by it; and so the new semantics for when a class is
>>> eligible for class unloading would only apply to classes loaded by
>>> transient class loader (ad subclasses thereof).
>>
>> This is *exactly* what I want. Unfortunately the only way to get it
>> right now is to hack the JDK or create your own version that calls  
>> out
>> to JNI to define the underlying class. But such an addition would  
>> be a
>> trivial piece of code to add to JDK.
>>
>> - Charlie





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM 
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to