On Nov 11, 2008, at 8:17 AM, [EMAIL PROTECTED] - [EMAIL PROTECTED] wrote:
Your (dual) suggestion of compilation of Java sources into either OCaml sources of OCaml binaries for ocamlrun (or even interpretation of Java bytecode) is interesting. The Java language is clearly easy to parse, type, and compile. However, the runtime support library would be quite large (listing only the first items that come to mind): - implementation of a 'native' method from the JDK;
As the original designer of the Java native method mechanism (JRI at netscape which became JNI at Sun)... I'll be the first to say that I'd be very happy to write all my native methods using ocaml's methodology.
- explicit encoding of the algorithm for message dispatch; - explicit encoding of elements need by the reflection mechanism.
Reflection is another feature of Java that one could get pretty far without. Certainly when porting an application to a new VM this would be a consideration, but when developing a new application, there are simple alternatives that avoid much of the need for reflection.
At the opposite, the Java compiler performs the bare minimum checks. Then, at runtime the bytecode is verified before execution. More, through the security manager some checks are done at runtime to verify if the JVM is allowed to access a file, open a network connection, etc. All these runtime checks are obiously needed to grant the user that some code will not harm its computer (e.g. inside applets).
Java's focus on downloaded applet security and JIT compilation made a lot of sense in the browser world, but is somewhat useless in a server context, which is where most java applications are deployed today. I think that a server-only subset of Java could make a lot of sense, particularly in conjunction with a VM such as ocaml's that provides superior performance and footprint. I think many developers would happily sacrifice a few language features for performance.
Warren
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
