16

I am using JAXB to create Java objects from XSD file. I am creating immutable wrappers to conceal objects generated by JAXB (earlier I was updating JAXB objects to implement immutable interface and return interface to client. But realised it is bad to change auto generated classes, hence using wrappers)

Currently I am returning these immutable wrappers to client app. Is there any option so that auto generated classes will be immutable and it will avoid extra work of creating immutable wrappers. Any other approach is encouraged.

  • Thanks
Andremoniy
  • 34,031
  • 20
  • 135
  • 241
niteen22
  • 351
  • 3
  • 13

5 Answers5

33

as of JSR-133 (Java 1.5 dependency) you can use reflection to set uninitialized final variables. so you can init to null in the private constructor and use JAXB + immutable cleanly without any XMLAdapter.

example from https://test.kuali.org/svn/rice/sandbox/immutable-jaxb/ , got this from a comment on Blaise's blog http://blog.bdoughan.com/2010/12/jaxb-and-immutable-objects.html#comment-form_584069422380571931

package blog.immutable;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement(name="customer")
@XmlAccessorType(XmlAccessType.NONE)
public final class Customer {

    @XmlAttribute
    private final String name;

    @XmlElement
    private final Address address;

    @SuppressWarnings("unused")
    private Customer() {
        this(null, null);
    }

    public Customer(String name, Address address) {
        this.name = name;
        this.address = address;
    }

    public String getName() {
        return name;
    }

    public Address getAddress() {
        return address;
    }

}
user2062595
  • 331
  • 3
  • 3
  • 1
    This should be marked as the best answer, it saves us on writing an adapter class and a mapped class for each immutable object, a very light-weight solution. Thank you! – Nicole Finnie Feb 08 '18 at 22:13
10

You can use these XJC compiler plugins to directly generate immutable classes:

Michal Sabo
  • 623
  • 7
  • 10
2

JAXB can work with non-public constructors/methods, so the only feasible approach would be to have the no-arg constructor and setters protected, ending up with "pseudo-immutable" objects.

I choose this approach every time I manually write the JAXB-annotated classes, but you can check whether this is possible also for generated code.

Costi Ciudatu
  • 37,042
  • 7
  • 56
  • 92
1

Based on this blog post http://blog.bdoughan.com/2010/12/jaxb-and-immutable-objects.html by Blaise Doughan (who knows a lot about JAXB), looks like there's no native support for immutable objects, so your wrapper objects are necessary.

artbristol
  • 32,010
  • 5
  • 70
  • 103
-3

You can create a Proxy for your beans just before returning them to the client. You will need javassist to create Proxies from classes (create proxies from interfaces can be done with Java SE directly).

Then, you can throw an exception if methods starting with "set" are invoked.

Here is a reusable class with a method that can wrap "any" POJO:

import java.lang.reflect.Method;

import javassist.util.proxy.MethodFilter;
import javassist.util.proxy.MethodHandler;
import javassist.util.proxy.Proxy;
import javassist.util.proxy.ProxyFactory;

public class Utils {

 public static <C> C createInmutableBean(Class<C> clazz, final C instance)
        throws InstantiationException, IllegalAccessException {
    if (!clazz.isAssignableFrom(instance.getClass())) {
        throw new IllegalArgumentException("given instance of class "
                + instance.getClass() + " is not a subclass of " + clazz);
    }
    ProxyFactory f = new ProxyFactory();
    f.setSuperclass(clazz);
    f.setFilter(new MethodFilter() {
        public boolean isHandled(Method m) {
            // ignore finalize()
            return !m.getName().equals("finalize");
        }
    });
    Class c = f.createClass();
    MethodHandler mi = new MethodHandler() {
        public Object invoke(Object self, Method m, Method proceed,
                Object[] args) throws Throwable {
            if (m.getName().startsWith("set")) {
                throw new RuntimeException("this bean is inmutable!");
            }

            return m.invoke(instance, args); // execute the original method
                                                // over the instance
        }
    };
    C proxy = (C) c.newInstance();

    ((Proxy) proxy).setHandler(mi);
    return (C) proxy;
 }
}

And here is an example code. Let Employee be your bean:

public class Employee{
  private String name="John";
  private String surname="Smith";
  public String getName() {
    return name;
  }
  public void setName(String name) {
    this.name = name;
  }
  public String getSurname() {
    return surname;
  }
  public void setSurname(String surname) {
    this.surname = surname;
  }
};

And here a test case showing that you can create a proxy for a POJO, use its getters, but you can't use its setters

@Test
public void testProxy() throws InstantiationException, IllegalAccessException{
    Employee aBean = new Employee();

    //I can modify the bean
    aBean.setName("Obi-Wan");
    aBean.setSurname("Kenobi");

    //create the protected java bean with the generic utility
    Employee protectedBean = Utils.createInmutableBean(Employee.class, aBean);

    //I can read
    System.out.println("Name: "+protectedBean.getName());
    System.out.println("Name: "+protectedBean.getSurname());

    //but I can't modify
    try{
        protectedBean.setName("Luke");
        protectedBean.setSurname("Skywalker");
        throw new RuntimeException("The test should not have reached this line!");
    }catch(Exception e){
        //I should be here
        System.out.println("The exception was expected! The bean should not be modified (exception message: "+e.getMessage()+")");
        assertEquals("Obi-Wan", protectedBean.getName());
        assertEquals("Kenobi", protectedBean.getSurname());
    }
}
lipido
  • 66
  • 3
  • 7
    This is the worst idea humanity has ever conceived. How exactly is this going to be of benefit to anyone? Who wants classes that unexpectedly throw runtime exceptions? What the original poster wanted was immutable classes by design, not by FUD. – DeejUK Jul 17 '13 at 13:04
  • I agree with you. Hidding the setters statically would be a better solution. My solution tries to create wrappers without changing the generated beans and without need to write more code. In addition, you could have seen such bad idea in the Standard Java API: http://docs.oracle.com/javase/6/docs/api/java/util/Collections.html#unmodifiableList(java.util.List), or in the Google Collections API: https://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/ImmutableList.html#set(int, E) Both of these throwing runtime exceptions. – lipido Jul 23 '13 at 14:33