Remote Method Invocation (RMI)

Paul C. Barr Prof. Steven A. Demurjian, Sr.

The Mitre Corporation Computer Science & Engrg. Dept.
CSE333
145 Wyckoff Road The University of Connecticut
Eatontown, NJ 07724 Storrs, CT 06269-3155
[email protected]
http://www.engr.uconn.edu/~stev
e
(860) 486 - 4818

JRMI-1.1
 Introduction
 The Core Java Classes That Made the Success of Java
Provides the Basic Building Blocks for Creating
CSE333
Robust Networked Applications.
 Those Classes Are All the Ones Included in the
Following Packages:
 java.applet,
 java.awt,
 java.io,
 java.lang,
 java.net and
 java.util.
 They Form the Base of the Java Framework That Was
Shipping in the Java Development Kit, Version 1.0.

JRMI-1.2
 Introduction
 The 1.1 Version of the JDK, Was an Essential
Improvement As the Kit Contained a Set of New
CSE333 API’s Specific to Distributed Computing:
 java.security,
 java.sql with sun.jdbc,
 java.beans, and
 java.rmi.

JRMI-1.3
 Introduction (Concluded)
 The Next Version JDK 1.2 Extends the Set of New
API's Specific to Distributed Computing:
 Enterprise Java Beans (EJB),
CSE333
 javaRMI Extensions
 java Naming and Directory Interface (JNDI),
 java IDL,
 java Transaction Systems (JTS),
 java Messaging Systems (JMS)

JRMI-1.4
 RMI defined
 Java Remote Method Invocation (RMI) Is an Inter-
process Protocol for Java, Allowing Java Objects
CSE333 Living in Different Java Virtual Machines to
Invoke Transparently Each Other's Methods.
 Since These Virtual Machines Can Be Running on
Different Computers Anywhere on the Network,
RMI Enables Object-oriented Distributed
Computing.
 Java RMI Provides the Java Programmers With an
Efficient, Transparent Communication Mechanism
That Frees Them of All the Application-level
Protocols Necessary to Encode and Decode
Messages for Data Exchange.

JRMI-1.5
 RMI CORBA metaphor
 Remote Objects Written in Java RMI Interact
Approximately in Much the Same Way CORBA
CSE333 Objects Do:
 Server Objects Publish Their Interfaces to Make
Them Available to RMI Clients;
 Stub Classes Deal With Binding to the Remote
Objects and Do the Client-side Data Marshaling;
 Skeleton Classes on the Server-side Handle
Incoming Calls.
 The Communication Mechanism Is Shown in the
Next Slide . Without Any Surprise, This Looks
Very Much Like the Elementary ORB Structure of
CORBA.
JRMI-1.6
 RMI CORBA Block Diagrams

CSE333

RMI Block Diagram

CORBA Block Diagram

JRMI-1.7
 Extensions included in RMI
 Java RMI Introduces a New Object Model to
Programmers:
 The Java Distributed Object Model, Which
CSE333
Naturally Extends the Pre-JDK1.1 Object
Model.
 A Few New Features or Divergence's Were
Added.
 The Results of a Remote Invocation, As Well
As the Arguments That Came Along With the
Initial Request, Are Passed by Value Rather
Than Reference.
 This Is Because Object References Are Only
Useful Within the Same Virtual Machine.

JRMI-1.8
 Extensions included in RMI
 New Features (Continued)
 Instead, Ordinary Objects Are Passed by Value, by
CSE333 Copy, Between Two Different Virtual Machines.
To Do This Copy Operation, RMI Uses the New
Object Serialization Service, Which Flattens a
Local Java Object's State Into a Serial Stream That
It Can Then Pass As a Parameter Inside a Message.
 A Remote Object, an Object That Implements the
java.rmi.Remote Interface, Can Nevertheless Be
Passed by Reference and Not by Copying the
Actual Implementation. Clients of Remote Objects
Interact With Remote Interfaces, Never With the
Implementation Classes of Those Interfaces.

JRMI-1.9
 Extensions included in RMI (Concluded)

 Clients That Invokes Methods on Remote Objects

CSE333 Have to Deal With Additional Interfaces and
Classes, but Also With a Whole New Set of
Exceptions.

 Extra Security Mechanisms Are Now Introduced

to Reinforce the Control of the Behavior of Java
Classes, and Most of All Stubs Classes.

 If a SecurityManager Is Not Explicitly Installed by

