Re: [equinox-dev] Changes to DefaultClassLoader and EclipseClassLoader

[Martin Lippert <lippert@xxxxxxx>]

Hi,

Sorry for the late reply to this thread...

> To allow for more flexiblity to FrameworkAdaptor developers the 
> DefaultClassLoader and EclipseClassLoader have been change.
>
> The changes allow for a FrameworkAdaptor to have more control over the 
> construction and use of ClasspathEntry objects.  A new protected method 
> was added to DefaultClassLoader:
>
> protected ClasspathEntry createClassPathEntry(BundleFile, 
> ProtectionDomain)
>
> This allows Framework adaptors to extend DefaultClassLoader and to provide 
> their own implementation of ClasspathEntry class.  The defineClass and 
> findClassImpl have been changed to accept a ClasspathEntry instead of a 
> separate ProtectionDomain and BundleFile arguments.

This implementation works for my specialized adaptor implementation. But 
it also means some extra work for people subclassing EclipseClassLoader 
to implement their own class loading.

The reason is that the bundlefile field of 
DefaultClassLoader.ClasspathEntry is protected so that my subclass of 
EclipseClassLoader cannot read the field from the bundlefile parameter 
of the findClassImpl method. I have to create my own subclass of 
EclipseClassLoader.EclipseClasspathEntry, override the 
createClassPathEntry method and use an additioal accessor method of my 
classpath entry innerclass to get access to the bundlefile to load the 
bytecode.

This is of course possible, but makes things more complicated. A pure 
bundlefile object seems to be useless for subclasses. They need to 
define their own subclass of ClasspathEntry to make use of it. What do 
you think of that?

Best regards,
Martin

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature