Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Design with dynamic extension

How dynamic extension works in Java and how to use it in your designs

By Bill Venners, JavaWorld.com, 01/01/99

Page 5 of 7

Dynamic linking and name spaces

When you compile a Java program, you get one class file for each type (class or interface) you define in source code. The class file is an intermediate compiled binary format for the type. Class files, which haven't been linked, contain symbolic references to other types in a list called the constant pool. At runtime, the JVM dynamically links the Java application by resolving the symbolic references contained in the constant pools of class files. This process is called constant pool resolution.

Name spaces in the JVM arise from a simple rule that all JVMs must follow when they resolve the symbolic references contained inside class files. Sometimes, an entry in a constant pool may refer symbolically to a type that hasn't yet been loaded. When such entries are resolved, the JVM must load the referred-to type. Because all types must be loaded by a class loader, the JVM must at that point decide which class loader to ask to load the type.

To choose a class loader, the JVM uses this simple rule:

The Resolution Rule - The JVM loads referenced types via the same class loader that loaded the referencing type.

An example with no dynamic extension

This one fundamental "Resolution Rule" of Java's linking model is what generates name spaces inside a JVM. If a class named Cat, for example, contains a symbolic reference to a class named Mouse, the JVM will load Mouse via the same class loader that loaded Cat. Because Mouse is loaded via the same class loader that loaded Cat, Mouse will end up in the same name space as Cat.

Thus, given these classes...

// In file dynaext/ex1/Cat.java
public class Cat {
    public static void main(String[] args) {
        Rodent myToy = new Mouse();
        myToy.scurry();
    }
}
// In file dynaext/ex1/Rodent.java
public class Rodent {
    public void scurry() {
        System.out.println("Rodent scurrying");
    }
}
// In file dynaext/ex1/Mouse.java
public class Mouse extends Rodent {
    public void scurry() {
        System.out.println("Mouse scurrying");
    }
}

the name spaces of the Cat application (just after scurry() is invoked on the Rodentreference) will look as shown in Figure 3. Because no class loader object is instantiated in this application, only one name space (that of the primordial class loader) exists. Because the primordial loader loaded Cat, the JVM will use the primordial loader to load Mouse.

Dynamic extension with forName()

Class java.lang.Class contains a static method, forName(), that enables you to dynamically load types into your program. For example, the following application, named Cat, dynamically loads classes that descend from Rodent, makes an instance, and invokes scurry() on the resulting object.