Re: nio development in Jawin

Hi Roger,

Plugging in another transformation engine like Saxon should be simple and
will probably just involve adding a -D system property tot the command line
and perhaps updating the classpath in the manifest.mf file inside the type
browser jar file:

All of the transformation code is completely contained in this class:

package org.jawin.browser.xsl;

import java.util.HashMap;
import javax.xml.transform.*;
import javax.xml.transform.stream.*;
import java.io.*;
import org.w3c.dom.Node;
import javax.xml.transform.dom.DOMSource;

import org.jawin.browser.config.ConfigManager;
import org.jawin.browser.log.Log;

/**
* Manages on the fly XSL transformations of XML and transparent caching of
* loaded and compiled XSL stylesheets
*
* Use of this class implies Xalan (or another XSLT processor)
* is available on the classpath.
*
* Download the latest version or Xalan from http://xml.apache.org
*
* Due to intended useage, this class may not be thread safe for concurrent
* additions of new stylesheets.
*
* <p>Title: Jawin Code Generation GUI</p>
* <p>Description: GUI for exploring type libraries and generating Java
code</p>
* <p>Copyright: Copyright (c) 2003</p>
* <p>Company: Open Source Incentive</p>
*
* @author Josh Passenger
* @version 1.0
*/

public class TransformationManager
....

There are some other dependencies on Xerces as I wrote some SAX parsers for
the config files, nowadays I just use XStream, I haven't written SAX parser
code since I found that!

I see saxon is moving towards a split commerical full schema conformance and
a freebie light version with minimal conformance.

Could be a bit of a hassle to upgrade to Saxon with fighting between VM
patched up with Xerces and Xalan in the lib endorsed directory per Xalan
reccommended installation, that coupled with Saxons dependancy on JAXP.....

What features in XSL 2.0 are you using, I haven't really looked at the
latest spec.  Would moving to 2.0 confirmance require updates to the XSL
versions in the stylesheets too?

Performance issues in XSL transformations are usually solvable with some
judicious use of xsl:key etc

I'll leave it with you.  The nio stuff looks pretty interesting, good luck
with it =]

Josh

>
>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
>>