In the Jini world, the protocol used between a proxy and a service is a private matter between those two objects. This works because the Jini system uses the RMI semantic notion of associating the proxy with the service and dynamically loading the proxy on demand. In effect, the proxy and the service form a single object that is itself distributed, with part of the object living in the address space of the client and part of the object living at the location of the service. This approach gives great flexibility to what protocol is actually used. Different services can invent their own specialized protocols that are optimized for that particular pair of proxy and service.
Protocols can evolve over time as new ideas are tried out.
But this also explains why the client's access to the network is Java environment-centric. For this approach to be viable, there needs to be a way of dynamically downloading code from the service to the client-code that the client can safely load into its address space and call. Java technology provides this kind of environment, and is the environment of choice for both RMI and Jini. For an RMI environment, all that is required is that the Java environment be running to allow the exportation of the Java classes that are the implementation of the references to the RMI object. All that is needed is a simple JNI wrapper, not a complete conversion.