You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ovidiu Predescu <ov...@cup.hp.com> on 2002/02/15 22:39:41 UTC

Re: [provocative] resurrecting native code

On Fri, 15 Feb 2002 16:19:42 -0500, Berin Loritsch <bl...@apache.org> wrote:

> Lewis, Andrew J wrote:
> > A a user of Cocoon, I think that (provided of course Xalan-J is still
> > supported) this would be fantastic! 
> > 
> > The ability to include native code in the pipeline as option, at any step,
> > makes perfect sense. To not support it makes no sense, and XSLT is the ideal
> > candidate!
> 
> 
> Word of warning:
> 
> if JNI crashes the VM, it would be a *bad* thing.

I tend to agree here. Having written lots of code in C/Objective-C in
the past, it's no fun to mix a garbage collected environments with
manual memory management. With JNI you'll have to manage the memory
for your objects manually, and that's very painful. And all the
platform details, which and where the headers are, what are the
features a system supports, all this is nightmare. Granted you can
probably use the Apache 2.0 system independent layer, but I have no
experience with it and don't know how many problems it
solves. Autoconf is a very good helper, but how many people here know
autoconf and/or m4 to be able to write maintainable code?

Rather than investigating this option, I think it's worth looking at
replacing Xalan with faster implementations, like Saxon or XSLTC. And
perhaps optimizing bottleneck pieces in the system is going to provide
us with much better results.

Ovidiu

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org