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
