JAMM Known Problems

This section describes the known problems and limitations of rJAMM. If you find anything not covered in this section, please let me know (begolej@vt.edu). Please include test code that will help me recreate the problem.

Replicated Collaboration Transparency
Platform Independence
rJAMM Known Bugs
- rJAMM 0.6.1
- rJAMM 0.5.1

Replicated Collaboration Transparency

Replicated or semi-replicated architectures are common in collaboration-aware groupware toolkits, primarily because of their lower network bandwidth requirement and flexible support of different collaboration modes. Despite these advantages, researchers have previously deemed replication as unsuitable for collaboration transparency. Researchers have identified several difficulties that must be addressed to maintain consistency among the replicas (See Collaboration Transparency Architectures for a discussion of distributed system architectures).

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 JAMM is to transparently provide the benefits of replication when feasible.

Platform Independence

This version of JAMM takes advantage of the JFC/Swing libraries 100% pure Java platform independence. Because the Swing GUI library does not use the native platform's GUI components, a Swing button on the Windows platform, looks and behaves the same as the same button on X or Macintosh. Unfortunately, there is one exception to Swing's 100% pure Java: Fonts are still platform dependent.

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 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 1a. Windows
PC rendering of text.

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.
Figure 1a. X
rendering of same text.

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 0.6.1

Version 0.6.1 has modified some of the issues that existed in version 0.5.1:

JPopupMenu

JPopupMenu in Swing 0.6.1 has a problem similar to that of 0.5.1. However, this version of rJAMM 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. Solutions for the externality problem are described here.

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 rJAMM:

Make the Notepad class and its constructor public.
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 rJAMM's class loader, I made the following changes:

make ColoredSquare implement java.io.Serializable in Stylepad.java
In Wonderland.java change icon loading code from:

Icon alice = new ImageIcon(resources.getString("aliceGif"));

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 rJAMM. 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.

Top Level JAMM
JAMM Home

James "Bo" Begole

begolej@vt.edu

Last modified: Mon Jan 5 18:14:12 EST