[EBOB-DISCUSS] FWD: how to instantiate objects from a string or IType?

[Morley, L. M <lm...@WP...>]

I finally got a response on a post to the Eclipse newsgroup regarding
instantiating objects using Eclipse APIs. Here it is:

---

"We have such capability through the Visual Editor project. All you need =
is
the JEM (Jave EMF Model) feature, which is separately available from the =
VE
download page. It has complete function to allow starting the remote vm,
creating objects on it through different constructors (from the IDE's =
VM),
running methods, getting results, etc.=20

It is the org.eclipse.jem.proxy plugin that would be of interest...."

---

My original post involved having an object that implemented
org.eclipse.jdt.core.IType (IType objects represent either a source type
inside a compilation unit, or a binary type inside a class file) but not
knowing what to do with it, plus this:

Eventually, I want to be able to instantiate an object of this type =
through
any number of constructors (not just the default), and perform =
operations on
this object. I understand I'll probably have to start a new JVM to do =
this
all in. Do I need to create a new ClassLoader?...

-------

Justin and I will probably end up looking into this in the morning, and
hopefully have something worth discussing on Thursday. I think this is
probably one of the most important decisions regarding design..

Liam

=20

P.S. If you're interested in how BlueJ, bluEclipse, and the scrapbook =
handle
some of these issues:

bluEclipse has a custom class loader. It does not load a new JVM. If you =
call
System.exit(0) in bluEclipse, all of Eclipse will exit. It does not =
respond
to changes in the original resource. If you change a class definition =
for a
class currently in the OB, it will neither remove the object from the =
object
bench or update the class definition.

BlueJ isn't open source, but the System.exit(0) test only wipes out the
Object Bench, and it is then reinitialized, so it's clear that BlueJ =
runs the
OB in a separate JVM. It responds to any change in an original resource =
by
removing everything from the object bench (whether it was involved with =
that
resource or not).

The scrapbook also runs everything in a separate JVM, or at least =
catches
code like System.exit() (which throws some sort of special exception, =
which I
think is new to 3.0). However, the scrapbook will take chunks of code =
and
evaluate it; the internal objects are somewhat hidden, and it seems that
scrapbooks are written for one-time evaluation whereas we want our =
objects to
last beyond their construction.