That's an entirely different aspect -- there is the JVMTI (JVM Tools Interface) that allows you to do this kind of operations on a JVM from a native (C-linked) code module loaded into the JVM process itself - debugging, profiling, hot code replacement, whatnot. It is generally not available as an implementation-independent facility to programs running within the JVM itself. There are some "standard" native modules that'll then an out-of-process bridge for, say, debugging (i.e. a low-level JDI protocol upon which the higher level JPDA is built).
But JVMTI/JDI/JPDA can't be considered to be standard facilities available to code running within the JVM, so you it's generally a bad idea to base your code logic on them :-) Attila. On 2008.01.30., at 13:49, Marcelo Fukushima wrote: > > i think you can if you use the jvm agents like eclipse does to modify > running bytecode, but there are lots of restrictions > > On 1/30/08, Attila Szegedi <[EMAIL PROTECTED]> wrote: >> >> 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 [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 -~----------~----~----~----~------~----~------~--~---
