• ↑↓ pour naviguer
  • pour ouvrir
  • pour sélectionner
  • ⌘ ⌥ ↵ pour ouvrir dans un panneau
  • ←→ pour naviguer
  • esc pour rejeter
⌘ '
raccourcis clavier

The Problem

Sometimes we need the server to actually act on the client’s object, not a copy. How can RMI allow a remote method call to modify the original object on the client side?

Core Idea

In RMI, objects that implement the Remote interface are passed by reference. Instead of serializing the object, Java sends a stub that acts as a network proxy. All method calls on the stub are forwarded to the original object in the client’s JVM.

How It Works

  1. Client calls: remoteObj.method(remoteObject) where remoteObject implements Remote
  2. RMI sends a stub for remoteObject instead of serializing it
  3. Server receives stub as a reference
  4. When server calls methods on this stub, the calls go back over network
  5. The calls execute in the client’s JVM on the original object
  6. The server is actually modifying the client’s object
  7. This creates the illusion of shared memory across JVMs

Visual Explanation

G Client JVM Client JVM Original Object Server JVM Server JVM calls stub.method() Client JVM->Server JVM Stub sent Server JVM->Client JVM Method calls forwarded

Key Properties

  • Stub-based: A proxy is sent instead of the actual object
  • Shared behavior: Server’s actions affect original object
  • Network calls: Every method call on stub goes over network
  • Only for Remote objects: Regular objects cannot use this
  • Identity preserved: Original object is shared, not copied
  • Bidirectional: Communication can happen both ways

Connections

Edge Cases & Gotchas

  • Performance overhead: Every call on stub is a network call
  • If client JVM goes down, stub becomes invalid
  • Only Remote objects can be passed by reference
  • Latency: Calls can fail or be slow
  • Security: Remote object on client must be accessible