Altova Mailing List Archives

RE: XSLT vs Omnimark

From: "Didier PH Martin" <martind@------------->
Date: 3/6/2000 6:11:00 AM
Hi Louis-Dominique

Louis-Dominique said:
Or they will compile Java to native binary code.  A lot of work is
done on JIT-compiling.  Of course, the problem with JIT... if it is
really JIT... is that your startup time may be significant.  The work
there could be taken one step further though and have the whole thing
cached or just plain compiled like C++ is.  (I'm not saying that there
are not caveats or that this is simple: just that this is possible.)

Didier replies:
Yes a lot of things are feasible but a reality remains: the Actual Java is
slooooow even with the newest Hot spot technology. I am still amazed why
something as simple as the following is not yet implemented (may be too
simple I guess :-))

a) the byte code is downloaded
b) it is compiled into native code locally
c) it is then stored in a cache (this would imply that each class would be
properly classified in a particular namespace to prevent name collision).

The first time you run the apps, you would have the overhead of the
compiling but after this time,

a) when the class is called, its binary version is running

What is the difference between this an JIT? Simple, it is compiled only once
and cached for future use. It means that we would have about the same thing
as we get with today's desktop apps but the code transportation would be
simplified. In fact, it means that the byte code would be used only to
transport the code and this latter to be compiled into native code. Only
native code would be running.

We will still have some overhead with the code written in C++. Garbage
collection is one, function or class member call is an other.

Actually the advantage of Java compared c++ is more for the developers than
for the users. I can see one advantage to the users thought, a potential for
less memory leaks with Java. Memory leaks is still the Number one weakness
of C++ but speed is still its biggest quality.

If we want to get an XSLT engine able to sustain thousands of users, With
C++ we can pretend to have a better usage of the hardware resources but have
also the risk of a badly developed interpreter with memory leaks. With Java,
no memory leaks but with thousand users, frequent garbage collection (and
inconsistent behavior) also, a slower XSLT interpreter.

So yes everything is possible but it remains that today XSLT engines written
in Java are still slow. This is the reality we have to face and I hope that
we will have a fast and reliable XSLT engine available. If only Java would
be made more efficient...

Didier PH Martin
Email: martind@xxxxxxxxxxxxx
Conferences: Web Chicago(
             XML Europe (
Book: XML Professional (
column: Style Matters (

 XSL-List info and archive:


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.