Flexible JAMM Known
This section describes the known problems and limitations of Flexible JAMM.
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.
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 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
Version 1.0 has the same issues that existed in version 0.6.1
and the following new issues:
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.
Version 0.6.1 has modified some of the issues that existed in version 0.5.1:
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
The Notepad Example has been modified as before. Additionally, I have changed
the FileDialog to use Swing's JFileChooser.
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.
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 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:
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.
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.
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
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:
Make the Notepad class and its constructor public.
make fileDialog transient.
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:
make ColoredSquare implement java.io.Serializable in Stylepad.java
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);
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
James "Bo" Begole
Last modified: Wed Jul 29 18:16:14 EDT