Re: nio development in Jawin

I thought I'd pass this along. Recently I added support to jSegue to support
generation of structures from type libraries. It's based on using nio's
ByteBuffers. We are having good success with the approach.

For each field in a structure or union we generate accessors. For example:

    public void set_m_revision_number(long v) {
        putUnsignedInt(20, v);
    }
    public long get_m_revision_number() {
        return getUnsignedInt(20);
    }

The magic number 20 is just the offset of the field as reported by the
typelibrary. ByteBuffer does not have get/put methods for unsigned values so
I created my own wrapper, these methods are trivially defined in terms of
byte buffer methods:

    protected void putUnsignedInt(int offset, long v) {
        putInt(offset, (int)v);
    }
    protected long getUnsignedInt(int offset) {
        return getInt(offset);
    }

For nested structures we create a new byte buffer that is a slice of the top
level structure and return. So if you modify a field of the sub-structure
you are modifying the right memory location in the top-structure. I'm not
handling pointers as field members. However, nested arrays are handled.

Well, not sure how useful that will be for jawin, but it's been working
great for us.

Robert

-----Original Message-----
From: Discussion of Java/Win32/COM integration with Jawin
[mailto:[email protected]] On Behalf Of Roger I Martin PhD
Sent: Tuesday, May 17, 2005 5:31 AM
To: [email protected]
Subject: Re: [JAWIN] nio development in Jawin

I'm seeing quite a paradigm shift in marshaling possible with the
application of nio.  Nobody would be upset if Java 1.3.x .  is no longer
supported?  Does anybody extend DispatchPtr by hand?  The old
functionality would still be there but to get the benefits of nio,
updating classes extending DispatchPtr by hand could be a lot of work.
The Type Browser method will just require you to perform another
transform.using another set of stylesheets.

There is much info we are not using from the type info xml and
transforms.  Rather than push everything on a flat marshaling stream,
much direct memory can be employed via nio to build DISPARAMS up with
low overhead.  This would remove all the checking and building of
variants on both the Java and Jawin native side.

I'm thinking of also creating a family of invoke methods:
invokeIntMethod
invokeIntArrayMethod
invokeShortMethod
invokeDoubleMethod
invokeObjectMethod
...
invokeVoidMethod
for even more optimization.  For each of these the native side will be
completely new code.  The new DISPARAMS marshaling would readily allow
for the COM object to construct and return arguments.  Strings can be
resized. Further the rest of the arguments will be independent and need
not be copied around.

Also Josh, would it be a good idea to apply Saxon8.x instead of xalan?
I'm doing all my other xslt with XSLT 2.0.  Great speed and great new
functionality in the stylesheets.

More later,

Roger

Roger I Martin PhD wrote:

> Hi.
>
> Morten, you are a fantastic project organizer!  Things look well
> maintained and things work.  I just upgraded my Platform SDK and the Ant
> script is nice.
>
> How should we develop/maitain the nio version?  Java version? support
> jdk 1.3 until the nio version reaches and passes in functionality? On
> the Java side the nio version can use the current as base classes and we
> set the ant compile to 1.3 or 1.4>.  On the cpp side I'm not certain.
> Compile flags?  Gets ugly especially if the nio bores down thru
>
http://cvs.sourceforge.net/viewcvs.py/jawinproject/jawin/cpp/jawin/StreamOnM
emory.h?view=markup
>
> for example.
>
> One thing it will give us is speed and less work to do about byte endian.
>
> I'm also starting to have some success with the jawt on another project
> and am looking to use it in Jawin.
>
> Resizing a buffer may be problematic.
>
http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/functions.html#nio_suppor
t
>
> I'm experimenting...
>
> Any other areas of interest to anyone?
>
> -Roger
>