When I started using continuous integration against my own code, the very first results were buggy as expected, a lot of warnings, bugs and minor mistakes. Step by step, I am tailoring my source code in order to satisfy the quality criteria of PMD and Findbugs, but some warnings persist and some of them make me worry about the code quality I am delivering to my customers.

From the controversial analysis results, one specific issue remains unanswered: the exposition of internal representation of mutable objects.

The risks of exposing internal representation of mutable objects

Problem description: imagine you have a class member of type array of bytes, and imagine the public getter method of this field returns a reference to the array. It allows any external code to manipulate the contents of this field without the control of its owner instance (goodbye encapsulation). From the Findbugs' bug descriptions:

EI2: May expose internal representation by incorporating reference to mutable object (EI_EXPOSE_REP2) - This code stores a reference to an externally mutable object into the internal representation of the object. If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.

If such exposition comes from a hand crafted code, you can blame the developer or even use some code quality metric to avoid that kind of risk comes out to the release. But what to do when it comes from an automatic process? Well, that's what happens when you unmarshal base64Binary schema elements with JAXB 2.0.

Compiling your own byte array Trojan

Ok, it can be excess of paranoia, but if you compile a schema containing elements defined as base64Binary, JAXB will compile it as byte[] and give it public access methods, like the example below:

XSD fragment:

    <xsd:complexType name="ImageAttachment">
      <xsd:sequence>
        <xsd:element name="name" type="xsd:string" />
        <xsd:element name="flash" type="xsd:base64Binary"
          mime:expectedContentTypes="application/x-shockwave-flash" />
      </xsd:sequence>
    </xsd:complexType>

    public class ImageAttachment
    {
        protected byte[] flash;
        public byte[] getFlash() {
            return flash;
        }
        public void setFlash(byte[] value) {
            this.flash = ((byte[]) value);
        }
    }

Workaround

Here are the few workarounds I assume reasonable to adopt in such situation:

1. To ignore or to disable this specific Findbugs warning, assuming getters and setters or any other generated code don't need to be checked anyway.
2. Create your own type wrapping the byte array. Humm :( eventually useful, but if you are not following any standards like MIME-types.
3. Use a JAXb customization to change the way the element is marshaled and un-marshaled, forcing the copy of the array contents. It forces you to create custom code, quite boring if you have several mutable objects around, but it seems to be the correct way to go.

So far this is the only one bug pointed by Findbugs over my project, so I prefer to keep the warning alive in in my quality reports, in the hope to find an elegant solution for that. Perhaps you know how to fix that :)