Interacting with Java in GHCVM

Hi Haskell-Cafe, I've been working on a JVM backend for GHC [1] and I took some time to flesh out a design for the Java FFI [2] which will pretty much decide whether the project will be useful or not. I would love feedback from the community on how to improve the design or requests for important interop features that I have neglected. Thanks, Rahul Muttineni [1] http://github.com/rahulmutt/ghcvm [2] https://gist.github.com/rahulmutt/355505bce57c7c2cffd7d4cf5edddad4

Hi,
For what it's worth, at Tweag we've developed some preliminary bindings to
Apache Spark, and as part of this we developed a somewhat decent API for
calling Java. You can check it out on hackage [1] and on github [2]. In
cast that can save you some time or inspire you.
[1]: http://hackage.haskell.org/package/inline-java
[2]: https://github.com/tweag/sparkle -- see the inline-java directory
On Sun, May 22, 2016 at 4:54 AM, Rahul Muttineni
Hi Haskell-Cafe,
I've been working on a JVM backend for GHC [1] and I took some time to flesh out a design for the Java FFI [2] which will pretty much decide whether the project will be useful or not. I would love feedback from the community on how to improve the design or requests for important interop features that I have neglected.
Thanks, Rahul Muttineni
[1] http://github.com/rahulmutt/ghcvm [2] https://gist.github.com/rahulmutt/355505bce57c7c2cffd7d4cf5edddad4
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- Alp Mestanogullari

Hi Alp,
I had a nice time going through inline-java and sparkle! The API I made up
for the Java FFI is similar to yours but I don't do the extensive
type-level hackery that you have. Another key difference is that I use GHC
Annotations to specify the qualified class name where you use type-level
strings.
Nice work supporting almost all of the JNI in a clean way! I recently
looked at the JNI API and it stated that the functions that interact with
the JVM are a tad slow due to reflection + the fact that native methods
don't get inlined. I'm interested in benchmarking programs compiled with
GHC/Sparkle vs GHCVM/FFI to Spark once the first release is out.
Thanks,
Rahul
On Sun, May 22, 2016 at 1:05 PM, Alp Mestanogullari
Hi,
For what it's worth, at Tweag we've developed some preliminary bindings to Apache Spark, and as part of this we developed a somewhat decent API for calling Java. You can check it out on hackage [1] and on github [2]. In cast that can save you some time or inspire you.
[1]: http://hackage.haskell.org/package/inline-java [2]: https://github.com/tweag/sparkle -- see the inline-java directory
On Sun, May 22, 2016 at 4:54 AM, Rahul Muttineni
wrote: Hi Haskell-Cafe,
I've been working on a JVM backend for GHC [1] and I took some time to flesh out a design for the Java FFI [2] which will pretty much decide whether the project will be useful or not. I would love feedback from the community on how to improve the design or requests for important interop features that I have neglected.
Thanks, Rahul Muttineni
[1] http://github.com/rahulmutt/ghcvm [2] https://gist.github.com/rahulmutt/355505bce57c7c2cffd7d4cf5edddad4
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- Alp Mestanogullari
-- Rahul Muttineni

Hey Rahul,
Please keep us posted about further experiments/benchmarks, I'm really
interested in seeing where GHCVM goes and what we can learn/reuse from it :)
Cheers
On Wed, May 25, 2016 at 6:20 AM, Rahul Muttineni
Hi Alp,
I had a nice time going through inline-java and sparkle! The API I made up for the Java FFI is similar to yours but I don't do the extensive type-level hackery that you have. Another key difference is that I use GHC Annotations to specify the qualified class name where you use type-level strings.
Nice work supporting almost all of the JNI in a clean way! I recently looked at the JNI API and it stated that the functions that interact with the JVM are a tad slow due to reflection + the fact that native methods don't get inlined. I'm interested in benchmarking programs compiled with GHC/Sparkle vs GHCVM/FFI to Spark once the first release is out.
Thanks, Rahul
On Sun, May 22, 2016 at 1:05 PM, Alp Mestanogullari
wrote: Hi,
For what it's worth, at Tweag we've developed some preliminary bindings to Apache Spark, and as part of this we developed a somewhat decent API for calling Java. You can check it out on hackage [1] and on github [2]. In cast that can save you some time or inspire you.
[1]: http://hackage.haskell.org/package/inline-java [2]: https://github.com/tweag/sparkle -- see the inline-java directory
On Sun, May 22, 2016 at 4:54 AM, Rahul Muttineni
wrote: Hi Haskell-Cafe,
I've been working on a JVM backend for GHC [1] and I took some time to flesh out a design for the Java FFI [2] which will pretty much decide whether the project will be useful or not. I would love feedback from the community on how to improve the design or requests for important interop features that I have neglected.
Thanks, Rahul Muttineni
[1] http://github.com/rahulmutt/ghcvm [2] https://gist.github.com/rahulmutt/355505bce57c7c2cffd7d4cf5edddad4
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- Alp Mestanogullari
-- Rahul Muttineni
-- Alp Mestanogullari

