Introduction

In Java RMI-style designs, a class that implements a remote interface can absolutely contain non-remote methods. Only the methods declared in the remote interface are remotely invocable through the remote stub. The rest of the implementation can contain ordinary helper methods, lifecycle logic, validation, caching, and internal utilities just like any other Java class.

Remote Exposure Is Interface-Driven

This is the key rule: a method is remotely accessible because it is part of the remote interface contract, not merely because it exists on the implementing class.

For example:

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

And the implementation:

1import java.rmi.RemoteException;
2import java.rmi.server.UnicastRemoteObject;
3
4public class CalculatorServiceImpl extends UnicastRemoteObject implements CalculatorService {
5    public CalculatorServiceImpl() throws RemoteException {
6        super();
7    }
8
9    @Override
10    public int add(int a, int b) throws RemoteException {
11        validateInput(a, b);
12        return a + b;
13    }
14
15    private void validateInput(int a, int b) {
16        // local helper method
17    }
18
19    protected void loadCache() {
20        // another local method
21    }
22}

validateInput and loadCache are normal local methods. They are part of the server implementation, not part of the remote contract.

Why Local Methods Belong in the Implementation

A remote object implementation usually needs far more behavior than what you want to expose over the network. Examples include:

• validation
• caching
• connection management
• logging
• authorization checks
• mapping internal exceptions to remote-friendly errors

Those concerns are implementation details. They do not belong in the remote API unless clients truly need to invoke them remotely.

The Client Only Sees the Remote Interface

A remote client normally works with a reference typed as the remote interface. That means it can only call methods declared there.

CalculatorService service = lookupRemoteService();
int result = service.add(2, 3);

The client cannot call loadCache() through that remote reference because that method is not part of CalculatorService.

This is good design. It keeps the remote surface small and intentional.

Remote Methods Need Remote Semantics

Methods exposed remotely typically declare RemoteException and should be designed with network behavior in mind:

• latency
• serialization cost
• partial failure
• versioning

Local helper methods do not need that shape. They can use normal exceptions, internal types, and server-specific optimizations freely.

That separation is another reason not to expose every implementation method remotely.

Public Does Not Automatically Mean Remote

One point that often confuses people is visibility. A method may be public on the implementation class and still not be remotely callable if it is not part of the remote interface contract being used by clients.

In other words:

• 'public controls Java visibility'
• remote-interface membership controls remote accessibility

Those are related but not identical concepts.

Keep the Remote API Small

A good remote API exposes coarse-grained operations that make sense over a network. It should not expose every internal helper just because the implementation happens to need them.

So a healthy design rule is:

• remote interface contains only client-facing operations
• implementation class contains remote methods plus internal local methods

That makes the network contract easier to evolve and easier to secure.

Common Pitfalls

• Assuming every method on the implementation class is automatically remotely callable.
• Exposing helper methods on the remote interface just because the implementation uses them internally.
• Forgetting that remote methods usually need network-aware exception and serialization design.
• Confusing Java visibility modifiers with remote accessibility.
• Making the remote interface too fine-grained and turning every internal step into a network call.

Summary

• A remote object implementation can contain both remote and non-remote methods.
• Only methods declared in the remote interface are remotely invocable through the remote reference.
• Local helper methods are normal and often necessary for good design.
• Keep internal logic out of the remote API unless clients truly need it.
• Treat remote accessibility as an interface contract, not as a property of the implementation class alone.