[Caml-list] [ANN] OCaml-Java project: 1.1 release
fo...@x9c.fr
The goal of the OCaml-Java project is to allow seamless integration of
OCaml and Java.
This version is still based on Objective Caml 3.10.2, the next one
will be based on 3.11.0.
Home page: http://ocamljava.x9c.fr
Download page: http://ocamljava.x9c.fr/downloads.html
Toplevel applet: http://ocamljava.x9c.fr/toplevel/toplevel.html
Main changes since 1.0:
- move from Java 1.5 to Java 1.6 (will hence not run on a 1.5 JVM)
- support for JDBC, with automatic generation of bindings to
databases
- support for java.math package
- Dbm, Servlet, SwiXml and OCamlScripting projects merged into
Cadmium
- experimental support for stack frames
- bug fixes
Xavier Clerc
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
fo...@x9c.fr
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
fo...@x9c.fr
Le 12 nov. 08 à 03:21, Warren Harris a écrit :
>
> On Nov 11, 2008, at 8:17 AM, fo...@x9c.fr - fo...@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.