Feature Pack 8 is there - and here’s the trouble

Wednesday, March 8, 2017 at 9:31 PM UTC

Yesterday FP8 was released. As you know me, I always try new things out immediately, so I did with FP8. Installation on the server worked like a charm, the client though was a bit tough in some cases. But it’s not about the installation I am writing about but about the consequences we have to face when choosing to update.

Some projects may fail to build once DDE got FP8, too (or later it won’t run on the server with FP8) as IBM added some new methods to the Document interface class.

As you can see those methods are missing in the own classes which implement Document. Ok, we can discuss if it’s a good idea to implement a „system“ interface, but sometimes you have to. In this case you have to implement the missing methods.

So far so bad. Once you chose to change you code to be compliant to the new code base, there’s no way to turn back. One could say: hey, even on old systems without FP8 those methods never will be called. That’s true. But think further: if you now rely on those methods (i.e. implement own code) you wisely have to check the target Domino environment. If it’s not running FP8 or higher, your code will not run as expected.

Just keep that in mind.


It was reported (and I experienced similar) that the FP8 installer will overwrite the jvm.properties file in <notes>/framework/rcp/deploy which leads to unwanted behavior of Domino Designer due to changed memory settings for the JVM. My file was set to an Xms value of 48k where 512m should be the default. You should check that file and accordingly change after FP8 installation. For a convenient way of configuring this file you can also use this nice GUI tool from Fredrik Norling: http://www.xpagedeveloper.com/software/designer-memory-configurator

Extension Library

IBM added all the 17 versions from OpenNTF's Extlib to the core product, named v_08 now. But there is another problem:

This is the package name from IBM: com.ibm.xsp.extlib.library

If you used the OpenNTF versions before then you run into trouble, too. If you just used the built-in one then everything is fine. 

This was the package name when you used the OpenNTF version: org.openntf.domino.xsp.XspLibrary

The problem: the IBM version in FP8 has a never timestamp so that the OpenNTF version won't be loaded and used - and your apps will fail. After ExtLib v18 is out this shouldn't be a problem anymore. I really hope v18 won't depend on FP8...

The Exltib problem wasn't a problem - I clarify that in this post.


As IBM will also update the XSP runtime on Bluemix with the latest Feature Pack you instantly should check if your apps continue to work on a server with FP8 enabled, especially when you used the OpenNTF ExtLib (yes, you can do this even on Bluemix).

What others say

There are some other issues and caveats as well as my fellow IBM peeps documented so well on their own blogs:




For now it is for me just doing this:

Latest comments to this post

Ketil Hjerpaasen wrote on 09.03.2017, 15:16

We found a bug regarding css and js files

We have upgraded a testenvironment to FP8 from FP6.

In an XPINC application we found a bug where the Notes client couldn´t find our css files and js files IF there where more than one of them. When we copied the content from our css files and js files into one css and one js file it started to work in the FP8 client. 

There was somebody that reported this in FP7, can´t remember where I read it.

 Link to this comment
Karsten Lehmann wrote on 09.03.2017, 11:39

Regarding problem #1, take a look at java.lang.reflect.Proxy or the cglib library. They let you dynamically implement interfaces or create subclasses from existing classes.

 Link to this comment

Leave a comment right here