Design with dynamic extension

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

1 2 3 Page 3
Page 3 of 3

Why would you need name spaces? There are two reasons. Firstly, if your application may encounter name conflicts among the types it loads dynamically, you can use class loader objects to load types with potentially conflicting names into different name spaces. Browsers, for example, usually load applets from different sources into different name spaces. This enables a browser user to visit two different pages containing two applets written by two different people, both of whom may have given the same name to one of the classes that make up their applet. The second reason you may need name spaces is security. Java's linking model lets you shield types loaded into different name spaces from each other. You can design a system of dynamic extension in which types loaded into one name space can't even see types loaded into other name spaces. This capability is one aspect of Java's built-in security model. Security is the other reason (aside from avoiding potential name conflicts) that browsers usually load applets from different sources into different name spaces. It keeps untrusted applets from fooling around with trusted applets loaded from another source. However, this kind of security is optional, as the programmer who creates an application that dynamically extends itself via class loaders can decide to shield code in different name spaces from each other. It is also possible (at the programmer's option) to enable types loaded into one name space to get at and interact with types loaded into other name spaces.

  • Customizing the load process -- Another reason you might use class loaders is if you really need to customize the loading process. If you want to download class files across a network, for example, and the primordial loader doesn't know how, you'll need to write a class loader that can do it. This is another reason browsers use class loaders to load applets -- the primordial loader of the JVM used by the browser doesn't know how to download class files across the network.
  • Live replacement -- The third reason you might need a class loader is if you want to swap out a customization as an application is running. In other words, class loaders will enable you to dynamically extend your application with a class named Mouse, and later, to throw away that Mouse and dynamically extend the application with another class also named Mouse. You can't do this with forName() because once a type is loaded into a name space, it can't be removed unless the whole name space is removed. With a class loader, you can throw away a particular class loader object by dropping out all references to it, to any instances of any classes it loaded, and to any Class instances for the types it loaded. When you drop all these references, the class loader object and all the classes it loaded become unreferenced and available for garbage collection by the JVM. You can then create a new class loader object with a fresh (and empty) name space, and load the revised versions of the classes you just threw out with the old name space. This is how Web servers (running 24 hours a day, 7 days a week) enable servlet programmers to replace a servlet with a new version of the same servlet.

Next month

In next month's

Design Techniques

article, I'll talk about designing with type information.

A request for reader participation

I encourage your comments, criticisms, suggestions, flames (all kinds of feedback) about the material presented in this column. If you disagree with something, or have something to add, please let me know. You can either participate in a

discussion forum

devoted to this material, enter a comment via the form at the bottom of this article, or e-mail me directly, using the link provided in my bio below.

Bill Venners has been writing software professionally for 12 years. Based in Silicon Valley, he provides software consulting and training services under the name Artima Software Company. Over the years he has developed software for the consumer electronics, education, semiconductor, and life insurance industries. He has programmed in many languages on many platforms: assembly language on various microprocessors, C on Unix, C++ on Windows, Java on the Web. He is author of the book: Inside the Java Virtual Machine, published by McGraw-Hill.

Learn more about this topic

  • Bill's next book is Flexible Java
  • An complete online reprint of Chapter 7, "The Linking Model," of Bill's book Inside the Java Virtual Machine
  • The handout and slides for Bill's "Dynamic Extension in Java" talk
  • Bill recently returned from his European bike trip. Read about it at
  • The discussion forum devoted to the material presented in this article
  • Links to all previous Design Techniques columns
  • Recommended books on Java design
  • A transcript of an e-mail debate between Bill Venners, Mark Johnson (JavaWorld's JavaBeans columnist), and Mark Balbe on whether or not all objects should be made into beans
  • Object orientation FAQ
  • 7237 Links on Object Orientation
  • The Object-Oriented Page
  • Collection of information on OO approach
  • Design Patterns Home Page
  • A Comparison of OOA and OOD Methods
  • "Object-Oriented Analysis and Design MethodsA Comparative Review"
  • Patterns discussion FAQ
  • Patterns in Java AWT
  • Software Technology's Design Patterns Page
  • Previous Design Techniques columns
1 2 3 Page 3
Page 3 of 3