What about Frege? Haskell on the JVM with interop to Java libraries...
https://github.com/Frege/frege
On Sat, May 21, 2016 at 7:54 PM, Rahul Muttineni
Hi Haskell-Cafe,
I've been working on a JVM backend for GHC [1] and I took some time to flesh out a design for the Java FFI [2] which will pretty much decide whether the project will be useful or not. I would love feedback from the community on how to improve the design or requests for important interop features that I have neglected.
Thanks, Rahul Muttineni
[1] http://github.com/rahulmutt/ghcvm [2] https://gist.github.com/rahulmutt/355505bce57c7c2cffd7d4cf5edddad4
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 05/22/2016 10:16 AM, David Escobar wrote:
What about Frege? Haskell on the JVM with interop to Java libraries...
It doesn't support MPTCs, Type families, FunDeps, etc. etc. (I'm not trying to rag on the project. Supporting all of the now-almost-mandatory exensions in GHC is a highly non-trivial undertaking.) Regards,

Makes sense. I hadn't thought about all the GHC extensions.
On Mon, May 23, 2016 at 8:24 AM, Bardur Arantsson
On 05/22/2016 10:16 AM, David Escobar wrote:
What about Frege? Haskell on the JVM with interop to Java libraries...
It doesn't support MPTCs, Type families, FunDeps, etc. etc.
(I'm not trying to rag on the project. Supporting all of the now-almost-mandatory exensions in GHC is a highly non-trivial undertaking.)
Regards,
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Hi David,
You can find the differences between GHCVM and Frege here:
https://github.com/rahulmutt/ghcvm/issues/3
The primary difference is that since we're using the GHC API, you'll have
the access to all the features of GHC Haskell (barring Template Haskell
which requires more effort).
Also, the interaction with Java is very different, see here:
https://gist.github.com/rahulmutt/355505bce57c7c2cffd7d4cf5edddad4
Thanks,
Rahul
On Sun, May 22, 2016 at 1:46 PM, David Escobar
What about Frege? Haskell on the JVM with interop to Java libraries...
https://github.com/Frege/frege
On Sat, May 21, 2016 at 7:54 PM, Rahul Muttineni
wrote: Hi Haskell-Cafe,
I've been working on a JVM backend for GHC [1] and I took some time to flesh out a design for the Java FFI [2] which will pretty much decide whether the project will be useful or not. I would love feedback from the community on how to improve the design or requests for important interop features that I have neglected.
Thanks, Rahul Muttineni
[1] http://github.com/rahulmutt/ghcvm [2] https://gist.github.com/rahulmutt/355505bce57c7c2cffd7d4cf5edddad4
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- Rahul Muttineni

Thank you for the information Rahul. This makes it clear.
On Tue, May 24, 2016 at 9:56 PM, Rahul Muttineni
Hi David,
You can find the differences between GHCVM and Frege here: https://github.com/rahulmutt/ghcvm/issues/3
The primary difference is that since we're using the GHC API, you'll have the access to all the features of GHC Haskell (barring Template Haskell which requires more effort).
Also, the interaction with Java is very different, see here: https://gist.github.com/rahulmutt/355505bce57c7c2cffd7d4cf5edddad4
Thanks, Rahul
On Sun, May 22, 2016 at 1:46 PM, David Escobar
wrote: What about Frege? Haskell on the JVM with interop to Java libraries...
https://github.com/Frege/frege
On Sat, May 21, 2016 at 7:54 PM, Rahul Muttineni
wrote: Hi Haskell-Cafe,
I've been working on a JVM backend for GHC [1] and I took some time to flesh out a design for the Java FFI [2] which will pretty much decide whether the project will be useful or not. I would love feedback from the community on how to improve the design or requests for important interop features that I have neglected.
Thanks, Rahul Muttineni
[1] http://github.com/rahulmutt/ghcvm [2] https://gist.github.com/rahulmutt/355505bce57c7c2cffd7d4cf5edddad4
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- Rahul Muttineni
participants (4)
-
Alp Mestanogullari
-
Bardur Arantsson
-
David Escobar
-
Rahul Muttineni