How is the following Java code useful, in the realm of autonomic computing?

Question

In a book I'm studying, they show this Java code :

Class c = ClassLoader.getSystemClassLoader().loadClass(name);
Class type = this.getClass().getClassLoader().loadClass(name);
Object obj = type.newInstance();

This code is used to dynamically load a Java class. The book goes on :

unloading modules raises an issue. A class loader cannot unload a class. Unloading a class requires unloading the class loader itself. This is why programmers .. tend to define several class loaders.

What is the benefit of using such code? The idea of autonomic computing is generally - "autonomic system administration." How does this relate to how a Java program is under the control of the JVM?

source: pg 166 of Autonomic Computing Principles Design (by Lalanda)

Answer 1

The benefit is that you can decide at runtime what class is actually loaded and used. For simple Java programs where you have one single implementation of a class there is no benefit.

Complex environments like Osgi (the basis of Eclipse) use individual classloaders for each module. That brings flexibility and the possibility to replace modules during runtime.

Another "classical" usecase is the loading of a database driver during runtime. You might want to connect to a MySQL database or Oracle and both use different implementations of JDBCDriver.

Addition:

A very nice article by Alex Blewitt that discusses the eclipse/osgi class loading concept can be found here.

In my own coding experience I used eclipse plugins for an enterprise level web-monitoring project. The monitoring basically is concerned with scraping constantly some resources on the network. Each such resource is monitored by an implementation of a monitor plugin. Not all resources are controlled by us, so when they change we must adapt the plugin that deals with that resource. The whole monitoring application can continue to operate while we unload the old plugin module against the new one. All in runtime, almost no downtime (only for the module that needed to be exchanged) Of course, my use of the classloader of each plugin was implicit by using the Eclipse Rich Client Platform (RCP). You just need to specify which plugin is dependent on which and the actual class loading is then done by the RCP platform.

Webservers like Tomcat use the same approach, although I do not have much experience with Tomcat.

It is maybe a good exercise to implement a dynamic class loading system directly, but for real world applications I would definitively look into the production grade implementations, like Eclipse RCP or Apache Karaf

If you want to take the whole thing one step further and need to run your plugins in a cluster, you may want to look into Gyrex

I can't share my code here, but here are some excellent starting points with code samples:

• http://www.vogella.com/tutorials/EclipsePlugIn/article.html
• https://karaf.apache.org/manual/latest-2.3.x/quick-start.html
• http://www.javaworld.com/article/2077837/java-se/hello--osgi--part-1--bundles-for-beginners.html

Answer 2

Assume following example. You develop a program. User can write some plug-ins (or agents in the context of autonomic programs) for it. Your program will load all plugins (or custom agent classes) defined in a configuration variable like:

plugins: foo.bar.myplug,another.plugin

In this situation, you need a dynamic load of the classes enumerated in the property. These classes are unknown when you develop the main program, normal class load can not be used.

Moreover, if for any reason you want to unload these classes (by example, after reread the configuration), you will need a custom class loader.

Addendum

We could, as example, imagine a program with a "world" where some "agents" interact. In addition to several agents included with the main program, an user can create its own agents.

Main program will take care of the interaction between agents (the world rules): sent events to agents; update the state of the world taken into account agents actions; save, load worlds; ... .

Each agent is a single Java class that must contain a method "public Action handleEvent( Event )" that is called by the main program. By default, some predefined classes like "Person.class", "SearchRobot.class", exists, each one with its own implementation of "handleEvent". All them extents the abstract class "Agent".

The program allows the user to create his own agents. User must create a new class (extend Agent) that contains the method "handleEvent". Take by example a user class "WalkerAgent.class" that has an heuristic short path to walk across the world.

The main program will also have a property called "plugins". This property must contain the list of user agents:

plugins: foo.bar.WalkerAgent 

when the main program starts, it should load all classes enumerated in the "plugins" property. Something like (pseudocode):

 read property "plugins" and split it by ","
 for each split in previous:
    call loadClass

In order to create a new instance of an agent of class "WalkerAgent" you can not write in main program a "new WalkerAgent()" because the class doesn't exists when main program is written. Instead, you must call "newInstance()" of the Class that "loadClass" returns.

Now, agent "WalkerAgent" is ready to be used in the same way that the predefined agents "Person" and "RobotSearch".

(PS: obviously, in autonomic computing, the world is, by example, a network description and the agents does actions like "monitor IP", "route optimizer", ... . This example has used easier concepts for easier understanding).