I just upgraded my Thinkpad from Windows Vista 32 bit to Windows 7 64 bit and besides being amazed at the speed improvements (thanks to moving of Windows Vista) I needed to think about how I develop Java for Notes in general. When moving to 64 bits there are some things you need to consider if, and only if, you install the 64 bit version of the Java Development Kit (JDK) as I did. You need to consider stuff for two reasons which I’ll address in turn.
Please note: This blog post will focus on 64 bits Windows 7 as that’s what I’m running now but I suspect it will apply to other Notes platforms such as Windows Vista, Linux and Mac as well. I’m not using Lotus Expeditor Toolkit so I can’t confirm the following is but a wise man told me that XPD Toolkit doesn’t support 64 bit JDK’s so in that case you need this as well as my “Configure Eclipse 3.4 for Notes 8.5.1”-guide as well.
Notes is a 32 bit application
Say you install a 64 bit JDK and try to run an application that access Notes using local address (NRPC; a client or server installed on the same machine) such as the following:
import lotus.domino.Session;
import lotus.domino.Database;
import lotus.domino.DocumentCollection;
import lotus.domino.NotesFactory;
import lotus.domino.NotesThread;
public class Main {
public static void main(String[] args) {
NotesThread.sinitThread();
Session s = NotesFactory.createSession();
System.out.println("Name: " + s.getUserName());
Database db = s.getDatabase("server1/Example", "names.nsf");
DocumentCollection dc = db.getAllDocuments();
System.out.println("Docs: " + dc.getCount());
} catch (Throwable t) {
t.printStackTrace();
} finally {
NotesThread.stermThread();
}
}
}
The code will compile fine but when you run it you’ll see a message like the following (plus a stacktrace):
java.lang.UnsatisfiedLinkError: C:Notes8nlsxbe.dll:
Can't load IA 32-bit .dll on a AMD 64-bit platform
The problem is, as the message explains, that you cannot load a 32 bit DLL (remember Notes is a 32 bit application) into a 64 bit Java Virtual Machine (JVM). The solution is to install a 32 bit JDK instead and run the application using this JDK. Remember that it is perfectly valid and possible to install multiple JDK’s on a single machine and it fact that’s what I’m doing.
Developing plugins for Notes 8+
Developing plugins for Notes 8+ on 64 bit Windows is also somewhat different from doing it on a 32 bit Windows system. Of course you need Eclipse but here’s the first difference – you need to use a 64 bit version of Eclipse if you’re using a 64 bit JDK. The reason is that Eclipse uses SWT (Standard Widget Toolkit) for the user interface widgets. The reason SWT looks so nice on any supported platform is because it wraps the native, C-code, platform widgets. So remember that and grab a 64 bit Eclipse. Once that’s installed and working with your 64 bit JDK configure Eclipse as you normally would but with a small difference that will cause your code not to compile (my Eclipse complained about not be able to resolve org.eclipse.swt.widgets.Shell).
As you may know, you specify the bundles you depend on when developing your plugin and in turn you also specify which environment you run in. This is how Eclipse knows which versions to the bundles to put on the class path but since you’re running 64 bit Windows and Notes is 32 bits it will be a problem. The fix is however very easy to implement and only means tweaking the target platform setup to explicitly set the architecture you’re running on to “x86” and not “x86_64” which is the default if you’re on a 64 bit JVM. Where to set this differs a little between Eclipse 3.4 and Eclipse 3.5 but the concept is the same.
- Open the target platform setup
- Edit the “Environment” settings
- Set the architecture to “x86”
Once this is done the workspace will be rebuilt and everything should work just fine. Mine did anyway… 🙂
Back to our standalone Java application
If you need to run a Java application that accesses Notes locally from within an Eclipse instance (lets face it – who writes Java code without an IDE these days?) you also need to use a 32 bit JVM although you very well may be running 64 bit Eclipse in a 64 bit JVM. The JVM used to execute an application from within Eclipse is the JVM you setup in the build path. To set it simply right-click the project, choose Build Path -< Configure Build Path… and replace/edit the JVM library used.
Conclusion
I hope the above is clear – if not let me know using the comment system. I’ll soon be blogging about using Eclipse 3.5 for your Eclipse development instead of the current version 3.4. Stay tuned.
