While the term Service today is perhaps misunderstood, this is the
terminology that Jini uses, but really it means a runtime discoverable
remote dependency injection, so there is no dependency on the
implementation.  But it takes that one step further, there is also no
dependency on the communication protocol, the computer language or
platform used at the remote node.  The implementation code is
dynamically downloaded at runtime.

Furthermore, River allow's ServiceUI's to be defined for different
platforms, such as Android, or even a specif version of Android, so the
User Interface for a Service can be platform specific and multiple
implementations may exist for many platforms cooperating utilising
common distributed resources.

I'd like to create a port of Apache River to the Android Platform,
however, to do so, I'll need the following platform package classes from
java.rmi:

java.rmi.Remote
java.rmi.AccessException
java.rmi.RemoteException
java.rmi.UnexpectedException

Apache River has it's own implementation of Java RMI called JERI, an
extensible much improved totally new RMI, originally intended to replace
Java's RMI.

These files are very small and would not increase the platform footprint
much, but would make many new interesting and varied applications
possible utilising River.

Apache River is open source and distributed under the Apache License 2.0

Best Regards,

Peter Firmstone.

I've thought about it, however it creates issues with other platforms
for us with backward compatibility and Serialization.  This doesn't mean
that it's not possible, just not palatable.

At best we could change the exceptions (and more) and in a nutshell,
narrow it down to a single interface, 2 lines long we'd need included in
Android:

java.rmi.Remote:

    package java.rmi;
    public interface Remote {}

This is a core dependency of our application, spread throughout our
code, that would get us across the line.

Thanks,

Peter.