Runtime versus compile time,modularity(osgi)

Runtime versus compile time

Java typically has a flat classpath, whether at compile time or at runtime. In other words, applications normally have full visibility to any class that's found on the classpath, regardless of the order of entries in the classpath (assuming that there are no overlaps, at least; otherwise, first one wins). This enables the functionality of dynamic linking in Java; a class loaded from the front of the classpath need not have resolved all references to the classes that may be towards the rear of the classpath until they're actually required.

This is frequently used when working against a set of interfaces to which the implementation isn't known about until runtime. For example, an SQL utility can be compiled against the generic JDBC package, but at runtime (and with an additional piece of configuration information) can instantiate the correct JDBC driver. This is typically achieved through the name of a class (which implements a pre-defined factory interface or abstract class) being supplied to a Class.forName lookup at runtime. If the specified class doesn't exist (or can't be loaded for any other reason) an error is generated.

It's therefore quite likely that the compile time classpath is (subtly) different from the runtime classpath for a module. Further, each module is often compiled in isolation (module A may be compiled against module C 1.1, and module B may be compiled against module C 1.2) but then combined at runtime in a single path (and in this case, either arbitrarily choosing version 1.1 or 1.2 of module C). This leads quickly to Dependency Hell, especially when it is the transitive closure of these dependencies which forms the runtime classpath. Build systems like Maven and Ivy make modularity visible to developers, if not end users.

Java has an under appreciated feature called ClassLoaders which allow the runtime path to be more segmented. Typically, all classes are loaded from the system ClassLoader; however, some systems partition their runtime space with different ClassLoaders. A good example is Tomcat (or other Servlet engines) which typically have a one ClassLoader-per-WebApp. This allows a WebApp to function normally but not see (accidentally or otherwise) classes defined by other WebApps in the same JVM.

The way this works is that each WebApp loads classes from its own ClassLoader, so that a (local) WebApp's implementation doesn't load classes which conflict with another WebApp's implementation. The requirement is, for any ClassLoader chain, that the class spaces be consistent; this means you can have two Util.classes loaded from two separate ClassLoaders in your VM at one time, provided that these ClassLoaders aren't visible to one another. (It's also what gives the Servlet engine its ability to redeploy changes without a restart; by throwing a ClassLoader away, you throw away references to its classes as well, making the old version eligible for garbage collection – this then allows the Servlet engine to create a new ClassLoader and re-load the new versions of the classes in at runtime.)

InfoQ