Given the vast amount of crap that we as programmers need to know these days (which is growing exponentially) I typically wrap unknowns into a black box and add them to my list to check out at a later time. java.lang.reflect.Proxy fell onto this list.

I typically associated a “magic” factor to anything that’s in the core Java classes. Take for example how NIO’s InterruptibleChannel interacts with Thread. I still want to know how Sun expects third parties to use the SPI to create other NIO implementations but that’s another battle for another day.

I assumed incorrectly that Proxy had some magic tie-ins to the JVM that allowed it to masquerade as another class. Instead, Proxy actually goes the sane route. It generates a class (as a byte array) using reflection to inspect the specified interfaces. The class is then loaded using something very similar to ClassLoader.defineClass() (why it does not just use ClassLoader is not known but if there is one thing that I’ve learned over there years is that programmers love to keep secrets). By default, these generated files are not persisted to disk. You can set the system property sun.misc.ProxyGenerator.saveGeneratedFiles to true to save the files for examination (I do not know where they are saved to).

It’s actually unfortunate that Proxy does not use JVM magic since then it might be possible to create a proxy to a class (rather than just interfaces) which would provide a truely useful generic proxy mechanism (facilitating AOP, for example).



  1. CGLIB is a great suggestion. I was playing around with Javassist and BCEL today and didn’t get too far other than to realize that no matter how thin I slice it, I’ll probably need to use -Xbootclasspath/p for a generic solution when dealing with “java.*”. Oh why can’t I disable this crapola if I’m executing in my own environment? Had they delegated to the security manager in ClassLoader.defineClass() life would be good, but noooo.
    BTW: I really liked your “Transparent asynchronous methods using annotations” article. That’s some good stuff to noodle over.

  2. And I should mention that my “It’s actually unfortunate that Proxy does not use JVM magic …” statement meant that it would be nice if Proxy would do what it currently does for interfaces, what Mr. Nokleberg suggests for non-final classes (i.e. generate a subclass) and whatever else for the final ones (JVM magic) so that it was a one-stop-shop. (Heck, I’d be happy even if it didn’t do the final class case.)
    I just didn’t want to look like a bigger boob than I actually am by not suggesting subclassing for classes. Not that I’m against bigger boobs or anything ….

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s