Server Objects, No Remote Invocation Will Be
Possible.
JRMI-1.10
 RMI Presentation
 Remote Method Invocation Is the Action of
Invoking a Method of a Remote Interface on a
CSE333 Remote Object. Therefore, We Must Provide Our
Server Object With the Interface Implementation
and Class Inheritance It Needs. We Must Also
Obtain the Stubs and Skeleton Classes Needed for
the Communication Between Remote Objects

 The Development Process Is Show in Next Slide

Where Bob Is the Server Developer and Alice the
Client One.

JRMI-1.11
 RMI Block Diagram for HelloWorld
Application
Client Server Hello

CSE333 HelloApplet HelloImpl

rmic HelloImpl.java
5 1 2 3
Stub Stub Skel Skel

Unmarshall Marshall Unmarshall Marshall

RMI Layer
NDR NDR NDR NDR

Transport Transport Transport Transport

4
Start rmiregistery

JRMI-1.12
 Hello.java

package examples.hello;
CSE333

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface Hello extends Remote {

String sayHello() throws
RemoteException;
}

JRMI-1.13
 HelloImpl.java
package examples.hello;

import java.rmi.Naming;
import java.rmi.RemoteException;
import java.rmi.RMISecurityManager;
CSE333 import java.rmi.server.UnicastRemoteObject;
public class HelloImpl extends UnicastRemoteObject
implements Hello {
public HelloImpl() throws RemoteException {
super();
}
public String sayHello() {
return "Hello World!";
}
public static void main(String args[]) {
// Create and install a security manager
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
try {
HelloImpl obj = new HelloImpl();
// Bind this object instance to the name "HelloServer"
Naming.rebind("HelloServer", obj);
System.out.println("HelloServer bound in registry");
} catch (Exception e) {
System.out.println("HelloImpl err: " + e.getMessage());
e.printStackTrace();
}
}
} JRMI-1.14
 HelloApplet.java
package examples.hello;

import java.applet.Applet;
import java.awt.Graphics;
import java.rmi.Naming;
CSE333 import java.rmi.RemoteException;
public class HelloApplet extends Applet {
String message = "blank";
// "obj" is the identifier that we'll use to refer
// to the remote object that implements the "Hello"
// interface
Hello obj = null;
public void init() {
try {
obj = (Hello)Naming.lookup("//" +
getCodeBase().getHost() + "/HelloServer");
System.out.println("Host = "+getCodeBase().getHost());
message = obj.sayHello();
} catch (Exception e) {
System.out.println("HelloApplet exception: " +
e.getMessage());
e.printStackTrace();
}
}
public void paint(Graphics g) {
g.drawString(message, 25, 50);
}
} JRMI-1.15
 RMI Steps
 The Different Steps That Must Follow to Get a
Server Implemented and Running Are:
CSE333
 1. Define the Server Interface. The Server
Object Declares Its Service Via a Remote
Interface, That Must Therefore Extends the
java.rmi.Remote Interface.

 2. Write the Server Code. HelloImpl Must

Provide the Java File Containing the Server
Class That Implements Its Server Interface, and
That Inherits From the
java.rmi.UnicastRemoteObject Class.

JRMI-1.16
 RMI Steps
 Different Step (Continued)

CSE333  3. You Need to Also Include the Code That

Will Install a SecurityManager and That Will
Register the Server Interface Within the RMI
Naming Context Using the Naming.Bind (or
Rebind) Method. The Daemon Program That Is
in Charge of the Naming Service Is
RMIregistry, and It Must of Course Be
Running for the Interface Registration to
Succeed.

JRMI-1.17
 RMI Steps (Concluded)
 Different Step (Continued)
 4. Compile the Server Class. First, Uses the
CSE333 Javac Compiler to Produce the Server .class
File, and Secondly, Run the rmic Compiler to
Obtain the Stub and Skeleton .class Files.
 5. Execute the Server Program. If the
RMIRegistry Daemon Is Not Already Running,
It Must Be Launched. He Can Then Run the
Java Interpreter With His Server .class File.
 6. Distribute the Stub Class. In Order to Get
Clients Calling the Methods of the Server, the
Stub Class That Has Been Generated Needs to
be Provided . This Will Enable Client Code to
Make Successful Requests to Server Object.
JRMI-1.18
 Java, JavaBeans and Java RMI
 Java Is "A Simple, Object Oriented, Distributed,
Interpreted, Robust, Secure, Architecture Neutral,
Portable, High-performance, Multithreaded and
CSE333
Dynamic Language".
 Javabeans Is the Specification for Building Reusable
