On 5/2/08, Rémi Forax <[EMAIL PROTECTED]> wrote:
>
> Jochen Theodorou a écrit :
>
> > John Wilson schrieb:
> >
> >> On 5/2/08, Jochen Theodorou <[EMAIL PROTECTED]> wrote:
> >>
> > [...]
> >
> >>> The major problem with code generating parts in the MetaClass I met
> >>> so far is class loading. If you want to do a direct call to
> >>> Foo#foo(X,Y), then you may do this:
> >>>
> >>> myAccessor = new Ivooo(){
> >>> void fvooo(Object o1, Object o2, Object o3) {
> >>> Foo foo = (Foo) o1;
> >>> foo.foo((X)o2,(Y)o3));
> >>> }
> >>> }
> >>>
> >>> Now the problems comes with in what classloader to place this class? Yo
> >>> may or may not have access to the class loader that was used for Foo. In
> >>> Groovy we had the Reflector and it was using a child to the ClassLoader
> >>> in which the class was defined in. If the ClassLoader behaves normally,
> >>> then nothing bad will happen. At that time we had the disadvantage of
> >>> needing an interface form the Groovy lib and if two Groovy where active,
> >>> then it was possible, that the normal classloading would load the wrong
> >>> one, causing class cast exceptions for our Reflector, when casting the
> >>> generated Reflector class to its interface. This version has the
> >>> advantage of using the system loader to generate and access the
> >>> interface, so there shouldn't be a problem with this.
> >>>
> >>> Besides that you only need to have a classloader that returns the same
> >>> class if you ask the loader for a certain class. Which means, there is
> >>> still some risk involved here.
> >>>
> >> I'm not quite sure I understand this problem.
> >>
> >> When you are creating a MetaClass you have the Class instance so you
> >> can get the classloader which loaded that class. Surely you can just
> >> use a classloader which delegates to the classloader which loaded the
> >> class to load the MetaClass?
> >>
> >
> > sure, you can. But when you execute your code, then it will cause the
> > loading of several classes that are used in the parent loader. And for
> > the method call not to end in an exception, you need to get the exact
> > same classes from the classloader. So if the loader does not behave as a
> > good little classloader should, then you are screwed.
> >
> > [...]
> >
>
> You need a classloader which is able to create your interfaces AND
> be able to load the classes used by the code.
> It's not a big deal if the user code follows the parent loader
> delagation scheme,
> you can change the application classloader and user defined classloaders
> will use it as parent.
>
> The trouble comes if the user use a classloader that doesn't follow the
> scheme.
> In my opinion, there is currently no way to work around that because
> the only solution i see is to be able to load interfaces using the boot
> classloader.
That's a good point, however consider this:
These interfaces are in a package that contains no other classes or
interfaces and the package *never* appears in the classpath.
It's therefor safe for the classloader which loads the MetaClass to
delegate requests for thinks in this one package to the classloader
which generates them on the fly and to delegate all other requests to
the classloader which loaded the class.
John Wilson
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
