Java XML Serializing, Missing fields in file

Question

Hi there this is the issue at hand, when trying to serialize the class below with the code below i'm getting is the below xml file without all the strings in the class.

The Class (some static values have changed but basically it), I left out all the generated get\set but they are all there with public access modifiers.

public class NotificationConfiguration implements Serializable
{
    public static final String PORT_KEY =  "mail.smtp.port";
    public static final String DEFAULT_PORT_VALUE =  "587";
    public static final String TTL_KEY = "mail.smtp.starttls.enable";
    public static final String DEFAULT_TTL_VALUE = "true";
    public static final String AUTH_KEY =  "mail.smtp.auth";
    public static final String DEFAULT_AUTH_VALUE = "true";
    public static final String MAIL_SERVER_KEY = "mail.smtp.host";
    public static final String DEFAULT_MAIL_CLIENT_HOST = "smtp.gmail.com";
    public static final String DEFAULT_MAIL_CLIENT_USERNAME = "*********";
    public static final String DEFAULT_MAIL_CLIENT_PASSWORD = "*********";
    public static final String DEFAULT_MAIL_CLIENT_ADDRESS = "*********";
    public static final String DEFAULT_ADMIN_EMAIL = "*********";
    public static final long DEFAULT_MAIL_INTERVAL = 24*60*60*1000; //One time a day default
    public  static final String SAVED_FOLDER_NAME = "C:\\Library";
    public  static final String SAVED_FILE_NAME = "C:\\Library\\NotificationCfg.xml";

    private String portValue = DEFAULT_PORT_VALUE;
    private String ttlValue = DEFAULT_TTL_VALUE;
    private String authValue  = DEFAULT_AUTH_VALUE;
    private String mailClientHost = DEFAULT_MAIL_CLIENT_HOST;
    private String mailClientUserName = DEFAULT_MAIL_CLIENT_USERNAME;
    private String  mailClientPassword = DEFAULT_MAIL_CLIENT_PASSWORD;
    private String mailClientAddress = DEFAULT_MAIL_CLIENT_ADDRESS;
    private String adminEMail = DEFAULT_ADMIN_EMAIL;
    private boolean overdueSubsNotificationEnabled = false;
    private boolean adminReportNotificationEnabled = false;
    private long mailInterval = 
}

The code used to serialize, which also creates the folder if missing.

public void storeChanges()
{
     try
    {
        try
        {
            File f = new File(NotificationConfiguration.SAVED_FOLDER_NAME);
            f.mkdir();
        }
        catch (Exception e){}
        XMLEncoder encoder = new XMLEncoder( new BufferedOutputStream(new FileOutputStream(NotificationConfiguration.SAVED_FILE_NAME)));
        encoder.writeObject(notificationConfig);
        encoder.close();
        System.out.println(LOG_CONFIGURATION_STORED);
    }
    catch (Exception ex)
    {
        System.out.println(LOG_CONFIGURATION_NOT_STORED + ex.getMessage());
    }
}

The XML file received, with no exceptions thrown while serializing. It basically just has the long value. Thanks in advance falks!

Answer 1

Could that be that only mailInterval has a getter?

Just looked again the question apparently there is getter for all fields so ...

Answer 2

XMLEncoder encodes information about how to restore your object. If field values haven't changed from their defaults, XMLEncoder doesn't store anything.

This can cause confusion.

Hence, my rules of thumb when using XMLEncoder are:
1. don't initialize fields. don't do private String foo = DEFAULT_FOO;
2. don't do anything in the default constructor.
3. have some other method, or factory that will give you a "default" setup if needed.

Answer 3

What is SAVED_FOLDER_NAME ? Is that like a factory object and did you by any chance call setMailInterval on that object?

Answer 4

I highly recommend to read again the XMLEncoder Javadoc I will point out the main differences with the binary serialization we all know.

1. to restore the instance it need the class definition available to the JVM
2. It serializes only the data. And only the modified from default data.
3. As result of the 2 points above - is that there is no reason to serialize Static final values - they are part of the class definition.

The binary serialization on the other hand does serialize the class definition and can load from byte stream a class that was not available to the JVM before.

That is why you got results that you see. It Ok this is behavior by design and you use it right. It seems just not to be what you need. By the way see what Xstream has to offer.