Tag: java

LotusScript.doc v2 – java.policy changes required

Strong: Just to clarify – LotusScript.doc v2 isn’t out yet. It is out in a very, very limited prebeta 1 (one person besides me) in preparation for a more general beta process hopefully in the very near future. See this post for a clarification on the progress.

LotusScript.doc v2 uses java.util.logging as its underlying logging framework. To spice things up a little it also uses some internal magic to ease troubleshooting and provide easy debugging. One of these tricks is to print out the XPath expression of the element being processed in the log. More on this another time.

In order to use java.util.logging and set custom Handlers and Formatters you need to tweek the java.policy a little bit. It’s quite easy as the only thing you have to add to your <Notes binary directory</jvm/lib/security/java.policy file is the following in the first “grant” section:

permission java.util.logging.LoggingPermission "control";

Here is a link to a default java.policy file and a changed java.policy file.

I’m trying to create script libraries using DXL – possible?

I have spent a little time this weekend trying to create Java script libraries (that is script libraries with Java code and not “JavaScript” libraries) from scratch using DXL. Exporting the DXL of a script library with a jar-file imported into it yields some base64 in a <javaarchive /> tag. The base64 data is however not decodable as it’s not valid base64. Base on prior experiences with this kind of stuff I tried decoding the bytes but without success.

The header in base64 is (or at leas to a multiple of 4 characters) is “UEsDBBQACAAIAKyEATkAAAAAAAAAAAAAAAAUAAAA”. I guess the beginning is probably a CDFILEHEADER struct (based on prior help) but I’m unable to decode it… 🙁

The struct should start with a DSIG struct (16 bit unsigned integer and a 32 bit unsigned integer) but I’m unable to get anything that makes sense. I end up with 20555 for the first WORD but that doesn’t “compute”. Bummer!

If you’ve done any work on this and is willing to share please drop me a comment. Thanks.

Looking into Scala

I’m spending a little time this Christmas holiday looking into Scala which is a functional programming language that runs on the JVM. I’m off to a good start with the excellent The Busy Java devlopers Guide to Scala on developerWorks by Ted Neward. 

object HelloWorld {
  def main(args : Array[String]) {
    Console.println("Hello Scala World!")
    for (value <- args; if value.startsWith("Lotus")) {
      Console.println(value)
    }
  }
}

Doing Java in Notes? – make sure you know about JavaCompilerTarget

I blogged about the JavaCompilerTarget back in August last year when Notes 8 came out as you needed it to enable Java 5 in Domino Designer. Last week some nice new info on this notes.ini setting came my way in the Design Partner forum for Domino NEXT. If you’re doing Java development in Notes you would want to read on.

And yes – I did check with IBM whether it was okay to blog it. Since this info is on its way out in technote (technote 1320401) it was fine that I blogged it.

JavaCompilerTarget

In Notes/Domino 8.5, you can set the JavaCompilerTarget INI variable to any value from 1.1 through 1.6. Here is a draft of the documentation (Note: In the following text, we refer to JDK 1.6, which is also known as JDK 1.6.0 and JDK 6.0.)

By default, Notes/Domino 8.5 utilizes JDK 1.6 to compile and run agents, but it limits language features to maintain backwards compatibility through JDK 1.2, to allow agents to run on earlier Notes/Domino installations (and, more generally, with any JVM version earlier than the target flag), regardless of whether the new language features are actually used in the agent’s code (e.g., setting JavaCompilerTarget=1.6 could introduce the possibility of having an agent recompiled and replicated to a V8.0 server, and then failing to run). Additionally, problems could arise editing and saving agents compiled in Notes/Domino installations that are not using the same INI setting.

Developers must override the default behavior if they wish to use features specific to different JDKs. The default behavior is equivalent to the setting
JavaCompilerTarget=1.2

In Notes/Domino V8.5, the developer may specify any JavaCompilerTarget from 1.1 to 1.6. (In each case, the -source flag is the latest source that can be specified with a particular -target flag.)

The developer may also specify
JavaCompilerTarget=CurrentJavaVersion
which means the target flag will be synced to the version in future Notes/Domino releases (e.g., if some future Notes/Domino version were to include JDK 1.9, then “JavaCompilerTarget=CurrentJavaVersion” would create “-target 1.9”).

