JNIPort for VisualWorks Update

Hi all,

I made a new version of JNIPort for VisualWorks available in the Cincom
Public Store 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). For more
information on JNIPort see
        http://www.metagnostic.org/DolphinSmalltalk/JNIPort.html

The new version is a breakthrough:
----------------------------------
* IMHO, it seems to be stable. With the usual caveats, and the "use it
at your own risk" provision of Chris Uppal's JNIPort licence, of course.

* All the unit tests are green except for callbacks from Java to Smalltalk.

* Lazy generation of wrapper methods ("ghost methods") for Java classes
is working. This brings startup time for attaching a Java VM down to the
sub-second range on my laptop.

* JNIPort now has a settings tool which can be started from the
VisualLauncher's Tools menu. Using the context menu on the list subpane,
you can add new configurations, start and stop the Java VM, save the
settings to the Windows registry and load them from the registry.

* JavaObjects can be inspected in Trippy, showing the instance variables
of the Java objects they are representing, and the dynamically generated
ghost methods (glue code for Java methods).

* GhostMethods can be decompiled, such that it is possible to debug them
just like normal methods. You may wonder why this was an issue:
GhostMethods are special because some of their literals are not
literals, but things like MethodIDs, FieldIDs, or the JVM object. The
Decompiler was not really prepared for this, leading to endless
recursions in the debugger.

* Performance for ghost class generation has been doubled by reducing
the number of VM method cache flushes (which are a workaround for VM
crashes after code generation with the 7.4d VM - this is probably fixed
in 7.5, but I have not yet verified it). This brought down the time for
attaching a JVM with non-lazy ghost class creation to 6.5-10 seconds on
my laptop.

* Performance of JNI function calls has been improved by using Michael
Lucas-Smith's FastCMethodPointers package, which is available in the
public repository.

What you need:
--------------
- You will need the following components:
* Weaklings
* Registry
* FastCMethodPointers
* SUnitToo, SUnitToo(ls) - development only
* JNIPort Prerequisites
* JNIPort
* JNIPort Tests - development only
* JNIPort Tools - development only
* To run the unit tests, you will need the files contained in the
  'Extras' directory contained in the archive which can be downloaded
  from Chris Uppal's web site:
        http://www.metagnostic.org/DolphinSmalltalk/JNIPort-Complete.zip
  The archive also contains a copy of the complete documentation.
* Read the bundle comments for additional information.

What's missing:
---------------
- Callbacks from Java to Smalltalk don't work yet, they fail with a Java
exception (UnsatisfiedLinkError).

- JNIPort for VisualWorks has been tested on Windows XP SP2 with
VisualWorks 7.4.1, the VM 7.4d, and Sun's Java Runtime Environment
1.5.0_10. Other platforms, VW and Java versions have not yet been tested.

- The licensing conditions for my own contributions have yet to be
clarified in the package and bundle comments. Don't worry, they will be
functionally equivalent to Chris Uppal's license which allows to use it
wherever you want to (see the bundle and package comments).

What's next:
------------
- Callbacks from Java to Smalltalk.

- A Java class browser and other development tools. E.g., it may be
useful to generate static Smalltalk classes from ghost classes. A use
case for this would be: Develop an application using ghost class
generation, then create static Smalltalk classes for all ghost classes
generated, and switch to a JVM configuration which does not generate
ghost classes to enhance performance.

- Test it with Sun Java 1.6.

- Find people willing to test and adapt JNIPort for VisualWorks to other
platforms and Java versions.

- Bug fixing: When a VisualWorks image is saved with a running JVM, it
can happen that finalization of certain objects leads to an "External
access failed" exception. Workaround: stop the JVM using the settings
tool before saving the image. This should not be an issue for runtimes.

Enjoy!
Joachim Geidel