goo
After publishing one of my recent posts, I noticed a Freudian slip in the way I talked about software standards (emphasis added):
I think of security-related code as [being] responsible for authentication, authorization, encryption, and the complex protocols that the industry has created to simplify them.My initial reaction was to correct this oxymoron, but then I realized that it was a fairly accurate description of many software projects and protocols that I encounter every day. My previous work in WS-Land was a great example of this: things started out simple, but as the specs expanded in order to handle more use cases, it became much harder to provide a simple toolkit for implementing them. Complex problems beget complex protocols, all in the name of simplification.
On the Zero forum there is a discussion about whether or not to include support for the deserialization of JSON data into Java beans. My gut reaction to this - which is based on many years of programming in strongly-typed languages and the belief that context assist is a inalienable right - was that converting JSON objects to beans is a fantastic idea, and that I wouldn't want to be friends with anyone who thought otherwise. Data binding, while complex in many ways, simplifies the even more complex problem of wading through the raw bytes of serialized objects. Right? You have to have principles.
Pat Mueller agrees with this sentiment, comparing a JSON object to a bag of goo, which doesn't sound like something that is easy to debug. If you have any doubts about this, ask a programmer on your team if he thinks his current project could be improved by adding bags to goo to the source - at best you'll get a weird look, and you probably won't be invited to give your opinions on the project anymore. In general, people don't want bags of goo in their source code.
What I could not have predicted was just how much working on Zero has changed my world view, and how much I would waver as I started to think about my experience creating RESTful services with JSON data structures. The more I thought about it, the more I realized how easy it is to get things done with JSON's Java APIs; the JSONObject and JSONArray types are just Maps and Lists, respectively, so if you're unfamiliar with the data flowing in or out of a service, it's easy to learn about it - just dump it to the console! The true nature of any JSON data structure can be determined in one step, without reading any documentation[1]. There is no data binding framework to configure or reflection errors to debug - you get the data in a simple collection of name-value pairs, and that's that. It's made service development a simple affair without the presence of a complex protocol.
But why is it okay to work with bags of goo for my RESTful services while demanding strongly-typed APIs in my other code? I definitely wouldn't want to write JavaScript-style code for all of my projects - it's too frustrating - but I like it for sending packets of data between applications and processing said data in a single module. Once you have to start delegating the data processing to multiple classes or systems, the Map and List usage becomes confusing because the origin of the data is no longer clear to the reader. This is where Pat's bags of goo comment rings true for me - if you're just passing around hash tables from library to library, you've got a debugging nightmare on your hands. For Groovy scripts in Zero, though... it's nice.
The worst part about using a more dynamic, JavaScript-style of coding in Java would be the inevitable move towards something like EMF, which I hate with the hate of a thousand suns. I think that as long as I stick to using simple collections for immediate processing of service I/O and use strongly-typed beans for the rest of my logic and utilities, I can enjoy the magic of JSON without getting lost in some programming black hole.
In conclusion, my thoughts on data binding and type safety aren't as concrete as they once were, and I think that pure JSON objects and other goo-oriented data are great for Zero developers creating RESTful resources. Hopefully Pat and I can still be friends.
[1] You may need docs to find the values of enumerations (if any), but you would have to do that for a bean-based API too.
Labels: narcissism, programming, zero
1 Comments:
Yes, I suppose we can still be on speaking terms.
It's pretty clear to me that binding 'JSON' style objects (maps of arrays of ...) into POJOs has a lot of benefits. In Java. Mainly because accessing things out of a bag of goo involves dealing with a lot of .get() methods, using literal string keys. Gets real yucky, real fast. And the code completion issue.
As you note, in 'dynamic' languages, it's often the case that you don't need to do this; there are more direct ways to access string keyed values (as in JavaScript), or you can always fake it (override methodMissing / doesNotUnderstand / __call__ to catch those undefined accesses).
It hurts sitting on the fence, but there it is, because I can't quite seem to get Java completely out of my life at this point.
There is one thing pushing me towards the 'goo' state though. And that's extendability. It's impossible to dynamically extend a POJO with a new 'field' if I decide I want to add some new attribute at some point in time; I need to change the POJO. But I don't have to change anything if it's a bag of goo; it's just more goo.
October 10, 2007 10:14 PM
Post a Comment
<< Home