From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=AWL,DNS_FROM_SECURITYSAGE, SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id ECFC5BB84 for ; Tue, 11 Nov 2008 17:17:56 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucCAMs+GUnAXQImgWdsb2JhbACUKgEBFiK4YYNX X-IronPort-AV: E=Sophos;i="4.33,584,1220220000"; d="scan'208";a="19085410" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 11 Nov 2008 17:17:56 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id mABGHtbn022054 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 11 Nov 2008 17:17:56 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoBAKc+GUnVuj7VmWdsb2JhbACUKgEBAQEBCAsKBxG4aINX X-IronPort-AV: E=Sophos;i="4.33,584,1220220000"; d="scan'208";a="19842834" Received: from 30.mail-out.ovh.net ([213.186.62.213]) by mail1-smtp-roc.national.inria.fr with SMTP; 11 Nov 2008 17:17:55 +0100 Received: (qmail 8562 invoked by uid 503); 11 Nov 2008 16:17:43 -0000 Received: from unknown (HELO mail191.ha.ovh.net) (213.186.33.59) by 30.mail-out.ovh.net with SMTP; 11 Nov 2008 16:17:43 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 11 Nov 2008 16:17:59 -0000 Received: from cha92-8-82-231-217-153.fbx.proxad.net (HELO ?192.168.1.104?) (forum%x9c.fr@82.231.217.153) by ns0.ovh.net with SMTP; 11 Nov 2008 16:17:59 -0000 Message-Id: <265612EB-D831-4993-9B43-6BEE42A3831B@x9c.fr> From: "forum@x9c.fr" To: caml-list@inria.fr In-Reply-To: <1A9267AD-B392-40CC-A2AF-0C3F68BF1750@metaweb.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [Caml-list] [ANN] OCaml-Java project: 1.1 release Date: Tue, 11 Nov 2008 17:17:54 +0100 References: <1FE63159-2C69-4F8C-9D04-6721E98D4DDB@x9c.fr> <1A9267AD-B392-40CC-A2AF-0C3F68BF1750@metaweb.com> X-Mailer: Apple Mail (2.929.2) X-Ovh-Tracer-Id: 12697617675481645856 X-Ovh-Remote: 82.231.217.153 (cha92-8-82-231-217-153.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Miltered: at discorde with ID 4919B033.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 runtime:01 recompile:01 recompile:01 compilation:01 ocamlrun:01 bytecode:01 runtime:01 low-level:01 runtimes:01 compiler:01 compile-time:01 bytecode:01 compiler:01 Le 9 nov. 08 =E0 21:38, Warren Harris a =E9crit : > Interesting project. Looks like you're mostly focused on getting =20 > ocaml code to run in a jvm. Have you given any consideration to =20 > making things work the other way around? I've found the ocaml =20 > runtime to be far superior, and it would be nice to be able to =20 > recompile a java library (source or class file) to run in an ocaml =20 > program if need be. (For instance, I'd love to be able to recompile =20= > 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=