Introduction

A simple "add two numbers" example is the classic way to learn Java RMI because it shows the full remote-call path without distracting business logic. The point is not the arithmetic. The point is understanding how a client invokes a method on an object living in another JVM through a remote interface, a registry lookup, and serialized request-response handling.

Start with a Remote Interface

Every RMI service begins with a remote interface that extends Remote. Each remotely callable method must declare RemoteException.

1import java.rmi.Remote;
2import java.rmi.RemoteException;
3
4public interface Adder extends Remote {
5    int add(int x, int y) throws RemoteException;
6}

This interface is the contract shared by client and server. The client does not need the server implementation class, but it does need this interface so it can invoke the remote method safely.

Implement the Remote Object

The server-side implementation usually extends UnicastRemoteObject.

1import java.rmi.RemoteException;
2import java.rmi.server.UnicastRemoteObject;
3
4public class AdderImpl extends UnicastRemoteObject implements Adder {
5    public AdderImpl() throws RemoteException {
6        super();
7    }
8
9    @Override
10    public int add(int x, int y) throws RemoteException {
11        return x + y;
12    }
13}

For this example, the remote logic is intentionally trivial. That is useful because it keeps the network mechanics visible.

Bind the Service in the Registry

The server must create an RMI registry or connect to one and bind the remote object under a name.

1import java.rmi.registry.LocateRegistry;
2import java.rmi.registry.Registry;
3
4public class Server {
5    public static void main(String[] args) throws Exception {
6        Adder service = new AdderImpl();
7        Registry registry = LocateRegistry.createRegistry(1099);
8        registry.rebind("AdderService", service);
9        System.out.println("AdderService ready");
10    }
11}

Using rebind is often easier during development because it replaces an existing binding if the service name was already registered.

In a distributed setup, the registry may run as a separate process or on another host. The idea stays the same: the server publishes a name, and the client resolves that name.

Look Up and Call the Service from the Client

The client contacts the registry, looks up the remote object, casts it to the shared interface, and calls the method as if it were local.

1import java.rmi.registry.LocateRegistry;
2import java.rmi.registry.Registry;
3
4public class Client {
5    public static void main(String[] args) throws Exception {
6        Registry registry = LocateRegistry.getRegistry("localhost", 1099);
7        Adder adder = (Adder) registry.lookup("AdderService");
8
9        int result = adder.add(5, 7);
10        System.out.println("Result: " + result);
11    }
12}

That local-looking call is the key idea behind RMI. Under the hood, Java handles marshalling, transport, and unmarshalling for you.

Understand What Actually Happens on the Network

Even though the client code looks simple, the call is remote. That means:

• latency is real
• connection failures are possible
• serialization rules still matter
• 'RemoteException is not optional boilerplate'

This is why remote methods should be designed as remote methods, not as ordinary in-process helpers. In the addition example the cost is invisible, but in real systems it shapes API design.

Compile and Run in a Predictable Order

A basic manual flow looks like this:

javac Adder.java AdderImpl.java Server.java Client.java
java Server
java Client

In modern Java versions, explicit stub generation is usually unnecessary for ordinary dynamic stub handling. Older RMI tutorials often include extra rmic steps, which can confuse readers working with newer JDKs.

That is one reason simple, updated examples are valuable: the core concept survives, but some historical boilerplate no longer does.

Common Pitfalls

• Forgetting that remote methods must declare RemoteException.
• Binding the service on the server but looking up a different name on the client.
• Treating remote calls as if they had the same cost and reliability as local method calls.
• Following outdated tutorials that assume manual stub-generation steps still apply universally.
• Sharing only the implementation class and forgetting that client and server both need the remote interface contract.

Summary

• Java RMI exposes remote methods through an interface that extends Remote.
• The server implements the interface and binds the object in an RMI registry.
• The client looks up the service by name and calls it through the shared interface.
• 'RemoteException is part of the contract because network calls can fail.'
• The addition example is simple by design, so the remote invocation flow stays visible.