Nick Roberts wrote:
> Well I can personally vouch for the bugginess of the Symantec Java JIT
> product (for Windows).
Were using the JIT in Sun's JDK (I think their PC JIT
is/was from Symantic) or the JIT in Visual Cafe.
Cafe does have problems debugging with JDK 1.2.
> It crashed about once every ten minutes (often
> taking down the whole machine, of course).
I have never heard of a JIT crashing a PC,
although I'm sure it can happen if you have a
(a PC is phenomenally good at crashing all by itself)
I have seen a JVM crash an UltraSparc which didn't
have mandatory patches (suspected, but not proven).
I use vanilla JDK 1.2 (with JIT on) on both PC and Sparc
and have found it be very reliable and have found few bugs.
> Java really, truly, and honestly, is a toy language
This sort of language will do nothing to further
the cause of Ada. We will do better by pointing out
where Ada is better, or where the opposition just
doesn't cut the mustard. Disparaging comments will
just result in closed ears.
Java may be a toy, but I have seen (and have myself built)
some impressive Java applications.
The problem is, people are pushing Java as the solution
to everything. It is good for some applications
(not as good as Ada, of course!), horrid for others.
Don't get me wrong, I think Java is a horrible language
compared to Ada. But I would much prefer to use it than
C or C++.
> (and I don't see how
> it can ever really mature to the point where it isn't).
I have been watching with interest the development
of native compilers for Java. I have always thought
that people have been naive in thinking that a native
compiler will instantly solve performance problems.
Java performance problems largely arise because
the only forms of abstraction available involve
allocation of objects from the heap (and of course
the garbage collection just adds to this problem).
Unless a compiler can be smart enough to allocate
locally used objects on the stack, Java will always
have performance problems.
I see that the gcj native Java compiler results in programs
that run maybe half as fast as the same program on a JVM.
This is because the JVMs have highly tuned heap management
and GC. The gcc optimizer is always going to produce
faster code than a JIT, but (at the moment) that is not
where the bottle-neck is.