If you’re not primarily coding in (client-side) JavaScript, my recommendation has always been that any XPages developers who have worked with the platform beyond a few projects should be coding in Java. That’s why I developed a course specifically around Java development in XPages*. Server-side JavaScript is a good starting point, but only a starting point. It’s client-side JavaScript syntax and some classes which hides the complexity of Java. That’s okay if you understand that complexity, but in many cases it causes more problems, with developers unable to differentiate between what’s running on the server and what’s running on the client. It’s also increasing causing problems because the developers who answer questions on StackOverflow don’t code much in SSJS and haven’t for a long time. I rarely write more than four lines of SSJS in a single block, typically only one or two. And from what I can see, there do not appear to be many people with active SSJS experience adding to the group of people answering questions there.

But if you move to Java, there are a few initial hurdles. Understanding calling static methods and the relationship between classes, objects and beans is one. That’s covered in various places, from Java books to NotesIn9 videos. But there are a lot of SSJS variables that developers use without thinking. Accessing those from Java initially seems more challenging. Many years ago David Leedy helped with some of those, with the XPages CheatSheet. Before that, Tim Tripcony’s JSFUtil class was a resource many used. But those both pre-dated the XPages Extension Library. Nowadays I would hope that no one is developing an XPages application without the Extension Library, hopefully none are doing so without a modern version of the Extension Library which included Bootstrap.

In the Extension Library, ExtLibUtil is the key class that gives you access to everything you would use without thinking in SSJS. getCurrentSession() with all its variants is a typical example. It also has methods for getting all the scope maps (sessionScope etc). To get the context SSJS variable you can use getXSPContext(). And if you can’t find a method to get a particular variable, resolveVariable() will get you there.

Yes, Java is a learning curve. It was a big learning curve reading through the source code of the Extension Library and cross-referencing to the demo database, in order to write the XPages Extension Library book. But it’s more than paid back the time spent, not least with OpenNTF Domino API and various non-XPages Java packages I’ve used like Apache POI, Watson developer code etc. And to be frank, working in IT means always being willing to learn. So if you’re doing web development and not focusing your energies on Node.js, Java is where your focus should be.

* Intec’s XPages and Java course (other courses are available online)

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.