On Thu, 6 Aug 1998, Claus Reinke wrote:
> >Another approach, which would perhaps be more generically useful is to
> >use Java via the Java Native Interface.
>
> 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.
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.
> 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.
> >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.
Can you explain more here?
> 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)
> >1. a reasonable gui (AWT and Swing)
> >2. a decent set of network and http libraries
[...]
> >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 think this is sufficiently true to reject a java interface (I am
guessing that you don't either). For example, one might write an interface
that imports java headers as haskell modules so that you could do...
> main = do
> vec <- Java_lang_Vector.new_a3 -- create new vector
> -- new is implicitly static
> vec # Vector.addElement_c1 12 -- add element to vector
> --print size of vec
> putStr $ show $ vec # Java_lang_Vector.size_21
This would be annoying in that you would
1. have to append the hash of the signature to each method name
2. reference the class name every time you want to call a function
3. use package names in referring to the class
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.
Once Haskell 2.0 adds, as Simon says, "Allow ad-hoc overloading as well as
type classes (a la Java or C++)." then everything becomes much more
straightforward.
I would also add as a todo item for Haskell 2.0, fix the module namespace.
(I know that this use of (#) is outdated, but I don't know the current
one. If there isn't any right now, how about (./)?)
> I don't know whether the GUI is reasonable (still being adjusted to
> custumer needs),
Fair enough, but it is probably advancing much faster than Tk and
> 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?).
Library writing is substantially easier if it consists mainly
of namespace mapping rather than actual implementation of new libraries
(e.g. encryption or guis or database connectivity).
Calls to Java that really are stateless can of course get implemented by
Java calls inside an unsafeperformIO block...
The point I am making here is not that we want to use the java libs
directly. My point is that the ability to use the java implementations
allows the FP community to focus on better representations and DSELs that
are richer than the OO noun.verb() or noun.getProp() syntax.
> 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
As I said above, you might want to check out Kaffe because you have access
to source and two different native interface specs.
-Alex-
___________________________________________________________________
S. Alexander Jacobson i2x Media
1-212-697-0184 voice 1-212-697-1427 fax
