Sergey Malenkov's Blog

How to load classes from JAR or ZIP?

I needed to load the classes from the dt.jar archive on the fly. The path to the archive was generated automatically based on the "java.home" system property. The original idea was to use the URLClassLoader, but it could not find classes. I had to write a custom class loader which read an archive and loaded classes on demand. At that instant I realized why the URLClassLoader did not work: I had incorrectly generated the path to the archive and the URLClassLoader for a wonder provided no warning that the archive was not found.

Below is the code of the custom class loader for work with jar- and zip-archives:

public final class ZipClassLoader extends ClassLoader {
    private final ZipFile file;

    public ZipClassLoader(String filename) throws IOException {
        this.file = new ZipFile(filename);
    }

    @Override
    protected Class findClass(String name) throws ClassNotFoundException {
        ZipEntry entry = this.file.getEntry(name.replace('.', '/') + ".class");
        if (entry == null) {
            throw new ClassNotFoundException(name);
        }
        try {
            byte[] array = new byte[1024];
            InputStream in = this.file.getInputStream(entry);
            ByteArrayOutputStream out = new ByteArrayOutputStream(array.length);
            int length = in.read(array);
            while (length > 0) {
                out.write(array, 0, length);
                length = in.read(array);
            }
            return defineClass(name, out.toByteArray(), 0, out.size());
        }
        catch (IOException exception) {
            throw new ClassNotFoundException(name, exception);
        }
    }
}

Note that it is not necessary to cache classes here, because the ClassLoader caches loaded classes automatically. Also you can override the following methods to search resources in the archive:

    @Override
    protected URL findResource(String name) {
        ZipEntry entry = this.file.getEntry(name);
        if (entry == null) {
            return null;
        }
        try {
            return new URL("jar:file:" + this.file.getName() + "!/" + entry.getName());
        }
        catch (MalformedURLException exception) {
            return null;
        }
    }

    @Override
    protected Enumeration findResources(final String name) {
        return new Enumeration() {
            private URL element = findResource(name);

            public boolean hasMoreElements() {
                return this.element != null;
            }

            public URL nextElement() {
                if (this.element != null) {
                    URL element = this.element;
                    this.element = null;
                    return element;
                }
                throw new NoSuchElementException();
            }
        };
    }

Perhaps someone may need it because it slightly faster. But I recommend to use the URLClassLoader which is able to work with remote archives and supports security:

URL[] urls = { new URL("jar:file:" + path + "!/") };
return URLClassLoader.newInstance(urls);

If the classes cannot be loaded, double check the correctness of the path.

It is time to choose Color

I would like to discuss some proposed changes in the JColorChooser component.

At present, the JColorChooser component contains the following default tabs:
* Swatches: the predefined set of colors
* HSB: color selection defined by hue, saturation, and brightness using a diagram
* RGB: color selection defined by its constituents (Red, Green, and Blue) using a slider

My suggestion is to combine the last two tabs into a one. The proposed color selection approach applies the color diagram from the second tab, but enables using several color models: HSV, HSL, RGB, and CMYK.

Test diagram is available for the following L&Fs: system, metal, and motif.

]]> This tab has been developed for the 6552812 CR. However, I think that it is an improper solution to add a new tab which looks exactly the same as a previous one. That is why I decided to combine the HSV and HSL color spaces. Moreover, I added the means to select the RGB color in the same diagram. What do you think about this integration? Do we need several separate tabs for each color model? Do you like the existing RGB tab?

Additionally, I developed CMYK support. However, this model consists of four constituents: cyan, magenta, yellow, and key (black), which are hardly laid out on a 3D diagram. Should I leave it as is, use CMY instead, or it will be better to remove CMYK at all?

Personally, I prefer not to use a slider, because we cannot identify the exact position the slider points to. Applying the Motif L&F we may notice that the slider center does not coincide with line pointer on the extreme values. Do you really need the slider? My new tab fixes rendering of this slider in Windows Vista that is described in the 6579827 CR. However, I would like to remove the slider, because the new component enables mouse selection and possesses an accurate pointer. What kind of pointer would you prefer? Why?

