jvm-bridge-devel

[JVM-B] Calling Haskell from Java?

[Jan S. <jan...@gm...>]

Hi,

I want to call Haskell functions from a Java GUI.

Is this possible with the Haskell-jvm-bridge?
As far as I can see the bridge goes only in one direction: Call Java from 
Haskell.
Correct me if I'm wrong.

Do you know of any other ways of calling Haskell from Java?

Thanks a lot.

Best regards,
Jan

[JVM-B] ANNOUNCE: Haskell/Java VM Bridge 0.2.1 Release

[Ashley Y. <as...@se...>]

Release 0.2.1 of Haskell/Java VM Bridge is now available in source-code 
form. 

0.2.1 is a minimal update to work with GHC 6.0. If you are using GHC 
5.04, you should use the 0.2 release instead.


Haskell/Java VM Bridge allows Haskell programs access to the Java Virtual 
Machine. It comes in two parts: the 'Native' part, that abstracts away 
differences in the various Java VMs, and the 'Haskell' part that provides 
a Haskell API. The Native part is not Haskell-specific, and could 
potentially be used by other languages wishing to access the Java VM.

Features include:

* Calling of Java methods, access to fields, array-handling;

* Integration of garbage collectors;

* Reconciliation of exception models;

* Reconciliation of thread models, including 'synchronized' monitor 
support and the ability to fork Haskell actions as Java threads;

* Strong typing for Java classes and method argument lists (as tuples), 
and use of Haskell lists as arrays;

* Creation of Java classes 'on the fly' (using DefineClass and the Java 
Class File Format) that can have Haskell callback methods;

* Lifted monads which do all the necessary JNI class and method/field ID 
preloading and 'JNIEnv'-pointer variable handling for you -- these can be 
automatically generated via a tool (MakeJVMModule);

* Layered design includes lower-level IO-based interface;

* Automatic generation of modules for Java API classes;

* All relevant imports, flags and libraries etc. handled by a single GHC 
package 'javavm';

* No 'unsafe' Haskell calls or pure function FFI anywhere;

* Easy to port to new Java VMs.

This release should be 'beta' quality, but has undergone little testing.

You will need:

* An x86 machine running some form of Unix, or a Mac OS X machine;

* GHC 6.0 or later;

* A Java VM. It's been tested only with Sun's JVM, but should (may?) work 
with a number of others.

