To recap, in the Lotus Notes Talk column, I wrote a succession of articles about Java programming in notes: 6. The development language in Lotus Notes, 8. From LotusScript to Java, 22. Why write Java in xpages? , 31. How to write Java, 42 in the Xpages application. Java for garbage collection in Lotus Notes, and so on. This article continues to talk about Java in the Notes client development.
using Java for Notes interface operations?
Notes as a software and development platform, historically, the overall trend of development is the continuous improvement of programmability. R4 introduced the LotusScript and Java. The Notes platform is run in native (native) code, and it is more portable to write user logic embedded in a scripting language such as LotusScript. But as skilled programmers try to develop more and more complex features, LotusScript's syntax and functionality are always clumsy and unwieldy: lack of support for object-oriented advanced features, inconvenient error handling, and so on. At this point in time, we expect to be able to develop in a more modern and powerful language like Java. The biggest obstacle to this is that the Java class Library contains only notes back-end objects, without front-end objects such as Notesuiworkspace and Notesuidocument, and the Notes user interface cannot be manipulated. This is due to the fact that the notes native code and the virtual machine running the Java agent are in different threads and cannot operate the user interface at the same time. After R8, the Notes client uses the Eclipse platform, the foreground runs a Java graphical user interface program, and the native Notes operation and interface display is still the responsibility of the nlnotes process through the JNI docking Nlnotes.exe running in the background. Because the Java code is already in direct control of the user interface, it is possible and necessary to manipulate the user interface of the notes, and Java's Notes client Notes2.exe itself is doing so. IBM also publishes this API, which is the notes Client Java UI APIs that can be seen in the designer help:
There are projects on openntf that use this API to demonstrate a variety of interface features, from which video can be more visually visible to the API's capabilities.
If you see here, excited, eager to use Java in future development, it is unfortunate that IBM will let you down again. These Java interfaces can only be used for Eclipse plug-in (plugin) development and cannot be used in a common Notes client application, which is the Java proxy, and still cause conflicts between threads. If called in the plug-in, The Java thread of the portal gives the task of the Notes native user interface to Nlnotes.exe, and if called in the proxy, Nlnotes.exe starts the Java proxy, which also passes the user interface's work to Nlnotes.exe, and the user interface will be manipulated in different threads. So for traditional Notes client applications, the old LotusScript is still the main development language.
Debugging a Java Agent
Prior to R8.5, designer's development support for Java was a little better than using a normal text editor, which was completely out of the integrated development environment (IDE). At that time, if you were debugging a Java proxy, you would have to use the so-called two-headed beast Method, which is to write code in a modern Java IDE like Eclipse, writing an entry method in the main class, It is called in the Notesmain method of the agent in notes, and is invoked through the main method of the standard Java application when debugging in Eclipse. After R8.5, the designer ported to the Eclipse platform, the editing of the text code and the attributes of the design element are presented by the Eclipse view, but the changes to the binary design elements, such as the Form view, are still handed to the native Nlnotes.exe. We have reason to think that debugging Java code can be done by eclipse within the designer. This is also true, and the help documentation has detailed steps for debugging the Java agent. This help is somewhat obscure, and the key is to require that the sleep code be written to the agent, which is an extra clumsy formality for debugging, and also makes the code more cumbersome to switch between debugging and production state. Fortunately, this requirement is actually superfluous. Martin Vereecken A clearer step in his blog post debugging Java code in Domino Designer 8.5 or 9. I am following a little translation and collation:
Designer's settings:
1. Add the javaenabledebug=1 parameter to the Notes.ini.
2. Select Menu Tools--> Java debugging Preferences, set the port on the client Agents/applets Line of the dialog box, with the default value of 8701.
3. Restart notes.
Settings for the agent:
1. Open the Java proxy you want to debug, and select compile Java code with debugging information in the Basic column (properties Tab–basics) of the Property tab.
2. Open the main class, such as Javaagent.java. Select Menu Run–debug configurations ..., create a new setting under Remote Java application and set the port number to the number you filled in step 2 above. Click Apply.
To start Debugging:
1. Add breakpoints in the Java Proxy's entry method or where you want to stop.
2. Switch to debug view (Debug Perspective), Menu window--Open perspective to other ...-->debug, or you can switch between different views with the shortcut key ctrl+8.
3. Use the toolbar's icon or menu to start the debug settings you just added, such as run-to-debug configurations-to-javaagent.
4. Start the Java agent.
If everything goes well, you'll see the familiar interface for debugging Java in Eclipse, where the agent stops at the breakpoint.
There are a few noteworthy places to note:
1. The debug settings are for one agent (the current agent is indicated in project settings), and if you want to debug another agent, you will have to build one more setting.
2. The debug settings are temporary and will be lost when you restart the designer.
3. Debugging a Java agent is still not like debugging a standard Java application, but a debugging remote Java program. The principle is that the designer starts listening to port 8701 first, and Eclipse is attached to the Java virtual machine for the specified host and port, which is the notes itself. This process in practice often error, the normal situation there is no manual separation of the virtual machine after debugging, debugging will be error connection. Exception, all settings are correct, the replacement port, the restart notes, and the computer are still not connected.
The Java in the development of the Notes client.
