Home

The goal of this project is to modernize the way that we write Java code for Domino applications. Some of the results of this are as follows:

• The primary advantage of this API is that it removes the need to recycle Domino objects. Objects in the lotus.domino API have a relationship to a C++ object. If the Java object is destroyed (or reallocated to a different Domino object) without this relationship being cleaned up, the C++ object is orphaned. Since Domino has a fixed limit of how many of these C++ objects can exist at a time, it's always been crucial for Domino developers to explicitly clean these up by calling .recycle() on every Domino object. It's a pain, but it's been unavoidable... until now. The org.openntf.domino API completely removes the need for recycling. We monitor each object to ensure that, if it's about to be garbage collected, recycling happens automatically. So you can focus on what you want to do with these objects, not what happens when you don't need them anymore.
• The lotus.domino API has a notion of collections, but does not use the Java Collections API. As a result, looping through documents and view entries, for instance, is not nearly as straightforward as what most Java developers are accustomed to. Part of the problem is that we've always needed to recycle, so we couldn't just reuse the same variable over and over again... we had to create a "temp" variable to assign the next object to, recycle the current object, then set the current object to the temp object. Yuck. But the API itself doesn't feel like Java because it was originally written to feel like LotusScript, so Java code in Domino typically ends up inheriting LotusScript patterns, making it unnecessarily verbose. The org.openntf.domino API treats Domino collections like true Java Collections. So there's no need for any of the old getFirst / getNext nonsense (not to mention getNth...); instead, we can just do what other Java developers do:

for (Document eachDocument : Database.getAllDocuments()) { /* do something with each document */ }

• We've always had to exercise some caution in how much data we store in each type of item in a Domino document. This isn't specific to Java, of course: despite how much the rest of the platform has evolved since its late 80's inception, a couple remaining quirks hearken back to the days when both RAM and disk space were precious. So we need to understand the difference between "summary" and "non-summary" data, and how much we can store in each, and design our data structure such that these limits are unlikely to be exceeded. Wouldn't it be great if you could just not care? The org.openntf.domino API combines NSF's capacity to store any content (regardless of size) as MIME entities with Java's capacity for serialization, allowing you to focus on your application's business logic, not the size of the data involved. If your item sizes are small, they're just stored the same way they would be anyway... but if it gets too big for its current container, the API adapts the storage for you. A handy benefit of this approach is that we can now store not only individual values or lists of values in a document, but also entire object structures. Instead of treating each document like a flat map of properties and values, values can have their own properties, which have values that have properties, and so on. Imagine being able to treat an item value as the conceptual equivalent of an entire JSON or XML document, without the hassle of actually generating or parsing JSON or XML. If you've ever maintained complex hierarchies of parent and response documents (and practically every Notes developer has), perhaps you can anticipate some of the implications of this capability.

This labor of love is still a work in progress, but a surprising amount of it is already complete. You can browse the Javadoc to get a feel for what's already included.