Spelunking in Notes 8.5 beta 2
When IBM ships a public beta version, one
of the coolest consequences is that anything that's in the beta is no longer
subject to IBM confidentiality rules. So now that public beta 2 is
out, I can go digging in it and see if some things are publicly exposed
now.
So, this afternoon, I did. And guess what I found?
...\Notes\framework\shared\eclipse\plugins\com.ibm.notes.java.ui_8.5.0.20080822-1349
Hmmmm... wait a minute. That bundle is com.ibm.notes.java.UI?!??!?!
You should, of course, know packages like com.ibm.notes.javaapi, or even the venerated lotus.domino package. But what's this UI stuff? UI is the Achilles' Heel of Java in Notes. You can't put Java code in the UI events in Notes. So what the heck would be in com.ibm.notes.java.ui?
Let's unpack the JAR...
NotesUIField.class
NotesUIView.class
NotesUIWorkspace.class
NotesBEDocument.class
My my! Whatever could that be!?!?!
Of course, there's nothing in the HELP yet that I can find, and there's certainly no Javadoc made available that's obvious. But we can, at least, open the .class files in a standard Java editor and poke around. Let's see some highlights from NotesUIDocument...
public abstract void reload();
public abstract void refreshHideFormulas();
public abstract com.ibm.notes.java.ui.NotesUIField getCurrentField();
public abstract com.ibm.notes.java.ui.NotesBEDocument getDocument();
Or NotesUIField...
public abstract void setText(java.lang.String arg0);
public abstract java.lang.String getName();
It won't surprise you that I know a bit more than guesses about what some of these things do. But until IBM decides to publish details, I really can't do more than invite readers to make some assumptions about what these methods might do. (Please don't try to ask me "off-the-record.")
I encourage you NOT to make too many assumptions about the presence of this bundle in the 8.5 beta. There's a fairly long history of new technologies appearing in Notes even when they're not actually ready. The list of undocumented functions that later became supported is substantial. And I'm sure no one can forget NSFDB2, which went through an entire major release cycle with a status of "technology preview" before achieving officially supported status.
The important point, though, is the presence of this bundle as an indicator of potential direction. If you're looking to prevent decay on your Notes applications, I believe you owe it to yourself to look seriously at how the availability of notes.java.ui might affect your development plans.
Bob Balaban asks about real world use of Lotusscript vs. Javascript vs. Java. Though I don't think it's ever going to be truly deprecated, Lotusscript is a language with a limited lifespan, simply because the rest of the technology industry is going to leave it behind. I'll give a nod to Javascript, but it has no real threading model, and it's never going to have the extent of libraries that are available on Java. It's simply not as extensible as Java.
The one thing you can't do with Java in Notes/Domino that you can do with Lotusscript is execute it from client UI events. IBM is hinting at how it might address that gap.
Make of that what you will.
So, this afternoon, I did. And guess what I found?
...\Notes\framework\shared\eclipse\plugins\com.ibm.notes.java.ui_8.5.0.20080822-1349
Hmmmm... wait a minute. That bundle is com.ibm.notes.java.UI?!??!?!
You should, of course, know packages like com.ibm.notes.javaapi, or even the venerated lotus.domino package. But what's this UI stuff? UI is the Achilles' Heel of Java in Notes. You can't put Java code in the UI events in Notes. So what the heck would be in com.ibm.notes.java.ui?
Let's unpack the JAR...
NotesUIDocument.class
NotesUIField.class
NotesUIView.class
NotesUIWorkspace.class
NotesBEDocument.class
My my! Whatever could that be!?!?!
Of course, there's nothing in the HELP yet that I can find, and there's certainly no Javadoc made available that's obvious. But we can, at least, open the .class files in a standard Java editor and poke around. Let's see some highlights from NotesUIDocument...
public abstract void addEditListener(org.eclipse.swt.widgets.Listener arg0);
public abstract void reload();
public abstract void refreshHideFormulas();
public abstract com.ibm.notes.java.ui.NotesUIField getCurrentField();
public abstract com.ibm.notes.java.ui.NotesBEDocument getDocument();
Or NotesUIField...
public abstract java.lang.String getText();
public abstract void setText(java.lang.String arg0);
public abstract java.lang.String getName();
It won't surprise you that I know a bit more than guesses about what some of these things do. But until IBM decides to publish details, I really can't do more than invite readers to make some assumptions about what these methods might do. (Please don't try to ask me "off-the-record.")
I encourage you NOT to make too many assumptions about the presence of this bundle in the 8.5 beta. There's a fairly long history of new technologies appearing in Notes even when they're not actually ready. The list of undocumented functions that later became supported is substantial. And I'm sure no one can forget NSFDB2, which went through an entire major release cycle with a status of "technology preview" before achieving officially supported status.
The important point, though, is the presence of this bundle as an indicator of potential direction. If you're looking to prevent decay on your Notes applications, I believe you owe it to yourself to look seriously at how the availability of notes.java.ui might affect your development plans.
Bob Balaban asks about real world use of Lotusscript vs. Javascript vs. Java. Though I don't think it's ever going to be truly deprecated, Lotusscript is a language with a limited lifespan, simply because the rest of the technology industry is going to leave it behind. I'll give a nod to Javascript, but it has no real threading model, and it's never going to have the extent of libraries that are available on Java. It's simply not as extensible as Java.
The one thing you can't do with Java in Notes/Domino that you can do with Lotusscript is execute it from client UI events. IBM is hinting at how it might address that gap.
Make of that what you will.




Comments
That is all.
Posted by Tim Tripcony At 10:19:12 PM On 09/07/2008 | - Website - |
At least, not by choice.
Posted by Nathan T. Freeman At 10:43:25 PM On 09/07/2008 | - Website - |
True for the language but when running on the JVM, Javascript can use Java's threads and abstractions.
{ Link }
Posted by Dan Sickles At 01:07:17 AM On 09/08/2008 | - Website - |
var authorName = entry.getDocument().getItemValueString("FromId");
var bleedYellowKey = database.getView("(locateProfile)").getDocumentByKey(authorName).getItemValueString("BleedYellowProfileKey");
var logDoc = database.createDocument();
logDoc.replaceItemValue("Form","Memo");
logDoc.replaceItemValue("Subject",authorName + " - " + bleedYellowKey);
logDoc.send(false, "postmaster@timtripcony.com");
return '<img width="32" height="32" src="{ Link } + bleedYellowKey + '" />';
Yes, that actually works (note to self: time to go clean out my Inbox)... you wouldn't want to do that, of course, but imagine the raw power of actually being able to read, create, modify, and even send documents, all during evaluation of a column value for each document... with (as far as I've seen so far) no discernible performance hit. You can already do primitive forms of this with Formula, of course, but the XSP engine extends this to ridiculous new heights. I can't wait to have this kind of power in the Notes client (hm... for some reason Felicia Day's voice is now singing in my mind about inner joins...).
Posted by Tim Tripcony At 07:57:40 AM On 09/08/2008 | - Website - |
Posted by John Head At 09:09:50 AM On 09/08/2008 | - Website - |
What if you have mostly Notes client apps and your management is interested in web enabling the Notes apps? Seems to me, with all these new goodies, One should wait for 8.5 to be released and stable. Agree?
Posted by Curt Stone At 02:00:48 PM On 09/08/2008 | - Website - |
Now, installing an 8.5 beta server, putting it in an isolated environment, and working to convert your templates to Xpages on that server NOW is a pretty good idea.
Posted by Nathan T. Freeman At 03:17:10 PM On 09/08/2008 | - Website - |
Rock on!
Posted by Curt Stone At 03:34:23 PM On 09/08/2008 | - Website - |
Of course, not all of it (or none of it...) will probably surface to the public but it gives some hints regarding what is possible to do...
Posted by Daniel At 08:29:50 AM On 09/11/2008 | - Website - |