[ANN] OCaml-Java project: 1.1 release

[ANN] OCaml-Java project: 1.1 release

[forum]

This post announces the 1.1 release of the OCaml-Java project.
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

Re: [Caml-list] [ANN] OCaml-Java project: 1.1 release

[Warren Harris]

[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]

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

Warren


On Nov 9, 2008, at 12:05 PM, forum@x9c.fr - forum@x9c.fr wrote:

> This post announces the 1.1 release of the OCaml-Java project.
> 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


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3739 bytes --]

Re: [Caml-list] [ANN] OCaml-Java project: 1.1 release

[forum]

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

Re: [Caml-list] [ANN] OCaml-Java project: 1.1 release

[Warren Harris]

[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]


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.

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

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

Warren

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3739 bytes --]

Re: [Caml-list] [ANN] OCaml-Java project: 1.1 release

[forum]

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