Monthly Archives: December 2011

JAXB and interfaces

My readership (hi, both of you) may notice that my previous article on JAXB interfaces has been taken down.?? I did it on purpose, so there.

I had posted it, and I think it was substantially correct.?? Then I started messing with it.

After a few experiments, I managed to leave behind an annotated file that led me to think I was seeing results I actually wasn't seeing.?? That led me to question my own post and to edit and update it twice.?? By the time I realized my mistake, the damage was done, so I took the post down to make sure I didn't further muddy the already polluted JAXB waters out there.

Thanks to Blaise Doughan for a pointer to his own document on working with interfaces and JAXB.

One area I'm still interested in is late binding of implementation classes to interfaces.?? In my project, I have a one-to-one correspondence of implementation to interface, but it is not known which implementation will be used until .ear file packaging time.?? The interface packages don't have compile-time visibility into the implementation packages (if yours do, you're Doing It Wrong), so specifying XmlAdapters with good type information is impossible.?? I can use XmlAdapter<Object, Object> to break the compile-time annotation dependency as recommended in the inscrutable Unofficial JAXB Guide, but that leads to some very funky XML output featuring lots of namespace declarations and things like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
?????? <age>61</age>
?????? <habit xsi:type="habitImplementation" xmlns:xsi="">
?????????????? <name xsi:type="xs:string" xmlns:xs="">Staying up late coding</name>
?????? </habit>
?????? <name xsi:type="xs:string" xmlns:xs="" xmlns:xsi="">Fred</name>

(How come the <name> element needs its type specified?)

I'd like to use the excellent Swiss Army knife approach of @XmlJavaTypeAdapters applied to a file, but I don't actually want to specify this until the moment when I'm packing up my .ear file.?? At that point I will know (or can know, anyhow) what single implementation of a hypothetical Person interface, for example, will be used.

I know I'm ignoring lots of complexities and whatnot and surely there are valid reasons why the following is a bad idea, but it all sure would be simpler if it were possible to have the type attribute of @XmlElement take a String, not a Class, and get resolved at runtime.?? After all, how many times does an interface actually have a compile time dependency on its implementation class??? Zero, in almost every case I can think of.

I am currently musing over a nasty but intriguing stew of a Maven plugin, Javassist and programmatically generated package-info.class files to basically produce a big list of XmlAdapter specifications.?? The pro is this should get me exactly what I want.?? The con is this shouldn't be this difficult.