Getting To The Java Roots of XPages – Part 2

You may be asking yourself why you even need to care about Java when it comes to your XPage applications, your xsp file is converted to java and then compiled and ran on the server when called by the browser. You’ll probably even get different answers from different people when you ask that question but for me I see two reasons, speed and reusability.

Reusability is probably something you already do in your applications, lets say you have a requirement to fing the internet email address of the currently logged in user from the addressbook. There are a couple of ways you can do this but you have elected to write some ssjs directly in the computed field control on your page. Later in the same app you need to add a similar field onto a different page, you could copy/page the original field which would duplicate the ssjs code or, in a flash of brilliance , you create a function in a ssjs library and then change both control to call the function, now you only have a single place to change the code for the purpose of showing the currently logged in user’s internet email address. Pat yourself on the back and go grab another coffee.

But what about speed?

The performance of your Xpage application is important for end users, if the page doesn’t appear fast enough they think it is broken and they log a support call and then you look and because you wrote the code and you know it can take .5 of a second to show on screen ( the user wants it in .1 of a second ) you don’t see anything wrong, the user then hates the app and then won’t use it any more.

That ssjs function that you wrote to get the name from the nab is actually a bottleneck in terms of speed. When your xsp file is converted into java the ssjs is not converted, it just becomes a big string of characters that is then passed into another java class that runs it at run time. It is ‘interpreted’ at run time. If there is an error in the code you won’t find out about it till run time and even if you made it a function in a ssjs library it is still only dealt with at runtime.

Here is an example of the java code that is generated by a link control on a page. The text of the link is computed using ssjs.

XspOutputLink result = new XspOutputLink();
setId(result, "link1");
String sourceId = "link1/xp:this.text[1]/text()";
String textExpr = "#{javascript:try {ntvar nabDB:NotesDatabase = session.getDatabase(database.getServer(),"names.nsf",false);ntvar nabView:NotesView = nabDB.getView("($Users)");ntvar nabDoc:NotesDocument = nabView.getDocumentByKey(session.getEffectiveUserName());ntreturn nabDoc.getItemValueString("InternetAddress");n} catch(e) {ntprint(e);ntreturn null;n}}";
ValueBinding text = evaluator.createValueBinding(result, textExpr, sourceId,String.class);
result.setValueBinding("text", text);
return result;

Eeek! Java! Run Away, Run Away!

Actually this is very easy to interpret  first it creates a, for the moment lets call it a variable, called result. This variable has a number of things that can be set like the value, and id and text. The scary bit for me was the thing called a ValueBinding but we can ignore exactly what that does right now but you will see that it is being setup with the ssjs that was written for the link and then that is being put into the result variable before the result variable is passed back to the calling java.

The ssjs itself is not converted into java like the rest of the xpage. It is kept as a big blog of text that is then passed into the valueBinding when the class is called to create the page.

If you have a LOT of ssjs on a page then that is a lot of stuff happening at run time and if you have a lot of your business logic in ssjs libraries then it can really slow things down as the ssjs is interpreted at runtime.

So from a speed point of view compiled java is much much faster then ssjs and that alone is a good reason to switch, but it gets even better…

Tagged with: ,
Posted in None
2 comments on “Getting To The Java Roots of XPages – Part 2
  1. Nathan T. Freeman says:

    I’ll offer two more reasons besides reusability and speed: 1) maintainability; and 2) integration. Java code is much easier to maintain, with a vastly superior IDE that understands refactoring, delegation, etc. And there are literally millions of outside Java packages (both open and closed source) that can be integrated with your code when using Java. With SSJS there are maybe 10.


  2. Great explanation of how the SSJS is handled. Thanks for sharing.


Comments are closed.

%d bloggers like this: