Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Hacking Java libraries

Learn how to replace or patch application classes

By Alex Kalinovsky, JavaWorld.com, 05/10/04

Just about every developer at some point has used a library or a component developed by someone else. Just about every developer at some point has also gotten frustrated with the library to the point of being willing to find the guy who decided to make a method private and talk some sense into him. Well, most of us wouldn't go that far, but it would certainly be nice to be able to change things that make our lives miserable. It's not that libraries are written by mean people; it's just that even the brightest designers are unable to foresee all the possible ways that other developers would want to use their code.

Certainly, it is always better to resolve matters peacefully. If you can get the vendor to change his code, or if you are in a position to do it yourself, then certainly do so. But, in real life, the conventional approach does not always work. And this is where things get interesting. Having said that, when should you resort to replacing and patching classes? The following are several of the situations that call for a hacker approach:

• You are using a third-party library that has the capability you need, but it is not exposed through a public API: For example, until J2SE 1.4, Java Swing did not provide a method to obtain a list of JComponent listeners. The component would store the listeners in a package-visible variable with no public access to it, so there was no way to find out programmatically whether a component had event listeners.
• You are using a third-party class or an interface, but the functionality exposed is not flexible enough for your application: A simple change in the API can save you days of work or might be the only solution to your problem. In this case, you are happy with 99 percent of the library, but the remaining 1 percent prevents you from being able to use it effectively.
• There is a bug in the product or API you are using and you cannot wait for the vendor to fix it: JRun 3.0, for instance, had a bug in the JVM version detection on HP UX. While parsing the version string reported by the Java Runtime Environment, it would erroneously conclude that it was running under an older version of the JDK and refuse to run.
• You need a very close integration with a product, but its architecture is not open enough to satisfy your requirements: Many frameworks separate interfaces from implementation. Internally, interfaces are used to access functionality, and concrete classes are instantiated to provide the implementation. Java core libraries for the most part allow specifying implementation classes through system properties. This is the case for AWT (Abstract Windowing Toolkit) and SAX (Simple API for XML) parser, where implementation classes can be specified using the java.awt.toolkit and org.xml.sax.driver system properties, respectively. Hacking would be required if you needed to provide a different implementation class for a library that does not provide means of customization.
• You are using third-party code, but the expected functionality is not working: You are not sure whether it is because you are not using it correctly or because of a bug in the code. The documentation does not refer to the problem, and you do not have a workaround. Temporarily inserting debug traces and messages into the third-party code can help you understand what is happening in the system.
• You have an urgent production issue that has to be fixed: You also cannot afford to go through risky redeployment of the new code to the production environment. The solution to the problem requires a small change in the code that affects only a few classes.

If dealing with third-party code, you might be violating the license agreement, so be sure to read it and run it by your legal department to be safe. Copyright laws can be strictly enforced, and changing third-party code is often illegal. Get the vendor's permission to implement a solution rather than assuming responsibility for the hack. The good news is that by using the method presented in this chapter, you aren't making direct changes to the library or the product you are using. You aren't tampering with the code, but rather providing replacement functionality for the one you are not happy with. In a way, it is like deriving your class from the vendor's class to override a method, although this can be a slippery slope. Legal issues aside, let's see how you can go about doing this.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.