RE: [ve-dev] Re: Future of VE

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi Philippe,

"Philippe Ombredanne" <pombredanne@xxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

09/14/2007 11:05 AM

Please respond to
pombredanne@xxxxxxxxx; Please respond to
Discussions people developing code for the Visual Editor project        <ve-dev@xxxxxxxxxxx>

To	"'Discussions people developing code for the Visual Editor project'" <ve-dev@xxxxxxxxxxx>
cc
Subject	RE: [ve-dev] Re: Future of VE

Rich:
thanks for the kind reply. That creates a real good base for looking at
alternatives!

>but seriously I doubt it. Introspection is pretty mature and hasn't
changed in a long time. 
Introspection could help there I am sure.
Or what about that wacky idea: we now have open source java
implementations such as Harmony and Sun's itself. Maybe we could
investigate how we could use a patched VM (with all the IPzilla caveats
that would need to be adressed of course) to suit of needs.
That VM could be then pacakged to be shipped as private VM for VE only.
Sounds weird, but possible, or not?

>>> RLK >>> I think a better approach
would be to take an "opensource" copy of just the java.beans.Introspector
and rename it to something unique, keeping the appropriate copyrights.
And then either

• make all of the statics instead be instance methods/fields, and then have an Introspector instance per classloader (we could even then hook them together as classloaders are hooked together), and then depending on the classloader of the class use the correct Introspector for that classloader. Then there would be no conflicts with other Introspectors for other projects. And then if a project's classpath is changed, just throw away the introspector for the associated class loader. The introspectors could be chained together just like the classloaders are. That way anything from the base vm, such as java.swing.JPanel, would only be introspected once, instead of once for each project.
• A less intrusive change and closer to what we have now we be to just add a flushCache(Classloader) method that would go through the caches and remove anything for a class that is in the given classloader.

This all depends of course on the License of the chosen
opensource copy that you choose. Might need a lawyer first before you just
copy and modify some opensource vm and then reship in Eclipse. Maybe Eclipse
foundation can help there.


>These are things that need to be thought  about. Though the idea
of
separate classloaders is a good one. 
>JEM would need to be modified such that it understands classloaders.
>Right now it only loads classes from the application class loader.
>So the "class factories" would need to become "class
loader" proxies
instead. 
kk. Where would that be in JEM?

>>> RLK >>> I think these are implementation
of IBeanClassFactory or something like that.


Thanks, 
Rich