JavaCaml is not intended for problems requiring high execution performance
JavaCaml is an interpreter written in a typically interpreted
language. Compared to a native program the loss of speed is dramatic:
A factor of 100 or more must be taken into account. But not all
programs are affected so much, as there are high-level primitives that
run in JavaCaml only 10 times slower than in the native
environment. These "good" primitives are fortunately very often used,
for example the high-level string functions.
JavaCaml does not translate Ocaml to Java bytecode
At the first glance, the direct translation from Ocaml to Java
bytecode seems to be a superior approach, as one of two interpretation
steps can be avoided. But Java bytecode is designed to represent Java
that does not know some of the core features of Ocaml, namely closures
and the automatic elimination of tail recursions. Because of that
closures would have to be represented by classes, and this means that
even small OCaml programs would be translated to hundreds of
classes. This is one difficulty. Tail recursions are eliminated in the
OCaml bytecode by a technique that substitutes subroutine calls
by direct jumps to the beginning of the routine. This even
works if the subroutine that is being invoked is different from the
current running routine, i.e. is not limited to direct
recursions. (And there are many ways writing indirect recursions!)
Java bytecode has not an analogous technique, and this is actually
totally unimportant for Java programs.
The conclusion is that the direct translation approach has many
problems that makes it not very attractive for a first implementation.
Up to now JavaCaml cannot communicate with arbitrary net services
The net package of Java is currently not fully visible in
JavaCaml. You can read files located on the server where the applet
comes from, but you cannot contact arbitrary services on the server.
Up to now JavaCaml cannot use the AWT user interface
It is simply not visible in JavaCaml.