JavaCompilerTarget Resulting compiler flags Agent would run on Notes/Domino versions
1.1 -source 1.3
-target 1.1		 V5.0 or later
1.2 -source 1.3
-target 1.2		 V6.0 or later
1.3 -source 1.3
-target 1.3		 V6.0 or later
1.4 -source 1.4
-target 1.4		 V7.0 or later
1.5 -source 1.5
-target 1.5		 V8.0 or later
1.6 -source 1.6
-target 1.6		 V8.5 or later
CurrentJavaVersion -source 1.6
-target 1.6		 V8.5 or later

Remember that these settings may prevent compiled agents from running on some earlier Notes/Domino installations. Therefore, it is suggested that organizations use a consistent setting across machines.

Developers who will not be using language features specific to recent JDKs are encouraged to keep the default Notes/Domino behavior to maximize backward compatibility.

XPD – where do you live?

Disclaimer: I’m trying to get some info from IBM on this subject so please check back as I will update this post as more info becomes available…

Again this is one of those posts that will annoy the heck out of European developers…

Internationalisation – or i18n – is done using the java.util.Locale class in Java. When calling Locale.getDefault() the standard Locale for the JVM should be returned and should be da_DK for me (country: Denmark, language: Danish), en_US for you US guys (country: USA, language: English) and de_AT for people from Austria (Country: Austria, language: German). The Locale can be supplied to many localisation sensitive classes such as java.util.Calendar etc. to make sure it works as expected for the current user locale. Most times however you don’t supply the locale explicitly which will make the platform do a Locale.getDefault() for the current locale.

Meet Lotus Notes 8+…

Per default Lotus Notes 8+ runs with a Locale of en_US which is great if you’re based in the USA and speak English or simply only use the built-in functionality of Lotus Notes. If you’re a plugin developer and you do any i18n work you will be sadly disappointed since Calendar and ResouceBundle will be broken. Since Locale.getDefault() returns en_US you will get back a Calendar for the US (e.g. Sunday is first day of the week) and English strings from your resource bundles.

Maybe this is why the preference has a page for locale setup (see File/Preferences/Calendar and To Do/Regional Settings) which is used by Mail.

To makes matters worse I think it’s a core platform issue since you can actually change the language of your Notes client by supplying a command line argument (-nl) to the Notes client. Doing this (-nl da / -nl da_DK) changes the menu item text in my Notes client but any plugin that use Locale.getDefault() still return an incorrect result as shown on the image below.

To make it even weirder it works as expected when the Notes client is started from the Eclipse IDE using “-nl da_DK”. Go figure!



(click on the image for larger version)

This behavior has been verified with Notes 8.0.1, Notes 8.0.2 and Notes 8.5 beta 2.

Show ‘n Tell Thursday: Easy access to Lotus Connections Profiles translation files (21 August 2008)


This weeks SnTT post is about Lotus Connections and how to more easily get access to and change the translation files for the UI of the Profiles feature.

Configuring which pieces of information are surfaced in the Profiles feature is pretty easy and well documented using the profiles-config.xml file. Changing the label text however is harder and not that easy to do. As it is documented it involves stopping profiles, locating a jar-file, extracting it using WinZip, changing a properties file, repackaging the jar-file, redeploying the jar-file and finally restarting profiles to see the change. This is well and good and acceptable if you only need to change the file once, but chances are that it’s an iterative process and you need to do it multiple times. Wouldn’t it be easier to simply stop profiles, change the file and restart profiles? Well read on to see how.

The labels for the fields (and all the other pieces of text for that matter) in Profiles are stored in property files in a jar-file in the Profiles application. Changing the property files for the appropriate language causes the text to change in the UI after a restart of the Profiles application. This is easy enough but require a lot of repeated steps every time since you have to unpack the jar-file, change the property file and repack the jar-file.

Since Profiles is just another Java web application we can move some of the classes and property files out of the jar-file (in the “lib”-directory) and into the “WEB-INF/classes”-directory. This means that we only have to repack the jar-file once and for all since the property files are now available from the “classes”-directory.

On your Websphere Application Server where the Profiles feature is installed (with Profiles stopped) do the following using a file explorer:

  1. Open the profile directory for the profile you’re using
  2. Open the installedApps directory and the node directory underneath it (chances are that there’s only one node directory)
  3. Open the Profiles.ear directory
  4. Open the peoplepages.war directory
  5. Open the WEB-INF directory
  6. Create a new directory called “classes”, and inside this directory create a com/ibm/peoplepages/webui directory (a total of 4 directories)
  7. Open the lib directory and locate the peoplepages.web.jar file and make a backup copy of this file
  8. Now unzip the jar-file (maybe renaming it to a zip-file first), navigate through the directories to com/ibm/peoplepages/webui and move the resources folder to the “classes/com/ibm/peoplepages/webui”-directory you created above
  9. Navigate back to the extracted jar-file and zip the “com” and “META-INF” directories back up into peoplepages.web.jar and overwrite the peoplepages.web.jar file you located in step 7

