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! 🙂

9 thoughts on “What’s the future of Java in Notes/Domino?”

  1. Hello Mikkel,

    I don´t know, why IBM always has to use their “own” JAVA. It has been really frustrating the last 5 years.
    I was hoping, that that is over with Notes 8. But that was perhaps a little bit too optimistic…

    Like

  2. I was told by IBM that the JVM in Notes 8 is the IBM JVM – the same JVM as in Sametime and Expiditor – and would stay that way. The reason IBM gave for this was that this removed any cross-JVM compatibility issues and was extensively tested, as it’s the same core JVM as the one they use for numerous other OEM’d hardware (I was told the Playstation 3??)

    I guess with the whole stack on one JVM that makes sense, but it does tie us into IBMs’ current JVM level.

    Like

  3. All methods of the java.util.Vector and java.util.Hashtable are synchronized which means that there is a large(r) performance overhead to calling the methods than any unsynchronized counterpart. You use the synchronized keyword to only allow one thread access to a given object at a time which is overkill unless you know that multiple threads will access the objects at any given time.

    Starting with Java 1.2 (!!) a proper collection API was provided as part of the Java SDK and the proper way to have a Vector style collection is to use ArrayList and to use HashMap instead of Hashtable. Both these classes are unsynchronized but can easily be made synchronized by using the static methods of the java.util.Collections class.

    Like

  4. I’m trying to dig up exactly what you need to implement to have a compliant Java SE Platform runtime. The best I can come up with is the API docs that do say “JavaTM 2 Platform, Standard Edition, v 1.4.2 API Specification” (for the example I’m looking at) and there are javax, org.omg, org.w3c and org.xml packages in that spec. That’s not to say that the J9 JVM isn’t a fully compliant JVM, just that the runtime can’t be a compliant Java SE Platform runtime without including those APIs, unless I missed an “optional” somewhere.
    Personally I’d love to have the ability to use any shiny new Sun VM and JDK as soon as they were available, but I understand that’s going to be a support nightmare for IBM. They want to support a single JVM on all platforms Domino is running on, therefore they need the JVM on Windows, AIX, Linux, etc, etc. I wouldn’t be surprised to see them produce a JVM for Mac OS X (maybe with only X windows support for UI.)
    I think IBM will be doing well if they get Java 6 VMs out on all their platforms within 6 months of Sun. That’s probably coming up rapidly, so well see how they fair.
    I’m far more annoyed about the lack of info on a JEE 5 build of WebSphere. I fully expect to see a JEE 5 version of Geronimo, with pay for support from IBM under WebSphere Community Edition, before we see WAS 7 (or whatever they decide call it.)
    Of course, if I develop in a proper IDE and then import classes into Domino and turn the compiler compatibility down to what’s supported in Domino, then that should work fine, as long as I don’t need any of the new standard in libs. Pah 😉

    Like

  5. I do not ever see IBM allowing us to change the jvm on the client, and really do not expect it on the server. The issue is support. IBM has to, because of who IBM is, test everything to a level most of us do not understand. The QA for Notes 8 is probably the big limiting factor to features that will make the 8.0.0 release. They have to test on 2 client platforms (and soon 3) and multiple server platforms. Add in different langagues and all that. Adding in a JVM that could change and things will just go nuts.

    Add in the new level of complexity with Sametime 7.5 embedded and Expeditor. I know that is all client stuff, but still.

    I know many people think IBM should allow the customer to decide how much risk to take, but that is not the IBM way. Add in the fact that this decision could make the java version on the server and different clients different and you have a support nightmere. Customers calling IBM with problems and having to diagnose issues might not even say they changed the jvm, or not know. Talk about chaos.

    I will tell you … I have made the recommendation that IBM does not go down this road when my opinion is asked.

    Like

  6. I agree that the problem is support but unless we express our “dream-scenario” nothing will ever happen. I however still think that IBM should give customers the option of running the client using a pre-installed JVM – it could be with a limited support option to start with until they gain experience with it.

    As to the server it could be that it was time to distinguish between the platforms. Maybe different release cycles (at least JVM-wise) for different platforms. Alternatively I fear that customers will start moving code execution of the Domino server and onto Java servers such as JBoss og Geromino or simply a simple Java program with a scheduler. We are already doing this in production but it isn’t without problems and avoiding it would be number one.

    How about a specialized “agent-server” instance option? Many customers already do this anyway…

    Like

  7. In my opinion, IBM should be much more agressive in latest Java version adoption…

    But, has I think expeditor is now the base of Notes client, we have more chances JDK is upgraded more agressively. Let’s hope it happens on the server too (have to ask Bob Balaban about it :))

    Like

Comments are closed.