[cc cut down]
>Another possible approach which would sidestep the sun JNI issue, would be
>to use the Kaffe source (www.transvirtual.com). I took a look and the
>source *seems* clean though I haven't tried anything with it. Once JNI
>stabilizes, you can make the architecture more generic.
Been there, done that (because it comes with source). I even have the
current snapshot, because of some problems with the last official beta.
However, I don't want to sidestep the JNI issue (Kaffe now supports
JNI). If this is to make any sense, the Java folks have to agree on
some standard foreign language interface. Calling the native libraries
used by the JVMs directly is even less standardized (even systems that
support JNI are not forced to use it when they call native methods) and
therefore hardly portable..
As you pointed out in your other message, a communication-based
interface wouldn't be optimal either (and hardly as simple as sending
program strings to an untyped Tcl-eval).
>> Of course, access to the Java libraries is also one of the objectives of
>> those who have started to base their Haskell implementations on Java or
>> on the JVM.
>
>Do you have a URL for this project? I asked alastair about doing this and
>he said there are in-principle problems with getting this to work
>efficiently.
Did I really say Haskell implementations? Sorry. But the ideas and most
of the problems are the same, so:
Compilation to Java Virtual Machine Code
http://www.dcs.ex.ac.uk/~david/research/java.html
Persimmon MLJ 0.1
http://research.persimmon.co.uk/mlj/
The JML Project
http://www.dcs.ed.ac.uk/home/cdw/JML/index.html
Kawa, the Java-based Scheme system
http://www.cygnus.com/~bothner/kawa.html
Papers are currently flooding the workshops and conferences (well, not
really;-). Note that the first reference (David Wakeling) actually deals
with Haskell; both he and Nick Benton (Persimmon) talked about some of
their problems and successes at IFL'97 (http://www.dcs.st-and.ac.uk/~ifl97/).
>> One of the slides of a JNI talk at JavaOne said explicitly:
>>
>> don't try to write Java programs in C using JNI
>>
>> There are various reasons for this.
>
>Can you explain more here?
Unfortunately, the slide doesn't say more and I did not attend JavaOne.
The reference is "JavaTM Native Interface Technology Programming",
http://java.sun.com/javaone/javaone98/sessions/T410/.
Some of the more obvious reasons are the insufficient type-checking in C
and the indirect style of programming with lots of error handling code.
And there are lots of opportunities for errors (the other rule of thumb
on that slide is "Keep interactions with native code simple";-). For GUI
purposes, the fact that many Java programs rely on "on-the-fly"
subclassing and method overriding gets in the way, too (think of
listeners and call-backs).
>> My hope is more to enable a
>> connection between larger chunks of software (components) written in
>> Java and Haskell. <Dream>Industry uses Java to write their GUI and
>> Haskell to write the `real' program</Dream>.
>
>Alternatively, fudgets could sit on top of AWT....
>(The chalmers ftp server is down so I can't read the fudgets paper)
Probably. See the Embracing Windows and TkGofer stuff for how to
implement them on top of basic libraries in the IO monad. Still, none of
these high-level GUI libraries are known outside the FP community, and
we ourselves haven't agreed on a standard yet. So even if someone
decides to learn and use FP for their projects, what would be their
incentive to learn one of those non-standard GUI techniques?
> For example, one might write an interface
>that imports java headers as haskell modules so that you could do...
Currently, I don't have any plans in this direction. I hope to work out
some kind of high-level interface, so that you don't have to mess about
with JNI directly (I have some other ideas than using module signatures,
but that is too speculative for discussion right now).
>However then the primary task of a Haskell library writer it the mapping
>of Java functionality into a more reasonable Haskell namespace -- as
>opposed to implementation of this functionality itself.
True, but I have to get into that stage first;-)
>As I said above, you might want to check out Kaffe because you have access
>to source and two different native interface specs.
Yeah. If I could get it to work properly..
Claus
