[Editor's Note: To learn more about Java integration within Notes, check out the discussion with Matt in the Developer Spotlight.]
Notes developers are hard at work on projects to integrate a variety of Java-related technologies into Domino and Notes. This includes enhanced support for JavaBeans, development of an onboard Java development environment (IDE), beefing up of the security model and more. We talked recently with Matt Siess and asked him to give us a look at Java's emerging role within Notes.
Matt, what projects are you working on to bring Java-related technologies into upcoming versions of Notes?
Most recently, I was heavily involved in providing Java applet support for the 4.6 release. Now, we are working to deliver enhanced support for JavaBeans in the Domino 5.0 time frame. This support will allow developers to insert Beans into Notes forms and documents the same way you can insert applets in 4.6. You'll be able to edit design-time properties of Beans, as well as change design-time properties and save those changes. Developers will also be able to connect Beans together so that an event in one Bean could cause an event to be fired in another Bean.
Beans are certainly "in the news" but how, technically, do you define a Bean?
There are a few technical characteristics of Beans. For example, a Bean typically supports serialization. Also, a Bean needs to have a constructor that takes no arguments so that tools can create Beans without knowing anything about them other than their class name. However, the most useful aspect of Beans is the ability to manipulate them from the outside (that is, visually) in a builder tool. One of the ways Bean developers do this is by having their properties and events conform to a set of design-time naming conventions that allow introspection to occur.
What's introspection, and how does it relate to Notes?
Introspection is a feature that was added by Sun Microsystems into Java 1.1. Using introspection, the environment can determine what properties a Bean has. For instance, if your Bean has a "getColor" method and a "setColor" method, the system can assume you have a property named "Color" and take action appropriately. Bean developers can also override introspection and explicitly tell the builder tools what properties are available so that a Bean can have properties that are manipulated internally, but that are not exposed to builder tools.
A number of visual third-party builder tools already exist to help you wire components together without a lot of programming. These include Lotus' BeanMachine and others like Visual Cafe, JBuilder and Visual Age. We hope 5.0 will make it possible to do some of the things that these builder tools provide within Notes itself.
Builder tools provide property sheets to inspect or set properties. Or, a Bean developer can create custom property sheets if that is a better solution. For example, if you have a Bean that does a lot of work with color, the builder tool's default color editor may simply provide edit controls to set the red-green-blue values. A Bean developer could write their own customizer to create a palette for picking among a wide range of colors.
It will also be possible to serialize Beans into Notes. Serialization is a process where a piece of Java code can write out all of its data into a form that can be read back in later. Any setting of those variables will be reinstated to the point of serialization.
I want to ask you more questions about serialization and Java technical details later. Sticking for now with the big picture, how does support for JavaBeans interact with existing support for Java applets? How do both relate to the use of ActiveX components?
We are planning to support JavaBeans and ActiveX controls at an equivalent level. There are significant similarities between ActiveX and Beans. For instance, they both expose events and properties and both let you program them from the outside in similar ways.
Unlike ActiveX controls, however, Beans can serve as a cross-platform component solution (as Sun says, "write once, use everywhere.") Sun is promoting Beans as the "ubiquitous" component model for browsers, because you can't assume anything about the platform the browser is running on. Some people might also say that Beans are easier to write because the classes provided by Sun do a lot of the work for you. If you only care about Windows, however, ActiveX might be a better solution because you can use the Windows API.
We have put a lot of effort into supporting ActiveX and we will do the same for Beans. However, Beans support the cross-platform, browser-agnostic point of view that we favor, and there are some useful things we can do in the programmability area with Beans since we are providing support for Java as a programming language in Notes (and not C or C++).
Moving on from Beans, how do you see Java support evolving for Notes?
Well, although I'm not working on this personally, we will deploy a Java integrated development environment (IDE) within Notes itself. Using this IDE, developers can write any Java agent directly in Notes. This will include support for debugging in the IDE so you can set breakpoints and look at variables.
The IDE will merge together with the existing Notes IDE to form a common back-end. This way, the IDE itself won't have to know which language it is talking to, whether LotusScript, JavaScript, or Java. Of course, JavaScript is not specifically related to Java, but we expect people who design Web applications to rely on JavaScript as their primary scripting language. We want to include onboard support for JavaScript within the IDE as well.
[For more information on the Java IDE work, see this sidebar "Pete Lyons: Implementing a native Java IDE."]
Stepping back for a moment, how long have you been working with Java? What is your view of it as a programming language?
I have been following Java since it was introduced, of course, but my first serious exposure with it was on the applet project for 4.6.
The first thing I noticed was Java's strong syntax resemblance to C++. Since I had been programming in C++ for many years, I immediately felt comfortable. Java is an incredibly natural language for someone coming at it from that point of view. There are a few techniques you do have to adjust to, such as not having structures or pointers.
You also have to keep in mind the performance aspects when using Java. It's easy to create lots of objects without having to worry about their storage requirements so that you can end up with executable but inefficient Java programs if you don't watch out. We can write efficient Java programs by taking advantage of buffered I/O classes instead of non-buffered ones, using the StringBuffer class (instead of creating a bunch of Strings on the fly) when manipulating strings, and synchronizing code in a more fine-grained way rather than synchronizing on methods. Performance monitors can help developers find performance problems in their Java code.
There are lots of debates raging between Microsoft and Sun about the quality of the class support for Java. Where do you come down on that?
I think it's amazing how many classes Sun has provided for windowing and user interface support. Many times, your primary task is simply to locate a class that already delivers a needed function and integrate it without having to think about the direct development that you were required to do yourself in C++.
Of course, there is no doubt that creating a mature, robust generalized version of Java for delivery across platforms is going to be somewhat inefficient in its first few attempts. It's more important at the moment that a Java program works on all platforms than it is for it to run efficiently on a particular platform. But everyone in the Java community is highly motivated to wring out those inefficiencies and I expect that to happen, providing people are willing to cooperate.
If you imagine yourself "looking back" from a point five or ten years in the future, where will Java's most significant contributions be made?
While developers will certainly write complete Java applications for particular platforms, I don't think the main activity is going to be application development specifically for Windows or the Mac. I very much like the model developed for the Kona applications. The real focus there is support for a network computer architecture. I know there are still doubts about that, but I believe there is going to be a very big market for network computers and that is where Java will really shine.
It's amazing how quickly everything has been moving, but it will take a couple of iterations before everyone gets it right with network computers. There are so many advantages to plugging your machine in and everything just works because you're attached to the network. They certainly won't replace personal computers as we know them, but businesses will be asking themselves, "Will a network computer satisfy this need?" If so, why not adopt them?
I also see a lot of continuing value in being able to write components such as Java applets and Beans that can be embedded into other programs. These are easy to write and are already being hosted successfully in many applications. More and more applications will function as containers for Beans, including Notes, of course. So, I think widespread use of Bean-related tools is not only here to stay, but will expand greatly over the coming years.
Could you define a "Kona" applet for us?
Kona applets are productivity applets designed for situations where you would otherwise use a word processor, spreadsheet or the like. The difference is that Kona applets are smaller, pared down, and easier to learn.
Keep in mind this is my view as someone not in that group, but my sense is that the Kona developers look at what they've done in two different ways. The first goal was to create applications suitable for network computers. The other goal was to develop them as components that can be dropped into other applications. For instance, you might want to use the word processing component in an application where you want to be able to display and edit HTML.
Does the design trade-off between applications and components compromise the Kona project in any way? Corel has abandoned their original Java productivity applications based on fears about size and performance limitations.
I think you can create useful components and applications at the same time. For instance, Internet Explorer can be viewed as just a bunch of components that were put together to make a browser, but Microsoft did a great job of integrating those components as well as exposing them individually for developers to use. Kona has been faced with the same challenge of coming up with smaller, reusable pieces that are useful when assembled, but that also have enough behavior as components to be useful on their own.
I feel Kona will be ground-breaking in delivering applets that are actually valuable to the corporate world. These aren't tic-tac-toe or "bouncing head" applets. The Kona people seem to have thought about this from the ground up, rather than viewing it as a port of 1-2-3, for instance. They are trying to make it small, in the best sense, by limiting functionality and enhancing performance.
One of the things that will help, at least in the network computer world, is that they are getting a lot of direct support from network computer manufacturers for prototyping and testing. They've been able to ask questions like, "What the heck is going on here. Why is this so slow?" They have actually been able to see performance problems as they emerge on the hardware and get the manufacturers to fix them.
Do you feel that Notes developers should invest the time to learn Java for themselves or will JavaBeans meet their needs as it stands?
That's an interesting question. I think developers always get into situations where they need to break out of the closed box of what a particular builder tool can do. Builder tools can generate lots of Java code for you, but there will be cases where you will need to write some Java code to get the results required for a given application. Also, since Notes provides support for Java agents as well as for applets and Beans, it would probably be worth the time to take a look at what Java can offer.
I would recommend that either a developer or some of their people train in Java, because I think it's going to be a useful skill. Sun provides Java courses, and I'm sure many other training companies do, too. There are tons of Java books out. The JavaSoft web site (www.javasoft.com) has online documentation, specs and white papers.
What is your sense of the learning curve this will take for someone who is comfortable with Visual Basic and LotusScript?
There are at least two different aspects involved in learning Java. First, you have to learn the syntax of the language itself. I don't know how hard this will be for people who don't know C++, but my guess is that it's an initial hump only. Java is not an obscure language.
The other learning curve requires you to master or at least know how to maneuver among the large number of classes that are provided for you. It becomes much easier to program in Java when you know how to use those classes effectively. This is a gradual learning process, but it doesn't mean that you can't develop good applications until you've mastered all of the Java classes.
One of the things that is really interesting and helpful about the Java movement is that everyone seems willing to share code. It is fairly easy to find code that someone has done, look at it, modify it and use it. Good sites to check out include "www.javasoft.com" and "www.gamelan.com" on the Web.
I'm not entirely sure why the willingness to share Java code has happened, but it may partly be because Java has come out of Sun. Sun has clearly recognized the importance of making the tools and the knowledge, including Java examples, readily available to developers.
And, their definition of "who a developer is" covers a lot of ground, because they're supporting everything from smartcards to network computers. There is a lot of Java code and lore that Sun has intentionally exposed to many different types of developers. I think everybody has just picked up from there. The general attitude is, "Hey, I may not be doing the greatest things that can be done in Java, but here are some little snippets of code that you may be able to learn something from -- take a look." When you multiply this hundreds or thousands of times, it makes learning and using Java a lot easier for everybody, whether they're a beginner or a serious user.
We read in the press that a number of developers complain that they are being forced to maintain two entirely different Java versions for their applications. Is this true and, if so, should it affect developer strategies when it comes to using Java and Notes together?
No question, there is certainly a need for resolving issues in dispute about the Java virtual machine (VM). Technically, the VM is simply the piece of code that executes the Java byte codes. People usually fiddle with this only if they need to add support for something their tool needs (like debugging). The other area that people modify is for beefing up the native platform support (such as the windowing system).
It's not that vendors are trying to make the virtual machine better to compete directly with Sun, though Microsoft does fall into that category, of course. It's more that people deliver different VMs to get things to work. In other words, this is primarily about bug fixes from the vendor perspective.
For instance, we're shipping the 1.1.1 version of the VM. This may not have the bug fixes you need, although we avoided making any changes to the VM at all, (except for a fix to get around a bug introduced in an NT service pack.) In general, if an applet doesn't work in the 1.1.1 JDK applet viewer, it won't work in Notes. But if it does work, it may still do something unexpected in someone else's 1.1.1 "compatible browser."
So, the conception that there is one Java is really not true.
There is a push-pull here, since one of the strengths of Java is that you can extend the language by over-riding one or more classes. But, it will be the death of Java if extensions like this become the rule instead of the exception. Everyone is willing to put up with the need to do a little tweaking to get a program to work well on a different platform, but not when you need to maintain two separate versions.
We are trying very hard to do the right thing by Notes users when it comes to Java. It's a strong part of our culture not to force even the most attractive technologies down the throats of users. On the other hand, we are strongly committed to providing Java within Notes at every point where users can leverage its benefits and choose for themselves whether or not they want to use it.
What are some of those other areas within Notes, besides Beans and the IDE, where Java will be available?
Keeping in mind that 5.0 is still out a bit, so things may change somewhat, we do want to solve some of the issues having to do with the security aspect. We will support a flexible but standard method for signing Java code, so you will feel safe allowing your applet to have access to other parts of Notes or to underlying file systems. The end result will probably be a modified sandbox, integrated with the onboard Notes security model. The applet will gain controlled access depending on the rights of the signer.
I think 5.0 will offer very interesting integration with a number of CORBA-related features, though this will evolve over a longer period than 5.0 itself. Right now, 4.6 applets have limited access to the Notes object store.
In the future, developers will be able to write more Notes-specific Java applets. The Notes client will have stubs that call out to the object request broker (ORB) on the server. Applets will be able to use the Notes Interface Definition Language (IDL) to access object store pieces safely, without compromising security. This will open up exciting new kinds of applications, especially those that pull information out of Notes databases and manipulate this information visually in ways that you can't do in the Notes UI itself.
You talked at the beginning about serialization and other technical aspects of your work on Beans. Could you describe the Java persistence framework and how it relates to managing applets?
Any applet can be serialized because applets are derived from the Component class and the Component class implements a serialized interface. (An "interface" in Java is an abstraction of a set of methods. If your Java code chooses to implement an interface, your code becomes responsible for the implementation.)
The benefit of serialization is that you can save the state of instance variables so that they can be retrieved at some later time. Although you have some measure of control, in general serialization is governed by Sun's default Java implementation. Serialization is extremely important in the context of Bean tool development. By serializing the design-time state of a Bean, any changes made to its exposed properties can be captured and reinstatiated later.
The down side is that serialization, which resembles a memory dump, writes out more data than you need for some purposes -- every variable, every class, all header information and the like. In these cases you might want to use externalization instead. With externalization, the applet or Bean writes out only the data that it is interested in.
The Kona applets implement externalization. Externalization allows the Kona word processor applet to save its data out as a word processing document and the spreadsheet applet to save its data in a 1-2-3 compatible format. This enables us to transport formats and expose data to other tools that want to get at it, like Windows or 1-2-3.
How will serialization be implemented?
Serialized data will get stored in Notes documents as attachments to that document. You will be able to set up your applet so that when the document is saved, the applet will be serialized (or externalized). Later, when you open that document, the applet will be restarted in the same state it was in when you saved the document. When we deliver a component database model, the data could be stored in a document that everyone can see.
This support will certainly be useful for the Kona applets so that their data can be stored inside a Notes document. It will also be useful for any applet that wants to maintain a user's changes, rather than always starting from some predetermined state. Finally, it will be useful for the Bean support we will be providing.
How are these emerging capabilities related to the concept of a container?
To qualify meaningfully as a Bean container, a tool should provide a way to manipulate Beans and their properties and also provide a way to hook their events together so an event that happens in one Bean can cause something useful to happen in another Bean. A user should be able to accomplish this without needing to extend the Bean source code themselves. (Keep in mind that the focus here is on helping application developers here at design-time, not end users during run-time).
Netscape's LiveConnect has offered us a way to use JavaScript to communicate between applets without being forced to change the applet code itself. Beans relieve you of the need to do this via JavaScript. Instead, builder tools write the adapter code for you and generate an applet containing the Beans. Right now, the Bean tools put adapter code within the applets themselves, but they will probably eventually store adapter code as separate class files (maybe as a Bean itself) within a particular page.
Anyway, the container provides a way for the Bean to execute its Java code and, for visual Beans, a place to display themselves. Of course, this is a minimal definition and will not necessarily satisfy users by itself. Remember, the concept of a container is pretty well-known by this point. A Word document can be a container. Bean containers are re-implementing and extending OLE and OCX in rather unrevolutionary ways when all is said and done.
One of the challenges we have in supporting Beans is making it so that documents containing Beans can be rendered and used in similar ways in browsers as well as in Notes itself. Since the support for Beans varies from browser to browser, this will be a factor in deciding what we will be able to provide.
How will shared component databases enhance management of these application types?
The idea here is that you will have a component database to store the type of things that people use over and over again. Images are an example. For instance, the company logo needs to show up on forms, documents, applets, agents or Beans. A component database will contain documents that are analogous to files. Using a document model enables us to continue taking advantage of replication and access control. We can treat them conceptually as if they were part of a file system where one document is equivalent to one file. The company logo can be stored within one of these documents.
We are looking into providing support for component databases in the V5 timeframe, but there are a lot of implementation subtleties. Suppose I have a document that references a component database or document within such a database and then forward that document on to you. Would you be able to get the link? Inherit changes? What if I were to change the company logo and everyone has to be notified of that and get the change?
And, as always, what are the implications for working offline? If a user takes a whole set of documents that may have links to a server database, will all of that be locally replicated?
What are the benefits or trade-offs of relying on replication of applets rather than on locally-stored classes?
Using replication as opposed to local file systems relieves each user of having to do a formal install of some set of Java code. This can be complicated as well as slow, even if most of the burden is managed transparently. Making local replicas for you of a database, including its applets, relieves developers and users of lots of headaches. I don't think there are any negatives to this for the user, only positives.
This is especially true for large corporations, because everything can now be centrally managed. Everyone who needs access to an applet can get it from the database. New versions can be installed simply by changing it in one place. An applet often has a lot of "pieces," such as all of the class files, images and audio files. Having them in a database means that you don't have to worry about whether you can find all of the pieces.
Matt, can you give us some final words on the Java work going on?
If I was going to sum up our work with Java, I would say that Notes developers will be able to move in a very comfortable, flexible way between Notes and Java depending on the needs of their applications. If LotusScript or JavaScript will do the job, fine. If Java is required, all the onboard support needed to make that convenient will be provided.
Our integration of Java capabilities into Domino and Notes will enable developers to retain all the skills they have invested their energy in, while offering them the opportunity to build exciting applications that are completely Java-compliant. In a sense, like always, we will be giving them "just another tool," in this case, Java. In another sense, we are seeing to it that Notes is gradually redesigned so Java technology support isn't bolted on, but is integrated transparently across the environment.
BIOGRAPHY
Matt Siess has been with Iris for 4 years working on various parts of the Notes user interface, including graphics and color palette support and, most recently, support for Java applets. For the Notes 5.0 release, he will be adding support for native GIF and JPEG rendering, providing further improvements to the support for Java applets, and continuing to investigate how best to provide support for JavaBeans in Notes.
Matt holds a BA in mathematics from Carleton College in Minnesota. In his spare time, he enjoys listening to classical music and playing the piano and organ.
Copyright 1998 Iris Associates, Inc. All rights reserved.