Let's review the design. The above screenshots show different means of color selection on the diagram. While I prefer the large dagger, other reviewers would like to see the current color in the dagger's center. Additionally, I can use a simple circle, as before. What is your choice? Why?

What is your opinion on the joining up the text fields in groups? Would it be better to remove the title border and use a simple label above the first field instead? Should we use the border around the diagram?

New implementation of the diagram rendering uses the BufferedImage class recommended by Java2D team. This technique is considered more stable than implementation of the ImageProducer interface, because it enables us to solve the problem described in the 6417055 CR.

Your feedbacks and comments will be greatly appreciated!

How to veto a property change?

Correct usage of constrained properties seems still remain unclear for many users.

As is the convention in the Java, the IllegalArgumentException is thrown if a method receives illegal arguments which cannot be used to execute the method. However, this approach is not applicable for the set methods, since it is impossible to identify whether all values can be used or not. That is why using the PropertyVetoException is considered the proper solution to identify constrained properties.

With constrained properties, an outside object (either the source bean itself or a listener) can veto a property change.

How the bean can veto a property change?

It is quite simple. The property setter should declare that it throws PropertyVetoException. Let's consider a bean that prohibits setting the negative value of a property:

public class SimpleBean { 
    private int value; 

    public int getValue() { 
        return this.value; 
    } 

    public void setValue(int value) throws PropertyVetoException { 
        if (value < 0) { 
            throw new PropertyVetoException( 
                "the value change rejected", 
                new PropertyChangeEvent(this, "value", this.value, value)); 
        } 
        this.value = value; 
    } 
}

How a listener can veto a property change?

The JavaBeans API provides the event mechanism for handling constrained properties. The VetoableChangeSupport class facilitates creating constrained properties. Also, this class supports adding VetoableChangeListeners, which can veto a property change. Let's add a listener to manage a property change:

public class VetoableBean { 
    private final VetoableChangeSupport vcs = new VetoableChangeSupport(this); 

    public void addVetoableChangeListener(VetoableChangeListener listener) { 
        this.vcs.addVetoableChangeListener(listener); 
    } 

    public void removeVetoableChangeListener(VetoableChangeListener listener) { 
        this.vcs.removeVetoableChangeListener(listener); 
    } 

    private int value; 

    public int getValue() { 
        return this.value; 
    } 

    public void setValue(int value) throws PropertyVetoException { 
        this.vcs.fireVetoableChange("value", this.value, value); 
        this.value = value; 
    } 
}

In this case, the bean examines all listeners. If one throws PropertyVetoException, the property value will not be set. The following example shows the class that vetoes setting the negative value of a property:

private static class Listener implements VetoableChangeListener { 
    public void vetoableChange(PropertyChangeEvent event) throws PropertyVetoException { 
        if (event.getPropertyName().equals("value")) 
            if ((Integer) event.getNewValue() < 0) 
                throw new PropertyVetoException("I object!", event); 
    } 
}

Javadoc specification says: if anyone vetoes the change, then fire a new event reverting everyone to the old value and then rethrow the PropertyVetoException. Some developers consider this event as "undo" event and suppose it useless, because it is hard to distinguish between a normal event and an "undo" event. Actually, this is not so true. Let's modify the Listener class to skip "undo" events:

private static class Listener implements VetoableChangeListener { 
    public void vetoableChange(PropertyChangeEvent event) throws PropertyVetoException { 
        if (!isUndo(event)) 
            if (event.getPropertyName().equals("value")) 
                if ((Integer) event.getNewValue() < 0) 
                    throw new PropertyVetoException("I object!", event); 
    } 

    private static boolean isUndo(PropertyChangeEvent event) { 
        try { 
            return event.getNewValue().equals(getCurrentValue(event)); 
        } catch (Exception exception) { 
            return false; 
        } 
    } 

