Java JSON-RPC Client Binding


Getting device information:

import com.raritan.idl.emdmodel.Emd_2_0_0;
import com.raritan.json_rpc.Agent;
import com.raritan.json_rpc.emdmodel.Emd_2_0_0_Proxy;
Agent agent = new Agent("https://my-emx.raritan.com");
Emd_2_0_0 emd = new Emd_2_0_0_Proxy(agent, "/model/emd");
Emd_2_0_0.MetaData metadata = pdu.getMetaData()._ret_;
System.out.println("Firmware version: " + metadata.fwRevision);

IDL-to-Java Mapping

Modules and Java Packages

The classes implementing Raritan JSON-RPC communication are contained in two separate Java package hierarchy: The namespace com.raritan.idl contains Java interface declarations for all IDL interfaces, and Java equivalents for named IDL data types like structures or enumerations. The com.raritan.json_rpc namespace contains proxy classes that implement those interfaces and relay any method calls to a remote device using JSON-RPC.

Interfaces and Methods

IDL interfaces are mapped to Java interfaces and implemented by proxy classes. Each method defined in IDL maps to three overloaded methods in the corresponding Java interface:

public class CreateAccountResult {
public int _ret_;
// Version 1: synchronous method call
CreateAccountResult createAccount(String username, String password) throws Exception;
// Version 2: asynchronous method call
AsyncRequest createAccount(String username, String password,
AsyncRpcResponse<CreateAccountResult> rsp);
// Version 3: asynchronous method call with custom options
AsyncRequest createAccount(String username, String password,
AsyncRpcResponse<CreateAccountResult> rsp,
RpcCtrl rpcCtrl);
  1. A synchronous variant which takes the same arguments as the IDL method declaration. This method will block the calling thread until the JSON-RPC communication is finished and the result is available. If the method has a return value or out-parameters those will be included in the result object returned by the method.
    This version of the method is the only one that may throw a Java exception in case of communication problems or an error response from the server.
  2. An asynchronous variant. This version of the method returns immediately without performing any network communication. Instead, the request is processed by a background thread. When it is finished, a method of the passed rsp response object is called: onSuccess in case the JSON-RPC call was successful, or onFailure when there was an error.
  3. An asynchronous variant with custom options. By default, the background thread can combine multiple method calls into a single HTTP request. If that's not desired it can be suppressed by setting an option in the passed rpcCtrl object.


IDL structures are mapped to Java classes with public members for each structure element. Those classes feature a default constructor and implement the Cloneable interface.

Enumerations, Vectors and Maps

IDL enumerations are mapped to plain Java enums. Vectors are mapped to java.util.List, and maps are mapped to java.util.Map.


Exceptional error conditions may occur because of communication problems or because of system errors that occur on the server while processing a request. Those "unexpected" error conditions are not a part of the regular IDL signature, so they are handled by using one of the following exceptions:

For synchronous method invocations the exceptions are thrown and can be intercepted with a try/catch block. For asynchronous method invocations the exception object is passed to the onFailure method of the result object.

Interface Versions

The Java bindings contain interfaces and proxies for all IDL interface versions that have been released up to the firmware release the bindings were generated for. Using those classes client programs can be written to be compatible with any firmware version up until the most recent release.

IDL interface names like pdumodel.Pdu_3_1_0 contain three separate version numbers:

  1. A major version. This number is incremented when the interface has changed in an incompatible way. A client program that is written to support Pdu_2_* may or may not work with a device that implements the Pdu_3_* interface.
  2. The middle number is the sub-major version. This number is incremented in case a referenced interface is changed in an incompatible way. A client can safely ignore the middle version number as long as it uses only methods of the interface itself. However, it should verify the type and version of any objects returned from an interface with a different sub-major number before using them.
  3. The last number, the minor version, is incremented on backward- compatible interface changes, e.g. when a new method was introduced. A client that was written to support the Pdu_3_1_0 interface is guaranteed to work with Pdu_3_1_1 or later without modification. Object references returned from an interface with compatible changes can be safely used without additional compatibility checks.

See the DumpPdu.java program distributed with this documentation for an example how to write a client program that supports multiple interface versions.

Bulk Requests

The Bulk RPC interface allows combining multiple JSON-RPC method calls into a single bulk request that can be sent to the server and processed in a single HTTP request. When using the asynchronous API the Java client library automatically adds all submitted requests into a bulk request queue. A background thread combines pending requests into a bulk request and sends it to the device. As a result, submitted requests can be delayed by up to 250 Milliseconds while the bulk RPC thread waits for more requests to be queued.

To bypass the bulk request queue, add an rpcCtrl parameter to the asynchronous method call. The following call will be immediately sent to the device as a dedicated JSON-RPC request:

Net_4_0_0 net = new Net_4_0_0_Proxy(agent, "/net");
net.getSettings(new AsyncRpcResponse<Net_4_0_0.GetSettingsResult>() {
public void onSuccess(Net_4_0_0.GetSettingsResult result) {
public void onFailure(Exception e) {
}, new RpcCtrl(RpcCtrl.Bulk.FORBID));

com.raritan.json_rpc.Agent Method Reference

Constructor: Agent(url)

Creates a new agent.


It is necessary to call setUsername()/setPassword() or setToken() before the first request.


This method sets the username for HTTP basic authentication.



This method sets the password for HTTP basic authentication.



This method enables and disables HTTP authentication using a session token. A session token can be obtained by calling the newSession method of the session.SessionManager interface.

Calling setToken(token) with a string variable which contains the token will enable token-based authentication.

When calling setToken(null), token-based authentication is disabled.