Tag: java

New Sametime 8.0 Toolkit

The Sametime 8 SDK ships with a new toolkit called the Helper toolkit. The following is from the Sametime 8 SDK overview (Sametime_SDK_Overview.pdf).

“The Sametime Helper Toolkit is an API that provides an external interface to basic functionality of the Lotus Sametime Client. The Sametime Helper Toolkit is not intended to directly extend the capabilities of the Sametime Client. This toolkit differs from other Sametime client toolkits by providing an external interface to basic functionality exposed in the locally running desktop Lotus Sametime Client application. Applications that integrate the Sametime Helper API are essentially able to proxy the functionality of the locally running Sametime Client (Managing contacts, Starting chats, Alert notifications).”

Highlights of the Sametime Helper Toolkit

The Sametime Helper Toolkit exposes the following basic functionality of the Sametime Client:

  • Contact Management, Query, and Notification
  • Chat session initiation
  • Instant Share initiation

Deprecations

Be sure to review the API_Changes.txt file in the client/connect/doc directory of the SDK for changes in the public API.

Procedural vs. OO in Notes/Domino Java

In a comment to my “Is the lack of Java adoption *still* the Achilles’ heel of IBM?” post, Charles Ross has an interesting comment (emphasis *not* mine).

“I tend to learn by stealing and modifying/refactoring code. This is one kind of reuse. Most of the Java examples you find in the Lotus venues (LDD, Notes help, Sandbox, magazines etc) are not object oriented – not even structured. You can actually find more Lotuscript object oriented samples than Java ones. And at least in LS, the use of Subroutines is common practice in the Lotus templates. That’s good stuff to steal.

That lack of Domino Java source examples is a sore point. One OO thing I worked with was I mapped the Headfirst design patterns Ducks classes (Strategy pattern example) into a Notes Library and agent. Not quite coding, but educational.

So what we need is some nice Domino application classes to steal, basically.”

Something to think about… Maybe it’s because code in Java is so convoluted and hard to read due to the way the program flow may not be obvious that it’s easier to post Java snippets than full “programs”. Maybe this means that the posted code doesn’t lend itself to easy “stealing”. Hmm…

Is the lack of Java adoption *still* the Achilles’ heel of IBM?


In March of 2006 I wrote a lengthy post (see below for links) on how I considered the lack of Java adoption by Notes/Domino developers the Achilles’ heel of IBM. The post was picked up by Ed Brill and made quite a stir in the blogosphere.

Sitting here developing a Notes 8 plug-in in SWT (the Java widget toolkit of Eclipse/Expeditor/Notes 8) I got to thinking if the state of affairs has changed and if yes, how it has changed. As a strong Java proponent I’m afraid I don’t like the answer… My perception is that the percentage of Notes/Domino developers having adopted Java hasn’t changed since then. We’re exactly in the same place we were in March of 2006.

Why haven’t IBM done anything? Why wasn’t Java everywhere at Lotusphere 2007? Will it be a major focus area at Lotusphere 2008?


Not to sound too sour and/or disappointed but I fear there is somewhat of a connection between none of the 4 sessions on Java development I submitted for Lotusphere 2008 was accepted and the state of affairs. It could of cause also be that the sessions just wasn’t interesting enough.

Very few of the Lotusphere attendees will be looking for sessions on Java I’m afraid. A stark contrast to what the platform demands.

I understand that there is a learning curve to the language but we need to seriously address this lack of adoption. If we don’t we, as business partners, will not be able to fulfill customer demand for development resources. The platform as a whole will be the one that suffers. Of cause Java is *the* standard enterprise language so there’s an abundance of Java developers out there, but developers need a solid understanding of Notes/Domino as well as Java to be productive and bring value to customers.

My understanding of the current state of affairs is this:

  • Most of the Notes/Domino developers are older – very few straight out of school jump onboard. It’s all about learning an old dog new tricks…
  • Very few get into Notes/Domino development unless they work for a company running Notes. Could it be that the platform still have a monolithic feel to it even though it is anything but?
  • Very few existing Notes/Domino developers have started adopting Java due to lack of pressure from IBM. Certainly the Java API and IDE not evolving haven’t helped.
  • Many who have adopted Java in Notes/Domino use it as a procedural language as a LotusScript language substitute with threading or network connectivity. While this is a start there is a major leap in the level of abstraction needed for composite application development. If we had gotten started earlier we might be further ahead now.
  • Very few, if not none, of the guys and girls leaving school know that the Notes client of today is built on the same platform they have been using to learn the Java language (yes – that would be Eclipse).
  • Very few, if not none, of the guys and girls leaving school know that Lotus is all about the social and building software to support collaboration.

Please tell me I’m wrong!

Links:

Sick of java.awt type ahead suggestions in Eclipse?

Then you need this little handy tip. There are many classes with identical or similar names in the java.awt and the SWT widget libraries. Having to distinguish between the package names in the type ahead dropdown is a pain and lead to wrongful imports so do yourself this favor:

  • Open Eclipse
  • Select Window/Preferences from the menu
  • Expand Java/Appearance/Type Filters from the menu on the left
  • Click the “Add package” button, enter “java.awt” (without the quotes) and click OK
  • OK your way out

This will make Eclipse remove any matching classes from the java.awt package from your type ahead list. Very nice…

And while you’re there you might want to add lotus.domino.cso, lotus.domino.local and lotus.notes to the list as well as all Domino programming is done through the lotus.domino package.

Discovering Notes 8: Showing dialogboxes from SWT in Notes 8