    private static Object getCurrentValue(PropertyChangeEvent event) throws Exception { 
        Object bean = event.getSource(); 
        String name = event.getPropertyName(); 
        BeanInfo info = Introspector.getBeanInfo(bean.getClass()); 
        for (PropertyDescriptor pd : info.getPropertyDescriptors()) { 
            if (pd.getName().equals(name)) { 
                return pd.getReadMethod().invoke(bean); 
            } 
        } 
        throw new IllegalArgumentException(name); 
    } 
}

This common solution could be optimized for the specific case.

JDK 7 changes the behaviour

Specification mentions that the new event will notify all listeners if the change is rolled back. I disagree with this statement. The "undo" events must be fired only for those listeners, which received and approved the property change event. This functionality is available in JDK7. For example, we have 3 listeners and the second listener vetoes the change. The following event sequence will be generated for this case:

Old behavior in JDK 6:

first listener notified about changing A to B
second listener vetoes changing A to B
first listener notified about changing B to A (undo)
second listener notified about changing B to A (undo)
third listener notified about changing B to A (undo)

New behavior in JDK 7:

first listener notified about changing A to B
second listener vetoes changing A to B
first listener notified about changing B to A (undo)

In other words, the second listener will be not notified, because it vetoed the property change, while the third listener will not be notified, because it simply does not know about the change.

JavaBeans: feature attributes

Lets talk about FeatureDescriptor, the superclass for all other descriptors. It enables to add extra metadata to describe the beans. The builder tool could use such metadata to provide enhanced functionality. You can use the getValue(String) method to retrieve metadata. For example:

BeanInfo info = Introspector.getBeanInfo(JLabel.class);
Object value = info.getBeanDescriptor().getValue("isContainer");
boolean isContainer = (value instanceof Boolean) && (Boolean)value;

The following attributes are supported in JDK. Other beans creators can use their own attributes and support them in own builder tools. See JavaBean BeanInfo Attributes and JavaBeans in JFormDesigner articles for details and examples on how to use attributes.

`isContainer`

The attribute must be a Boolean value in BeanDescriptor. It specifies whether a component is a container or not (a container can have child components).

isContainer was introduced primarily for the Swing library. All Swing components inherit the Container class by design, so for the builder tool we assume that all Swing components are containers. Swing library provides BeanInfo classes with the isContainer attribute to fix this problem.

`containerDelegate`

The attribute must be a String value in BeanDescriptor. It specifies the name of a method to retrieve an actual container for any subcomponents of the bean. This method should not have any parameters and should return an instance of the Container class. For example: JScrollPane.getViewport().

`persistenceDelegate`

The attribute must be a PersistenceDelegate instance in BeanDescriptor. It specifies an instance of a class that can be used to persist the described bean.

By default every bean could be encoded with the DefaultPersistenceDelegate class, howewer, some classes requires special processing. For example, the HashMap object should be encoded, but its content cannot be accessed through a property getter and setter.

`enumerationValues`

The attribute must be an array of Object values in PropertyDescriptor. It specifies a list of valid property values. For each property value, the array must contain three items:

Name — A displayable name for the property value.
Value — The actual property value.
Java Initialization String — A Java code piece used for code generating.

For example, the orientation property of the JSlider class contains the following enumeration values:

new Object[] {
    "horizontal", Integer.valueOf(JSlider.HORIZONTAL), "JSlider.HORIZONTAL",
    "vertical",   Integer.valueOf(JSlider.VERTICAL),   "JSlider.VERTICAL",
}

`transient`

The attribute must be a Boolean value in PropertyDescriptor. It specifies whether the property value should not be persisted and no code should be generated. For example, we should not encode the location property of the Point class to avoid the StackOverflowError.

How to use the @ConstructorProperties annotation

The @ConstructorProperties annotation for constructors was introduced in JDK version 6. This annotation shows how the parameters of annotated constructor correspond to object's properties. The following code snippet shows the get methods of the x and y properties:

public class Point {
    private final int x;
    private final int y;