Haddock documentation is currently blocked on a bug in Haddock ("implicit 
parameters"). Should that be fixed, you will be able to build API 
documentaion by doing "make doc".

Some simple examples have been included such as a program that shows a 
Java Frame containing an instance of a Haskell-defined subclass of Canvas 
that has a Haskell 'paint' method that draws an oval. You should be able 
to figure out most of it from that.

Haskell/JVM Bridge and source code is licensed under the GNU Lesser GPL.

<http://sourceforge.net/projects/jvm-bridge/>


Future plans:

* port to Cygwin

* use hierarchical module structure

* separate out pure (non-FFI) Haskell into a separate package

* better typing for the IO-based layer


-- 
Ashley Yakeley, Seattle WA
Almost empty page: <http://semantic.org/>

[JVM-B] ANNOUNCE: Haskell/Java VM Bridge 0.2 Release

[Ashley Y. <as...@se...>]

Release 0.2 of Haskell/Java VM Bridge is now available in source-code 
form.

New in Version 0.2:

Haskell:

	* 'Haskell' now a separate Autotools project installing in 
/usr/lib/jvm-bridge/

	* New array region access functions

	* Correct array types in autogenerated class interfaces

	* Subtype parameters in autogenerated class interfaces

	* VMLayer 'env' parameter now implicit

	* Various changes in the BasicLayer

	* new native StartExecuteFunction function called by 
getExecuteFunctionClass, defineCallbackClass

Native:

	* Mac OS X support
	
	* Beginnings of MinGW32/Cygwin support
	
	* New Sun 1.4 JVM

	* Now installs in /usr/lib/jvm-bridge/
	
	* ExecuteFunction bindings now done at run-time


Haskell/Java VM Bridge allows Haskell programs access to the Java Virtual 
Machine. It comes in two parts: the 'Native' part, that abstracts away 
differences in the various Java VMs, and the 'Haskell' part that provides 
a Haskell API. The Native part is not Haskell-specific, and could 
potentially be used by other languages wishing to access the Java VM.

Features include:

* Calling of Java methods, access to fields, array-handling;

* Integration of garbage collectors;

* Reconciliation of exception models;

* Reconciliation of thread models, including 'synchronized' monitor 
support and the ability to fork Haskell actions as Java threads;

* Strong typing for Java classes and method argument lists (as tuples), 
and use of Haskell lists as arrays;

* Creation of Java classes 'on the fly' (using DefineClass and the Java 
Class File Format) that can have Haskell callback methods;

* Lifted monads which do all the necessary JNI class and method/field ID 
preloading and 'JNIEnv'-pointer variable handling for you -- these can be 
automatically generated via a tool (MakeJVMModule);

* Layered design includes lower-level IO-based interface;

* Automatic generation of modules for Java API classes;

* All relevant imports, flags and libraries etc. handled by a single GHC 
package 'javavm';

* No 'unsafe' Haskell calls or pure function FFI anywhere;

* Easy to port to new Java VMs.

This release should be 'beta' quality, but has undergone little testing.

You will need:

* An x86 machine running some form of Unix, or a Mac OS X machine;

* GHC 5.02.4 or later;

  In particular, GHC 5.02.2 and earlier will not work on Mac OS X.

* A Java VM. It's been tested only with Sun's JVM, but should (may?) work 
with a number of others.

Haddock documentation is currently blocked on a bug in Haddock ("implicit 
parameters"). Should that be fixed, you will be able to build API 
documentaion by doing "make doc".

Some simple examples have been included such as a program that shows a 
Java Frame containing an instance of a Haskell-defined subclass of Canvas 
that has a Haskell 'paint' method that draws an oval. You should be able 
to figure out most of it from that.

Haskell/JVM Bridge and source code is licensed under the GNU Lesser GPL.

<http://sourceforge.net/projects/jvm-bridge/>


Future plans:

* port to Cygwin

* use hierarchical module structure

* separate out pure (non-FFI) Haskell into a separate package

* better typing for the IO-based layer


-- 
Ashley Yakeley, Seattle WA
Almost empty page: <http://semantic.org/>

[JVM-B] JVM-Bridge close to 0.2

[Ashley Y. <as...@se...>]

I'd like to do a 0.2 release soon. What I now have in CVS seems to work 
OK on MacOS X and Linux. Could you see how it works for Windows?

-- 
Ashley Yakeley, Seattle WA

[JVM-B] Re: Thanks for your classwriter modules, and small bug? in getfield/putfield

[Ashley Y. <as...@se...>]

At 2002-10-11 08:13, Arthur Baars wrote:

>Hi Ashley,
>
>I found your JVM-bridge software after reading the "Java representation in
>Haskell" thread on the haskell mailing list. I used your java class file
>writer(JCF*.hs) as a back-end for a simple "Featherweight Java" compiler.
>It really like the library, it was easy to use to assemble class files.
>
>Unfortunately the class file writer modules did not work using Hugs. The
>main reason is that most of them import "BasicLayer", which in itself
>imports other non-hugs compatible modules. Fortunately none of the JCF
>modules really needs the BasicLayer(some of them require Bytes.hs, but
>that's all). After changing the imports I only had a problem with the Word64
>type which is not fully implemented in Hugs. Removing all the code that
>referred to the Word64 type, and adapting the "JFCWritable" instance for
>"Int64" was sufficient to get all your class writer code running in Hugs.

I haven't even tried to use it with Hugs...

>I added some code as well to the instruction module, because I needed the
>new, checkcast and dup instructions.

OK, I've put these in (in CVS).

>Are you planning to add all jvm instructions to JCFCodeInstruction in the
>future?

Originally I added just enough to write callback classes. I can't add 
branch instructions without rewriting the stack depth calculation code, 
etc.

>Maybe it is a good idea to distribute the class file writer as a
>separate library as well.

This is an excellent idea. I'd like to do a new release shortly, and 
after that I want to organise the modules hierarchically. All the stuff 
that doesn't use FFI (the 'Basic', 'Java' and 'JCF' layers) except maybe 
JCFCallback* should be in a separate project that can be made to work 
with Hugs.

>I think I discovered a small bug in your code in the getfield and putfield
>instructions.

Thanks, I've put this fix in.

-- 
Ashley Yakeley, Seattle WA

[JVM-B] Re: haskell-jvm-bridge

[Ashley Y. <as...@se...>]

At 2002-10-10 08:44, Assini, Pasqualino wrote:

>I wondered if you were planning to make your haskell-jvm-bridge available
>for Java 1.4/Windows ?

Yes, Thomas Pasch is working on it. All the code is in CVS, but we're not 
quite ready for a new release...

-- 
Ashley Yakeley, Seattle WA

[JVM-B] Re: jvm-bridge

[Ashley Y. <as...@se...>]

At 2002-10-10 04:03, Pasch, Thomas (ACTGRO) wrote:

>because of the ghc 5.04.1 release, i tried to compile jvm-bridge again on
>Windows NT with J2SDK1.4.1. Works fine, except one (small)
>problem (see below). No more problems to compile the examples
>(except of the linker problem that is still there).
>
>Perhaps it is time for a new release?

I've just checked in a bunch of changes, but I haven't quite finished. 
Probably we should do a new release soon, and then after that I want to 
organise the Haskell into hierarchical modules.

>In javavm.ghc-pkg I had to change 
>
>extra_frameworks = ["-LD:/Programme/j2sdk1.4.1/jre/",
>"-LD:/Programme/j2sdk1.4.1/jre/bin/",
>"-LD:/Programme/j2sdk1.4.1/jre/bin/client/", "-ljvm"],
>
>to 
>
>extra_frameworks = [-LD:/Programme/j2sdk1.4.1/jre/
>-LD:/Programme/j2sdk1.4.1/jre/bin/ -LD:/Programme/j2sdk1.4.1/jre/bin/client/
>-ljvm],
>
>Because of my ignorance of m4, I've got problems to fix this.

extra_frameworks should be empty except on Darwin machines. It's a bug in 
javavm.ghc-pkg.m4, I'll try to fix it.

-- 
Ashley Yakeley, Seattle WA

[JVM-B] Java VM Bridge / HC&A Report

[Ashley Y. <as...@se...>]

For the Haskell Communities and Activities Report:

Java VM Bridge
Java VM Bridge is a GHC package intended to allow full access to the Java 
Virtual Machine from Haskell, as a simple way of providing a wide range 
of imperative functionality. Its big advantage over earlier attempts at 
this is that it includes a straightforward way of creating Java classes 
at run-time that have Haskell methods (using DefineClass and the Java 
Class File Format). It also features reconciliation of thread models 
without requiring GPH.

It is intended to make writing "Java in Haskell" as straightforward as 
possible. To this end, each Java class is a separate type, and the 
argument lists of methods of automatically-generated interfaces to Java 
classes make use of subtype class relations to minimise explicit upward 
casting. Java exceptions are represented as Haskell monadic exceptions, 
and may be caught or thrown accordingly. Also, the two garbage collectors 
are integrated in such a way that cross-collector reference loops won't 
happen.

As a point of cleanliness and principle, it makes no use of "unsafe" 
Haskell calls (or pure function FFI). The layered design allows access to 
either lifted monads that keep track of context data (specifically, the 
JNIEnv pointer) and do all the work of preloading for you, or "IO"-based 
functions if you want to do all that yourself.

Current Status:
A beta-quality 0.1 was released in December 2001, for x86 Unix only. 
Release 0.2 will also be available for Windows and MacOS X, just as soon 
as stable 5.04 GHC is available on those platforms (unless I get tired 
waiting).

Contact: Ashley Yakeley <as...@se...>

-- 
Ashley Yakeley, Seattle WA

Re: [JVM-B] FW: More Diffs

[Ashley Y. <as...@se...>]

At 2002-04-22 04:30, Pasch, Thomas (ACTGRO) wrote:

>> - some fixes for problems on the windows platform (can't use /dev/sterr,
>>   tempfile, and readlink -f)

Does "mktemp" work for you?


-- 
Ashley Yakeley, Seattle WA

Re: [JVM-B] FW: More Diffs

[Ashley Y. <as...@se...>]

At 2002-04-23 02:07, Ashley Yakeley wrote:

>Does this work in your "sh" shell?
>
>  ghc -v 2>&1 | sed -n -e 's|^Using package config file: 
>\(.*/\)[^/]*$|\1| p'

Should be all on one line. Or else this:

#!/bin/sh
ghc -v 2>&1 |
sed -n -e 's|^Using package config file: \(.*/\)[^/]*$|\1| p'




-- 
Ashley Yakeley, Seattle WA

Re: [JVM-B] FW: More Diffs

[Ashley Y. <as...@se...>]

At 2002-04-22 04:30, Pasch, Thomas (ACTGRO) wrote:

>> - some fixes for problems on the windows platform (can't use /dev/sterr,
>>   tempfile, and readlink -f)

I'm currently working on detecting the location of the GHC include 
directory for HC_INCDIR. I can't use readlink without -f on my machine, 
since it is a double symlink. Instead I'm going to try out pulling it 
from "ghc -v".

Does this work in your "sh" shell?

  ghc -v 2>&1 | sed -n -e 's|^Using package config file: 
\(.*/\)[^/]*$|\1| p'



-- 
Ashley Yakeley, Seattle WA

[JVM-B] FW: More Diffs

[Pasch, T. (ACTGRO) <ext...@vo...>]

> Dear Ashley,
> 
> this weekend, I tried the Saturday CVS on GHC-5.02.3 on Windows.
> I produced a new diff which includes:
> 
> - some fixes for problems on the windows platform (can't use /dev/sterr,
>   tempfile, and readlink -f)
> - a Building.win32 file with some advices for building
> - added to Makefile.am MAINTAINERCLEANFILES to get ride of
>   all file not in the CVS when you say 'make maintainer-clean'
> 
> Add the moment, only one (easy hand-solvable) problem remains
> when compiling on Windows.
> 
> Apart form this it is not easy to compile Class_java_awt_Component.hs
> on Windows. You need a CVS version of GHC or the 5.03 
> pre-build. This is the reason a enclosed a compiled version in this mail.
> Perhaps you want to place it in the download section on sourceforge.
> 
> Kind regards,
> 
> Thomas
>  <<diff>> 
PS: Stripped the attachments a bit for FW to jvm-bridge-devel 

[JVM-B] JVM-Bridge Current Status

[Ashley Y. <as...@se...>]

1. Changes So Far
The following changes have been checked into CVS since the 0.1 release:

Native/

  * MacOS X support

  * Beginnings of mingw32 support

  * New Sun 1.4 JVM

  * Now installs in /usr/lib/jvm-bridge/

  * ExecuteFunction bindings now done at run-time

Haskell/

  * MacOS X support

  * 'Haskell' now a separate Autotools project installing in 
/usr/lib/jvm-bridge/

  * New array region access functions

  * Correct array types in autogenerated class interfaces

  * Subtype parameters in autogenerated class interfaces

  * VMLayer 'env' parameter now implicit

  * Various changes in the BasicLayer

  * new native StartExecuteFunction function called by 
getExecuteFunctionClass, defineCallbackClass

I recommend using GHC 5.02.2 or later. Possibly it might work with 5.02.

2. Current Work
MacOS X callback support is buggy, and I'm currently working on it. It 
might a problem with ghc-5.03-13032002-MacOSX (foreign export dynamic), 
or it might be a bug in JVM-Bridge.

Thomas Pasch <ext...@vo...> has done some work on 
getting JVM-Bridge to compile under mingw32. I have integrated some of 
his patches. I do not have a Windows machine myself.

I would like to do a 0.2 release, say when both examples work on all 
three platforms.

3. I have created a new mailing list:
<http://lists.sourceforge.net/lists/listinfo/jvm-bridge-devel>
If you are using JVM-Bridge I encourage you to subscribe.


-- 
Ashley Yakeley, Seattle WA