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.9 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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 07626BB84 for ; Wed, 12 Nov 2008 13:30:07 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucCAI9bGknAXQIngWdsb2JhbACULgEBFiK6BYNX X-IronPort-AV: E=Sophos;i="4.33,590,1220220000"; d="scan'208";a="31379261" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 12 Nov 2008 13:29:31 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id mACCTVP0007301 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 12 Nov 2008 13:29:31 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoBAFJbGknVuj7VmWdsb2JhbACULgEBAQEBCAsKBxG6BYNX X-IronPort-AV: E=Sophos;i="4.33,590,1220220000"; d="scan'208";a="19871573" Received: from 30.mail-out.ovh.net ([213.186.62.213]) by mail1-smtp-roc.national.inria.fr with SMTP; 12 Nov 2008 13:29:31 +0100 Received: (qmail 18583 invoked by uid 503); 12 Nov 2008 12:29:18 -0000 Received: from unknown (HELO mail191.ha.ovh.net) (213.186.33.59) by 30.mail-out.ovh.net with SMTP; 12 Nov 2008 12:29:18 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 12 Nov 2008 12:29:35 -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; 12 Nov 2008 12:29:34 -0000 Message-Id: From: "forum@x9c.fr" To: caml-list@inria.fr In-Reply-To: <84762F8F-9615-47D8-A5A1-BBAA7982E6B3@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: Wed, 12 Nov 2008 13:29:28 +0100 References: <1FE63159-2C69-4F8C-9D04-6721E98D4DDB@x9c.fr> <1A9267AD-B392-40CC-A2AF-0C3F68BF1750@metaweb.com> <265612EB-D831-4993-9B43-6BEE42A3831B@x9c.fr> <84762F8F-9615-47D8-A5A1-BBAA7982E6B3@metaweb.com> X-Mailer: Apple Mail (2.929.2) X-Ovh-Tracer-Id: 14712415558556582688 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 concorde with ID 491ACC2B.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; compilation:01 ocaml:01 ocaml:01 ocamlrun:01 bytecode:01 runtime:01 jni:01 ocaml's:01 spi:01 compiler:01 runtime:01 bytecode:01 compilation:01 subset:01 ocaml's:01 Le 12 nov. 08 =E0 03:21, Warren Harris a =E9crit : > > On Nov 11, 2008, at 8:17 AM, forum@x9c.fr - forum@x9c.fr 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 =20= > netscape which became JNI at Sun)... I'll be the first to say that =20 > I'd be very happy to write all my native methods using ocaml's =20 > methodology. I understand that it would make you happy ! In fact, my point was that it would be a long job, not that it would a =20= painful job. >> - 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 =20= > without. Certainly when porting an application to a new VM this =20 > would be a consideration, but when developing a new application, =20 > there are simple alternatives that avoid much of the need for =20 > reflection. I second that (even if I occasionally use reflection). However, some existing Java framework rely on reflection. As an example, the SPI mechanism is based on reflection and is then used at various places such as script engines, image loaders, charset converters, etc. These frameworks would be unavailable if you do not port the reflection mechanism. >> 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 =20= > a lot of sense in the browser world, but is somewhat useless in a =20 > server context, which is where most java applications are deployed =20 > today. I think that a server-only subset of Java could make a lot of =20= > sense, particularly in conjunction with a VM such as ocaml's that =20 > provides superior performance and footprint. I think many developers =20= > would happily sacrifice a few language features for performance. Well, I mostly agree but see scenarii where the sandbox model is =20 useful on the server side. The sandbox allows to fine-tune the execution permissions for an =20 application. Some of the permission can of course be enforced by the OS (e.g. =20 filesystem permissions, firewall rules, etc.) but it can be handy to be able to specify them =20 on an application basis. Xavier=