JNIPort 0.40 available in public repository

> A new version of JNIPort for VisualWorks, an interface for using  
> Java in
> VisualWorks, is available in the Cincom Public Repository.
>
> If you want to learn about JNIPort, read Chris Uppal's  
> documentation at
>   http://www.metagnostic.org/DolphinSmalltalk/JNIPort/index.html
> You should also read the comment of the bundle JNIPort which tells you
> what you have to load.
>
> Changes
> -------
> The new version does not contain any new features. I have  
> simplified the
> low level code for calling the functions of the Java Native Interface,
> resulting in the removal of several classes which corresponded to
> CTypes, but didn't have any interesting behaviour of their own.  
> Another
> change removes redundancies in the way the JNI functions are called,
> resulting in the removal of more than 200 methods. I also think that I
> have solved a bug in the "lazy ghost classes", which was more or less
> un-debuggable as it occurred in the middle of the resolution of a  
> proxy
> object. At least, lazy ghost classes haven't caused me any problems
> after the change. Let me know if they work for you.
>
> Plans
> -----
> At the ESUG 2007 conference at Lugano, Johan Brichau and I decided  
> that
> we want to investigate if and how Johan's JavaConnect, which is  
> also in
> the public repository, and JNIPort can be merged. JavaConnect has some
> interesting features, e.g. using VisualWorks NameSpaces as surrogates
> for Java packages, such that Java classes (or more precisely, their
> Smalltalk surrogates) can be referenced directly in Smalltalk methods,
> and can show up in browsers.
>
> Some features of JNIPort work on Windows only currently. I have tested
> JNIPort on Ubuntu Linux, and it worked with minor restrictions (see
> below). I would like to add full support for Linux next.
>
> Code generation for Java Wrapper Classes can be made much faster  
> than it
> is now by copying prototype methods into the wrapper classes,  
> instead of
> generating source code and compiling it. The predefined wrapper  
> classes
> have to look up Java MethodIDs every time they send a message to Java.
> This can be avoided by caching the MethodIDs either directly in the
> bytecode of the methods or in a registry in the wrapper class.  
> There are
> additional places where the performance of message sends to Java  
> objects
> can be enhanced.
>
> I have not yet tested callbacks from Java to VisualWorks when the
> callbacks come from a foreign thread. This has to be done.
>
> If you need any of this soon, feel free to contribute. ;-) I won't
> promise anything concerning the time frame.
>
> Restrictions
> ------------
> The features not supported on Linux/Unix/MacOS-X are:
>
> - The ExternalInterface to JNI has to be modified for MacOS-X.
> Apparently, the JNI functions are called differently on this platform.
>
> - The automatic discovery of where the Java VM is installed, which
> relies on the Windows registry. On other platforms, you have to set  
> the
> absolute path to the Java VM library in the settings for the JVM  
> (in the
> JNIPort settings tool or programmatically).
>
> - The "JVM hooks", which are low level callbacks from the Java VM to
> VisualWorks for debuging output and exit/abort notification, should be
> used in combination with a helper DLL which is available for Windows
> only at the moment. You can use them without this library, but you  
> risk
> deadlocks if the Java code which you call forks threads. This happens
> e.g. when you open Swing windows via JNI. On non-Windows platforms,
> either switch off the options called "use...Hook" in the JNIPort
> settings of the JVM, or use them only when you are sure that there  
> will
> be no additional threads in the Java VM which might cause deadlocks.
> This is of practical relevance only when you use Java VM options like
> "-verbose", "-verbose:jni", or "-verbose:class" in addition to  
> switching
> on the callbacks.
>
> Best regards,
> Joachim Geidel
>