Flexible JAMM Known Problems

• Replicated Collaboration Transparency
• Platform Independence
• External Resources
• Flexible JAMM Known Issues
• rJAMM 1.0
• rJAMM 0.6.1
• rJAMM 0.5.1

Replicated Collaboration Transparency

Java obviates some of the problems encountered by previous researchers of replicated collaboration transparency: The application environment is the same across hardware platforms (Java Virtual Machine), and all participants have access to application executables (applet class files are delivered via HTTP). Two other aspects of Java help support a replicated architecture. First, because objects encapsulate both data and code, it is possible to replace one object with another that may behave differently than the original (polymorphism). Second, an object persistence mechanism, Java Object Serialization (JOS), part of the Java Core API in version 1.1, allows applets to be copied and transfered to remote participants.

Fundamentally, however, the problem remains that the replicas of the transparently shared application may become inconsistent. If the application depends on the timing of an input or processor speed, replicas on different hosts may reach different states. For example, consider a simple application that increments a counter as fast as it can and displays the counter's current value. Replicas hosted on machines with different processors will likely increment and display the value at different speeds, resulting in different values. While replicated collaboration-aware applications are designed to avoid timing or processor dependencies, single-user applications may contain such dependencies. Our aim for Flexible JAMM is to transparently provide the benefits of replication when feasible.

Platform Independence

In Java 1.1.x and prior, the same font on two different platforms may be rendered differently. This can result in inconsistent state when sharing a Swing component via Flexible JAMM on two different platforms. Figure 1 shows the same text rendered differently on a PC (Figure 1a) and X (Figure 1b). This is not a problem in JDK 1.2, since fonts are rendered in the 100% pure Java 2D Graphics API.

Figure 1a.  Text rendered on a Windows host. The user has double-clicked and selected the word changed.

Figure 1b.  The same text rendered on X. The user's double-click has selected a different word, been, resulting in shared-application inconsistency. The participants' cursor locations are the same in both views; only the text and image positions are different.

The inconsistent rendering only exists for text on different platforms with versions of Java prior to 1.2. Generally, this is only a problem when viewing multiple lines of text, such as in a text editor. It is generally not an issue when the text is a simple label, such as in a button or menu. The problem is completely absent when all participants are using the same platform.

rJAMM 1.0

Modified Swing's DefaultCaret class
I modified Swing's DefautlCaret class slightly. Previously, when text was inserted, the caret would update the scroll position so that the user could see the caret in the scroll window. This was a problem when remote users were inserting text - the local user's scroll position would snap to the local caret whenever a remote user entered text. The modification is to update the scroll position only if the insert is the result of a local key press. Flexible JAMM works without this modification, but this improves the support for collaboration.

rJAMM 0.6.1

JPopupMenu
JPopupMenu in Swing 0.6.1 has a problem similar to that of 0.5.1. However, this version of Flexible JAMM contains an override class that fixes the problem.
Notepad Example
The Notepad Example has been modified as before. Additionally, I have changed the FileDialog to use Swing's JFileChooser.

rJAMM 0.5.1

Harmless NullPointerException
When using Java prior to version 1.1.5, you will see a NullPointerException after initiating sharing. This exception is harmless; the process will continue to execute as if the exception had not occurred. This exception is the result of a fixed known bug #4063321 in the AWT. The bug report says it was fixed in 1.1.4, but it still existed in 1.1.4 and is actually fixed in 1.1.5.

java.lang.NullPointerException
        at java.awt.LightweightDispatcher.retargetMouseEvent(Compiled Code)
        at java.awt.LightweightDispatcher.processMouseEvent(Compiled Code)
        at java.awt.LightweightDispatcher.dispatchEvent(Compiled Code)
        at java.awt.Container.dispatchEventImpl(Compiled Code)
        at java.awt.Window.dispatchEventImpl(Compiled Code)
        at java.awt.Component.dispatchEvent(Compiled Code)
        at java.awt.EventDispatchThread.run(Compiled Code)

Swing Serialization
Swing 0.5.1 is largely serializable, but not completely.  Particularly, anonymous classes used internally as Event Listeners may not implement java.io.Serializable.  Using the java.util.EventListener class in rJAMM/JDK1.1override solves many but not all of these.  The following is an incomplete list of non-Serializable classes in Swing. Use the classes in rJAMM/swingoverride/classes to correct these known cases:
com.sun.java.swing.basic.BasicPopupMenuUI
com.sun.java.swing.text.DefaultHighlighter$HighlightInfo
com.sun.java.swing.text.StringContent$StickyPosition
com.sun.java.swing.text.StringContent$PosRec
com.sun.java.swing.JMenu$WinListener

JPopupMenu
JPopupMenu  itself is serializable, but it also serializes the frame that  contains the menu.  That "parent" frame may not be serializable.  More important, when the JPopupMenu is  un-serialized, the new "parent" will likely not be the same.   Swing said they'd make the  frame transient for the next version.
Detachable Toolbars
The detachable toolbars on Windows are a little more sensitive than on X.  Therefore, it is possible to detach the toolbar  (in Notepad or Stylepad, for example) on the copy of a shared application running on Windows but not on Solaris.  The buttons are still shared.
System Clipboard
1) It is possible for the System clipboards on separate hosts to have different contents.  When the application reads from the System clipboard, the result may be different among replicas  of the shared application.  This inconsistency is because the clipboard is an externality, because it  relies on access to resources external to the portable Java environment.  
2) Bug #  4085183: on Solaris, the  System clipboard is not translated to a Java DataFlavor until a Java window gets input focus.  If the clipboard is set by a process, the contents are not available until the app window gets user focus.   When collaborating, a remote participant may perform a copy operation, but the contents won't be available to the local copy of the application until it gets input focus.  Don't know of a work-around.  The error message is:
java.io.IOException: could not get transfer data
Couldn't get clipboard contents in format: Unicode String
Notepad Example
The Notepad example distributed with Swing 0.5.1 is not completely serializable.  I made the following changes to allow its use in Flexible JAMM:
1. Make the Notepad class and its constructor public.
2. make fileDialog transient.
Stylepad Example
The Stylepad example distributed with Swing 0.5.1 is not completely serializable, and it loads images in a way not supported by most JAR ClassLoaders (at least not by mine).  To make Stylepad work in Flexible JAMM's class loader, I made the following changes:
1. make ColoredSquare implement java.io.Serializable in Stylepad.java
2. In Wonderland.java change icon loading code from:
Icon alice = new ImageIcon(resources.getString("aliceGif"));
 to (for three images):
URL url = getClass().getResource(resources.getString("aliceGif"));
Icon alice = new ImageIcon(url);
Externalities
Externality objects (files, sockets, host names, etc.) are not handled in this version of Flexible JAMM.   If the shared application queries the time (e.g., System.currentTimeMillis()), each copy of the shared component will get a response unique to the host on which it is running.  Future work.