This brings up an interesting question which I mentioned in passing in
an earlier email. Sun's JDK1.3 has the capability of generating classes
at runtime which implement particular interfaces - when any method is
called, a callback method is invoked, with the method that was called
and the arguments.
This would make writing something *like* RMI very simple, of course -
the callback method would just need to serialize the method and the
arguments and send it across the wire. There would be no need to
generate stubs at compile time at *all*. I was wondering if it would be
possible to use this feature and still be compatible with *real* RMI,
but I don't know nearly enough about RMI to answer this. Do you have any
thoughts, as someone who has implemented an RMI system in the past?
Thanks,
Stuart.
Matt Welsh wrote:
>
> Hi Simon,
>
> [This is Cc'd to the Classpath team, to give them an update on the status
> of NinjaRMI. Simon's original query is included below.]
>
> Unfortunately I don't have much time to work on NinjaRMI at the moment;
> my research has taken me into other directions.
>
> However, this would be a great project for someone to pick up and run
> with, since NinjaRMI has almost all of the pieces you need.
>
> The wire format is trivial to get right -- I think I basically use the
> same format right now, with the possible exception of a few header bytes;
> this is clearly documented in Sun's RMI spec.
>
> The real problem, however, is what to do if you are a client using the
> Classpath libraries talking to a server using Sun's libraries. If the
> server wants to push an RMI stub to the client, the client must be able
> to resolve any classes which that stub requires to operate. I haven't
> done the analysis to find out exactly what the standard RMI stubs depend
> upon, but I am sure that the NinjaRMI class hierarchy does not exactly
> mirror that of java.rmi.* or sun.rmi.*.
>
> So it would be interesting to see what classes are needed to accept a
> standard RMI stub from a server using Sun's libraries. I don't think it will
> be too hard to get it right, since the NinjaRMI stubs work in almost the
> same way. The same goes for the reverse situation, when the client sends
> the server an RMI stub. Basically the two sides must agree on certain
> classes being available (although they may implement those classes in
> different ways).
>
> A more serious concern in terms of compatibility is mirroring the full
> structure of java.rmi.* in Classpath. NinjaRMI changes the structure of the
> RMI classes somewhat, in order to be more flexible. This is fine, since the
> "programmer visible" portions of java.rmi.* are quite small
> (i.e. UnicastRemoteObject and RemoteException are pretty much it).
> But Classpath strives to implement *all* of the classes in java.rmi.*;
> it is my feeling that to do so dictates a particular implementation
> strategy for RMI overall, and there is no clear distinction between
> "programmer visible" classes and "internal" classes. This is an unfortunate
> misfeature of the Sun RMI spec, but grew out of the fact that RMI wasn't
> really meant to be reimplemented from scratch by third parties.
>
> I would say that a nice "middle point" for Classpath to be at, for
> the short term, is to strive to implement the top-level "programmer visible"
> RMI API (which is just a few classes) based on the NinjaRMI implementation.
> Later on people can go over it and clean it up to make things more
> compliant with java.rmi.* as a whole, but my guess is that nobody will
> notice or care as long as UnicastRemoteObject and RemoteException work!
>
> I am happy to re-release NinjaRMI under the GPL if that would help. I would
> probably say that the NinjaRMI code can be released under the GPL or
> Berkeley's own license.
>
> Although I probably won't have time to actually do this work, I would really
> like for someone to contact me with an interest in doing it. I will be more
> than happy to help them get started and provide guidance along the way.
>
> It might be a good idea for the Classpath folks to post this message on
> their website, next to the note mentioning that I'm working on NinjaRMI.
>
> Thanks much!
> Matt Welsh
>
> Simon Britnell <[EMAIL PROTECTED]> writes:
> > I read on your NinjaRMI page that this is a goal for integration with
> > the classpath project.
> > How's this been going?
> > What's required to plug the two together?
> >
