[jcifs] Re: Jarapac Stubs not Compatible with DEC/RPC Calling Conventions

[Michael B Allen]

Eric Glass said:
>     public void foo(UnsignedLongHolder arg1) throws RemoteException;
>
> The pointer wrapping would be done within the generated client stub,
> so all the caller would need to do is create the holder:
>
>     UnsignedLongHolder arg1 = new UnsignedLongHolder(5);
>     foo(arg1);
>     System.out.println(arg1.getUnsignedLong());
>
> That was the idea, anyways; RPC pointers were a bit fuzzy to me, so
> I'm not sure if this approach is feasible or not.

That would be feasible to handle pointers but 1) it's not pretty to use
wrappers for every little parameter and 2) the interfaces are frequently
too raw to be used directly anyway. Case in point are these "containers"
used to hold unions to info level structures.

So we might as well just use one wrapper class to hold all the parameters
(making them all effectively pointers) and then let the user make a nice
Java method that makes a sensible mapping between the Java way of doing
things and the C way of doing things.

So if we use a wrapper class like this:

public class NetShareEnumAll implements InputParameters, OutputParameters {

    // idl compiler generated inner classes and read/write functions here

    public String servername;
    public NetShareCtr ctr;
    public int prefmaxlen;
    public int entriesread;
    public int totalentries;
    public int resume_handle;

    public NetShareEnumAll(String servername,
                int level,
                NetShareCtr ctr,
                int prefmaxlen,
                int resume_handle) {
        this.servername = servername;
        this.info = info;
        this.prefmaxlen = prefmaxlen;
        this.resume_handle = resume_handle;
    }
}

you can then call this like:

NetShareEnumAll.NetShareCtr ctr = new NetShareEnumAll.NetShareCtr()
NetShareEnumAll rpc = NetShareEnumAll(server, 502, ctr, 4096, 0);
send(rpc);
NetShareEnumAll.NetShareInfo502[] info = ctr.info;
for (i = 0; i < rpc.entriesread; i++) {
...

Most of the parameters are somewhat awkward from a Java context. For
example prefmaxlen is useless as the ctr parameter isn't stored in a
buffer of prefmaxlen size bytes. But there's no logic in IDL to
communicate such principles so we have to just accept all [in] parameters
and leave it to the user to interpret.

Although, I can eliminate the necessity to pre-allocate container classes
like NetShareCtr. Technically all top level pointers are ref pointers
which cannot be null and are supposed to be allocated by the caller. But
since everything is in a wrapper class I don't see why we can't just let
the user pass null, have the stub allocate anything that's null, and if
necessary access it through the wrapper (e.g.
NetShareEnumAll.NetShareInfo502[] info =
((NetShareEnumAll.NetShareCtr)rpc.ctr).info).

Or something like that... :)

Mike