Java to WCF Service Error: Two declarations cause a collision in the ObjectFactory class.

I don’t talk about java on here too much, because I avoid it most of the time. I was never a big fan, but concede that it has it’s usefulness. After all: It powers devices of many shapes and sizes, it is platform agnostic, and it has a ton of community support. However, I’ve always found the IDEs to come up short of expectations — Visual Studio set this bar very high. Anyway, it was just recently that I had a good reason to dig into consuming a WCF service from a java client. This foray into the deep dark recesses of JAX had me ranting about the evils of java.

“As a .NET guy, I am convinced that JAVA was spawned in the depths of a cavernous inferno. A place where the pervasive stench, of all things unholy and unclean, consumes all it contacts. A place so vile that the darkness remains unerringly fast, even as the sun illuminates the surrounding lands.” — Me via Facebook

What powerful force could have driven me to such frustration, that I would publicly make such statements? This obscure error message:

[ERROR] Two declarations cause a collision in the ObjectFactory class. Line 1 of file...

The error in and of itself is innocuous enough, two proxy objects are trying to generate with the same name. However, I do not have two objects named the same thing, even if I was foolish enough to create that scenario, C# would not allow it. Perhaps I could have created the collision by assigning data attributes incorrectly. However, since the WSDL came across as a single line, I didn’t have a hint as to where to look.

Eventually I copied the WSDL to a text file, broke it out line by line, and attempted to regenerate the proxies. After this exercise, I finally had something to work with. The two lines were there, but they certainly were not named the same thing, not even close. One was named MailingAddress, the other was named MailingAddressZipCode. What madness is this?

So I popped open my service source to discover the following object definitions (shortened for brevity).

When I realized the problem, I second guessed it. Surely the proxies would not be generated in such a way that they drop scope resolution on the floor. MailingAddress.ZipCode is not the same thing as MailingAddressZipCode. However, the voodoo that JAX employs when generating these proxies fails to care. After a quick renaming of the properties I confirmed this to be true. I renamed the MailingAddress object to PostalAddress, and viola proxy generation succeeded.

So the lesson here is simple. When creating a WCF service, if you expect connectivity from java clients, you must not name classes anything that may potentially clash with a concatenated class + property elsewhere in code.

For a language that runs on so many devices, and has – and has had for so many years – so much potential in the marketplace, it’s things like this that makes me and many other developers run away from java except when it is the only choice. Well this and the fact that an equivalency operator is not valid for string comparison.