Software Components (on the Client Side) Using Java.
 Java-RMI Ensures Communication Between Distributed
Program-level Java Objects Residing in Different
Address Spaces by Assuming a Homogeneous Java
Virtual Machine Environment.
 It Thus Takes Advantage of the Java Object Model
Whenever Possible to Support Distributed Objects in
the Java Environment.

JRMI-1.19
 Enterprise Java Beans
 Enterprise Javabeans (EJB) (for the Server Side)
Provides a Fully-scaleable, Distributed, and Cross-
CSE333 platform Architecture That Makes the Most of
Your Business Resources.
 Not Only Can These Components Run on Any
Platform, but They Are Also Completely Portable
Across Any Vendor's EJB Component Execution
System.
 The EJB Environment Automatically Maps the
Component to the Underlying Vendor-specific
Execution Services.

JRMI-1.20
 Java Remote Method Invocation
 Remote Method Invocation (RMI) Is the Object
Equivalent of Remote Procedure Calls (RPC).
CSE333  While RPC Allows You to Call Procedures Over
a Network, RMI Invokes an Object's Methods.
 In the RMI Model,
 The Server Defines Objects That the Client
Can Use Remotely.
 The Clients Can Now Invoke Methods of This
Remote Object As If It Were a
Local Object Running in the Same Virtual
Machine As the Client.
 RMI Hides the Underlying Mechanism of
Transporting Method Arguments and Return
Values Across the Network.
JRMI-1.21
 Java Remote Method Invocation

 In Java-RMI, an Argument or Return Value Can

CSE333 Be of Any Primitive Java Type or Any Other
Serializable Java Object. Works Over a Network.

JRMI-1.22
 Java-RMI and comparison with other
Middleware Specifications

 Java-RMI Is a Java-specific Middleware Spec That

CSE333 Allows Client Java Programs to Invoke Server Java
Objects As If They Were Local.

 Java-RMI Is Tightly Coupled With the Java Language.

There Are No Separate IDL Mappings That Are
Required to Invoke Remote Object Methods.

 This Is Different From DCOM or CORBA Where IDL

Mappings Have to Be Created to Invoke Remote
Methods.

JRMI-1.23
 Java-RMI and comparison with other
Middleware Specifications

 Since Java-RMI Is Tightly Coupled With the Java

CSE333 Language, Java-RMI Can Work With True Sub-
classes.
 Neither DCOM nor CORBA Can Work With
True Subclasses Since They Are Static Object
Models.

 Because of This, Parameters Passed During

Method Calls Between Machines Can Be True
Java Objects.
 This Is Impossible in DCOM or CORBA at
Present.
JRMI-1.24
 Java-RMI and comparison with other
Middleware Specifications (Concluded)

 If a Process in an RMI System Receives an Object

CSE333 of a Class That It Has Never Seen Before, It Can
Request That Its Class Information Be Sent Over
the Network.

 Over and Above All This, Java-RMI Supports

Distributed Garbage Collection That Ties Into the
Local Garbage Collectors in Each JVM.

JRMI-1.25
 Workings of Java-RMI

 Since Both the Client and the Server May Reside

CSE333 on Different Machines/processes, There Needs to
Be a Mechanism That Can Establish a
Relationship Between the Two.

 Java-RMI Uses a Network-based Registry

Program Called RMIRegistry To Keep Track of the
Distributed Objects.
 (Note: The RMI Registry Is an RMI Server
Itself!!!)

JRMI-1.26
 The RMI Registry
 The Server Object Makes Methods Available for
Remote Invocation by Binding It to a Name in the
CSE333 RMI Registry.

 The Client Object, Can Thus Check for the

Availability of a Certain Server Object by Looking
up Its Name in the Registry.

 The RMI Registry Thus Acts As a Central

Management Point for Java-RMI.
 The RMI Registry Is Thus a Simple Name
Repository. It Does Not Address the Problem
of Actually Invoking Remote Methods.
JRMI-1.27
 Stubs and Skeletons

 Since the Two Objects May Physically Reside on

CSE333 Different Machines, a Mechanism Is Needed to
Transmit the Client's Request to Invoke a Method
on the Server Object to the Server Object and
Provide a Response.

 Java-RMI Uses an Approach Similar to RPC in

This Regard.
 The Code for the Server Object Must Be
Processed by an RMI Compiler Called rmic,
Which is Part of the JDK.

