Hacking The Java Library

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.