Java RMI为何无需骨架？新手对服务端参数处理的问询

Great question—since you’re coming from a basic RPC background, the move away from explicit skeletons in modern RMI can feel a bit hidden compared to the more hands-on setup you might be used to. Let’s break down who handles the key tasks like parameter unmarshalling and method routing now that skeletons are deprecated:

1. Request Reception & Parameter Unmarshalling #

This work is handled by the RMI Runtime Environment (built into the JVM) and the underlying transport layer (typically JRMP, Java Remote Method Protocol). Here’s how it flows:

• When a client sends a remote method call, the RMI transport first receives the raw byte stream.
• The RMI runtime then deserializes (unmarshals) the byte stream into Java objects—this includes extracting the method name, parameter types, and actual parameter values from the request.
• This unmarshalling relies on Java’s built-in serialization mechanism, so all parameters must implement Serializable (a key RMI requirement you might notice vs. some basic RPC systems).

2. Method Routing & Parameter Delivery #

Instead of a hand-generated skeleton class, modern RMI uses dynamic proxy classes created automatically by the JVM when you export a remote object (e.g., via UnicastRemoteObject.exportObject()). Here’s what the proxy does:

• It acts as an intermediary between the RMI runtime and your actual service implementation.
• After the runtime unmarshals the request, the proxy identifies which method on your service object needs to be called.
• It passes the unmarshalled parameters directly to the corresponding method in your service implementation class.

3. Result Marshalling & Response Sending #

Once your service method executes and returns a result, the dynamic proxy takes over again:

• It serializes (marshals) the result back into a byte stream.
• The RMI runtime sends this stream back to the client, which then unmarshals it into a usable object.

A Quick Note on Old vs. New RMI #

In early RMI versions, you’d use the rmic tool to generate a skeleton class manually—this class handled the unmarshalling and method routing logic explicitly. Now, the JVM generates these proxies on the fly, eliminating the need for manual skeleton code and making the setup much cleaner.

If you’re familiar with basic RPC where you might write custom code for marshalling/unmarshalling and request routing, think of RMI’s runtime + dynamic proxies as handling all that boilerplate for you out of the box.

内容的提问来源于stack exchange，提问作者Kopoj