What I would like to see is a mechanism for completely extracting the use of the java.rmi package use into an SPI like mechanism. The ability to then plug in some other details or more limited environments like those would be possible.
I don't know any details, but I suspect that some of the use of RMI stiff was left over from the JSRs and maybe some was there as preparation for another eventual JSR attempt. In the end, RMI ended up not getting as much support, from the top brass and in the Sun Developer Advisory Council meetings, I detected some personality conflicts that were probably also a factor. Jonathan eliminated some of those... Gregg Wonderly Sent from my iPad On Apr 16, 2010, at 6:44 AM, Peter Firmstone <[email protected]> wrote: > Hi, > > I'm grappling with the Apache River / Jini public API and dependency problems. > > I'm looking at what's required to support a subset of Apache River on the > Java CDC Personal Profile (available on Blue Ray players and Amazon Kindle, > both of which have networking and sufficient resources), however there are > some issues which I have to work around: > > * Personal Profile doesn't contain the full RMI implementation > components http://java.sun.com/javame/reference/apis/jsr216/ > * Apache River has parts of the RMI implementation in Jini's public API. > > I'm thinking of ways to deprecate some methods, excluding them from Java CDC, > while keeping the depreciated methods on Java SE > , > My intent is that I'd like Java CDC Personal Profile to be able to > participate in a djinn using dynamic classloading to provide and consume > simple services and UI. Nodes running Java 5 or later can provide lookup > services or any other service that might benefit from java 5 or later > language features, I just want to support the absolute bare essentials to > provide or consume basic services on java CDC. > > JSR 66, the RMI spec for Java CDC is an optional api and not included in > Personal Profile, it also appears that the reference implementation is no > longer available from either Sun or IBM. > > So which parts of net.jini.* should be included in a release artifact for > Java CDC Personal Profile? > > I would prefer if the core release artifact supported all platforms from CDC > up, however maintaining backward binary compatibility in SE is important, so > that may not be possible. > > What are the consequences of leaving out the following packages in a Java CDC > profile? > > * net.jini.activation > * net.jini.iiop > * net.jini.jrmp > * net.jini.loader.pref > > The components of RMI available in Personal Profile are: > > * java.rmi.Remote > * java.rmi.RemoteException > * java.rmi.AccessException > * java.rmi.AlreadyBoundException > * java.rmi.NotBoundException > * java.rmi.UnexpectedException > * java.rmi.registry.Registry > > The components of RMI missing from Personal Profile are: > > * java.rmi.activation.* > * java.rmi.server.* > * java.rmi.dgc.* > * java.rmi.Naming > * java.rmi.RMISecurityManager > * java.rmi.ConnectException > * java.rmi.ConnectIOException > * java.rmi.MarshalException > * java.rmi.NoSuchObjectException > * java.rmi.RMISecurityException > * java.rmi.ServerError > * java.rmi.ServerException > * java.rmi.ServerRuntimeException > * java.rmi.StubNotFoundException > * java.rmi.UnknownHostException > * java.rmi.UnmarshalException > * java.rmi.registry.RegistryHandler > * java.rmi.registry.LocateRegistry > > The affected remaining components are: > > net.jini.io.MarshalledInstance > net.jini.discovery.LookupDiscoveryService > net.jini.core.lookup.ServiceRegistrar > net.jini.core.event.RemoteEvent > net.jini.jeri.BasicInvocationHandler > > Apache River's public API that contains parts of java RMI missing from CDC: > > (MarshalledInstance is a return type for other classes, CDC needs it's own > implementation that doesn't depend on java.rmi.MarshalledObject) > net.jini.io.MarshalledInstance > > public MarshalledInstance(java.rmi.MarshalledObject<T> mo) > public java.rmi.MarshalledObject<T> convertToMarshalledObject() > > RemoteEvent get's used everywhere and MarshalledObject is part of it's > serialized form, I have a solution for this). > net.jini.core.event.RemoteEvent > > public MarshalledObject getRegistrationObject() > > This interface is a little tougher, as there is only one method. > net.jini.discovery.LookupDiscoveryService > > public LookupDiscoveryRegistration register(String[] groups, > LookupLocator[] > locators, > RemoteEventListener > listener, > MarshalledObject > handback, > long leaseDuration) > > > One of the exceptions thrown is java.rmi.ConnectException, which is a > subclass of RemoteException, although not available in CDC, however. > net.jini.jeri.BasicInvocationHandler > > private static RemoteException wrapSafeIOException(IOException ioe, > ObjectEndpoint oe) > > Exporter throws an java.rmi.server.ExportException > net.jini.export.Exporter > > public Remote export(Remote impl) throws ExportException > > I'll commit shortly so you can see what I'm up to. > > Cheers, > > Peter.
