[ANN] JNIPort for Pharo 3.0 alpha

Hi everybody,

JNIPort for Pharo 3.0 alpha is now available at SmalltalkHub.

JNIPort is a Smalltalk library which allows Java code to be invoked from
Smalltalk. It acts as a bridge between the world of Smalltalk objects and a
Java Virtual Machine (JVM) where Java code is executing.

When I first ported JNIPort to Squeak and Pharo 1.x, I used Alien as the FFI
library. As NativeBoost has superseded Alien, the interface to the Java
Native Interface library had to be rewritten. There are still some
undocumented and obscure parts in NativeBoost, so this has taken some time.

If you want to try it, load it via the ConfigurationOfJNIPort. I hope this
works. If it does not, load the packages individually in the order in which
they appear in the ConfigurationOfJNIPort.
        http://www.smalltalkhub.com/#!/~JNIPort/JNIPort
The next step is to read the documentation at
        http://jniport.wikispaces.com/
Otherwise, you won't know what to do next. ;-)
Download the extra files from the download page at Wikispaces, you will need
two jar files from there.

Start a Java VM attached to Pharo by adapting and executing the following
code snippet:

----
| jvmSettings |
 "You can set the path to the Java VM library by editing the path as
needed."
JNIPortJNIInterface libraryFile:
'/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib'
.
"JNIPortJNIInterface libraryFile:
'C:\Programme\Java\jre7\bin\client\jvm.dll' ."

 jvmSettings := JVMSettings new.
 jvmSettings usesGhosts: true.
 jvmSettings supportsCallbacks: true.
 jvmSettings jniPortSettings  useJNIHelperLibrary: false.
jvmSettings ghostClassSettings retainMethodSource: true.

 "On Mac OS X and Linux, class path entries are separated by colons."
 "On Windows, you have to use semicolons instead. Edit the following line as
needed."
jvmSettings runtimeSettings classpath:
'.:/Users/myname/JNIPort.jar:/Users/myname/JNIPort-Tests.jar'.
" jvmSettings runtimeSettings classpath:
'.;.\JNIPort.jar;.\JNIPort-Tests.jar'."

 "Uncomment the following if you want the Java VM to emit verbose messages.
  How to access these messages depends on your platform.
  On Mac OS X, they are visible in the Console application."
"jvmSettings runtimeSettings addOption: '-verbose:jni'; addOption:
'-verbose:gc'; addOption: '-verbose:class'."
Cursor execute showWhile: [JVM newWithSettings: jvmSettings].
----

Then the fun starts:

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

And now to the ugly little secret reason why I call it an alpha version:

While everything seems to work, it is *much* slower than it used to be in
Pharo 1.2 with Alien. And when I compare it with VisualWorks, I wonder if
the Pharo version secretly does some additional work for SETI:
- Starting the JVM:
        VisualWorks 0.7 seconds
        Pharo 7 to 8 seconds
- A benchmark using some methods of java.io.BufferedReader and
java.util.StringTokenizer:
        VisualWorks 114 milliseconds
        Pharo 12 to 13 seconds

I have not yet found the reason. The TimeProfiler is not very helpful, as
its 1 millisecond resolution is too coarse. It would be nice if it had
microsecond resolution. From the TimeProfiler results, it seems that calling
a JNI method with NativeBoost is extremely slow, but I don't trust those
profiles too much.

So, give it a try, and if you find something useful concerning the bad
performance, please send me a message.

Best regards,
Joachim Geidel




--
View this message in context: http://forum.world.st/ANN-JNIPort-for-Pharo-3-0-alpha-tp4750750.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Works on Windows 8.1 x64 with a 32-bit JRE 1.7 on a freshly fetched Pharo30

 

There is a Transcript flush that would help seeing the output to the Transcript…

 

Snippet:

 

| jvmSettings |

"You can set the path to the Java VM library by editing the path as

needed."

"JNIPortJNIInterface libraryFile:

