caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "forum@x9c.fr" <forum@x9c.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] [ANN] OCaml-Java project: 1.1 release
Date: Tue, 11 Nov 2008 17:17:54 +0100	[thread overview]
Message-ID: <265612EB-D831-4993-9B43-6BEE42A3831B@x9c.fr> (raw)
In-Reply-To: <1A9267AD-B392-40CC-A2AF-0C3F68BF1750@metaweb.com>


Le 9 nov. 08 à 21:38, Warren Harris a écrit :

> Interesting project. Looks like you're mostly focused on getting  
> ocaml code to run in a jvm. Have you given any consideration to  
> making things work the other way around? I've found the ocaml  
> runtime to be far superior, and it would be nice to be able to  
> recompile a java library (source or class file) to run in an ocaml  
> program if need be. (For instance, I'd love to be able to recompile  
> Rhino into an ocaml module.)

The goal of the OCaml-Java project is clearly to be able
to run Objective Caml programs on a JVM. Additionally,
it is useful to access Java elements through automatic
binding generation.


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;
   - explicit encoding of the algorithm for message dispatch;
   - explicit encoding of elements need by the reflection
     mechanism.

These items are not intellectually challenging but you
would have to do a lot a work, especially for the coding
of all native methods (just consider the low-level GUI
toolkit).


You say that the ocaml runtime is "far superior".
I do agree but would like, as a concluding remark, to draw
your attention on the fact that the two runtimes are very
different.
In OCaml, the compiler erases types, and all associated
safety is thus checked at compile-time. Then the produced
code (either bytecode or native) is supposed to be safe
and is run with no further consideration (hence its speed).

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).


Xavier

  reply	other threads:[~2008-11-11 16:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-09 20:05 forum
2008-11-09 20:38 ` [Caml-list] " Warren Harris
2008-11-11 16:17   ` forum [this message]
2008-11-12  2:21     ` Warren Harris
2008-11-12 12:29       ` forum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=265612EB-D831-4993-9B43-6BEE42A3831B@x9c.fr \
    --to=forum@x9c.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).