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.