'/System/Library/Java/JavaVirtualMachines/1..6.0.jdk/Contents/Libraries/libclient.dylib'"

.

JNIPortJNIInterface libraryFile: 'C:\Program Files (x86)\Java\jre7\bin\client\jvm.dll' ..

 

jvmSettings := JVMSettings new.

jvmSettings usesGhosts: true.

jvmSettings supportsCallbacks: true.

jvmSettings jniPortSettings  useJNIHelperLibrary: false.

jvmSettings ghostClassSettings retainMethodSource: true.

 

"On Mac OS X and Linux, class path entries are separated by colons."

"On Windows, you have to use semicolons instead. Edit the following line as

needed."

"jvmSettings runtimeSettings classpath:

'.:/Users/myname/JNIPort.jar:/Users/myname/JNIPort-Tests.jar'."

jvmSettings runtimeSettings classpath: '.;.\JNIPort.jar;.\JNIPort-Tests.jar'.

 

"Uncomment the following if you want the Java VM to emit verbose messages.

  How to access these messages depends on your platform.

  On Mac OS X, they are visible in the Console application."

"jvmSettings runtimeSettings addOption: '-verbose:jni'; addOption:

'-verbose:gc'; addOption: '-verbose:class'."

Cursor execute showWhile: [JVM newWithSettings: jvmSettings].

"----

 

Then the fun starts:

 

----"

zfClass := JVM current findClass: #'java.util.zip.ZipFile'.

zipfile := zfClass new_String: 'JNIPort.jar'.

zipfile size. "--> answers an Integer"

entries := zipfile entries.

entries asAnEnumeration do: [:each | Transcript cr; print: each].

Transcript flush.

"----"

 

Cool to have a bridge.

 

Phil

 

 

From: Pharo-users [mailto:[hidden email]] On Behalf Of Tudor Girba
Sent: mardi 25 mars 2014 21:26
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] [ANN] JNIPort for Pharo 3.0 alpha

 

Thanks a lot for this contribution!

 

I will give it a try soon.

 

Doru

 

On Tue, Mar 25, 2014 at 7:59 PM, Joachim Geidel <[hidden email]> wrote:

Hi everybody,

JNIPort for Pharo 3.0 alpha is now available at SmalltalkHub.

JNIPort is a Smalltalk library which allows Java code to be invoked from
Smalltalk. It acts as a bridge between the world of Smalltalk objects and a
Java Virtual Machine (JVM) where Java code is executing.

When I first ported JNIPort to Squeak and Pharo 1.x, I used Alien as the FFI
library. As NativeBoost has superseded Alien, the interface to the Java
Native Interface library had to be rewritten. There are still some
undocumented and obscure parts in NativeBoost, so this has taken some time.

If you want to try it, load it via the ConfigurationOfJNIPort. I hope this
works. If it does not, load the packages individually in the order in which
they appear in the ConfigurationOfJNIPort.
        http://www.smalltalkhub.com/#!/~JNIPort/JNIPort
The next step is to read the documentation at
        http://jniport.wikispaces.com/
Otherwise, you won't know what to do next. ;-)
Download the extra files from the download page at Wikispaces, you will need
two jar files from there.

Start a Java VM attached to Pharo by adapting and executing the following
code snippet:

----
| jvmSettings |
 "You can set the path to the Java VM library by editing the path as
needed."
JNIPortJNIInterface libraryFile:
'/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib'
.
"JNIPortJNIInterface libraryFile:

'C:\Programme\Java\jre7\bin\client\jvm.dll' .."

 jvmSettings := JVMSettings new.
 jvmSettings usesGhosts: true.
 jvmSettings supportsCallbacks: true.
 jvmSettings jniPortSettings  useJNIHelperLibrary: false.
jvmSettings ghostClassSettings retainMethodSource: true.

 "On Mac OS X and Linux, class path entries are separated by colons."
 "On Windows, you have to use semicolons instead. Edit the following line as
