cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <>
Subject RE: [provocative] resurrecting native code
Date Sat, 16 Feb 2002 11:57:55 GMT
I had the same idea a week ago. Damn I should be
louder ;)

>I've (finally, some would say) come to the conclusion that WORA (write
>once run everywhere) has to do with Java more or less like it has to do
>with any other programming language in the world. 
>Despite Sun's marketing.
>Thus, we (Pier and I) have decided break the unwritten rule "don't mix
>java bytecode with native code" and decided to go resurrect native code
>and use JNI.

Why not. It would be not very intelligent to ignore this option...

>Early investigations are *impressive*. 
>I even venture to say that the right mix of java code and native code
>could well outperform completely native implementations.


>This said, I want to throw a stone in the lake and see where the waves
>if Cocoon performance bottleneck is XSLT processing, what about using
>Xalan C as the XSLT processor instead of Xalan J?

I agree on that. But:
- which Xalan C++ libaries do you want to ship? All (Windows, Linux, Solaris....)?
- Leave it optional? The user can download the libary and we provide 
the interfaces and Xalan J is default... But then we have to abstract Xalan
in Cocoon, but that's clear (org.apache.cocoon.transform.*).
- Throw xalan J completly overboard? But then we arn't plattform independent
anymore (academic).

"things, that try to look like things, do often more look 
like things than things"

To unsubscribe, e-mail:
For additional commands, email:

View raw message