Module rpc 

IDL-Service → Java-RPC-Codegen (DDS-RPC 1.0 §7.11.2 — Java-PSM).

Dieser Modul ist die Bruecke zwischen dem typisierten RPC-Datenmodell aus zerodds-rpc (ServiceDef/MethodDef/ParamDef) und dem Java-Source-Codegen. Pro Service emittieren wir vier Klassen:

• <Service>.java — synchrones Interface mit allen Methoden (throws RemoteException + User-Exceptions).
• <Service>Async.java — asynchrones Interface mit CompletableFuture<TOut>-Returns (Spec §7.11.2.2.4 mappt Future<T> auf java.util.concurrent.Future<T>; wir nutzen CompletableFuture als vollstaendige Implementierung).
• <Service>Requester.java — Client-Side: kapselt einen org.zerodds.rpc.Requester<TIn,TOut> und implementiert <Service> + <Service>Async.
• <Service>Replier.java — Server-Side: kapselt einen org.zerodds.rpc.Replier<TIn,TOut> und dispatcht eingehende Requests an einen <Service>Service-Handler.
• <Service>Service.java — Server-Side Handler-Interface: das Service-Implementor implementiert dieses Interface.

Out-Parameter

Java hat kein out/inout-Konzept. Wir mappen out/inout ueber das Holder-Pattern (Spec §7.11.2.3 / IDL-to-Java 1.3 §1.5):

public final class IntHolder {
    public int value;
    public IntHolder() {}
    public IntHolder(int v) { this.value = v; }
}

Holder werden nicht pro Service emittiert — wir referenzieren die generischen Holders aus org.zerodds.rpc.Holder<T> (siehe runtime/rpc/Holder.java). Begruendung: weniger Boilerplate als pro-Type-Holder, vollstaendig kompatibel mit dem Spec-Pattern (der Caller schreibt vor dem Aufruf in holder.value, der Reply-Decoder ueberschreibt nach Rueckkehr). Alternative Object[]-Wrapper waere type-unsafe und scheidet daher aus.

Exception-Mapping (Spec §7.11.2.1)

• IDL exception E { ... } → wir delegieren an den existierenden emit_exception_file-Pfad (E extends RuntimeException); der RPC- Codegen ergaenzt nur die throws E1, E2-Klausel auf der Methode.
• org.zerodds.rpc.RemoteException ist eine RuntimeException- Subclass, die jede RPC-Methode implizit werfen darf — wir setzen sie deshalb nicht explizit in den throws-Listen, weil RuntimeException in Java nicht checked ist.

Was diese Stufe NICHT macht

• Keine javac/mvn-Integration — der Output ist Skeleton-Java ohne JVM-Build-Verifikation.
• Keine JNI-Anbindung — Requester/Replier halten Object-Felder fuer den Native-Handle (Stub-Form).
• Keine Reflection-TypeRep (Stretch in idl4-java §8).

Functions

emit_replier_class

Emittiert die Server-seitige Replier-Klasse (<Service>Replier.java).

emit_requester_class

Emittiert die Client-seitige Requester-Klasse (<Service>Requester.java).

emit_service_files

Convenience-Wrapper: emittiert alle 5 Java-Files fuer ein Service.

emit_service_handler_interface

Emittiert das Server-side Handler-Interface (<Service>Service.java).

emit_service_interface

Emittiert das synchrone Service-Interface (<Service>.java).

emit_service_interface_async

Emittiert das asynchrone Service-Interface (<Service>Async.java).