[jcifs] RPC Stub Format Changes

[Eric Glass]

> It sounds like a good idea but I'm not impressed with the mapping. It
> seems needlessly complicated. Staic helper methods, reading and writing to
> XxxputStreams, requiring holder classes with methods for each member.
> Granted, I didn't read it carefully enough to understand what the point of
> all the helpers and holders is about but yuk it's alot of code. If someone
> really wants that they can write an emit_stub_corba_java.c.
> 

I was just using that as an example; we would be "generating" mapping
rules based on whatever we come up with.  The gist is just documenting
the rules for the IDL translation.  As an example, from your previous
srvsvc.java you might infer some of the following:

1) A public class is generated for the IDL interface.

2) Unions are generated as public static abstract inner classes
extending NdrObject; each union arm is generated as a public static
class extending the union superclass.

3) ....


And so on and so forth.  We would just document the approach that IDLC
takes to generate stubs for Jarapac, and then say "this is the
standard way you generate stubs for Jarapac".  So if someone else
wanted to do so (e.g. Chris with his PIDL backend), they could use
that rather than reinventing the wheel in an incompatible fashion.

This document would also be useful to end users; if they have existing
IDL code, and want to use it with Jarapac, they would know what files
would be produced and could write Java code based on that.  They also
know that if they used some other tool (or even a future version of
IDLC), the generated artifacts would look the same.


Eric