troubles with JNIPort on Pharo 5 / Java 8
Locked
troubles with JNIPort on Pharo 5 / Java 8
 
|
Hi,
I am having trouble running JNIPort with Pharo 5 and Java 8 on Mac OS X 10.10.4. The code loads fine: Gofer new smalltalkhubUser: 'JNIPort' project: 'JNIPort'; configuration; loadVersion: '3.0-alpha'. However, I do not know where to point "JNIPortJNIInterface libraryFile:" to. In the original instructions for Java 1.6, the code looked like: JNIPortJNIInterface libraryFile: '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib' With JDK 1.8 (and even 1.7), the file organization seems to be different and the libclient.dylib does not exist. I tried to point it to libjli.dylib, which looks similar, but that does not seem to work: JNIPortJNIInterface libraryFile: '/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/MacOS/libjli.dylib'. Can anyone point me in the right direction? |
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Hi Doru, JLI is the Java Legacy Interface, not the VM. AFAICT, the JVM library should be at /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/server/libjvm.dylib Java 8 for OS X is a 64 bit version, it won't work with a 32 bit Pharo. When I released the latest version of JNIPort, there was no 64 bit NativeBoost, and as as JNIPort for Pharo is based on NativeBoost, I guess that it won't work with Java 8. However, if you have Apple's original Java 6 installed, you can still use that. An alternative JVM might be JamVM, but I can't check right now if there is a 32 bit version as SourceForge is currently offline. HTH Joachim |
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Hi Joachim, Thanks for the answer. I did not have Java 1.6 anymore on my Yosemite, but I installed it now. For reference, here is how to get it: I still have problems in Pharo5. I am trying the following script: I tried in Pharo 3, and the script worked fine. I also tried with Pharo4 and Pharo5, but it does not work because I get a MNU for GhostClassBuilder>>#client:. I fixed it in a Pharo5 image by using #installer: instead, but the computation of "JVM newWithSettings: jvmSettings" does not seem to finish and it blocks the VM. Any idea of what goes wrong? Cheers, Tudor On Fri, Jul 17, 2015 at 11:56 AM, Joachim Geidel <[hidden email]> wrote: Tudor Girba-2 wrote |
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Hi Tudor,
unfortunately I haven’t had much time to work on JNIPort for a while. I have started to simplify some of the code, but this isn’t finished yet, and I have not yet looked into Pharo 4 and 5. The latest Pharo version I have worked with was 3, because I was waiting for the VM and NativeBoost changes which were announced but not finished the last time I looked (which is a long time ago). So currently, I can’t tell what is wrong. Obviously, something has changed in the class building mechanism since Pharo 3. The other problem might be related to NativeBoost or the VM, but of course I am speculating for now. Cheers, Joachim
|
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Hi Joachim, Thanks for the answer. Unfortunately, I am stuck at the moment too, and I have no idea how to proceed. I would really benefit from your, or someone else's, help :). Cheers, Doru On Tue, Jul 28, 2015 at 9:57 PM, Joachim Geidel <[hidden email]> wrote: Hi Tudor, |
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Hi again, I continued with experimentation in Pharo 3. Specifically, I would like to get a callback working, but something does not work out. Could you take a look below? Perhaps you can spot what I am doing wrong. Here is what I did: 1. I downloaded: 2. I created the following Java class: package com.tudorgirba.jniport.callback; import jniport.RequestNotHandedException; import jniport.SmalltalkNotification; public class SimpleNotifier { private static final Object notifyTag = new String("sendNotification()"); public static Object notifyTag () { return notifyTag; } public void sendNotification() throws RequestNotHandedException { new SmalltalkNotification(notifyTag, this).send(); } } 3. Then I ran this code in a Pharo 3.0 image: "---" Gofer new smalltalkhubUser: 'JNIPort' project: 'JNIPort'; configuration; loadVersion: '3.0-baseline'. JNIPortJNIInterface libraryFile: '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib'. jvmSettings := JVMSettings new. jvmSettings usesGhosts: true. jvmSettings supportsCallbacks: true. jvmSettings jniPortSettings useJNIHelperLibrary: false. jvmSettings ghostClassSettings retainMethodSource: true. jvmSettings runtimeSettings classpath: '.:/Users/girba/Work/Code/moose/JNIPort30.jar:/Users/girba/Work/Code/moose/JNIPort30-Tests.jar:/Users/girba/Work/Code/moose/jniport/jniport-callbacks/bin/'. Cursor execute showWhile: [JVM newWithSettings: jvmSettings]. notifierClass := JVM current findClass: #'com.tudorgirba.jniport.callback.SimpleNotifier'. JVM current callbackRegistry setCallback: notifierClass notifyTag handler: [:this :param | self halt]. notifier := notifierClass new. notifier sendNotification. "---" Everything executes without error, but the self halt part is not reached. I would expect that when the #sendNotification is executed, the corresponding handler gets executed and the debugger appears. (I thought that perhaps something is wrong with the classpath, but the notifierClass and the notifier objects look just fine) Any idea of what is wrong? Cheers, Doru On Wed, Jul 29, 2015 at 10:47 AM, Tudor Girba <[hidden email]> wrote:
|
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Hi again, In the meantime I found the problem: if I replace self halt with a concrete execution, it works :). I also tested the passing of arguments back and forth between Pharo3 and Java 1.6 and that works fine, as well. Now, the only thing left is to get this running on Pharo5. Cheers, Doru On Thu, Jul 30, 2015 at 10:44 PM, Tudor Girba <[hidden email]> wrote:
|
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
In reply to this post by Tudor Girba-2
Hi Tudor,
some progress in Pharo 5: > Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>: > > I also tried with Pharo4 and Pharo5, but it does not work because I get a MNU for GhostClassBuilder>>#client:. > > I fixed it in a Pharo5 image by using #installer: instead, but the computation of "JVM newWithSettings: jvmSettings" does not seem to finish and it blocks the VM. Changing the call of #client: to #installer: in GhostClassInstaller>>#initialize: was correct. > Any idea of what goes wrong? Someone declared String>>subStrings: as deprecated in Pharo 4 or 5. When I ran „JVM newWithSettings: jvmSettings“, a notifier opened which warned about the deprecated method. I changed the method which used it in the debugger, then proceeded. The image blocked until I hit <cmd-.>. A debugger opened, it was in the middle of writing to the Pharo error log file. I proceeded, the image blocked again, I hit <cmd-.> again. A debugger opened which contained a very large stack of contexts with the method handleSignal: calling itself endlessly. There seems to be something wrong with handling/logging deprecation warnings in Pharo 5. Why do they have to be written to the error log in the first place? I don’t think that they belong there. There are four methods sending subStrings: in the package JNIPort-Java-Base. I changed them to use substrings: instead. There are two methods in JNIPort-StringEncoding which send "Smalltalk isLittleEndian“, String>>#asJavaLangStringEncodedByteArray and String>>#fromJavaLangStringEncodedByteArray:. This does not work anymore. I replaced this with "EndianDetector isLittleEndian“. After these changes, starting a JVM and executing the example script which you posted just worked fine. Unfortunately, loading the test package JNIPort-Tests-Java-Base fails with an exception: UTF8InvalidText(Object)>>subclassResponsibility UTF8InvalidText(Exception)>>defaultAction UndefinedObject>>handleSignal: Context>>handleSignal: AFAIK, there was no problem when loading the package in Pharo 3. There seem to be two problems: The UTF8TextConverter seems to think that there is an invalid character in the source code file, and UTF8InvalidText has no #defaultAction method. Looks like a bug in Pharo 5 to me. HTH Joachim |
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Hi Joachim, This is great news! Thanks a lot for looking into this. Could you commit your changes? Or could you grant me access to the JNIPort project? Cheers, Doru On Sun, Aug 9, 2015 at 12:25 PM, Joachim Geidel <[hidden email]> wrote: Hi Tudor, |
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Hi, I tested your changes, and I confirm that the code works fine in Pharo 5. Now, we just need to get them published :). Cheers, Doru On Sun, Aug 9, 2015 at 12:50 PM, Tudor Girba <[hidden email]> wrote:
|
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Hi Tudor,
I tend to avoid words like „just“, „simply“ etc. when talking about software. ;-) The ConfigurationOfJNIPort should be updated in a way which lets one load the current package versions when using Pharo 3, and new ones when using Pharo 4 or 5. I haven’t used this stuff for a while, and will have to read the documentation again before being able to publish something useable. Cheers, Joachim |
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Hi, Great. However, I notice that you have some distinct version names, and this seems to throw MC off. For example, when trying to load the latest version of ConfigurationOfJNIPort: - we get: ConfigurationOfJNIPort-JoachimGeidel.3.0a3 - instead of: ConfigurationOfJNIPort-JoachimGeidel.3.0a4 This problem would be fixed if we would change the numbering a bit. For example, when I try to commit a new version of the configuration, Monticello offers: ConfigurationOfJNIPort-TudorGirba.3.5 Is it Ok if I commit it like this? Cheers, Doru On Sun, Aug 9, 2015 at 1:44 PM, Joachim Geidel <[hidden email]> wrote: Hi Tudor, |
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
> Am 09.08.2015 um 14:36 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>: > However, I notice that you have some distinct version names, and this seems to throw MC off. For example, when trying to load the latest version of ConfigurationOfJNIPort: > - we get: ConfigurationOfJNIPort-JoachimGeidel.3.0a3 > - instead of: ConfigurationOfJNIPort-JoachimGeidel.3.0a4 > > This problem would be fixed if we would change the numbering a bit. For example, when I try to commit a new version of the configuration, Monticello offers: > ConfigurationOfJNIPort-TudorGirba.3.5 > > Is it Ok if I commit it like this? Yes, of course, do whatever it takes. I used the „aN“ suffer because I considered that version as an alpha release, and wanted to do a lot more before publishing a „real“ release. Cheers, Joachim |
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Ok. I added now: - 3.1-alpha with packages for pharo 5 - development and stable symbolic versions for pharo 3 and pharo 5. The tests problem should still be solved. Do you still want to look at that? Once that is done, the tests packages should be added to the version. I can do that. Cheers, Doru On Sun, Aug 9, 2015 at 2:51 PM, Joachim Geidel <[hidden email]> wrote:
|
Re: troubles with JNIPort on Pharo 5 / Java 8
|
|
Thanks a lot!
I will look into the problem with the test package as soon as possible. Joachim Am 9. August 2015 17:29:42 MESZ, schrieb "Tudor Girba-2 [via Smalltalk]" <[hidden email]>:
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |