One of the great features of XStream is its ability for customization of the XML. I began customizing my XML and ran into a slight snag (not a bug, but a snag). I couldn't figure out how to get an enum field to output as an attribute rather than a child element. Example Java class:

class Card {
int val;
Type type;

enum Type {
HEARTS, CLUBS, DIAMONDS, SPADES
}
}

Now let's export it:

void export(List<Card> cards) {
XStream xs = new XStream();
xs.alias("cards", List.class);
xs.alias("card", Card.class);
xs.useAttributeFor("val", int.class);
xs.useAttributeFor("type", Type.class);

System.out.print(xs.toXML(cards));
}

Executing the above code will produce the following XML:

<cards>
<card val="1">
<type>SPADES</type>
</card>
</cards>

As you can see, the type field is not properly used as an attribute like I instructed: xs.useAttributeFor("type", Type.class); The reason? Well, I wasn't sure, so, being the lazy developer I am, I trolled around Google, et. al. to find if someone else had this problem. Nothing. And after a few minutes of poking around in the XStream documentation, I was at a loss. I sent an email describing my problem to the users' mailing list, expecting to wait a day or so for an answer. Supprisingly, I recieved an answer within a few hours, from the project lead himself.

Jörg informed me that attribute converters must be of type SingleValueConverter. Attributes are single text values and don't need all of that other object (un)ravelling stuff. Jörg also pointed me to an issue that had been opened in the project's bug tracking system just a few days ago that also described this.

The solution, at the moment, is to simply create a specific converter for my Enum types that is a SingleValueConverter. The code for this is below:

public class SingleValueEnumConverter extends AbstractSingleValueConverter {

private final Class enumType;

public SingleValueEnumConverter(Class type) {
this.enumType = type;
}

public boolean canConvert(Class c) {
return c.equals(enumType);
}

public Object fromString(String value) {
return Enum.valueOf(enumType, value);
}
}

And to modify the XStream example above:

XStream xs = new XStream();
xs.alias("cards", List.class);
xs.alias("card", Card.class);
xs.useAttributeFor("val", int.class);
xs.useAttributeFor("type", Type.class);

xs.registerConverter(new SingleValueEnumConverter(Card.Type.class));

System.out.print(xs.toXML(cards));

And now the XML looks like this:

<cards>
<card val="1" type="SPADES"/>
</cards>

So as you can see, this was exactly what I needed. I love coding in a world where we have such a large community of people willing to take a few minutes of their time to guide you in the right direction. Great job XStream!

With a little more testing, I discovered that the issues lied with anti-aliasing and clipping using Graphics2D. Since this issue was purely asthetic, I moved on to more pressing issues. Then, about a week later I got my monthly Tech Tips from Sun. Talk about reading my mind. The Java 2D Trickery - Core Java Technologies Technical Tips contains 2 excellent Java 2D tips. The first one titled Java 2D Soft Clipping was the answer I needed.

After about 5 minutes, the problem was resolved and it now looks great on both platforms. Excellent tip! Well done Chris Campbell! I suggest you check it out and subscribe if you haven't already done so.

Since this is the first article in a series, it really only covers the basics, but it promises even more. Jeff does say that in case you're still not impressed with GridBagLayout, part 3 presents the JGoodies FormLayout alternative, and compares this layout manager with GridBagLayout so you can choose the layout manager that works best for you. I can't wait. People are always telling me to switch to FormLayout, but I've used it in the past and have not looked back. I just did not like dealing with those cryptic configuration strings ("3dlu p d:fill 4f 5u") all the time. I look forward to the 3^rd part of the series.

If your scratching your head over which LayoutManager to use for forms, I would recommend the GridBagLayout. Our old friend.

The layout of the book is extremely easy to follow and reference. The individual concepts are grouped into "Items" and those items are grouped into topics that are the chapters of the book. At the very least, every programmer needs to read the first 18 items. I'll give you a brief example of the power of this book.

Item 7: Obey the general contract when overriding equals

Every Java developer tends to think he/she knows when and how to override the Object.equals method. This item explains the core concepts of the method and when and how to implement it. It's over 10 pages of explanation with code examples. I have used the techniques that Josh explained in almost every class I've written since I read this item. Before I read this book almost all of my equals methods failed to follow the general contract.

I could go on all day, but I know this isn't the place for that, so I really do hope that if you're a Java developer, you will own this book if you don't already. The full table of contents can be seen on the book's site.

I used to be in the Roll Your Own camp when it came to database persistence. I'd create a set of classes roughly separated along table boundaries. Those classes would call the classes in the java.sql package directly. This method seemed to work just fine, but it did take a lot of work to get all the code setup to convert ResultSets to real objects. I actually used that method several times in the past with great success. My only regret is that my internal object model usually mapped exactly to my tables -- meaning that references were often represeted by id's rather than an actual object reference.

As new projects arose, I found myself searching for something better suited to persisting objects from my data model. My next attempt was to use Hibernate. The most attractive feature that Hibernate offered was forced separation of the persistance layer and the Java object model. We eventually got Hibernate up and running and the project was done.

Hibernate left a bad taste in my mouth. It seemed that I spent a *lot* of time learning their object querying language as well as fiddling around with the XML mappings. I would much rather have spent the time adding additional features to the software. I know that one of the most attractive reasons that people use Hibernate is that the underlying database can change without too much effort. Sadly, this feature is flat-out usless to me. I have never once had management come to me and force me to change my DB.

I decided to be a little more drastic on my next project and I went with Prevayler. For those of you not familier with Prevayler: it's an object persistence layer relying on Java's object serialization with added transaction support. I have to say that I was pretty enthusiastic after reading up on Prevayler. Prevayler turned out to be a good fit for that application. My only complaint is that I had to create a boat load of transaction objects. I ended up with 50+ classes that handle the individual transactions within the object model. So basically, if I wanted to change a user's first name, I would create a ModifyUserTransaction passing in the new field values and that would perform the modification. Seemed like a lot of work.

Prevayler also left a sour taste in my mouth. I just hated having a package full of classes that were basically one line-ers. Anyway, it did work and given my previous battle with Hibernate, I was happy to see that no XML configuration files were needed. Also, the objects were all stored as serialized java objects in a snapshot file that could easily have been read by another Java application.

Then came my current project. This time, I'm forced to use an SQL server backend. Mostly due to the fact that we will want to take advantage of the stability and host it in a centralized location. I know that a lot of you would have immediatly jumped for the 3-tier JEE architecture. I, myself, chose to do an old-fashioned client-server application. This application will ultimatly communicate via JDBC to the native protocol for the database.

For this attempt, I've deviced to use the SpringFramework's JDBC API. After much reading this seems like a good choice. I'll let ya'll know how it turns out.

After reading back over this post, I realize that it may have rambled a bit, but I'll leave it as-is. After all, I'm just a lazy programmer.