In this blog post, I’m going to explain two of the concepts I covered when describing my work on XPages OpenLog Logger – interfaces and enums.

Firstly, I will state categorically that diving into Java not a step I recommend to those starting out on XPages development from a Notes Client development background. There is a steep enough learning curve. Working out how you should climb over the hurdles is challenging enough at times, without trying to work out if the problem is actually in one of the heavy bags you’ve chosen to carry! But I would strongly recommend learning Java to someone who’s got comfortable with the basics of XPages enough to be able to diagnose when problems are because of SSJS code or elsewhere in XPages. Once you can develop youor back-end logic in Java, it gives you greater power and fewer limitations. (The work on the OpenNTF Domino API has proved that.)

As a preliminary to this blog post, if you’re not familiar with Java, I would very strongly recommend Declan Lynch’s blog series on Java “Getting to the Java Roots of XPages” as well as the NotesIn9 videos about Java. They both explain how to move from SSJS to using Java beans. I don’t intend to duplicate their code, this about moving on from beans, to some more generic Java concepts, both of which I learned from my work on the OpenNTF Domino API.

The first is interfaces. If you’ve used beans, you’re familiar with Java classes – your bean is just a Java class that has a constructor that doesn’t take any parameters, so something like:

public class myBean extends Serializable {
public myBean() {
}

You’re already familiar with the concept of classes extending other classes, in this case myBean extending the class Serializable. And in the case of the work I did on bringing XPages OpenLog Logger into OpenNTF Domino API, DominoOpenLogItem and XspOpenLogItem both extend BaseOpenLogItem.

Interfaces don’t have any code in them per se, but just define what methods any class based on the interface must implement. In the case of BaseOpenLogItem, the interface is IOpenLogItem. A snippet from the class shows the differences:

public interface IOpenLogItem {
public String getAccessLevel();
public int getErrLine(final Throwable ee);

The declaration of the interface uses public interface instead of public class. And the methods don’t have any code within them. It just defines “these are the methods that any class based on this must use”. The other difference is how the class is used. BaseOpenLogItem doesn’t extend the interface, it implements it. Implementing an interface also pre-populates which methods need to be populated with code and you cannot save the class without those methods. It helps prevents any future developer from missing out key code if they create a class based on the template you define in the interface.

The second is enums, which you’ll also see referenced in IOpenLogItem. If you’re using interfaces, they’re a good place to put the enum, because they’re then available once everywhere the class that implements the interface is required. You’ve been used to the concept in Notes for years. It’s the same concept of the Dialog List field type. Don’t let the user just type whatever they want, give them a list of options and force them to select from the list. enums are the Java implementation of that concept for parameters for your methods. In the case of IOpenLogItem, there are two enums – debugLevel and logType.

The LogType enum means you can no longer pass a string to setEventType. In XPages OpenLog Logger, there was a method setEventType(String). It expected either “Event” or “Error”, but there was nothing preventing a future developer calling setEventType(“Eventt”) or setEventType(“Eror”) or setEventType(“Load of Rubbish”). IOpenLogItem and its implementations don’t have a setEventType(String) method. Instead they have a setEventType(LogType) method. You can call setEventType(LogType.TYPE_EVENT) or setEventType(LogType.TYPE_ERROR). setEventType(LogType.TYPE_EVENTT) will not compile. DebugLevel has the same kind of constraints. So it avoids typos when calling methods and avoids any future developer passing something that was not intended. You could use static variables, but then you can’t use the static variable easily in another class or package. enums get over that.

The declaration is similar to a class, but as a static class, so it’s values are defined at the time it’s written:

public static enum LogType {
TYPE_ERROR("Error"), TYPE_EVENT("Event");
private final String value_;
private LogType(final String value) {
value_ = value;
}
public String getValue() {
return value_;
}
}

The enum is static, so you don’t need to create an instance of it, you can just call LogType.TYPE_ERROR or LogType.TYPE_EVENT. Indeed, not only do you not need to create it, you can’t create it, because the constructor is private – private LogType(final String value). That also creates all the options at the time the enum is compiled. TYPE_ERROR is the label, “Error” is the value. To get that value, there is the public method getValue(). The value doesn’t have to be a String, indeed the DebugLevel enum has a value that’s an int. And an enum doesn’t have to have just one property. You could create an enum that has multiple properties, each defined against the label and created via a constructor that takes the relevant number of parameters.

Hopefully you can see the benefit of interfaces (particularly if you’re creating classes to be used by other developers) and enums.They’re also concepts that aren’t available in LotusScript or SSJS, but which I’m sure you’ll find add extra power to the developer to ensure classes are used the way they were intended.

2 thoughts on “Moving from LotusScript/SSJS to Java: Interfaces and Enums”

  1. Splendid article. Especially Enums are really cool to allow the compiler to check for typos – and putting them inside an interface is a neat way of grouping them with the relevant code 😉

    /John

    PS. Shouldn’t “public static enum LogType()” be without the “()”…?

    1. Ah, correct. I’ve fixed that now. You just demonstrated another good reason for moving from SSJS to Java – Java editor picks up any errors when you save, unlike SSJS editor 😉

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.