Re: [Caml-list] Make OCaml library available to Java

[Arlen Cox <arlencox@gmail.com>]

Thank you for your answers.  I should be more clear on a couple of
things.  My default method of communication is to use pipes or
sockets.  However, my code is an abstract domain library.  The
interface exposes large, recursively defined variants; exposes
first-class modules (though not functors); and is expected to be
relatively high performance.

For now I'll tinker with the js_of_ocaml option.  It might be a pain
to wrap it properly, but I think it should be possible to make the
performance acceptable by replacing a few of the hotter internal
components with native Java code accessed via the Javascript api.

I am still open to other ideas, though.

Has anyone considered writing a source-to-source translator from OCaml to Scala?

Thanks,
Arlen

On Tue, Aug 2, 2016 at 6:56 AM, Malcolm Matalka <mmatalka@gmail.com> wrote:
> You could also make an executable written in Ocaml that communicates
> over stdin/stdout.
>
> Arlen Cox <arlencox@gmail.com> writes:
>
>> Hi all,
>>
>> I'm trying to figure out what the best way is to make an OCaml library
>> available to a Java program.  I can think of several ways to do this
>> each with pros and cons:
>>
>> 1.  OCaml-Java:  This is the most obvious solution that translates the
>> OCaml code directly to Java.
>>   + Simple interface to OCaml code
>>   + Portable Java-compatible code
>>   + Can easily call back into Java
>>   - OCaml-Java is a bit buggy
>>   - Code runs slower
>>
>> 2.  js_of_ocaml:  Translate OCaml to JavaScript and then use the new
>> "fast" JavaScript engine in Java 8 to execute the JS.
>>   + Portable Java-compatible code
>>   + Can call back into Java (albeit, less easily than OCaml-Java)
>>   - Not type safe interface
>>   - Possible massive slowdowns or at least unpredictable performance
>>
>> 3.  JNI with C Library:  Wrap OCaml code in a C library and then call
>> into that with JNI
>>   + Native OCaml performance
>>   - Complex GC interaction
>>   - Not type safe
>>   - Not portable (need different .so for each platform)
>>   - No tools to help in doing this (CamlJava is both unsupported and
>> seemingly unidirectional)
>>   - No easy call back into Java
>>
>> Does anyone have any experience with doing this or have any
>> suggestions on what to do in this situation?
>>
>> Thanks,
>> Arlen