Alex wrote:
>Another approach, which would perhaps be more generically useful is to
>use Java via the Java Native Interface.
I agree. At least it is worth a try, and I this is what I'm currently
working on (anyone else out there on the same project?-). There are
quite a few problems, though:
- JNI is part of this little discussion between SUN and MS
(not too bad in principle, there are still several products
which support JNI on various platforms - including Windows;
nevertheless, it hampers progress and acceptance of the interface,
not to mention the other native interfaces on the market)
Corollary: despite all marketing hype, the future of Java
hasn't been decided yet
- JNI is on the move. Only the reference document is up to date
(if you collect all the pieces together), and it is not exactly verbose.
- JNI is always in beta, and debugging is no fun if you have to
juggle with three languages and two experimental dynamic interfaces.
- ...
My current approach is to connect Haskell/Hugs and Java/JDK using
GreenCard 2 and JNI. I thought this first step would be simple, but
progress has been almost discouragingly slow.
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.
>By allowing Haskell to script and control Java objects, Haskell would
>instantly have:
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. 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>.
>1. a reasonable gui (AWT and Swing)
>2. a decent set of network and http libraries
>3. decent database libraries (ODBC/JDBC)
>4. RPC and Corba support via Java RMI
>5. encryption
>6. Linda style parallel processing via javaspaces
>7. a better relationship with the rest of the industry
>
>And it would offer these capabilities on a cross platform basis.
>Developers could wrap the Java libs with more sophisticated Haskell
>interfaces as the language evolves...
More problems on this way. In essence, access to Java libraries is
pretty much Java-specific, and apart from the complex interlanguage
connection, we all know how good Haskell's current type system can cope
with object-oriented programming styles. I don't know whether the GUI is
reasonable (still being adjusted to custumer needs), but I agree with 7,
which makes the GUI interesting (even our best FP GUIs are simply
unknown outside the FP community). Nearly all of the other points should
be taken with a good grain of salt: having a feature on the Java side
does not at all mean that you just need a JNI-connection to import it
all into Haskell (and we don't really want to write too much Java-code
in the Haskell IO monad, do we?).
Enough bad news for today (back to those segmentation faults in
JNI_something). Unless someone else has it all ready now, I will
continue to work on the Hugs/GreenCard/JNI/Java road over the next
weeks, and if I don't jump out of the window because of the persistent,
not well documented obstacles, then we should have some basis for
further experiments before this year is over (N.B: [a] no promises here!
[b] once I get the basic connection to work, there is still a lot of
work to be done!). If everything should work out well, the connection to
JNI could be useable by all systems that support GreenCard..
Claus
PS: Please do contribute to Olaf's GUI survey. If he could complete
the GUI information on his Haskell page, that would be very useful.
I share the suspicion that, after the FP community has invented all
those nice new approaches to functional GUIs, many of them are no
longer supported, let alone portable. I would like to have an
overview of the current state of the art (please include old
libraries, too - just because they are no longer supported, that
doesn't mean they are not useful any more).