JRMI-1.28
 Rmic Compiler
 The rmic Compiler Generates Two Files:
 A Stub and a Skeleton.
CSE333  The Stub Resides on the Client Machine and the
Skeleton Resides on the Server Machine.
 When a Client Invokes a Server Method, the
JVM Looks at the Stub to Do Type Checking.
 The Request Is Then Routed to the Skeleton on
the Server, Which in Turn Calls the
Appropriate Method on the Server Object. In
Other Words, the Stub Acts As a Proxy to the
Skeleton and the Skeleton Is a Proxy to the
Actual Remote Method.

JRMI-1.29
 Java RMI Internals

 The RMI Server Creates an Instance of the 'Server

CSE333 Object' Which Extends
UnicastRemoteObject

 The Constructor for UnicastRemoteObject

"exports" the Server Object - Basically Making It
Available to Service Incoming RMI Calls.
 A TCP Socket Which Is Bound to an Arbitrary
Port Number Is Created and a Thread Is Also
Created That Listens for Connections on That
Socket.

JRMI-1.30
 Java RMI Internals

 The Server Registers the Server Object With the

CSE333 Registry
 This Operation Actually Hands the Registry the
Client-side "Stub" for That Server Object.
 This Stub Contains the Information Needed
to "Call Back" to the Server When It Is
Invoked (Such As the Hostname/port of the Server
Listening Socket).

JRMI-1.31
 Java RMI Internals (Continued)
 A Client Obtains This Stub by Calling the
Registry, Which Hands It the Stub Directly.
CSE333  (This Is Also Where the “codebase” Comes In:
If the Server Specified a “codebase” to Use for
Clients to Obtain the Class File for the Stub,
This Will Be Passed Along to the Client Via
the Registry.
 The Client Can Then Use the codebase to
Resolve the Stub Class - That Is, to
Load the Stub Class File Itself).
 The RMIRegistry Holds Onto Remote Object
Stubs Which It Can Hand off to Clients When
Requested.

JRMI-1.32
 Java RMI Internals (Continued)
 When the Client Issues a Remote Method Invocation
to the Server, the Stub Class Creates a "RemoteCall"
CSE333 Which Basically
 (A) Opens a Socket to the Server on the Port
Specified in the Stub Itself, and
 (B) Sends the RMI Header Information As
Described in the RMI Spec.
 The Stub Class Marshals the Arguments Over the
Connection by Using Methods on
RemoteCall to Obtain the Output Stream Which
Basically Returns a Subclass of ObjectOutputStream
Which Knows How to Deal With Passing Objects
Which Extend java.rmi.Remote, Which Serializes
Java Objects Over the Socket
JRMI-1.33
 Java RMI Internals (Continued)
 The Stub Class Calls RemoteCall.executeCall
Which Causes the RMI to Happen.
CSE333
 On the Server Side, When a Client Connects to the
Server Socket, a New Thread Is
Forked to Deal With the Incoming Call.
 The Original Thread Can Continue Listening to
the Original Socket So That Additional Calls
From Other Clients Can Be Made.

 The Server Reads the Header Information and

Creates a RemoteCall Of Its Own to Deal With
Unmarshalling the RMI Arguments from the Socket.

JRMI-1.34
 Java RMI Internals (Concluded)
 The Server Calls the “dispatch” Method of the Skeleton