needed."
jvmSettings runtimeSettings classpath:
'.:/Users/myname/JNIPort.jar:/Users/myname/JNIPort-Tests.jar'.
" jvmSettings runtimeSettings classpath:
'.;.\JNIPort.jar;.\JNIPort-Tests.jar'."

 "Uncomment the following if you want the Java VM to emit verbose messages.
  How to access these messages depends on your platform.
  On Mac OS X, they are visible in the Console application."
"jvmSettings runtimeSettings addOption: '-verbose:jni'; addOption:
'-verbose:gc'; addOption: '-verbose:class'."
Cursor execute showWhile: [JVM newWithSettings: jvmSettings].
----

Then the fun starts:

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

And now to the ugly little secret reason why I call it an alpha version:

While everything seems to work, it is *much* slower than it used to be in
Pharo 1.2 with Alien. And when I compare it with VisualWorks, I wonder if
the Pharo version secretly does some additional work for SETI:
- Starting the JVM:
        VisualWorks 0.7 seconds
        Pharo 7 to 8 seconds
- A benchmark using some methods of java.io.BufferedReader and
java.util.StringTokenizer:
        VisualWorks 114 milliseconds
        Pharo 12 to 13 seconds

I have not yet found the reason. The TimeProfiler is not very helpful, as
its 1 millisecond resolution is too coarse. It would be nice if it had
microsecond resolution. From the TimeProfiler results, it seems that calling
a JNI method with NativeBoost is extremely slow, but I don't trust those
profiles too much.

So, give it a try, and if you find something useful concerning the bad
performance, please send me a message.

Best regards,
Joachim Geidel




--
View this message in context: http://forum.world.st/ANN-JNIPort-for-Pharo-3-0-alpha-tp4750750.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

 

--

www.tudorgirba.com

 

"Every thing has its own flow"

---

Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! est active.

Hi Doru,

Am 27.03.2014 um 13:07 schrieb Tudor Girba:

> Just a question: is there a way to communicate with an already running VM that was started independently from Pharo?

JNIPort uses the Java VM as a DLL / shared library, using the Java Invocation Interface which is part of the Java Native Interface. Actually, the Java VM *is* a shared library, and the java.exe is just a wrapper for starting it. When using JNIPort, the Pharo VM and the Java VM run in the same operating system process, and communicating with the Java VM just means calling functions from a library.

Communicating with an already running Java VM is a totally different use case, as the Pharo VM and the Java VM run in two different operating system processes. To establish a communication between them, you would have to use an inter-process communication mechanism available in both of them. Pipes, TCP sockets, a messaging system, or running one of them as a server and the other as a client using a common protocol. That’s not what JNIPort is made for, and what you need for implementing it depends on the communication mechanism.

HTH,
Joachim

Am 31.03.2014 um 21:25 schrieb Tudor Girba <[hidden email]>:

> Now, the next question. I saw that it is possible to enable callbacks, but I could not find an example of how it works.
>
> For example, could we model this:
>
> - in a JavaClassOriginator class we have a method like
> execute(JavaClassTargetInterface target) { target.m() }
> - In Pharo we create PharoClassTargetImplementation as an implementation of JavaClassTargetInterface
> - passing an instance of PharoClassTargetImplementation to JavaClassOriginator results in calling PharoClassTargetImplementation>>m
>
> ?
>
>
> Cheers,
> Doru

Hi Doru,

it’s not completely straightforward, but also not really complicated. Chris Uppal’s JNIPort documentation contains examples, and you can also get some information from the test cases for callbacks. You will need the jniport.jar file which can be downloaded from http://jniport.wikispaces.com/Downloads (it is contained in JNIPort_Extras.zip). The Java classes needed for callback support have names starting with „Dolphin“ - they come directly from Chris’ implementation for Dolphin Smalltalk.

A simple example: To set up sending a simple notification without parameters to a Smalltalk object, you need a Java class similar to the following:

