JNIPort for VisualWorks updated

Hi all,

I have posted an updated version of JNIPort for VisualWorks to the
Cincom Public Repository.

JNIPort is an interface which makes it possible to transparently use
Java libraries from Smalltalk. It invokes a Java VM using the Invocation
Interface functions of the Java Native Interface (JNI). Once the full
functionality works, it will automatically generate wrapper classes for
Java classes, enabling to write code like this:

        jvm := JVM current.
        zfClass := jvm findClass: #'java.util.zip.ZipFile'.
        zipfile := zfClass new_String: aFilenameAsString.
        zipfile size_null. "--> answers an Integer"
        entries := zipfile entries_null.
        entries asAnEnumeration do:
                [:each | Transcript print: each; cr].

The methods new_String:, size_null, entries_null will be generated in a
"ghost class" when the JVM accesses the Java class - no need to write code!

Chris Uppal has sent me several bug fixes and changes to bring JNIPort
up to date. I have changed the unit tests to use SUnitToo instead of
SUnit and added some more bug fixes.

It is already possible to execute Java methods and access Java objects.
Chris' example for accessing ZIP files using java.util.zip.ZipFile works:
http://www.metagnostic.org/DolphinSmalltalk/JNIPort/java-base-example-1.html

The unit tests for the base layer are almost all green. There are 6
tests which fail because out-of-range values for short and byte values
do not raise exceptions as expected, and one test fails because of a bug
somewhere in the conversion between Java and Smalltalk strings (only for
two-byte characters).

If you want to run the tests, the corresponding Java code (files
"Extras\JNIPort.jar" and "Extras\JNIPort-Tests.jar" in the JNIPort
download) must be on the Java classpath. One way to ensure this is to
set the CLASSPATH environment variable like this if you have copied the
two jar files to the working directory:
        CLASSPATH=.;JNIPort.jar;JNIPort-Tests.jar
It is better to use absolute paths, as VisualWorks 7.4.1 changes its
current directory when using the Windows file dialog - this can have the
consequence that the Java VM looks in the wrong directory.

To run the tests in the package "CU Java Base Tests", first execute
        JVM default
in a workspace, which initializes a running Java VM. The tests for
wrapper generation and for callbacks from Java will break when the
default JVM is used. You have to use a JVM configured for wrapper
generation and callbacks to run them.

What's next (feel free to help me):
- Fix the bug in String conversion.
- Add checks for out-of-bounds values for short and byte values.
- Make finalization of JavaClassInstances work.
- Make wrapper class generation work (if it doesn't already by
  accident).
- Make callbacks work.
- Add a GUI for configuration, monitoring, and inspecting ghost classes.
- See what happens when using Java 1.6.

Give it a try!

Joachim Geidel

Joachim Geidel schrieb am 20.01.2007 17:54: