Flexible JAMM Known Problems

This section describes the known problems and limitations of Flexible JAMM. 

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 .

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

This version of Flexible 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 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 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 1.0

Version 1.0 has the same issues that existed in version 0.6.1 and the following new issues:

rJAMM 0.6.1

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

rJAMM 0.5.1

Flexible JAMM Home

James "Bo" Begole
Last modified: Wed Jul 29 18:16:14 EDT