If you’ve been developing in Domino for more than, I dunno, 15 minutes, you’ve probably taken a look at the lotus.domino Java API. And when you did, there’s probably two things that happened: 1) you already knew Java and you thought “This thing makes no sense. Everything throws the same Exception? I have to manage memory myself? The collection classes don’t actually implement Collection? Am I on crazy pills?”; or 2) you didn’t know Java and you thought “Ack! This Java stuff is complicated! I don’t want anything to do with it. Give me my Lotusscript agents and let me live in peace.”
(There’s a slight chance you’re in the set of people that already knew Java and the Lotus API and you understood the leaky abstraction. If you are, I just want to say that all of this is your fault for not holding the Domino team’s feet to the fire. You accepted this nonsense in the first place; you should have known better.)
People have tried before to build a better Java API for Domino. I worked for a number of years at GBS, where on several occassions we wrote Java code to emulate or replace the IBM implementation. Even before that, there was a SourceForge project called Domingo that was intended to supplant the IBM implementation. While these projects were successful to varying degrees, they ultimately failed because of usability limitations of their APIs and the ability to completely replace the lotus.domino API itself.
What this all about? Well, a few things…
- a drop-in extension to notes.jar that’s usable in all Java contexts.
- a complete elimination of the NotesException architecture that instead defers to a java.util.Logging model for Exceptions.
- the elimination of manual .recycle calls. This is NOT done through proxies, but instead through reference tracking.
- proper implementation of Java Iterables so you can stop accidentally writing infinite loops.
- use of generics, so you can stop manually class-casting.
- sensible use of C++ handles, so they arren’t maintained when they aren’t needed. This is most important in dealing with DateTime, Name, DateRange and International objects. These are all encapsulated at the Java layer and their C++ handles are immediately released.
- a more sensible Interface/Class hierarchy that understands the parenting hierarchy of Domino objects as well as the common usage.
- a set of Helper classes to simplify common use patterns like Document synchronization and token extraction
And this is all just for the M1 release, which should be available in a few weeks. The team is still ironing out some details like object-sharing across threads, timezones and proper logging implementations. But already some people in the community are running tests that create or process tens of millions of Documents without any memory leaks and with astounding performance results.
When we are successful, we believe this will usher in a new era of productivity for Domino developers. It is our most earnest hope that with the support of OpenNTF.org and the Domino community, this kit will finally be the way forward for developers who haven’t yet made the emotional commitment to the Java language.
As a long-standing Lotusscript guru, I assure you that you will be glad you made the transition.
See you there!