In article <dzdYs.98654$Sq4.71538@newsfe14.iad>,
Arved Sandstrom <asandstrom2@eastlink.ca> wrote:
I just had an epiphany today at work. For years upon years I have used
Java libraries which have grown increasingly cumbersome and finicky and
unreliable to do XML or JSON in a REST context...99 percent of which is
actually super-simple.
The epiphany came when neither Jettison (the default Jersey JSON
library) nor Jackson (which is undoubtedly more modern) could, out of
the box without arcane configuration tweaks, convert a single-item list
into a JSON array. They both just converted the item into a JSON object
and forgot about the array.
Apparently this catches out a lot of people, judging by googling. The
Jackson solutions are many. The point being - leading to my epiphany -
why the hell is this even a problem?
I have probably wasted tens of weeks on the arcana of Jersey, Jackson,
XStream to some extent, JAXB...I'm ditching most all of it. It is an
obstacle.
XStream I actually like for producing and consuming XML. It works
nicely. I'll keep it in the toolbox. But for almost everything I do with
Java REST, there is no call for Jersey (nor Jackson et al. for JSON
(de-)serialization). It's a bunch of extra JARs for no added value.
It occurred to me that for over 90 percent of my POJOs I can write
reliable toJSON() methods that *will not break* and are fully under my
control in a matter of minutes. For anything more I might give
simple-json a whirl - it actually has appealing simplicity.
And Jersey has got to go. Why do we even drink that Kool-Aid? Once
you've got your JSON string a handful of lines of code with an HTTP
client will take care of your REST call. A lot more reliable.
SOAP is a different story. I'm sticking with CXF and JAXB and all that
good stuff for SOAP.
Just an opinion piece. I'm getting tired of bloated APIs and unreliable
JARs that, in their quest to make everything possible, make the simple
things difficult.
A lot of people like to preach open source projects, modern APIs, and
the elegance of abstraction layers. "Don't reinvent the wheel!" they
say. It's all good until it's time to fix bad performance, change a
feature, or track down a strange conflict. The cost of that must be
weighed against the cost of creating a simple custom solution. Some
APIs give you a train, tracks, and train stations when all you wanted
was the wheel.
My experience with Jackson is good except for the documentation sucking.
It's a nicely layered API so you get only the services you need. The
only thing it doesn't handle is large values. Take a look at whether or
not its poor documentation has led to it being used incorrectly.
SOAP is one of the worst widely adopted protocols ever. It makes LDAP
seem sensible. Just say "no."