I learned in JavaOne that the latest version (1.6.0) of VirtualBox has a web service API. Since one of the things I work on is Metro web service toolkit and because I wanted to use VirtualBox as Hudson slaves for better provisioning, this seemed like the obvious choice for my use case.
Now, when I tried VirtualBox WSDL through wscompile, I found that the resulting client interface is nearly unusable. This is because VirtualBox came up with its own OO emulation mechanism on top of plain SOAP, and decided to pass around "object reference" as a string token explicitly. Even worse, this token is just ajava.lang.String, so you totally lose the type safety. You can see this emulation in the following code I took from the user guide:
// in the COM API
result = machine->getName();
// in web service API
result = port.iMachineGetName(machine);
It really smells like the poor C API, and the API discoverability in IDE suffers.
So I was thinking about how to fix this problem for a few days, and eventually discovered that they have their master IDL in the XML format. So I took this and wrote a little Groovy script to generate the Java classes that wraps the bare JAX-WS API into more usable OO API, and packages that up as a jar file for better reuse. With this library, you'll be writing code like this, which is much more like a Java API IMO:
The library depends on JAX-WS (so either you use Java6 or bundle JAX-WS 2.1 implementation as a dependency — I tested this with Metro 1.1.1.)
The library is built by Maven, and I used GMaven to drive CodeModel and generated the wrappers. GMaven lets me do this without writing a separate non-reusable Maven plugin project, so despite the few shortcomings I liked it overall. I think I'll be using it more on other projects.