You can see the thread I found here

The downloads for both the JDK and the associated documentation live here login and go to downloads. You want “Java for Mac OS X Release X” and “Java for Mac OS X Release X Developer documentation”

It then lives in (e.g) /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home

<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.

Thanks to my colleague Tom Czarniecki I have found a solution that appears to be working.

Some googling turned up very little, but mostly points to the JVM being the problem. I had tried updating the Java installed on os x and setting the JDK to be 1.5 which did seem to improve stability but still crashed.

Tom pointed out that Intellij also has a configuration for the JDK version in its config which I updated to be 1.6+ and then switched my JDK back to 1.6 64bit. That was a week ago and not only have I had no crashes, of course the whole experience is smoother under 1.6! woo hoo!

The trick lies in the file

/Applications/IntelliJ IDEA 8.1.3.app/Contents/Info.plist

<key>JVMVersion</key>
<string>1.6*</string>

To Switch JDKs:

/Applications/Utilities/Java/Java Preferences.app

Some other references I found along the way:

http://www.jetbrains.net/devnet/thread/282406

JDK Update:

http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update4.html

To See IntelliJ Log output:

~/Library/Caches/IntelliJIDEA8x/log/

UPDATE:

For Intellij9:

/Users/jim/Library/Logs/IntelliJIdea90/idea.log

(I found this using the activity monitor and then “inspect process” and you can see a list of open files and ports)

IntelliJ stores its plugins here (Thanks to these guys) :

~/Library/Application Support/IntelliJIDEA80

pretty simple ….

private static Logger log = Logger.getLogger(XSDStoreServletParameters.class.getName());

then log.finest(“hello”);

and

if (log.isLoggable(Level.CONFIG)) {

}

etc.

problem is that it doesnt do anything in the websphere process server…

hey ho.

it uses the old commons-logging (apparently called “JCL” these days!)

grrrrrr!

so you do :

private static Log log = LogFactory.getLog(JDBCToXML.class);

then its just like Log4J

the trick is to get Websfear to print it out – it doesnt want to put low level logging to the console.

you can get it to go to a file though and tail that i guess.