During a recent discussion on Java I bemoaned the fact that some basic pieces of functionality we’ve exploited for years in Formula Language are missing. The example I gave was @Right, being able to get a portion of a string based upon the existence of another string. In JavaScript and Java there are no inherent methods in the base string classes to facilitate this. Yes, it’s not rocket science to write those functions, but it’s frustrating that popular languages don’t do that kind of thing out of the box. So you end up building up large libraries of basic code snippets that you have to include into every project. The problem is that if you’re starting off in the language you don’t have that library to start off with, extending the development time and unfavourable comparisons with what you’ve come from.
The work IBM has done to port @Functions to Server-Side JavaScript helps avoid many of those frustrations and is to be applauded. And whereas some functions like @DBLookup are so crucial to development and could not easily be written by developers, the time taken to port @Right, @Trim etc may not have been extensive but would be greatly missed.
And so to Java. The Java String class has a substring method which, like JavaScript, takes a start index and an end index. But if you want to do something like @Right, you end up writing more code. Maybe less than a minute. But add that time up over your development lifetime and work out the amount of extra pints you could have down the pub!
It was after expressing this frustration that Nathan Freeman pointed me in the direction of org.apache.commons.lang which contains a host of additional classes and methods for handling the core Java classes. One of these is StringUtils.substringAfter(String str, String separator), the equivalent of @Right. What’s better is that these classes are null safe, so they gracefully handle getting passed a parameter that’s null.
But the question of some developers will be whether these are supported by IBM and how to get hold of them. The answer can be found in
The alternative is to import the jar into the source folder for your custom Java code and managed beans and then add it to your build path using the Add JARs button. It will then appear under the Referenced Libraries, as in the screenshots below. Then you can take advantage of it. And there are another 1500 Java packages available in the same location (I can’t take the credit for the count, that was Nathan!). Enjoy.
Thanks Paul – thats the best explanation I have come across yet about the difference between referencing external JARS and bundling them within the Notes DB.
I assume the disadvantage with this approach is it increases the application size and if you have a custom JAR your application could go out of synch with the latest version of that JAR.
It may impact the size slightly, but I wouldn’t expect the impact to be that much that particular JAR is 248Kb. And bear in mind that the build process in both cases will add the compiled version of the JAR to the NSF anyway.
In terms of it being out of date, unfortunately you’ll hit that anyway. You’ll notice the JAR file has a version number on it, and this is different between 8.5.2 and 8.5.3. So it’s not going to pick up the 8.5.3 version when you upgrade, it will still look for the 8.5.2 version. That’s where you could get problems when trying to build on a PC that has never had 8.5.2, because it won’t find the JAR unless you’re using a version stored in the NSF. It’s the same as referencing a specific Dojo version for functionality. The advantage though is you don’t have to worry about backwards compatibility when you upgrade the server or Designer client.
You should add it as a dependency to the NSF’s plugin. In the Java Perspective, doubleclick on the plugin.xml in the roor of the project. On the tab Dependencies, add the org.apache.commons.lang plugin then click on the tab named plugin.xml and make sure the entry is OUTSIDE the generated dependencies, otherwise it get’s overwritten by a database rebuild. If you do it this way, you’ll always use the already installed jar and not waste space and memory.
@Peter Ah yes, of course. I remember now doing the same kind of thing to include the Java UI library in a plugin I developed last year. Of course an NSF is now just a plugin, so the same holds true.
@Mark Using the Dependencies tab (or just making the changes directly on the plugin.xml) will avoid needing to store it in the NSF and automatically pick up the relevant version from the Notes install path. You just need to remove the version attribute added to the import XML tag.
How do using these libraries come into play if you’re using the new JavaElement in 8.5.3? Do you still need to go into package explorer to add this?
@David you should be able to just add them to the plugin.xml as Peter outlines. See my next post for screenshots.
Glad to be of help, Paul.
Here’s the sad thing: I didn’t even bother to look deeply into the commons.lang library myself. And doing so just now, I stumbled across…
MutableBoolean
MutableByte
MutableDouble
MutableFloat
MutableInt
MutableLong
MutableObject
MutablePair
MutableShort
All of which I had to implement in GBS’s Lotusscript emulator for our Transformer.
I guess it’s some consolation that there’s no MutableString implementation there, which is probably the most important one. Still, I wish I had inherent knowledge of all 1500 packages available at runtime. I’m certain it would make my life much simpler. 🙂