From: Morley, L. M <lm...@WP...> - 2004-11-30 08:25:08
|
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. |