Tag: expeditor

Eclipse 3.3 is here – what does that mean for Lotus Expeditor?

As you might have heard version 3.3 of the Eclipse platform has been released under the codename of Europa (Eclipse 3.3 Europa) and is now the preferred version of Eclipse for new developers. With the new Eclipse release I’m wondering where that leaves us developing for Notes 8 and Sametime 7.5. Will development for the IBM Lotus Expeditor platform be supported with Eclipse 3.3 or will we need to stay to Eclipse 3.2 to be supported?

I’m just curious. It isn’t too much of a problem for me right now as I’m already running both Eclipse 3.1 and Eclipse 3.2 on different projects so adding a third to the mix shouldn’t be too much of a hazzle. I’m just curious as I think it will set a precedence as to how IBM Lotus plans to keep up with the ongoing development and evolution of the Eclipse platform.

Another reason why it isn’t too much of an issue for me is that I’m on Windows XP. One of the noteworthy features of Eclipse 3.3 is the support for Mac OSX on Intel. This is interesting since we as Notes/Domino developers are extending our reach into the Mac market and hence this kind of support is required.

What’s the future of Java in Notes/Domino?

At Lotusphere 2007 there was a session on the future directions of Java in Lotus Notes and Domino called AD508 (AD508: Java 5 Upgrade for IBM Lotus Notes and Domino). Basically the session discussed the future of Java in Notes/Domino and how IBM is planning to ship Java 5 as part of Notes 8/Domino 8. Unfortunately I haven’t had the time I wanted yet to play around with version 8 yet so I cannot comment on whether Notes/Domino 8 already has Java 5 – the Reviewers Guide says that it has though.

For those not in the know Java 5 introduced a number of new core language features which are definitely worth the upgrade but the most beneficial for me is the enhanced for-loop and generics. There are a number of additional API changes that makes life much nicer from the programmers point of view. This is all well and good but Sun Java is currently in version 6 and have been for a while now and Java 7 is currently being planned and scoped out. Java 6 has a number of additional features that would be nice for Notes/Domino programmers such as JDBC 4, new APIs for web-services and improvements to the Java Platform Debug Architecture (JPDA). Only going to Java 5 in Notes/Domino 8 seems like a bad choice.

Why would IBM not want to go directly to Java 6? It could be that, as of today, IBM hasn’t shipped a Java 6 development kit yet and since IBM probably wants to include their own JDK it might be why. Another reason could be that IBM Lotus Expeditor doesn’t run on a standard JDK but on the IBM J9 VM which is a scaled down version of the JVM with a limited set of API classes. With not even a Java 6 JDK ready I would guess that a Java 6 version of J9 is a long way off. The fact that Lotus Expeditor is based on J9 causes its own set of problems for plug-ins in Sametime 7.5 (as previously mentioned) but that’s another story.

I fear that since Lotus Expeditor now is the base platform for IBM client products and since IBM probably wants to avoid shipping two JVMs with the product they will stick with J9 for some time. Given I don’t know the exact technical reasons for J9 and there are performance to think of as well (JVM reuse for client platform code and client side Java) I find that a real shame. It would be a really big loss.

Suddenly the supported Java version will be tied to the JVM running the client and we as developers and customers will be tied to using back-level APIs. For trivial agents etc. this is probably not going to matter anyway since the Java API hasn’t been updated since its inception. For new code it is going to be a real show-stopper. Most new code and components are created by combining existing (open-source) modules into new code and modules and with most open-source projects being at at least Java 5 by now it is going to cause problems. I know Java 5 and Java 6 are bytecode compatible but requiring additional compatibility libraries are going to be a problem in the long run. Combining this with the Java security restrictions put in place we can find our self running on a monolithic IBM Java platform which hardly was the idea.

So what’s the answer?

It seems more and more like IBM should support custom JVM for at least the server. It would be nice for the client as well but lets be reasonable. It could a solution where there are a number of choices – some choices could be proven and (absurdly) battle-tested (Java 1.3, Java 1.4.2) and some simply following the industry (Java 5, Java 6). I know it probably never will be possible to simply drop a new run-of-the-mill Sun JVM into Domino but this isn’t necessarily the goal. I simply want a JVM that follows along. It might be that it required an additional download and install but at least give me the choice.

