From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q29I5Pk7017304 for ; Fri, 9 Mar 2012 19:05:30 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugBAERFWk9XYq6QmWdsb2JhbABDtVQBAQEBAQgLCwcUJ4IKAQEEAXkFCwtGVwYsh2wJuxGKJ4VQYwSfDIk9gVM X-IronPort-AV: E=Sophos;i="4.73,559,1325458800"; d="scan'208";a="135273173" Received: from 16.mo5.mail-out.ovh.net (HELO mo5.mail-out.ovh.net) ([87.98.174.144]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 Mar 2012 19:05:29 +0100 Received: from mail439.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo5.mail-out.ovh.net (Postfix) with SMTP id 69FB2FFB307 for ; Fri, 9 Mar 2012 19:08:37 +0100 (CET) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 9 Mar 2012 20:06:02 +0200 Received: from ip-131.net-82-216-20.versailles2.rev.numericable.fr (HELO ?192.168.0.13?) (forum%x9c.fr@82.216.20.131) by ns0.ovh.net with SMTP; 9 Mar 2012 20:06:00 +0200 X-Ovh-Mailout: 178.32.228.5 (mo5.mail-out.ovh.net) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "forum@x9c.fr" In-Reply-To: <4F5A41C6.10505@inria.fr> Date: Fri, 9 Mar 2012 19:05:25 +0100 Cc: Xavier Clerc Message-Id: <051FF700-7AB2-43CE-A917-53461BB3EEE6@x9c.fr> References: <4F5A41C6.10505@inria.fr> To: caml users X-Mailer: Apple Mail (2.1251.1) X-Ovh-Tracer-Id: 5082312179604128544 X-Ovh-Remote: 82.216.20.131 (ip-131.net-82-216-20.versailles2.rev.numericable.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeegtddrtdefucetggdotefuucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucenucfhrhhomhepfdhfohhruhhmseiglegtrdhfrhdfuceofhhorhhumhesgieltgdrfhhrqeenucffohhmrghinhepgieltgdrfhhrnecujfgurhepufggtgfhjgffgffkfhfvofesthhqredthhdtud X-Spam-Check: DONE|U 0.500084/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeegvddrfedvucetggdotefuucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucenucfhrhhomhepfdhfohhruhhmseiglegtrdhfrhdfuceofhhorhhumhesgieltgdrfhhrqeenucffohhmrghinhepgieltgdrfhhrnecujfgurhepufggtgfhjgffgffkfhfvofesthhqredthhdtud Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q29I5Pk7017304 Subject: Re: [Caml-list] A js_of_ocaml equivalent for the JVM? Le 9 mars 2012 à 18:45, Johan Grande a écrit : > Le 09/03/2012 18:12, Philippe Veber a écrit : >> Dear camlers, >> I used js_of_ocaml several times and was really stunned of how clever >> (notably because writing interfaces boils down to writing types) and >> efficient this approach is. Would a similar thing work for the JVM, that >> is a compiler from ocaml bytecode to java bytecode? It is not easy to envision such a tool on the JVM, because of the current restrictions imposed on Java bytecode. As an example, the size of a method is currently limited to 64Ko, which is clearly way too small for non trivial programs. >> I guess it wouldn't >> provide a full interoperability with java, in the sense that creating or >> extending classes may not be possible (well, why not after all?). >> However, being able to run an ocaml program on the JVM reusing existing >> java libraries would be so useful already! I am currently working on this for OCaml-Java (see below). >> Are there known obstacles to this? Has anyone tried something in this >> direction? Well, no real obstacle as OCaml-Java showed. However, OCaml-Java 1.x is still a bare proof of concept due to both poor design choices and JVM limitations. But then came Java 1.7 and some limitations were removed (e. g. a garbage collector better suited to functional languages, and an implementation of method handles). OCaml-Java has been largely rewritten and now exhibit acceptable performances. >> Would there be a chance to support multicore programming that >> way? Yes, it is actually working. But not released yet. Starting from vanilla OCaml, you "only" need two things: 1/ have a reentrant runtime; 2/ have a parallel garbage collector. OCaml-Java implements the former, while all modern JVMs provide the latter. So, basically, it just works. The great difficulty is then to provide the good abstractions to make the life of the programmer as easy as possible. I mean: who would like to program with locks? >> I hope these are not silly questions (sorry if they are!) > > http://ocamljava.x9c.fr Thanks for the plug. However, OCaml-Java is quite different and provides two tools: - an equivalent of ocamlrun written in Java (meaning you can interpret OCaml bytecode inside a JVM); - an equivalent of ocamlc/ocamlopt for Java (meaning you can compile OCaml sources to Java jar files to be executed by a JVM). Kind regards, Xavier Clerc