    @ConstructorProperties({"x", "y"})
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() {
        return this.x;
    }

    public int getY() {
        return this.y;
    }
}

The first parameter of the constructor corresponds to the x property and the second - to the y property. The simplicity of the conception enables a developer to adopt the @ConstructorProperties annotation easily. In particular this technique is applied to the Long-Term Persistence for JavaBeans (LTP) and Java Management Extensions (JMX). Technically, an annotation is used for copying beans with read-only properties. Let's examine the encoding the beans into XML form.

ByteArrayOutputStream stream = new ByteArrayOutputStream();

XMLEncoder encoder = new XMLEncoder(stream);
encoder.writeObject(new Point(10, 20));
encoder.close();

System.out.println(stream);

In JDK version 5 and earlier, the object Point(10, 20) would not be encoded, because DefaultPersistenceDelegate is applied by default. This delegate creates an object copy by using a constructor without parameters. Then values of properties are set by means of the setter methods. In the given example the Point class is immutable: its properties are read only, and it does not have a constructor without parameters. So you need to register a separate persistence delegate each time you are coding such a class. For example:

ByteArrayOutputStream stream = new ByteArrayOutputStream();

XMLEncoder encoder = new XMLEncoder(stream);
encoder.setPersistenceDelegate(Point.class, new DefaultPersistenceDelegate("x", "y"));
encoder.writeObject(new Point(10, 20));
encoder.close();

System.out.println(stream);

However this approach does not work for library classes. There is a convention to create a BeanInfo class in the library and add the persistenceDelegate attribute to BeanDescriptor. The following code snippet illustrates how to apply the block of static initialization of a library class:

import java.beans.DefaultPersistenceDelegate;
import java.beans.Introspector;

public class Point {
    private final int x;
    private final int y;

    static {
        DefaultPersistenceDelegate dpd = new DefaultPersistenceDelegate("x", "y");
        Introspector.getBeanInfo().getBeanDescriptor().setValue("persistenceDelegate", dpd);
    }

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() {
        return this.x;
    }

    public int getY() {
        return this.y;
    }
}

As you see this approach is inconvenient and resource-intensive, because it requires the BeanInfo class to be created. In fact this class may never be needed. Use the @ConstructorProperties annotation to resolve this issue. This annotation enables you to resolve an issue of coding the immutable objects by facilitating the custom persistence delegates registration.

Since the annotation describes the relationship between a constructor parameter and a property, but not an operational logic, it could be applied to other tasks, for example, in JMX technology.

XMLDecoder improvements

I would like to start a discussion about XMLDecoder improvements. Some requests can be found in RFE 4864117. I don't want to discuss improvements of persistence delegation (XMLEncoder) here.

How to read objects

Usually the following code is used to read XML file that represents JavaBeans archive:

public static Object[] readXML( InputStream stream ) {
    List list = new ArrayList();
    XMLDecoder decoder = new XMLDecoder( stream );
    try {
        while ( true ) {
            list.add( decoder.readObject() );
        }
    } catch ( ArrayIndexOutOfBoundsException exception ) {
    } finally {
        decoder.close();
    }
    return list.toArray();
}

This is the right way when you don't know about the amount of objects in JavaBeans archive. Also you can customize it with the class loader, the exception handler and the owner of this decoder. And you should do it every time for each file meant to parse.

I want to suggest the following code:

DocumentHandler handler = new DocumentHandler();
Object[] result1 = handler.parse( new InputSource( stream1 ) );
Object[] result2 = handler.parse( new InputSource( stream2 ) );

In this case you can parse each file with the same handler, so you don't need customize it before each usage. With InputSource you can use not only byte stream (InputStream), but you can use also character stream (Reader) or file name represented by String.

DocumentHandler extends DefaultHandler. So you can use it within your own SAX parser.

How to pass an argument

Each element that appears in the body of the outermost element () is evaluated in the context of the decoder itself. Typically this outer context is used to retrieve the owner of the decoder, which can be set before reading the archive. The owner is a property of the decoder and can be accessed in the usual way:



  
  ...objects go here...

