We Have The Technology: The org.openntf.domino API

Mar 21, 2013 9:16 PM

As Nathan and Tim posted earlier today, a number of us have been working recently on a pretty exciting new project: the org.openntf.domino API. This is a drop-in replacement/extension for the existing lotus.domino Java API that improves its stability and feature set in numerous ways. The way I see it, there are a couple main areas of improvement:

Plain Old Bug Fixes

doc.hasItem(null) crashes a Domino server. That's no good! We've fixed that, and we're going through and fixing other (usually less severe) bugs in the existing API.

Modern Java

Java has progressed a long way since Domino 4.x, but the Java API hasn't much. Our API is chock full of Iterators, proper documentation, generic type definitions, preference for interfaces over concrete classes, and other trappings of a clean, modern API. Additionally, Nathan put together some voodoo programming to take care of the recycle thing. You read that right: recycle = handled.

New Features

In addition to cleaning up the existing functionality, we're adding features that will be useful every day. My favorite of those (since I'm implementing it myself) is baked-in MIMEBean-and-more support in get/replaceItemValue:

Set<String> stringSet = new HashSet<String>();
stringSet.add("foo");
stringSet.add("bar");
doc.replaceItemValue("Set", stringSet);

doc.replaceItemValue("Docs", database.getAllDocuments());

NoteCollection notes = database.createNoteCollection(true);
notes.buildCollection();
doc.replaceItemValue("Notes", notes);

doc.replaceItemValue("ExternalizableObject", new MimeType("text", "plain"));

List<String> notAVector = new ArrayList<String>();
notAVector.add("hey");
doc.replaceItemValue("TextList", notAVector);

doc.replaceItemValue("LongArray", new long[] { 1L, 2L, Integer.MAX_VALUE + 1L });

That's all legal now! We have more on the docket for either the initial release or future versions, too: TinkerPop Blueprints support, easy conversion of applicable entities to XML and JSON, fetching remote documents from DXL or JSON files, proper Logging support, and more.

 

As we've been developing the new API, we've already found it painful to go back to the old one - it doesn't take long to get spoiled. And fortunately, the transition process will be smooth: you can start by just replacing one entry point for your code (say, changing "JavaAgent" to "org.openntf.domino.JavaAgent" in an agent), then advance to swapping out your "import lotus.domino.*" line for "import org.openntf.domino.*" line, and then start using the new methods. All the while, your existing code will continue to work as well or better than before.

We hope to have a solid release available around the beginning of next month, and in the mean time I highly encourage you to check out the code. Download it, give it a shot, let us know how it works for you and if you have anything you'd like us to add.

Commenter Photo

Sven Hasselbach - Mar 22, 2013 7:22 AM

Looks very cool! But it is Notes 9 only, or am I wrong (Because of the referenced NotesCalendar classes)?

Commenter Photo

Jesse Gallagher - Mar 22, 2013 8:50 AM

That's our plan at the moment, but our policy is "we could be convinced". It's not so much the new classes as it is a handful of new-in-9 things used elsewhere, I think.

Commenter Photo

Sven Hasselbach - Mar 22, 2013 9:09 AM

I just wondered why it is not possible to use the classes directly in an 8.5.3er agent and the compilation errors in Eclipse. But after switching to the correct 9er Notes.jar everthing worked fine.

Commenter Photo

Jeff Byrd - Mar 22, 2013 5:22 PM

Please create an 8.5.3 version  We just came up on 8.5.3 and 9.0 is in the distant future.

-- Jeff

Commenter Photo

Pierre - Mar 30, 2013 12:51 AM

very impressive, can't wait.

New Comment