One of the big changes in Notes 8 is the move to a Java threading model which means that showing a messagebox is not something you can *just* do. This has implications for you if you’re developing (or thinking of developing) UI components in Java for Notes 8. These UI components (e.g. sidebar contributions) are developed in SWT and hence follow the SWT way of doing it.

Please note: Although the following may seem (overly) complex nothing of it is new when discussion UI development. The only difference between Notes 7.x and earlier and Notes 8 is that some of these aspects now rears their ugly head.

Now lets get to it…

Since only one thread can access the display and hence draw on the screen at any one time, requests to the display needs to be serialized. In Notes 8 and SWT this is done using the Eclipse Job API. This is done by encapsulating a piece of functionality and asking the platform (the “scheduler”) to execute it. The scheduler adds the job to a queue and and execute it once it is its turn. This may not happen right away though it mostly will.

To display stuff in the UI you use an UIJob instance as shown below. This example simply shows a messagebox with some static content.

new UIJob("Rectangle") {
   public IStatus runInUIThread(IProgressMonitor arg0) {
      MessageDialog.openInformation(
         this.getDisplay().getActiveShell(),
         "HelloWorld", "Hello SWT Job API World");
      return Status.OK_STATUS;
   }
}.schedule();

The second example will show you how to display some Notes data. Since access to the Notes API must be run in a specially initialized thread (remember NotesThread.sinitThread?) you have two options:

  • Manually initialize a thread using NotesThread / extend NotesThread.
  • Take the easy route and use NotesJob.

Using NotesJob is by far the easiest and will handle all the dirty details for you. When you do this you can also use the NotesPlatform class which is an (undocumented) way of getting a lotus.domino.Session instance inside Notes 8.

Using NotesJob will take care of getting at the data – to display it in the UI you still need an UIJob which is why I use two job instances in the example below. Since you can only access final variables from within inner classes I mark the name variable as final.

new NotesJob("Show messagebox") {
   protected IStatus runInNotesThread(IProgressMonitor arg0) throws NotesException {
      Session session = NotesPlatform.getInstance().getSession();
      Name n = session.createName(session.getUserName());
      final String name = n.getAbbreviated();
      new UIJob("My UI job") {
         public IStatus runInUIThread(IProgressMonitor arg0) {
            MessageDialog.openInformation(
               this.getDisplay().getActiveShell(),
               "Username", "Username: " + name);
            return Status.OK_STATUS;
         }
      }.schedule();
      return Status.OK_STATUS;
   }
}.schedule();

I hope this helps you.

Exporting DXL for databases with Java web services

Today I needed to export a database application containing a web service written in Java as DXL. How stupid of me to think that I could do this with only Notes.jar on my build path… Doing such an export will make your code throw java.lang.ClassNotFoundExceptions unless you have the following libraries on your build path:

  • jvm/lib/ext/notes.jar (not much surprise there)
  • jvm/lib/ext/websvc.jar (due to missing lotus.domino.websvc.client.Service)
  • jvm/lib/ext/mail.jar (due to missing java.mail.Multipart from lotus.domino.ws.ServiceContext)
  • jvm/lib/ext/jsdk.jar (due to missing javax.servlet.http.HttpServlet)
  • jvm/lib/xml.jar (due to missing org.apache.xerces.parsers.SAXParser)

The above was found by diagnosing and reading ClassNotFoundExceptions in Eclipse at runtime since ClassNotFoundException is a runtime exception.

Now back to exporting…

Effective API Design presentation by Joshua Bloch

Although from JavaPolis 2005 this is still a very nice presentation by one of the gurus in the field of API design, Joshua Bloch. The presentation runs about 70 minutes but is well worth it.

Summary: “A well-written API can be a great asset to the organization that wrote it and to all that use it. Given the importance of good API design, surprisingly little has been written on the subject. In this talk (recorded at Javapolis), Java library designer Joshua Bloch teaches how to design good APIs, with many examples of what good and bad APIs look like.”

Effective API Design

Discovering Notes 8: Enabling Java 5 source compilation


I’m playing around with Notes 8 to get my bearings on the Gold release and I’m liking it. I’m kind of a Java-nut so I wanted to see if Lotus delivered on their promises to include Java 5 in Notes 8 and they did. Unfortunately the Java API hasn’t been updated for this release but hopefully this will happen in the near future. I know I will certainly stress that it will in the Domino Application Development Design Partner program where I have been fortunately enough to be included (together with Nathan and a fine line of other fine folks).

To test it out I fired up Domino Designer and created an agent to use generics and some autoboxing. Both are highly awaited in the Notes Java world – at least by me – and it will be really nice to have. The test agent code is as follows (generics and autoboxing is highlighted):

import lotus.domino.*;
import java.util.*;

public class JavaAgent extends AgentBase {

   public void NotesMain() {

      try {
         Session session = getSession();
         AgentContext agentContext = session.getAgentContext();

         int size = new Integer(10);
         List<Document> docs = new ArrayList<Document>(size);
         for (Document d : docs) {
            d.getUniversalID();
         }

      } catch(Exception e) {
         e.printStackTrace();
      }
   }
}

To my surprise the above code didn’t compile and gave me the below compile error message.

I tried compiling the same code in Eclipse (using Java 5 source compatibility) and importing the class file as an Imported Java agent which worked fine. Hmmm – binary support but no source support? Last resort – look for clues in the release notes and there you have it! In the section “Installation, migration, upgrade, and configuration informationUpgrade notesNotes/Domino 8 upgrade to JDK (Java Development Kit) 1.5” it states that in order to keep backwards compatibility Java 5 source compilation in Domino Designer is disabled out of the box. To enable it add the following notes.ini variable and restart Notes:

JavaCompilerTarget=1.5

Once this line has been added I was able to compile the above code… 🙂