CODEWITHSUNDEEP
javaserialization
rogerdpack
rogerdpack

Reputation: 66771

why does XMLEncoder miss a property?

I have this java class

class Go {

  public boolean isSha1() {
    return true;
  }
  public String getSha1() {
    return this.sha1;
  }
  public String setSha1(String sha1) {
  }
  ...
}

When I attempt to encode it using java's java.beans.XMLEncoder, it outputs it with all properties except sha1. It's like it's skipping a property!

Upvotes: 0

Views: 673

Answers (2)

rogerdpack
rogerdpack

Reputation: 66771

Either this is a bug in the JDK or not (unknown) but the fix/work around for now is to rename isSha1 to something (anything) else. Odd.

Upvotes: 0

erickson
erickson

Reputation: 269707

You aren't following the JavaBeans specification, so don't expect it to handle your arbitrary naming.

JavaBeans says that if it finds a pair of accessors, void setX(Y) and Y getX(), X is identified as a read-write property of type Y. It's specific about the type, Y, being the same in both cases. (The notation is mine, I'm just trying to illustrate in a concrete manner.) If the getX() method is missing, X is a write-only property. If setX(Y) is missing, X is a read-only property.

Properties where the type is boolean have special treatment. If there's a method boolean isX(), it will be used for read access to the property. It's okay if there's a boolean getX() method too, but it won't be utilized.

In your code, setSha1() is ignored by default introspection, because it's called set but takes no argument.

However, you have given the isSha1() and getSha1() different return types, so the introspector can't tell what the type of the sha1 property should be. The behavior here is not defined by the specification. You could probably fix this by providing explicit bean descriptors, but no one does this.

So, the upshot is, don't do this. Follow the conventions given in the specification.

Upvotes: 3

Related Questions