Now you should have replaced the original peoplepages.web.jar file with a new one and have a directory containing the resource files.

Now when ever you need to change a label for a field simply locate the label or text you would like to change in the property files underneath WEB-INF/classes/com/ibm/peoplepages/webui/resources and restart Profiles.

Please note that the above probably isn’t supported by IBM… 🙂

Show ‘n Tell Thursday: Cross compiling sidebar plugins for Notes 8.0.x and Notes 8.5 (7 August 2008)


I haven’t done a SnTT in months (actually the last one was back on 24 May 2007) so I guess it’s about time. This week it’s about cross compiling sidebar plugins for Notes 8.5 and Notes 8.0.2. Enjoy…

Since installing Notes 8.5 I have had a lot of trouble developing in Eclipse 3.4 for Notes 8.5 and having the plugins work in Notes 8.0.x as well. The problem showed itself as a NullPointerException when trying to load the plugin Activator and a “Viewpart is null” message in the Notes UI. Looking at the log trace showed a class incompatibility message (“bad major version at offset=6”).

So far I have been screaming my lungs out, developing in Eclipse 3.4 and building the plugins in a virtual machine with Eclipse 3.2 as I couldn’t get plugins to work otherwise. Now I finally found a solution that lets me develop in Eclipse 3.4 and having the plugins work in Notes 8.0.x and Notes 8.5.

The issue is that Eclipse 3.4 configured with Notes 8.5 as a target platform is using Java 6 and that Notes 8.0.x is using Java 5 which causes class format problems. The solution is to set the required execution environment in Eclipse 3.4 which will cause Eclipse to build correctly. Setting the required execution environment (J2SE-1.5) is done in the “Overview”-tab of the MANIFEST.MF editor as shown below.

Using the GUI is of cause just a shorthand for editing the manifest manually. As an alternative you can edit your META-INF/MANIFEST.MF file directly and add the following line:

Bundle-RequiredExecutionEnvironment: J2SE-1.5

Please note that this is not the default value when creating new plugins in Eclipse 3.4 so you’ll have to pay attention and make sure it’s set correctly. This is of cause only necessary if your plugins need to work on Notes 8.0.x as well as Notes 8.5.

Thanks to Pierre Carlson from IBM for pointers on this.

How to get started with Java

I regularly receive e-mails from Notes/Domino developers asking how to get started with Java. In general people are intimidated by the language itself and turned away by the absence of good resources for novice Java programmers so they ask my advise on how to get started. Normally the focus is to use Java for web development (J2EE) and Notes 8 development.

Although evidence to contrary Java is actually quite a simple language at its core and it’s mainly about syntax and a few (dozen) rules. I recommend starting with the language itself and focusing on that before diving into Java for Notes, J2EE and Notes 8 development.

Although not the easiest of routes I suggest the following:

  1. Start with a good Java book and learn the language itself without focusing on Notes/Domino. I can recommend the Thinking In Java book. Skip stuff on threading, GUI development and other advanced topics. Make sure to read up on the java.io framework (e.g. how to read/write to/from files) as that concept is used a lot. All in all – read chapter 1 through 12.
  2. Be sure you read the book and did the hands-on labs… 🙂
  3. Start doing some simple Notes agents in Java instead of LotusScript. Maybe even convert a few existing agents into Java. Here my posts called “Java explained” might help.
  4. Do step 3 again and again until you’re confident with the language.
  5. Start looking into more complex areas such as J2EE development and Notes 8 development.

If you have questions feel free to ask them here.

Part 2 of the blackbox article published

The second and final article in my series on Sametime blackboxes (Configuring the Sametime business card system, Part 2: Reach more data with custom blackboxes) has been published at the THE VIEW website and will be out in the May/June issue.

Where as the first article primarily focused on configuration and setup of the blackbox system the second article describes how to develop your own custom blackbox implementations. One of the blackboxes I describe is the one I developed for the bleedyellow.com Sametime server. This implementation retrieves business card data from Lotus Connections.