Letters to the Editor (April 5, 1999)

In this installment of Letters to the Editor, Merlin Hughes helps a former C++ programmer with Java; Mark Johnson answers several questions about his XML series; Bill Venners receives 'one of the best feedback e-mails' ever about his farewell column; and Bill Day fields Java 3D questions

JavaWorld.com, 04/01/99

Step by Step: 'Reading textual data: Fun with streams' by Merlin Hughes

Read

Porsches, Subarus, and fun with streams

Merlin,

I jumped from C++ to Java several months ago. A question comes to mind when reading your code:

public class UndoReader extends Reader {
  protected static final int INITIAL_UNDO_SIZE = 64;

  protected Reader reader;
  protected int[] buffer;
......
}

My question: Reader is an abstract class, that is, it cannot be instantiated. If so, then how can we use it as a data member?

Jianming Wang

'XML for the absolute beginner' by Mark Johnson

Read

Printing files with XML

Mark,

I read your column this afternoon and found it very educational. I've read a few books on XML, and I think it will be a great standardizing tool to make full-scale applications easily accessible from anywhere -- from custom, system-dependent GUIs, to Web browsers or even future cellular phones.

I'm writing to say I think your article demonstrates, in a rather unexpected way, what XML could do where HTML fails: it allows you to control the placement of your Java code on the page.

Indeed, why not? Readers who don't want to read through the code no longer have to scroll the browser window down page after page and those who want just text can simply scroll the text area.

But what about those who want to print such files? They will, of course, just get the top of the code. With XML and XSL, one could define different ways to display the data on a screen or on a printer. That way, you can receive a full code printout on paper.

But I guess that will come some day.

Nicolas Seigneurin

XML parsers

Mark,

I enjoyed your article, "XML for the Absolute Beginner." I've been searching for C++ parsers for XML. Do you know of any publicly or commercially available C++ class collections for parsing XML?

Stephen Benz

IBM's XMI proposed standard up to snuff?

Mark,

I just wanted to say that I really enjoyed your JavaWorld articles on XML technology. We're using XML fairly extensively on this project as the import/export format between disparate tools. We're looking forward to the day when a standard DTD is in place for UML.

Keep up the great work!

Mike Clark

Design Techniques: 'Farewell to Design Techniques' by Bill Venners

Read

Loose threads? Bill Venners responds

Bill,

I have enjoyed reading your columns. Your farewell column prompted me to review your August 1998 column, "Designing for thread safety." While I believe the article is correct in what it says, I'd like to point out some important omissions.

The article focuses on JVMs running on single processors. It does not ask the user to consider what happens when Java is executed on a multiprocessor machine, especially one with a relaxed memory model.

The Java Memory Model (JMM) was written to accommodate multiprocessors with relaxed memory models. Threads are allowed to cache values, and writes to main memory may be reordered. The JMM is specified in the Java Language Specification (JLS, Chapter 17, "Threads and Locks").

Doug Lea has also written a draft chapter for the next edition of his Concurrent Programming in Java, "Programming to the Java Memory Model":

http://gee.cs.oswego.edu/dl/cpj/jmm.html

According to the current spec, including (according to Doug Lea) any revisions that are expected to occur in the near future, being able to atomically access variables does not guarantee the visibility of those variables (visibility between threads, that is, not the 'scope' kind of visibility), nor the relative order in which variables appear to change. Without synchronization, writes might not happen for a long time, and when they do, they may appear out of order. In the presence of multiple threads, a shared object reference is a fragile thing.

To illustrate, consider the "double-check" idiom for singleton construction:

public class Singleton {
     private static Singleton instance;
     private Object value;
     private Singleton() { /* ... */ }
     public static Singleton getInstance() {
         if (instance == null) {
             synchronized (Singleton.class) {
                 if (instance == null) {
                     instance = new Singleton();
                 }
             }
         }
         return instance;
      }
      public static Object getValue() {
          return getInstance().value;
      }
}

One might think that this was a safe, efficient way to construct an immutable singleton object. Not according to the spec!

Consider this statement:

Object v = Singleton.getValue();

The thread that constructs the singleton may write out the shared reference to the singleton instance before the contents of the singleton are written out. (In this case, "contents" is the reference to value plus the contents of the value object itself.) This means that getValue may see a non-null instance reference, but it may not see the fully constructed contents. The only way to prevent a thread that is accessing the contents of this singleton from seeing transitional values is to synchronize the accessor method on the same lock as the getInstance method. That is, the static getValue method would need to be synchronized too.