« PSOne LCD | Main | Overriding Java Classes: Part 2 »
January 03, 2006
Overriding Java Classes
It started simple enough, I wanted to override a default Java class (one that is contained within the java.* package) to provide enhanced functionality without clients having to rewrite their code. Could I have supplied my classepath in the -Xbootclasspath java parameter? No because I just overrode some classes, not reimplemented them. For example, I wanted to override java.io.File, which is dependent on native code. Since I didn't want to reimplement this native code I couldn't just provide another implementation of java.io.File, but needed to extend it and override the methods I wanted to change.
So what mechanism gives you the power to dictate which classes are loaded given a specific class name? That's right, the ClassLoader. All I would have to do is implement my own ClassLoader that would detect when java.io.File was being loaded and then load and return my own implementation. I figured this would work because my class extended java.io.File so it should virtually look like java.io.File and be castable to java.io.File. Unfortunately I received a ClassCirularityError when I tried this method.
As best I can determine, the ClassCircularityError happened because I tried to define my own class and maskerade it as java.io.File which made it look like my class was its own parent.
Another error I ran into was in defining the class. Once I had my class bytes loaded I tried to define my class as java.io.File. Unfortunately the Java ClassLoader that performs the actual definition (some native code) will not allow you to define a class within the java.* package (java.io.File, java.foo.bar, etc).
I think the only way to do what I want is to do some Byte Code Engineering [apache.org].
Posted by Guy at January 3, 2006 01:20 PM
Trackback Pings
TrackBack URL for this entry:
http://blog.lunaflare.net/cgi-bin/mt-tb.cgi/41