FULL PRODUCT VERSION :
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Noticed on Windows, expected to be platform independent.

A DESCRIPTION OF THE PROBLEM :
The constructor for XMLDecoder was changed in 1.5 so that it did not eagerly read the file. In Java 5 the first call to the read() method initiates the reading of the file instead of the constructor. This cures a number of problems but unfortunately fails in the case where there are no objects in the file - i.e. the file just represents modifications to the owner object.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
javac Test.java
java Test

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Output:

Hello, world
ACTUAL -
No output.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.beans.XMLDecoder;
import java.io.ByteArrayInputStream;

public class Test {
    public static void main(String[] args) throws Exception {
        String s =
                "<java>\n" +
                " <void property=\"owner\">\n" +
                "  <void method=\"println\">\n" +
                "   <string>Hello, world</string>\n" +
                "  </void>\n" +
                " </void>\n" +
                "</java> ";
        XMLDecoder d = new XMLDecoder(new ByteArrayInputStream(s.getBytes()), System.out);
        d.close();
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The change made to XMLDecoder in 1.5 solved a number of problems - so although it caused a major regression it would be good to keep the positive effects. Overriding close() to call the read() function in the case then nothing has been read() retains the advantages of both techniques. To fix in the JDK it would be better to examine the size of the internal buffer of read objects instead of using try/catch. THe fix below seems to be about the best we can do from outside the SDK.

Override close() in XMLDecoder as follows:

    // 1.5 chnages the semantics so as not to call read()
    // This means nothing happens when the file only
    // performs an operation on owner.
    public void close() {
        try {
            readObject();
        } catch(ArrayIndexOutOfBoundsException e) {        }
        super.close();
    }

Release Regression From : 1.4.2_09
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.