A small ClassLoader change proposal

[Jevgeni Kabanov]

On 16.09.2010, at 17:51, Bob Lee wrote:

>  
> Unfortunately what I found out is that it doesn't work with some class loaders. Mainly because there are class loaders that at some point in their life cycle will throw an exception when a loadClass() is issued, and even if you use defineClass() a loadClass() is still issued for java.lang.Object when defining your class for the first time, causing an exception. So in the end I'm not using that code either, but I would be using it if it was safe.
> 
> Ugh. That's unfortunate.
> 
> You could submit a patch to OpenJDK. Patching ClassLoader on the fly sounds like a better idea though; it'd take years before you'd be able to use a patch.

Unfortunately you can't patch the ClassLoader like that via Instrumentation (it adds a new field), and I wouldn't like to enforce the bootstrap override as it's way clumsier than a -javaagent.

I will find some kind of solution that'll work for me, but it just seemed to me such a small change that the JDK7 could carry it and make someone else's life easier in the future. 

> You could patch all ClassLoader subclasses instead. That would be easier to do on the fly than patching ClassLoader itself. You'd instrument loadClass() so that if you're loading ClassLoaderLocals, it would run your loadClass() code (which would retrieve classes in the system classloader) instead of the original code which would otherwise throw an exception.

Yep, that's pretty much what I'm doing/thinking of doing right now. But it needs special handling for URLClassLoader that is defined in the bootstrap and some others. It's a pretty complicated solution to a pretty small and common problem, all-in-all.

JK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/f20054fd/attachment.html>