This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Dynamic Enough for Customization
Posted by Bill Venners on 08 Jan 1999, 11:44 AM
> This method of dynamic extension still limits the program to
> be aware of the superclass of the classes that are loaded and the
> method signature.
Well you don't actually have to know a superclass. You can
know about a superinterface, for example. You can also just use
reflection to inspect the class and find things of interest.
That is what JavaBeans builders do when you drop a bean into
them: they dynamically extend themselves with the bean and
use reflection to find properties and methods of interest.
Most of the time, however, you will want to use a superclass
or superinterface, and I think that isn't very limiting. It
enables you to make your program customizable. The known
superclass or superinterface determines the way you interact
with the customization, but doesn't say how the customization
behaves. You need to know the interface at compile time, but
not the implementation.
> How is load library different form Class loader. One obvious
> difference is that "loadLibrary" loads system library and not class,
There are some similarities. loadLibrary() loads a native
library, like a DLL, which is dynamically linked at run time,
just like classes. And you don't necessarily have to know at
compile time the name of the DLL you'll load at run time. In
fact, you don't even have to know the class that has the native
methods in it at compile time, because you can load that
dynamically. But a class loader has its own namespace and
gets to define how type definitions are produced
given a fully qualified name. loadLibrary() just loads in
implementations for native methods.