Background
One of the issues I ran into at some of my most recent project, is the classic classpath issue. In any Java project sooner or later too many classes and libraries (i.e. characters) are loaded onto the runtime classpath, either because of a lack of housekeeping or perhaps as a result of too much fragmented code.
Given the limited space of environment variables on some operating systems, this type of overflow on the classpath can result in the application failing to start (e.g. if the MainClass is not available) or ClassNotFound errors later on at runtime (e.g. a specific window uses a class that is not available). On Windows XP for instance there is a limit of 1023 characters for a single environment variable. Even if the CLASSPATH variable is not truncated the JVM must still search the CLASSPATH when loading classes, thus slowing down the applcation.
There are a number of structural ways to solve these issues, one being refactoring code. As projects often evolve over time, it is hard to trace back why certain code has found its way into the project workstream. This does nevertheless, still leave room for a number of other technical solutions to ‘crop’ the classpath down to a bare minimum.
Challenges
My current project uses a number of different subsets of code to form classpaths that are used in Eclipse, Build and Runtime. This makes it pretty hard for any outsider (like myself) to understand the logic and dependencies between libraries, classes, properties, etc. Some efforts have been made to document the history of certain jar files, however no documents give a complete overview of the full application landscape.
In essence the code in this project can be split into three big so-called ‘chunks’; vendor core code, vendor fixes code and custom (or Project) code. The correct working of the application heavily depends on the order of the these three code ‘chunks’. The JVM will want to access the vendor fixes code first, then the custom code and finally the vendor core code. Depending on the Operating System or Client Interface, the correct order may have to be reversed.
A Unix server will append classes (or jar files) at the start of the CLASSPATH variable. So in essence the vendor core code is loaded first, then the custom code and then the Calypso hotfixes. The JVM will be able to interpret this as it is suggested, but for instance when using Java Webstart, the JNLP files containing the classpath references will have to be loaded in the reversed order.
