Eclipse Community Forums: Visual Editor (VE) » [JEM] Reloading source files?

Help

Home

Home » Archived » Visual Editor (VE) » [JEM] Reloading source files?

Show: Today's Messages :: Show Polls :: Message Navigator

[JEM] Reloading source files? [message #84384]

Tue, 22 March 2005 05:55

Eclipse User

Originally posted by: lmorley.wpi.edu

Right now, we're using ProxyFactoryRegistry to initiate the JVM. When a
developer changes a class definition, we'd like this class definition to
be updated in the JVM. Is that possible to do without terminating the
registry completely?

To give you an idea of how we're using this, if you'd like, you can
check out our plug-in at http://ebob.sourceforge.net/ . It's roughly 80%
done. The screenshots might help as well.

A typical scenario would go like this. We have a container called an
"object bench". We start the registry and construct an object of type Z,
adding the object to the bench. We then change the class definition of
Z. This change is not reflected in the object currently on the bench, or
in a new object of type Z that we might add to the bench after making
the change, or to any object of any type. The object bench represents
the state of a project at the time of adding a first object (and thus
starting the registry), and only terminating the registry (and deleting
all of the objects) will solve that, as far as I know.

I'm hoping that I'm wrong.:)

Thanks,
Liam Morley
Worcester Polytechnic Institute
Undergraduate of Computer Science

Report message to a moderator

Re: [JEM] Reloading source files? [message #84399 is a reply to message #84384]

Tue, 22 March 2005 10:56

Joe Winchester

Messages: 496
Registered: July 2009

Senior Member

Hi Liam Morley,

> Right now, we're using ProxyFactoryRegistry to initiate the JVM. When a
> developer changes a class definition, we'd like this class definition to
> be updated in the JVM. Is that possible to do without terminating the
> registry completely?

I don't think it can be done without some kind of private access to the
JVM. Java's class loading mechanism is generally one way, so whenever a
class is first loaded this creates the blueprint for its instances and
morphing these into a new shape isn't supported. You can sort of do
this with a 1.4 JVM if it is started in -Xdebug model which the Eclipse
debugger supports if you alter a class during program execution then it
use a JVMDI API to hot swop the new class into the VM. Doing so however
requies morphing any instances of the old class definition into the new
class definition and the support of this varies depending on how well
the JVM supports JVMDI. Changing class shape is hard to morph instances
as it requires mapping the old instance variables into the slots for the
new ones and often a VM will just punt on the request and Eclipse's
debugger gives a "Unable to replace code - terminate, continue" type
dialog. Shape changes often occur without really knowing they will,
such as happens when an inner class is modified. How well Eclipse's
debugger works with different VMs varies - I find that often the j9 VM
works very well whereas other VMs can find hot swop harder.

In summary, I think if you cranked up the target VM in debug mode you
might be able to do some kind of hot swop. In normal non-debug mode
however there is no API to update class definitions. It is possible to
write a custom class loader that is able to retrieve the class from a
place you updated, however the hard part is instance morphing.

For these reasons what we do for the Visual Editor is start the target
VM in a run mode and when the class definition changes we just recycle
it. The IBeanProxy mechanism supports this without having to drop the
IDE VM because all of the live objects behind the proxies are dropped
and they recycle themselves with the new definition. Apart from the
performance hit involved with this, is there any reason why this isn't
actually sufficient as a design concept ?

> I'm hoping that I'm wrong.:)

Me too, We'd love to find a better way to deal with class updates within
a running workbench's target VM. There might be something we've not
considered, and possibly we should start a dialog with the Eclipse
platform and JDT teams.

Best regards,

Joe Winchester

Report message to a moderator

Re: [JEM] Reloading source files? [message #84414 is a reply to message #84399]

Tue, 22 March 2005 16:01

Eclipse User

Originally posted by: richkulp.us.NO_SPAM.ibm.com

If Proxy supported class loaders there might be a way. You would need to
throw away the classloader and any instances of the class and then
create a new classloader pointing to the updated classpath. However,
Proxy doesn't support this. It thinks all IBeanTypeProxy's are in the
application classloader, and will put them there automatically when
discovered.

This is something I had been thinking about, but it is a far off thing
and won't be implemented soon.

--
Thanks,
Rich Kulp

Report message to a moderator