3.9. Forget CLASSPATH

Each paradigm of programming has certain “cardinal sins.” With unstructured programming languages such as BASIC, it's probably goto, which can easily create incomprehensible spaghetti code. With structured programming languages such as C, it's probably the use of switch on types, which tests a fixed set of conditions and does not evolve well with the application.^[5] With library-based object-oriented programming, it is the inclusion of the entire class library with the application, which creates software bloat.

^[5] “Anytime you find yourself writing code of the form, 'if the object is of type T1, then do something, but if it's of type T2, then do something else,' slap yourself.” [10]

Veteran programmers know that they can put classes they need to use on the CLASSPATH. When they begin working in a component-based framework such as that used in the Java Embedded Server product, many find it natural simply to put the bundle JAR file they have developed on the CLASSPATH. Some do this because they are frustrated by not being able to understand interbundle class resolution well or how to get it to work.

However, to add bundle JARs to the CLASSPATH is to commit a cardinal sin in this new paradigm. Once a bundle JAR is part of the CLASSPATH, it morphs into the underlying platform and can no longer be used as a component. You cannot control its life cycle, nor can you update it. Moreover, you do not have the benefit of per-bundle insulation provided by the framework: All classes inside the JAR file are made accessible to all bundles in the framework.

It is imperative that you use the Import-Package and Export-Package headers in bundle manifests to set up interbundle class resolution. The CLASSPATH should only contain classes that make up the framework.