I think this is a bad idea for security reasons. Now it is possible to set any property of XMLDecoder and execute any method. Do not do this below:

So I think that the context of element should be an owner of DocumentHandler. There is no problem with backward incompatibility, because we can set appropriate owner depending of value of class attribute of element.

XMLDecoder was created to read JavaBeans archive generated by XMLEncoder, but some people prefer to create XML manually. In many cases JavaBeans archive contains only one element, that does not use the context. DocumentHandler does not require to use element. For example, the following code


  text

can be replaced with

text

How to use variables

When a graph contains cycles or multiple references to the same object, an identifier must be given to the object so that it can be referred to later. Identifiers are created using the id attribute, which binds a name to the expression value. The identifier has global scope extending from the last argument of the expression to the end of the file. The following expression creates an identifier button1, bound to an instance of JButton class:

Reference is made to named instances by using an idref attribute in the element. The following expression makes reference to a previously defined instance button1:

DocumentHandler allows the programmer to set the value of some variable before parsing and to get the value of some variable after parsing. Also you can parse some XML files by the same instance of DocumentHandler. The same variable can be used in all parsed XML files. For example:

DocumentHandler handler = new DocumentHandler();
handler.setVariable("input1", "example");
handler.parse( new InputSource( stream1 ) );
handler.setVariable("input2", handler.getVariable( "output1" ));
handler.parse( new InputSource( stream2 ) );

This is a way to pass many arguments to parser.

How to add own elements

XMLDecoder parses all elements and attributes in one method. It is very complex and hard to maintain. DocumentHandler uses separate ElementHandlers for each element. Such mechanism allows the programmer to create new elements easily. For example, the test application adds 4 custom elements:

DocumentHandler handler = new DocumentHandler();
handler.setElementHandler( "music", handler.getElementHandler( "java" ) );
handler.setElementHandler( "group", GroupElement.class );
handler.setElementHandler( "album", AlbumElement.class );
handler.setElementHandler( "track", TrackElement.class );

The element is a topmost element. It uses the same ElementHandler like the element.
The element specifies the music band. It uses GroupElement class to parse attributes name and home.
The element specifies the album of the music band. It uses AlbumElement class to parse attributes year, name and time.
The element specifies the track of the album. It uses TrackElement class to parse attributes name and time.

Note that it is possible to mix these elements with all basic ones.

How to include another XML file

I am working on this feature now. And I should solve the following issues:

What should I use: element or processing instruction?
1. This way is more flexible. We can use attribute file, idref and others to specify how we should create InputSource for included data.
2. This approach uses only one argument (file name in this case) and you can configure your XML creation tool to support such processing instruction (if it has such a feature).
How I can search file?
It is simple when the file name is given by full path. But I should decide how to find the file by its short name using the system id from InputSource. Note that the system id can be null.

About performance

You can download the following files to test the performance:

performance.jar (142 887 bytes)

This is a test application. It contains the following files to test performance:

music.xml (162 815 bytes): This file contains original data: the list of musical bands, their albums and songs.
music.old.xml (590 765 bytes): This file is generated from the original one by the XSL-transformation by using the file music.old.xslt. It contains a set of XML elements for creation corresponding JavaBeans. This file is compatible with the old XMLDecoder.
music.new.xml (598 833 bytes): This file is generated from the original one by the XSL-transformation by using the file music.new.xslt. It contains a set of commands that are analogue of commands from the file music.old.xml. But this file is optimized to be read by DocumentHandler.

decoder.jar (29 648 bytes)

This is the library needed for the application.

decoder.zip (64 244 bytes)

This file contains documentation for API of the library and supported tags, but it is not completed yet.

performance.zip (37 394 bytes)

This file contains documentation for API of the application with source code.

Theare are 4 test cases:

