I'm trying to run a HelloWord Java application that accesses the Notes client on a Mac. I had that working on older versions. Currently I have Java 1.8.0_101-b13 an OS/X 10.11.6. I try to run this code:
import lotus.domino.NotesException;
import lotus.domino.NotesFactory;
import lotus.domino.NotesThread;
import lotus.domino.Session;
public class HelloWorld {
public static void main(String[] args) throws NotesException {
HelloWorld hw = new HelloWorld();
hw.sayHello();
}
private void sayHello() throws NotesException {
System.out.println("java.library.path: "+ System.getProperty("java.library.path"));
System.out.println("PATH: "+ System.getenv("PATH"));
NotesThread.sinitThread();
Session s = NotesFactory.createSession();
System.out.println(s.getEffectiveUserName());
NotesThread.stermThread();
}
}
I've set LD_LIBRARY_PATH=/Applications/IBM Notes.app in an Eclipse run configuration. When I run the app I get:
java.library.path: /Applications/IBM Notes.app:/Users/joe/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:. PATH: /Applications/IBM Notes.app:/usr/bin:/bin:/usr/sbin:/sbin Exception in thread "main" java.lang.UnsatisfiedLinkError: no lsxbe in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at lotus.domino.NotesThread.load(Unknown Source) at lotus.domino.NotesThread.checkLoaded(Unknown Source) at lotus.domino.NotesThread.sinitThread(Unknown Source) at com.notessensei.HelloWorld.sayHello(HelloWorld.java:31) at com.notessensei.HelloWorld.main(HelloWorld.java:20)
The library path looks OK. I must be missing something obvious?
Update: When you look at the output, Java picks up the LD_LIBRARY_PATH variable, so DYLD_LIBRARY_PATH seems not to be needed (I added it to test to no avail). DYLD... seems to be problematic on OS/X.
One thought which isn't clear: In the OS/X world you usually point to the App (IBM Notes.app), but the content is actually in appname.app/Contents/MacOS. I think I tried both with the same result. Does the space in the path throw up?
Update 2: As requested the output of otool -L liblsxbe.dylib
liblsxbe.dylib: @executable_path/liblsxbe.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libxmlproc.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libnotes.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
otool -L libxmlproc.dylib
libxmlproc.dylib: @executable_path/libxmlproc.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libnotes.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
`otool -L libnotes.dylib'
libnotes.dylib: @executable_path/libnotes.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0) @executable_path/libjsmac.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libndgts.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libxmlproc.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libgsk8iccs.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55471.14.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.14.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.19.0) /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 673.2.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 59.0.0)
What else?
After much probing it turned out to be 2 issues to be solved. The first one, is described in a post by Mikkel Flint Heisterberg. Besides DYLD_LIBRARY_PATH another environment variable needs to be set: NOTESBIN. Both point at the same location:
DYLD_LIBRARY_PATH=/Applications/IBM Notes.app/Contents/MacOS
NOTESBIN=/Applications/IBM Notes.app/Contents/MacOS
No quotes or backslashes are needed in the Eclipse run configuration.
The second one was trickier. Out of convenience, since it worked prior, I had created a new entry "installed JVM's" called 'Notes9'. There I pointed to the Oracle JVM8 (yep, on Mac Notes is running Java8) and the Notes.jar (and the others) in jvm/lib/ext of the Notes program directory.
Mac doesn't like that (anymore). Once I pointed to a "naked" JVM8 and added Notes.jar as external Jar dependency, everything started working as expected.