CowTalk

* (or Factory Methods)

1. What's up, Doc?

One of 2 Coolest Features of upcoming Jackson v 1.2 -- and the Top Feature by actual user requests (and Jira user voting) -- is the ability to (finally!) use arbitrary constructors and factory methods a class has, for their intended purpose: constructing bean instances. And specifically, constructing beans without having to mess with setter methods whose sole purpose is to initialize the value.

So, if you have class like:

---

public class Name {
  private final String givenName, familyName;

  public Name(String given, String fam)
  {
   givenName = given;
   familyName = fam;
  }

  public String getGivenName() { return givenName; }
  public String getFamilyName() { return familyName; }
}

---

you can actually use it (almost) as is, without having to add setters and default constructor like you so far have had to:

---

public class Name {
  private String givenName, familyName;

  // Used to have to add these:
  private Name() { }

  void setGiveName(String str) { givenName = str; }
  void setFamilyName(String str) { familyName = str; }
  public String getGivenName() { return givenName; }
  public String getFamilyName() { return familyName; }
}

---

So what is this "almost" part? Well, you do have to decorate the constructor (or factory method) to let Jackson know which constructor/factory method to use (by @JsonCreator); and bind names to parameters (using @JsonProperty), like so

  @JsonCreator
  public Name(@JsonProperty("givenName") String given, @JsonProperty("familyName") String fam)

or, if you prefer factory methods:

  @JsonCreator
  public static Name constructIt(@JsonProperty("givenName") String given, @JsonProperty("familyName") String fam) {
 // construct and return an instance...
  }

and that's it.

My now-resolved earlier pet peeve was the inability to use Jackson with immutable value classes. Not so any more: now you can not only remove the setters, but can also make member fields constructor-assigned and final, i.e. value class immutable.

2. Soap Box Time

Ok now: after demonstrating this new, nifty and long-awaited feature, let's consider why this is a Fundamentally Big Thing.
(ok, I may rant a bit, perhaps even go monologuing a bit. Humor me here)

So: this is Big, because it nicely demonstrates 2 core Jackson Credos:

• Use Your Objects (aka "Have It Your Way")
• Do More (with less)

3. Jackson Credo: Use Your Objects

(aka "Have it Your Way", but that's (tm) by some fast food chain)

This is directly related to those alternative data binding (or object serialization) frameworks that take strict Schema-first approach.
This includes formats like Protocol Buffers.As nifty as these frameworks are for some purposes, they fundamentally want to rule their own sandbox; to the degree that objects to use are "Their Objects, Not Yours" (Tony-principle?). That is: they define Their Objects, using Schema you (have to) provide. And if you play nice, you just might get to borrow Their Objects for your personal temporary use.
But make no mistake, you do NOT get to provide the toys, specifically not Your Objects. It is clear who's the boss.

Jackson, on the other hand, is not that bossy. It lets YOU bring YOUR Objects, and it'll play nicely with them, as per YOUR instructions.

Sounds fair? Good, since we are ready to move to the other Credo.

4. Jackson Credo: Do More (with less)

Up until version 1.1, Jackson has sort of played catch up with other best-of-class data mapping/binding frameworks (and by-passed good many inferior ones, but I digress). But now it is rather close to true feature parity.

Good mature frameworks like JAXB are reasonably feature-filled. But one benefit Jackson has, specifically wrt. JAXB, is that the data format it uses (JSON) is simpler. Simplicity has many benefits, but the main thing is that it allows one to quickly solve the "simple" parts (parsing, writing) -- without sacrificing other important parts like API simplicity and performance -- and then move on to more advanced (and arguably more value-additive) features.

I claim that if it wasn't for complexities of XML (or, worse, complexities of XML Schema). JAXB might be much more full-featured. In fact, it seems little odd that it does not yet allow you to BYOC doesn't it? But considering scope of what has already been (it is a HUGE undertaking, akin to building a cathedral), it would be unfair to blame its creators. At some point you have done enough and move on. I gather that point was reached at some point in the past. So with all the usefulness, project is realistically in maintenance mode: good, stable, but not going anywhere fast.

But the important point here is that this point has not at all been reached with Jackson; nor is it likely to be reached any time soon. In fact, there is a boatload of New Features to consider for many new releases; and solid plan to get there; to develop new useful things, and have some fun along the way. We plan to enjoy the ride, so hang on loosely and enjoy the new scenery.

Oh, and the "with less" part is mostly meant to related to YOU having to do less; but it also applies to part of JSON itself providing less, but perhaps counter-intuitively making the whole package offer much more. I think there's some fundamentally neat principle hidden down there; but that's, as they, another story.

5. Next Up: Mix-in Annotations

Ok; and after introducing this allegedly cool new feature, be prepared to get your mind blown with next entry: we will be visiting the Feature Known as "Mix-in Annotations". Stay tuned!

Posted by Tatu Saloranta at Monday, July 27, 2009 11:57 PM
Categories: Java, JSON
| Permalink |Comments | links to this post