XMLDecoder parses music.old.xml:
$ java -jar performance.jar old music.old.xml
DocumentHandler parses music.old.xml:
$ java -jar performance.jar new music.old.xml
DocumentHandler parses music.new.xml:
$ java -jar performance.jar new music.new.xml
DocumentHandler parses music.xml using own ElementHandlers:
$ java -jar performance.jar mod music.xml

The following table contains results of testing (performance is better when time of parsing is less):

case	cold start	hot start
1.	703 ms	406 ms
2.	563 ms	281 ms
3.	484 ms	187 ms
4.	187 ms	31 ms

The result table shows that DocumentHandler has better performance than XMLDecoder on the same data set. Performance is even better when new features of DocumentHandler are used.

Conclusions

We cannot remove XMLDecoder because Java should be backward compatible, but we can rewrite it using DocumentHandler. I recommend to put DocumentHandler into the public domain, because it is much more flexible and usable than old XMLDecoder.

I would appreciate your comments, what else should we add to DocumentHandler? I would like to make it more convenient at all. You can vote for the RFE 4864117 here.

How to encode Type-Safe Enums?

This is a sequel of my first article about Enums encoding.
As you may know, Type-Safe Enums were proposed by Joshua Bloch in Effective Java,
but they are not supported by XMLEncoder. This article describes how to encode them into XML properly.

Let's create a simple Type-Safe Enum with static method to test encoding into XML:

import java.beans.XMLEncoder;
import java.io.ByteArrayOutputStream;

public final class TestEnum {
    public static final TestEnum LEFT = new TestEnum( "move to left" );
    public static final TestEnum RIGHT = new TestEnum( "move to right" );

    private final String info;

    private TestEnum( String name ) {
        this.info = name;
    }

    public String getInfo() {
        return this.info;
    }

    public static void main( String[] args ) {
        ByteArrayOutputStream stream = new ByteArrayOutputStream();

        XMLEncoder encoder = new XMLEncoder( stream );
        encoder.writeObject( TestEnum.LEFT );
        encoder.writeObject( TestEnum.RIGHT );
        encoder.close();

        System.out.println( stream );
    }
}

If the test method is executed it will print the following result:

java.lang.InstantiationException: TestEnum
Continuing ...
java.lang.Exception: XMLEncoder: discarding statement XMLEncoder.writeObject(TestEnum);
Continuing ...
java.lang.InstantiationException: TestEnum
Continuing ...
java.lang.Exception: XMLEncoder: discarding statement XMLEncoder.writeObject(TestEnum);
Continuing ...

As you can see, some exceptions were thrown during encoding and XML does not contain any object.

Let's change the test program. We should create persistence delegate and register it before encoding:

import java.beans.Encoder;
import java.beans.Expression;
import java.beans.PersistenceDelegate;
import java.beans.XMLEncoder;
import java.io.ByteArrayOutputStream;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;

public final class TestEnum {
    public static final TestEnum LEFT = new TestEnum( "move to left" );
    public static final TestEnum RIGHT = new TestEnum( "move to right" );

    private final String info;

    private TestEnum( String name ) {
        this.info = name;
    }

    public String getInfo() {
        return this.info;
    }

    public static void main( String[] args ) {
        ByteArrayOutputStream stream = new ByteArrayOutputStream();

        XMLEncoder encoder = new XMLEncoder( stream );
        encoder.setPersistenceDelegate( TestEnum.class, new TypeSafeEnumPersistenceDelegate() );
        encoder.writeObject( TestEnum.LEFT );
        encoder.writeObject( TestEnum.RIGHT );
        encoder.close();

        System.out.println( stream );
    }
}

class TypeSafeEnumPersistenceDelegate extends PersistenceDelegate {
    protected boolean mutatesTo( Object oldInstance, Object newInstance ) {
        return oldInstance == newInstance;
    }

