Re: 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/StreamOnMemory.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_support
>
> I'm experimenting...
>
> Any other areas of interest to anyone?
>
> -Roger
>