Smalltalk › Cincom › VisualWorks

DLL C connect -Java Connect

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Annick

DLL C connect -Java Connect

Hi,

I am trying to use DLL C under Linux, but the parser is stuck when I
regenerate the DLL with the following feature.h file.
What is wrong with the syntax ?

Also has anyone managed to use JNIPort or JavaConnect on Linux ?

Annick Fron
http://www.afceurope.com

features.h (12K) Download Attachment

Joachim Geidel

Re: DLL C connect -Java Connect

Hi Annick,

yes, I have used JNIPort on Linux (Ubuntu). In its current state, it's not obvious what you have to do, as there is no documentation for JNIPort except what Chris Uppal has written for the original Dolphin Smalltalk version - which doesn't cover Linux, of course. If you use the latest branch version in the public repository published by Johan Brichau, you can even use it on MacOS-X now.

Basically, you have to configure JNIPort manually. In the JNIPort settings tool, add a new configuration, then fill in the field for the JVM library. Use absolute path names. If you want to run the tests, you will have to add the jar file mentioned in the comment of the "JNIPort Tests" to the class path, which you can configure in the JNIPort settings tool, too. The same applies to the JNIPort jar file which is needed for using callbacks from Java to Smalltalk. Absolute path names may be better in this case,! too. A strange thing is that on Linux, the entries in the class path option of the Java VM have to be separated by colons instead of semicolons (or was it the other way round?).

If the configuration is such that the JVM library and the JAR files are found, JNIPort should work for all Java versions from 1.4 to 1.6. The current implementation is based on VisualWorks 7.5. I have not yet tried to run it on a current development build.

Did you encounter any specific problems (exceptions? error messages?), or is the problem that JNIPort needs more documentation to be usable (a problem which I am aware of)?

Best regards,
Joachim Geidel

Annick Fron schrieb:

Hi, 
 
I am trying to use DLL C under Linux, but the parser is stuck when I   
regenerate the DLL with the following feature.h file. 
What is wrong with the syntax ? 
 
Also has anyone managed to use JNIPort or JavaConne!
 ct on Linux ? 
 
Annick Fron 
<a href="http://www.afceu
rope.com">http://www.afceurope.com

Joachim Geidel

Re: DLL C connect -Java Connect

In reply to this post by Annick

Hi Annick,

I had only one problem with JavaConnect and JNIPort loaded simultaneously in one image. It was a method in JavaConnect which either encodes or decodes the Java modified UTF-8 strings used by JNI. If I remember correctly, if you load JNIPort first and JavaConnect second, the method from JavaConnect overrides a method of JNIPort. After restoring the overriden method, JNIPort worked again.

Modifying the methods #javaHomeForVersion: and #jvmDLLName is not necessary. They are only needed when JNIPort has no information about the location of the Java VM and tries to detect it automatically. This works on Windows only, where it can look in the registry. On all other platforms, the libraryFileName must be specified explicitly. This can be done in the JNIPort settings tool, but also programmatically. There is no documentation on how to do this at the moment - I hope to be able to do something about it in my Christmas holidays (sigh...). This automatic! detection of the JVM is in the wrong place and quite confusing.

In the latest versions of JNIPort, the JNIPortStandardLibInterfaceTest works on Ubuntu. It seems that on Ubuntu (Debian), the standard C library has a different file name than on RedHat. In your separate mail about how you managed to run the test, I see that you added libc.sl to the JNIPort.StandardLibInterface library files. I'll add this in the next version - thanks!

The messages about class file generation in some tests are "normal". Actually, these tests should be removed. They test something which is not part of Chris Uppal's publicly available packages. Apparently, he has some code which can generate Java class files on the fly.

#resetJavaNamespace either comes from JavaConnect or from the experimental branch of JNIPort which includes JavaConnect's support for Namespaces. I don't know what the problem is, as I h! ave not tried the JavaConnect branch of JNIPort yet. The "clean&q uot; version of JNIPort shouldn't have this problem.

Concerning the prerequisite packages: You will need versions from the public repository which are newer than the parcels which come with VisualWorks 7.5. The minimal version numbers are mentioned in the bundle comments of JNIPort Prerequisites and JNIPort. The Weaklings parcel in particular won't work. It is based on Weaklings 10, and you need at least version 12 (but you should really load the latest one).

Ah, the problem of restarting the JVM... Once the JVM is shut down, there is no way to restart it in the same operating system process. That's not a bug of JNIPort, it's a feature of the JVM. Don't ask me why Sun didn't manage to make it restartable. It's even better than that: According to the JNI specification (and probably the JVM spec as well) it should be possible to start multiple JVMs in parallel in the same process. Of course, this doesn't work. But the JNI i! nvocation interface gives you all the functions needed to try it and run into error messages... There is also a function which answers a list of all running JVMs. That list is pretty short. ;-)

Anyway, once the JVM is dead, you have to restart the image to be able to start another one. I have not yet tried to switch to a second installation, e.g. another Java version or an implementation by another vendor, and see if I can start an IBM JVM after shutting down a Sun JVM. I also don't know if other implementations have the same limitations as the Sun JRE.

Thanks for the feedback!
Joachim

Annick Fron schrieb:

Hi Joachim,

I have tried both JavaConnect and JNIPort, maybe the mix is not quite good ?

Here is a summary of my problems.

With your new method, I managed to launc h a JVM.

I had previously modified the following methods :

javaHomeForVersion: aVersionString
"answer the JavaHome (installation root) of the given version of the
JDK"

"^((self registryEntryForVersion: aVersionString)
valueNamed: self registryJavaHomeName) value"

^'/usr/java/jdk1.5.0_03'

jvmDLLName
"private -- answer the relative name of the JVM.DLL'"

"^ 'jvm.dll'."
^'libjvm.so'

Then I have tried to run the tests :

Summary of tests

JNI Tests : OK
Java base tests : OK
in JNIport prer equisites test : JNIPortStandardLibInterface test does
not work

I get the following messages :

JNIPort.Tests.JNIPortBasicHiddenFieldsTest>>testAmbiguousIntFieldViaJVM
not run (classfile generation is not installed?)
JNIPort.Tests.JNIPortGeneratedHiddenFieldsTest>>testOverloadedByTypeField not run (classfile generation is not installed?)
JNIPort.Tests.JNIPortGeneratedHiddenMethodsTest>>testOverloadedByTypeMethod not run (classfile generation is not installed?)

When I start the image again, I always get an error on :
resetJavaNamespace

When I start using "generate ghosts classes" I get the error :
Weaklings.WeakSetElementHolder has no binding

Which version of Weaklings is needed ? Should I load it from Cincom
repo ? I have tried it.

Once I have launched and stopped a VM, no way to launch a new one, I get
a JNI -1 error. I need to restart the image to launch the VM again.