Class (the Server-side ”stub" Generated by rmic),
Which Calls the Appropriate Method on the Object and
CSE333
Pushes the Result Back Down the Wire (Using the Same
‘RemoteCall Interface Which the Client Used to
Marshall the Arguments).
 If the Server Object Threw an Exception Then the
Server Catches This and Marshals That Down the
Wire Instead of the Return Value.
 Back on the Client Side, the Return Value of the RMI Is
Unmarshalled (Using the RemoteCall as Created
Above) and Returned From the Stub Back to the Client
Code Itself.
 If an Exception Was Thrown from the Server that's
Unmarshalled and Re-thrown From the Stub.
JRMI-1.35
CSE333

Java 1.1 Event Model

Paul C. Barr
[email protected]

JRMI-1.36
 The Java 1.1 Event Model

 Event-handling Code Is the Heart of Every Useful

CSE333 Application.

 All Event-driven Programs Are Structured Around

Their Event-processing Model. Java Events Are
Part of the Java Abstract Windowing Toolkit
Package (AWT for Short)

JRMI-1.37
 The Java 1.1 Event Model

 People Who Are Familiar With the Ms-windows or

CSE333 X-windows SDK Programming, Remember That
the Windows Procedure Was Braced Against a
Flood of Events and Then a Giant ‘Switch’
Statement Was Used to Sort Through These Events.

 Similarly, in The Microsoft Foundation Classes

Programming Model or The Motif Programming
Model, Each Component Has to Be Over-ridden to
Make It Do What You Want It to Do - Something
Similar to the Older Java 1.0 Inheritance Event
Model.

JRMI-1.38
 The Java 1.1 Event Model (Continued)
 The First Approach Is the Easiest to Implement, but
Any Time You Use a Switch Statement, You
CSE333
Somehow Have This Nagging Feeling That Perhaps
There Is Something Un-object-oriented in the Design
or That a Different Class Hierarchy and Design Would
Have Made This Go Away.
 The Second Approach Is More Object-oriented, but
Involves a Great Deal of Work.
 With the New 1.1 Delegation Event Model, a
Component Can Be Told Which Object or Objects
Should Be Notified When the Component Generates a
Particular Type of Event.
 If a Component Is Not Interested in an Event Type,
Then Events of That Type Will Not Be Propagated.

JRMI-1.39
 The Java 1.1 Event Model
(According to Sun)
 Simple and Easy to Learn
 Support a Clean Separation Between Application
CSE333 and GUI Code
 Flexible Enough to Enable Varied Application
Models for Event Flow and Propagation
 For Visual Tool Builders, Enable Run-time
Discovery of Both Events That a Component
Generates As Well As the Events It May Observe
 Support Backward Binary Compatibility With the
Old Model
 Facilitate the Creation of Robust Event Handling
Code Which Is Less Error-prone (Strong Compile-
time Checking)
JRMI-1.40
 The 1.1 Delegation Event Model

 The 1.1 Event Model Is Based on the Concept of

CSE333 an ‘Event Source’ and ‘Event Listeners’.
 Any Object That Is Interested in Receiving
Messages (or Events ) Is Called an Event
Listener.
 Any Object That Generates These Messages
(or Events ) Is Called an Event Source.

JRMI-1.41
 The 1.1 Delegation Event Model
(Pictorial Representation)

CSE333

JRMI-1.42
 The 1.1 Delegation Event Model
(Continued)

 The Event Source Object Maintains a List of

CSE333 Listeners Who Are Interested in Receiving Events
That It Produces.
 The Event Source Object Provides Methods That
Allow the Listeners to Add Themselves
( ‘Register’ ) or Remove Themselves From This
List of ‘Interested’ Objects.
 When the Event Source Object Generates an
Event, or When a User Input Event Occurs on the
Event Source Object, the Event Source Object
Notifies All the Listeners That the Event Has
Occurred.
JRMI-1.43
 Event Source Object Implementation

//This is one typical Event Source Object implementation

public class EventSource extends Applet {
public Label m_Label;
CSE333 public Button m_Button;
public int m_nCounter;

public void init() {

m_Label = new Label( "Go ahead and click away." );
m_Button = new Button( "Click Here" );
EventListener listenerObject = new EventListener( this );
//Register with event source using addXListener
m_Button.addActionListener( listenerObject );

add( m_Label );
add( m_Button );
}

JRMI-1.44
 Event Listener Object
//This is one typical Event Listener Object implementation
class EventListener implements ActionListener {
private EventSource m_sourceObject;

CSE333 public EventListener( EventSource sourceObject ) {

m_sourceObject = sourceObject;
}

//This method handles the EventObjects fired by the EventSource Object

//Note: An ActionEvent is an EventObject
public void actionPerformed( ActionEvent e ) {
m_sourceObject.m_Label.setText( "That was click " +
( ++m_sourceObject.m_nCounter ) + " buddy." );
}

JRMI-1.45
 Event Object Interactions

 An Event Source Object Notifies an Event Listener

CSE333 Object by Invoking a Method on It and Passing It
an EventObject ( An Instance of a Subclass of
java.util.EventObject ).
 In Order for the Source to Invoke a Method on
a Listener, All Listeners Must Implement the
Required Method.
 This Is Ensured by Requiring That All Event
Listeners for a Particular Type of Event
Implement a Corresponding Interface.

JRMI-1.46
 Event Delegation Model

 The Java 1.1 Event Delegation Model Is Based on

CSE333 Four Concepts:
 The Event Classes
 The Event Listeners
 Explicit Event Enabling
 Adapters

JRMI-1.47
 Event Classes

CSE333

JRMI-1.48
 Event Class Specifics
 Every Event Is a Subclass of java.util.EventObject.
 It Is a Very General Class With Only One Method of
Interest:
CSE333
 Object getSource()
 This Method Returns the Object That Originated the
Event. Every Event Has a Source Object, From Which
the Event Originated. This Method Returns a Reference
to That Source.
 AWT Events, Which Is What We Are Concerned With Here,
Are Subclasses of java.awt.AWTEvent.
 This Is the Superclass of All the Delegation Model Event
Classes. The Most Interesting Method in This Class is int
getID()
 This Method Returns the ID of the Event. An Event’s ID
is an int That Specifies the Exact Nature of the Event.
This Value is Used to Distinguish the Various Types of
Events That Are Represented by Any Event Class.
JRMI-1.49
 AWT Events

 java.awt.event - The Subclasses of

CSE333 java.awt.AWTEvent Represent The Various Event
Types That Can Be Generated by the Various
AWT Components.
 All the Various Types of AWT Events, Are
Placed in a Separate Package Called
java.awt.event for the Sake of Convenience.

JRMI-1.50
 Types of Events
 ActionEvent Generated by Component Activation
 AdjustmentEvent Generated by Adjustment of Adjustable
Components Such As Scroll Bars
CSE333
 ContainerEvent Generated When Components Are Added to
or Removed From a Container
 FocusEvent Generated When a Component Receives Input
Focus
 ItemEvent Generated When an Item Is Selected From a List,
Choice or Check Box
 KeyEvent Generated by Keyboard Activity
 MouseEvent Generated by Mouse Activity
 PaintEvent Generated When a Component Is Painted
 TextEvent Generated When a Text Component Is Modified
 WindowEvent Generated by Window Activity Like
Minimizing or Maximizing
JRMI-1.51
 Handling Events

 There Are a Number of Ways to Handle the Events

CSE333 Listed Above.
 Object.
 Another Way Is to Explicitly Enable the
Originating Component to Handle Its Own
Events.

JRMI-1.52
 The Event Listeners

 Event Listeners Are Objects That Are Responsible

CSE333 for Handling a Particular Task of a Component.
 The Listener Typically Implements the
Interface That Contains Event-handling Code
for a Particular Component.
 For Instance, When the Component Experiences
Input, an EventObject of the Appropriate Type Is
Constructed and Is Passed As a Parameter to a
Method Call on the Listener:

JRMI-1.53
 //This is one typical Event Listener Object implementation
class EventListener implements ActionListener {
private EventSource m_sourceObject;
CSE333
public EventListener( EventSource sourceObject ) {
m_sourceObject = sourceObject;
}

//This method handles the EventObjects fired by the EventSource Object

//Note: An ActionEvent is an EventObject
public void actionPerformed( ActionEvent e ) {
m_sourceObject.m_Label.setText( "That was click " +
( ++m_sourceObject.m_nCounter ) + " buddy." );
}

JRMI-1.54
 The applet code that forms the Event
Source
//This is one typical Event Source Object implementation
public class EventSource extends Applet {
public Label m_Label;
public Button m_Button;
CSE333 public int m_nCounter;

public void init() {

m_Label = new Label( "Go ahead and click away." );
m_Button = new Button( "Click Here" );
EventListener listenerObject = new EventListener( this );
//Register with event source using addXListener
m_Button.addActionListener( listenerObject );

add( m_Label );
add( m_Button );
}

JRMI-1.55
  If You Notice the Code Fragment Above, an
Instance of the EventListener Class Is Created.
CSE333  This Instance listenerObject, is Set As One of the
Button's Action Listeners Using the
addActionListener() Method Call. All in All,
You Will Find a Standard Pattern Followed for
Giving a Listener to a Component. It Can Be
Summarized As Follows
 Create a Listener Class That Implements the
...Listener Interface
 Construct the Component
 Construct an Instance of the Listener Interface
 Call Add...Listener() on the Component, Passing in
the Listener
JRMI-1.56
 EventListener Removal

 An Event Listener May Be Removed From an

CSE333 Event Source's List of Interested Listeners by
Calling a Remove...Listener() Method, Passing in
the Listener Object to Be Removed. For Example,
in the Above Code Fragment, the Code Below
Removes the Action Listener Object listenerObject
From the Button m_Button.

 m_button.Removeactionlistener( listenerObject );

JRMI-1.57