non-random ramble

I was just getting the following output from XStream when trying to serialize an object which has a collection property:

<addresses class="java.util.Arrays$ArrayList">
<a class="address-array">
<address>

It had to step through the code to see what was going on.

The key is in the subtlety of the type of the list that I was putting in there. Notice that actually its not an java.util.ArrayList its actually an inner class of the Arrays, called, happily $ArrayList, so I had been staring at it the whole time and not noticed.

When XStream serializes its doing the following:

        Class actualType = newObj.getClass();
        Class defaultType = mapper.defaultImplementationOf(fieldType);
        if (!actualType.equals(defaultType)) {
            String serializedClassName = mapper.serializedClass(actualType);
            if (!serializedClassName.equals(mapper.serializedClass(defaultType))) {
                String attributeName = mapper.aliasForSystemAttribute(”class”);
                if (attributeName != null) {
                    writer.addAttribute(attributeName, serializedClassName);
                 }
            }
        }

From version 1.3.1 – AbstractReflectionConverter:127

So its asking the mapper what the default implementation of the type is. The type in this case was java.util.List and the default implementation is of course java.util.ArrayList. It is not seeing java.util.Arrays$ArrayList as the same thing and so thinks it needs to specify it.

Now you might be asking, how come I have a strange inner class version of ArrayList ? Well the thing is, I thought I was being clever in the set up of my test data and im using:

       addresses = Arrays.asList(
                new AddressBuilder().addressType(”home”).streetAddress(”1 The street”).build(),
                new AddressBuilder().addressType(”work”).streetAddress(”2 The street”).build(),
                new AddressBuilder().addressType(”holiday”).streetAddress(”3 The street”).build()
        );

To set up my test data. asList does this:

 public static  List asList(T… a) {
	return new ArrayList(a);
    }
    private static class ArrayList extends AbstractList
	implements RandomAccess, java.io.Serializable
    {
        private static final long serialVersionUID = -2764017481108945198L;
	private Object[] a;

Where it uses its own implementation of ArrayList.

Phew, another fun couple of hours spent there.

I just discovered Exploding Pixels’ MacWidgets. Its a beautiful library. Literally just pasted a couple of lines of code into my Java app and now it looks right at home on the os x desktop. I’m running JDK 1.6 on Leopard.

Here is is in action:

And here is the code (its been edited slightly so may not copy and paste, but you get the idea) …

 
        MacUtils.makeWindowLeopardStyle(getRootPane());
 
        UnifiedToolBar toolBar = new UnifiedToolBar();
 
        JButton button = new JButton(”My Button”);
        button.putClientProperty(”JButton.buttonType”, “textured”);
        toolBar.addComponentToLeft(button);
 
        getContentPane().add(toolBar.getComponent(), BorderLayout.NORTH);
 
        BottomBar bottomBar = new BottomBar(BottomBarSize.SMALL);
        bottomBar.addComponentToLeft(MacWidgetFactory.createEmphasizedLabel(” Status”));
 
        getContentPane().add(bottomBar.getComponent(), BorderLayout.SOUTH);
 

I was trying to fix a test that is expecting a date to come back in UTC format.

It was using the XStream ISO8601DateConverter.

It worked fine if you were in the UK timezone, but not in a different timezone.

It hurt my head, so I wrote a test to demonstrate how to make it work.

Which is DateFormattingTest.java here.

I didn’t realise i can do this:

final String[] stringArray = {"string0", "string1", "string2"};

private Map<String, String> nodeValueMap = new HashMap<String, String>();
private Map<String, NodeHandler> nodeHandlers = new HashMap<String, NodeHandler>();

Or

public MyClass() {
    this.nodeValueMap = new HashMap<String, String>();
    this.nodeHandlers = new HashMap<String, NodeHandler>();
}

Well, I think I might have a rule of thumb… If you don’t actually have a constructor, then you should use inline instantiation. As soon as you need to do some more complex logic in the constructor (in the case above I might want to initialise the map with some objects) then move all the initialisers into the constructor ?

i.e. don’t have multiple patterns going on.

As an aside, a quick discussion with Alistair (of how big is my potato fame) reminded me of the fact that you can actually do an instance initialisation like:

{
    this.nodeValueMap = new HashMap<String, String>();
    this.nodeHandlers = new HashMap<String, NodeHandler>();
}

Although what the case for doing so is im not sure, might be nice if you are making a STRUCT kind of object.

Also I didn’t realise that you can declare a class inside a method:

public void doSomething() {
    public class InnerClasss{
        public void sayHello() { System.out.println("hello");}
    }

    InnerClass inst = new InnerClass();
    inst.sayHello();
}

Alistair had used this for testing some reflection code, when he needed some test classes to work with.