caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Ocaml to Java
@ 1998-05-19 12:45 Ohad Rodeh
  0 siblings, 0 replies; 3+ messages in thread
From: Ohad Rodeh @ 1998-05-19 12:45 UTC (permalink / raw)
  To: Ocaml Mailing List

> Ohad Rodeh wrote:
> 
> > Hi,
> >   It has been brought to my attention that a compiler from
> > SML to java bytecode has been written, see:
> >     http://research.persimmon.co.uk/
> >
> 
> My opinion as an OCAML user in an "industrial" context:
> 
> The only interest of a ML to Java compiler is that it can make your program run
> on Internet browsers.
> Not every browser supports Java correctly, implementation of Java are not
> compatible and will diverge
> completely in the future. Moreover, the Java bytecode is quite slow.
> Calves (OCAML plugin for Netscape) seems a better way of doing this... provided
> Microsoft doesn't
> change the borwser plugin specifications once they get 80% market share.
> 
> > We, at the Ensemble project could use such a compiler. Even better
> > would be a compiler from Ocaml to Java (not bytecode).
> 
> Here is an exemple of Java extension to ML (needed in at least one module,
> otherwise
> the MLJ compiler cannot work, as far as I understand):
> ---------------------------------------------------------
> _public _classtype MLApplet _extends Applet.Applet
> {
> _public _constructor ()
> _public _static _method "main"(env : Java.String option Java.array option)
> }
> ----------------------------------------------------------
> (extract from http://research.persimmon.co.uk/mlj/demos/gui/MLApplet.sig)
> 
> I'm not sure people want to see this in OCAML code.
> 
> Olivier Montanuy
> 
> Ps: I understand perfectly that you need Java in the Ensemble project, be it
> only for "marketing" reasons.
> We have the same kind of problems here, for our internal projects. And somehow
> we are forced to write
> Java applets even if we don't believe in Java.
> 
> 
> 

The problem we face is that Ocaml is not palatable for most people. The
Ensemble (our Group Communication System) code base is free and anyone
(including companies) can pick it up and use it. The problem we find is
that people are unwilling to use ML and will rather build their own
systems in Java/C/C++/SmallTalk. We believe that having a Java version of
our software will make it more accessible. This version may be
automatically generated and may not be very readable, but it will still be
100% Java which is a desirable property nowadays. At least it will compile
and link with other Java code. 

	Ohad.







^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Ocaml to Java
  1998-05-18 18:19 Ohad Rodeh
@ 1998-05-25 20:02 ` Xavier Leroy
  0 siblings, 0 replies; 3+ messages in thread
From: Xavier Leroy @ 1998-05-25 20:02 UTC (permalink / raw)
  To: Ohad Rodeh, caml-list

> SML to java bytecode has been written, see:
>     http://research.persimmon.co.uk/
> We, at the Ensemble project could use such a compiler. Even better
> would be a compiler from Ocaml to Java (not bytecode). Is anything
> in the works? 

The short answer is no.  But since this question comes once in a
while, let me elaborate.

I have reviewed a fair number of "X-to-JVM" papers recently, and
except when X is sufficiently close to Java (i.e. Eiffel or Ada-95),
the results are universally negative.  The papers report that the JVM
code obtained by translation runs incredibly slowly (e.g. 10 times
slower than a direct implementation of X with similar technology -- a
bytecoded X against Sun's JDK for instance), is fairly large (due to
code bloat during translation), and loads slowly (again, due to code
bloat and the large number of small classes that need to be
generated).  All this shows that there is a deep mismatch between the
languages being compiled and the Java/JVM execution model.

So, compiling to JVM is essentially a failure, and I don't expect
things to improve significantly in the near future.  Java's compiler
technology is nowhere progressing as fast as the Sun's marketroids
would like you to believe.  Everyone is obsessed with "killer JITs",
but obviously you can't produce good machine code and produce it as
fast as required for JIT operation.  More importantly, even Java
compilers based on more conventional technology (TOG's TurboJ,
Harissa) are strongly biased towards "typical" Java programs, and for
instance come with slow memory allocators and garbage collectors that
are no match for Caml and other functional languages.

So, I'm pretty sure a Caml-to-JVM or Caml-to-Java compiler would be
essentially unusable because of its terrible performances, and I have
no intention of working on one.  This said, you could look at Pizza,
an extension of Java with first-class functions, ML-style datatypes
and ML-style polymorphism developed by Martin Odersky.
A core Caml-to-Pizza translator would be relatively easy to write,
since the most delicate ML features are handled by the Pizza-to-JVM
compiler.  Both the module language and the OO features of Objective
Caml would be significantly harder to translate.

More generally, I think you need to determine why you really want to
translate Caml into Java.  I can see several motivations:

- You want to run your code as Web applets.  Then, the JVM is pretty
much unavoidable (altough there is this cool Caml plugin for
Netscape...).  But I don't see Ensemble fitting in this picture.
Ensemble is a serious piece of systems software, and applets are
throwaway toys.

- You want to pursue Ensemble development in Java.  Then, your only
choice is to rewrite everything by hand in Java.  There is no way an
automatic translator can generate readable, maintainable Java code.
In addition, the performance issues would be a major problem.  To
maximize performance, you'd need not only to hand-optimize the Java code,
but also to re-engineer significantly the current Ensemble
implementation so that it fits better the Java execution model.  Then,
after several man-years of effort, you might find that Java compilers
and runtime systems are simply not good enough for your needs.

- You want to use the Ensemble library from Java programs.  Then all
you need is Caml-Java interoperability via C.  E.g. use the Java JNI
interface to talk to Ensemble as if it were a C library, and the
Caml-C interface to package up the Caml Ensemble code as a C library.
The second half is already done, if I remember correctly.  And the
first half (JNI) should be fairly easy.  

Now, if you have questions to ask or experiences to report on
Caml-Java interoperability via C, we would be very happy to discuss
that with you.

Best regards,

- Xavier Leroy





^ permalink raw reply	[flat|nested] 3+ messages in thread

* Ocaml to Java
@ 1998-05-18 18:19 Ohad Rodeh
  1998-05-25 20:02 ` Xavier Leroy
  0 siblings, 1 reply; 3+ messages in thread
From: Ohad Rodeh @ 1998-05-18 18:19 UTC (permalink / raw)
  To: caml-list

Hi,
  It has been brought to my attention that a compiler from 
SML to java bytecode has been written, see:
    http://research.persimmon.co.uk/
We, at the Ensemble project could use such a compiler. Even better
would be a compiler from Ocaml to Java (not bytecode). Is anything
in the works? 

	Ohad.




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1998-05-27  9:22 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-05-19 12:45 Ocaml to Java Ohad Rodeh
  -- strict thread matches above, loose matches on Subject: below --
1998-05-18 18:19 Ohad Rodeh
1998-05-25 20:02 ` Xavier Leroy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).