-----------------
package my.package;
import org.metagnostic.jniport.*;
public class MyClass
{
        private static final Object     notifyTag = new String("MyClass.sendNotification()“);
        public static Object notifyTag () { return notifyTag; }
        public void sendNotification()
                throws RequestNotHandedException
                {
                        new DolphinNotification(notifyTag, this).send();
                }
}
-----------------

You have to install the callback in Smalltalk:

-----------------
NotificationHandler := … "the object which receives the notifications"
classStatic := jvm findClass: 'my.package.MyClass'.
jvm callbackRegistry
        setCallback: classStatic notifyTag "the tag can be an arbitrary String"
        handler: [:this :param | NotificationHandler handleNotificationFor: this].
-----------------

When you send sendNotification() to an instance of MyClass, NotificationHandler should receive the message #handleNotificationFor:.

In the example code, the tag is a static variable in MyClass. Of course, you can also give every instance of MyClass its own tag. In this case, you have to set up a callback in Smalltalk for every tag which is used.

The example is a short version of the test code for handling notifications in JNIPortCallbackNotificationsTest and the corresponding Java class org.metagnostic.jniport.test.regression.Notifications. The source code of this Java class is in the archive JNIPort-Tests.zip which is contained in JNIPort_Extras.zip.

If you need an example for a notification which has parameters and where the Smalltalk code returns  a result, have a look at JNIPortCallbackRequestsTest>>testCallbackWithOneParameterAndReturn and the corresponding Java class org.metagnostic.jniport.test.regression.Callbacks.

In the Java class, you need something like this (copied from Callbacks and simplified) which enables a callback taking an int parameter and returning an instance of the Java class Integer:

         private static final Object callbackTag = new String(„callback with parameters"),

        // callback with return value
        public int callbackAndReturn(int i)
        throws Throwable
        {
                Object returnValue = new DolphinRequest(callbackTag, this, i).value();
                return ((Integer) returnValue).intValue();
        }

A DolphinRequest is created with the tag which identifies the callback in Smalltalk, the object sending the callback (this), and an arbitrary number of parameters. For example, the following creates a DolphinRequest with two parameters:

                DolphinRequest dr = new DolphinRequest(
                                        s_callbackTag,
                                        this,
                                        new Integer(i),
                                        new Double(d));

Calling the value() method of the DolphinRequest sends the request to VisualWorks and returns the result of the Smalltalk callback block.

In Smalltalk, you can create callbacks accepting parameters like this (see JNIPortCallbackRequestsTest):

        "No parameters"
        jvm callbackRegistry setCallback: classStatic callbackTag
                        handler: [:this :param | self handleCallbackFor: this].

        "One parameter"
        jvm callbackRegistry setCallback: classStatic callbackTag
                        handler: [:this :param | self handleCallbackFor: this with: param].

        "Arbitrary number of parameters"
        jvm callbackRegistry setCallback: classStatic callbackTag
                        handler: [:this :params | self handleCallbackFor: this withArguments: params asArray].

If the callback has a result which should be passed from Smalltalk to Java, it must be a Java object. Here is an example from the test class (callbacksStatus is just an instance variable of JNIPortCallbackRequestsTest):

handleCallbackFor: aJavaObject with: anotherJavaObject

        | jliClass |

        jliClass := jvm findClass: #'java.lang.Integer'.

        callbacksStatus addLast: (aJavaObject = instance).      "identity test on the Java object"
        callbacksStatus addLast: ((anotherJavaObject static = jliClass) and: [anotherJavaObject intValue = 1]).

        ^ jliClass new_int: 15. "Do not return a Smalltalk Integer. It must be a Java Integer“

Johan Brichau’s JavaConnect had a more direct way of creating callbacks, using Java’s dynamic proxies. However, it had an open issue, as it relied on different Java objects having different identity hashes, which is not true in all cases. JNIPort’s implementation is relatively complicated because it had to take into account that the callbacks can be triggered from a different thread than the Smalltalk thread. In VisualWorks, that’s not a problem, as the VM handles this, and Pharo simply does not support callbacks from foreign threads. So, it could be simplified in JNIPort as well.

Does this help?
Joachim