Addition of "properties" layer on classmate.

We have a new format, SURF, for which we want to create a marshaling system (like Jackson) for JAX-RS. (We already have reference implementation parsers/serializers in place.) We considered piggy-backing on Jackson to take advantage of the property reflection and annotations (one of our developers, @magnonasc, already communicated with @cowtowncoder on the details), but I think the impedance mismatch is too great and we would wind up rewriting a lot of things. So I’ve pretty much decided we’ll just write everything from scratch (sort of like writing another Jackson, but for SURF).

Libraries such as Jackson, JAXB, XML encode/decode, and the like have several layers:

1. reflection / type discovery
2. property determination with optional annotations
3. actual marshaling (converting object propertis from the instance tree to the format and back)

I have written this stack myself many times over the years (an almost-two-decades old unfinished tutorial article I wrote is slightly amusing in hindsight), but only a few days ago did I realize that I could have been using Introspector to do steps 1 and 2. Then I realized I’d run into trouble with generics, and found this project, https://github.com/FasterXML/java-classmate . And I’ll be glad to use it.

The problem is that ClassMate only handles step 1: using reflection to discover methods and types (albeit resolved as mush as possible with generics). I’ll still need to use those methods to determine which properties (based upon the getter/setter names and annotations) the marshaled object should have. And this is the step where the wheel has been repeated over and over (my code included). Jackson (I assume) has its own code for determining which “properties” exist, based upon the accessor methods and properties. Jackson has its own proprietary annotations (although I see that Jackson can use JAXB annotations as well). This is somewhat of a shame, because really the determination of which properties to ignore, what their names should be, and whether to use methods and/or fields is in large part orthogonal to the actual format being used for marshaling (JSON in the case of Jackson, XML in the case of JAXB).

(A side note: all my historical property determination code would turn getURL()/setURL() into a url property, but just this week reading the JavaBeans specification I see that it prescribes a URL property in this case. I wonder which Jackson would use by default.)

My point of all this is that, rather than integrate step 2 (property determination with annotations) into the SURF marshaling system, I’m going to spin out that layer into a separate project this time so that it could be used by various libraries. That way we would have a consistent way of determining which properties exist for being marshaled (independent of the marshaling format), and a common set of annotations. You could then annotate your POJO one time, and it would work for SURF, JSON, XML, or whatever. (Of course that’s only if Jackson would support these annotations at some point in the future. The other of both our libraries would be sharing a common codebase for property determination and annotations.

So I’m filing this issue to ask what the interest on the Jackson/ClassMate side is for such a small, self-contained library for POJO property determination with an annotation set. It’s something that could be beneficial to both libraries. I’m going to have to write such a thing one way or another (and I’ve already started), but I’d love to collaborate. (On the other hand, if you indicate that ClassMate or another library already has this property determination layer built with a format-agnostic API, that would be even better.) I welcome any thoughts.

[cowtowncoder]

Sounds good – using Bitbucket should be fine. I recall cloning projects from there earlier, and I assume using git should make things pretty similar to github. Happy to help with classmate usage; it does solve generics part at least, and that is something that can be surprisingly complicated to deal with.

I might also be interested in trying out resulting Ploop library with jackson-jr (https://github.com/FasterXML/jackson-jr). It’s an alternative for full Jackson databinding, no annotations, uses Bean Introspector; but based on streaming Jackson parser/generator. It might be fun integration project, with no real legacy requirements.

[garretwilson]

Just FYI I got a chance to come back and start working on this again, so I’ll keep you updated.