As for the Notes 8 client it might be even easier than for the server since the Eclipse foundation already allows for a custom JVM. Why not support running Notes 8 on an already installed JVM? One could even argue that the client would benefit just as much from a JVM upgrade than the server since the Notes 8 client will be a universal client and hence not simply access Notes data. If IBM expects ISV’s to develop Java solutions for Notes 8 they will expect a common programming model for Eclipse/Notes 8 based solutions which comes down to the JVM.

So IBM – please upgrade the JVM or allow for “custom” JVM’s – soon… Oh – and please upgrade the Notes/Domino Java API – who still uses java.util.Vector? Thank you! 🙂

Microsoft Exchange protocol has been opened up

As you might have heard a number of Microsoft proprietary protocols has been opened up (incl. the protocol used for Microsoft Exchange Server) as reported on Slashdot and on Redmond Developer News. This would make it possible, as actually mentioned in a Notes 8 session at Lotusphere 2007, to make Notes 8 a client for Exchange since the Notes 8 client (read Lotus Expeditor) is actually very generic.

But then again who would want to run against Exchange Server? 😉

Via the Java Posse episode 110.

Lotusphere 2007: Sametime 7.5.1 miniApps


As mentioned the other day (Lotusphere 2007: Sametime 7.5 and Notes 8 sidebar compability) you’ll have to change how you do miniApps once Sametime 7.5.1 is released. I went and talked to Dave Schlesinger in the Developers Lab today since he’s in charge (or actually wrote) the Sametime client toolkit. It turns out that the com.ibm.collaboration.realtime.miniApp extension point will be kept for backwards compatibility but you should start writing miniApp plug-ins as ViewParts instead. This will also be the case for “miniApps” destined for the side-shelf in Notes 8.

Apart from discussing extension points we also talked about how one should go about discovering the active environment. We had a good talk about this since we as partners or ISV’s will need to be able to discover whether we are running in Sametime, Notes 8 or simply Expeditor. This discovery should be possible without having to link against or include specific libraries since not all libraries (e.g. notes.jar) will be available on all platforms. We kind of agreed that a system property would the simplest way to go.

I also asked him to please document the extension point schemas better… 🙂

Lotusphere 2007: Run your Update Sites from Domino (ID211)


Just attended ID211 by Thomas Gumz from IBM on how you can use Domino as the source for your Update Site to provision features and plug-ins to Sametime 7.5, Expeditor and Notes 8. Lotus has built a really cool template, shipping with Notes 8, that allows you to run an Update Site out of a Notes database instead of using a file system based site. Very cool.

Thomas also mentioned that in Notes 8 you can provision features and plug-ins using NRPC instead of HTTP for remote sites. This will only work against Domino 8 servers since this is a new call that has been added to the NRPC protocol. The URL syntax will be something like nrpc://intranet.company.com/_<replica_id>/updatesite.nsf instead of the http:// equivalent.

Show ‘n Tell Thursday: The missing link for plugging Notes into you Sametime 7.5 plugin (10 January 2007)


When you develop and run plugins for Sametime 7.5 on Windows or Linux you do not use a standard Java Development Kit (JDK) and standard 1.4.2 JVM. Instead you use a slightly modified version called the JCL Desktop JDK and the J9 JVM. The “slightly modified” means that some features have been removed from the JDK to make it “safe” for the Expeditor framework that Sametime 7.5 runs on.

An unfortunate side-effect of this decision is that you cannot use the Notes/Domino API (that is notes.jar or ncso.jar) without resorting to additional libraries. The reason is that the ever present lotus.domino.NotesException inherits from org.omg.CORBA.UserException which is an exception class that has been removed in the modified runtime class library (for more information about lotus.domino.NotesException see my post called Java in Notes/Domino Explained: NotesException).

Fortunately there is a way to remedy that. The solution is to include the ibmorbapi.jar library (can be found in c:Program FilesNotes7Datadominojava on my laptop) in your plugin alongside notes.jar or ncso.jar. The ibmorbapi.jar library is quite large (around 400kb) but I haven’t yet played around with it to see if you could simply get away with including the org.omg-packages.

Now you know why your plugin fails to compile due to indirectly referenced Corba classes.

Anyways – someone who has the ears of the Sametime development team might want to mention this to them. Apart from that – great product and its a joy to develop plugins for Sametime 7.5! 🙂