    protected Expression instantiate( Object oldInstance, Encoder out ) {
        Class type = oldInstance.getClass();
        if ( !Modifier.isPublic( type.getModifiers() ) )
            throw new IllegalArgumentException( "Could not instantiate instance of non-public class: " + oldInstance );

        for ( Field field : type.getFields() ) {
            int mod = field.getModifiers();
            if ( Modifier.isPublic( mod ) && Modifier.isStatic( mod ) && Modifier.isFinal( mod ) && ( type == field.getDeclaringClass() ) ) {
                try {
                    if ( oldInstance == field.get( null ) )
                        return new Expression( oldInstance, field, "get", new Object[]{null} );
                } catch ( IllegalAccessException exception ) {
                    throw new IllegalArgumentException( "Could not get value of the field: " + field, exception );
                }
            }
        }
        throw new IllegalArgumentException( "Could not instantiate value: " + oldInstance );
    }
}

Note that TypeSafeEnumPersistenceDelegate does not depend on concrete class.
So, it is possible to use one instance of such persistence delegate with any class,
that contains public static final fields with the same type,
but it is necessary to register it with this concrete class.

As a result, XML contains both encoded objects:

I have bad news for you: JDK 6 does not support Type-Safe Enum encoding.
It is not so easy to integrate this code into DefaultPersistenceDelegate,
but I think I can do it for JDK 7 (it can affect other classes with public static final fields).
So, you should create custom persistence delegate and register it for your Type-Safe Enum.

How to encode Enums?

As you may know, Enums were introduced in Tiger, but they are not supported by XMLEncoder.
This article describes how to encode them into XML properly.

Let's create a simple Enum with static method to test encoding into XML:

import java.beans.XMLEncoder;
import java.io.ByteArrayOutputStream;

public enum TestEnum {
    LEFT, RIGHT;

    public static void main( String[] args ) {
        ByteArrayOutputStream stream = new ByteArrayOutputStream();

        XMLEncoder encoder = new XMLEncoder( stream );
        encoder.writeObject( TestEnum.LEFT );
        encoder.writeObject( TestEnum.RIGHT );
        encoder.close();

        System.out.println( stream );
    }
}

If the test method is executed it will print the following result:

java.lang.InstantiationException: TestEnum
Continuing ...
java.lang.Exception: XMLEncoder: discarding statement XMLEncoder.writeObject(TestEnum);
Continuing ...
java.lang.InstantiationException: TestEnum
Continuing ...
java.lang.Exception: XMLEncoder: discarding statement XMLEncoder.writeObject(TestEnum);
Continuing ...

As you can see, some exceptions were thrown during encoding and XML does not contain any object.

Let's change the test program. We should create persistence delegate and register it before encoding:

import java.beans.Encoder;
import java.beans.Expression;
import java.beans.PersistenceDelegate;
import java.beans.XMLEncoder;
import java.io.ByteArrayOutputStream;

public enum TestEnum {
    LEFT, RIGHT;

    public static void main( String[] args ) {
        ByteArrayOutputStream stream = new ByteArrayOutputStream();

        XMLEncoder encoder = new XMLEncoder( stream );
        encoder.setPersistenceDelegate( TestEnum.class, new EnumPersistenceDelegate() );
        encoder.writeObject( TestEnum.LEFT );
        encoder.writeObject( TestEnum.RIGHT );
        encoder.close();

        System.out.println( stream );
    }
}

class EnumPersistenceDelegate extends PersistenceDelegate {
    protected boolean mutatesTo( Object oldInstance, Object newInstance ) {
        return oldInstance == newInstance;
    }

    protected Expression instantiate( Object oldInstance, Encoder out ) {
        Enum e = ( Enum )oldInstance;
        return new Expression( e, e.getClass(), "valueOf", new Object[]{e.name()} );
    }
}

Note that EnumPersistenceDelegate does not depend on concrete Enum.
So, it is possible to use one instance of such persistence delegate with any Enum,
but it is necessary to register it with concrete class of required Enum.

As a result, XML contains both encoded objects:



 
  LEFT
 
 
  RIGHT

I have good news for you: JDK 6 already supports Enum encoding.
So, you should not create persistence delegate and register it for your Enum anymore.