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 package-info.java 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:
?????? <habit xsi:type="habitImplementation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
?????????????? <name xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema">Staying up late coding</name>
?????? <name xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">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 package-info.java 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.