One can imagine another arrow linking the BankClientLoader class with the system
class loader into the underlying JRE. We omitted it for clarity, but we will discuss its
implications later when talking about our custom class loader code.
Our proposed implementation consists of five classes, organized as described in the previous
Of course, this is a basic implementation. Our purpose is to show the basic structure of and ad-
hoc deployment solution providing full support for pre-existing code.
Before getting into the code details, let's recap each class role:
• ApplicationHelper . Launches the application.
• BankClientLoader . It is our custom class loader, created by the ApplicationHelper class.
• BankClientManager . This class encapsulates the communication protocol, providing
higher-level methods to business classes.
• BankClient . An example of a business class (a class that implements the business code).
• BankServer . The server that listens for client requests. For simplicity, we implemented
both the deployment server and the business server in this class.
When a user launches the client application, the ApplicationHelper is invoked, and after hav-
ing created an instance of itself and of the BankClientLoader , it issues a CHECK command
on the server.
Such a command is used for deployment only, and only the ApplicationHelper is assumed to
invoke it. After the CHECK command has been completed, the client cache is ready for appli-
cation execution, and the method launch in the ApplicationHelper launches the application
The heart of the deployment mechanism is the class loading procedure. Requested classes are
first searched into the local cache. By means of overwriting the cache contents, we are able to
launch new code transparently to both users and other running applications.
In Listing 6.2, the ApplicationHelper class is shown.