Le 12 nov. 08 à 03:21, Warren Harris a écrit :

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

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

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

Well, I mostly agree but see scenarii where the sandbox model is  
useful on the server side.
The sandbox allows to fine-tune the execution permissions for an  
application.
Some of the permission can of course be enforced by the OS (e.g.  
filesystem permissions,
firewall rules, etc.) but it can be handy to be able to specify them  
on an application basis.


Xavier