Stefano, 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. Definitly >This said, I want to throw a stone in the lake and see where the waves >go: > >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). ~Gerhard "things, that try to look like things, do often more look like things than things" --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
