JSR-170: More inmates running the asylum

It’s nice to see that some things never change. The astounding incompetence of some of the JSR expert groups has become a comforting fact in this ever-changing landscape.

Today’s life-affirming group of inspirational thought leaders comes to us by way of JSR-170, the content management JSR.

The one obvious thing about this JSR is that all the vendors have come together and managed to somehow compile a list of the worst things from each of their products. The loving touch of Vignette is there to be derided and laughed at, while IBM’s bludgeoning idiocy works hard to highlight its presence.

Where does one start? Well, let’s focus on the API, since there’s plenty of ammo there. We have a delightful ‘util’ package. This package contains one class: ISO8601. As everyone knows, it’s vital for a content management system to have a quick and easy way to deal with ISO8601 compliant date forms. The need is so great, in fact, that it’s worth shipping a class to do this in the specification, rather than allow vendors or users to write those tedious 3 lines to do it in.

Of course, the true sign of an expert group desperate to make its mark is the rampant disregard for any built-in classes and exceptions in Java. So for example, we have the delightful ‘javax.jcr.UnsupportedRepositoryOperationException’ and the even cuter ‘javax.jcr.InvalidSerializedDataException’. Having said that, why settle for duplicating existing exceptions, when you duplicate whole API’s too? Witness the infinite hours of fun that can be had with javax.jcr.access.Permission!

To you aspiring EG members, if you think you’ve gone the whole way now, you’re sadly mistaken. The final salt-in-the-gaping-wound to be delivered to your poor unsuspecting audience is badly named classes. This way you can ensure you’ve fucked them in every possible way. This JSR provides this killing blow by way of ‘javax.jcr.nodetype.PropertyDef’.

Now that the group has discharged its ‘every JSR must ignore real world java usage and the core API’ duties, they can start to have fun. To distinguish themselves from other JSR’s that cause your average JSR eye bleedage, these guys really pulled out all the stops. They hit us with javax.jcr.StringIterator, javax.jcr.query.QueryResultIterator, and javax.jcr.query.QueryLanguage.

All in all, an impressive JSR. Roundly beats many many others in terms of unusability. Its downfall however is that it doesn’t quite manage to beat the servlet spec in the ‘mix implementation and spec’ category, where it has reigned supreme ever since its inception. A valiant attempt though.

14 Responses to “JSR-170: More inmates running the asylum”

  1. Jonathan Feinberg Says:

    It is downfall? It is? Run for the hills! JSR-170 is downfall!

  2. F.Baube Says:

    It’s not that horrible. The writing is very clear, and the versioning model looks workable, and they seem to be aware that the whole node/property model is so uber-generalized and open-ended that they’re not quite sure how it all might play out.
    I’ve already written an implementation of a subset, and it came together pretty quickly.
    What I’m more concerned is that when it comes to the topic of how to handle multiple concurrent changes to an item, and validate and write out a Ticket, there’s a lot of hand-waving and “something cool happens”. And access control? Oh, that’s someone else’s problem.
    All in all, the API is pretty modest.

  3. Rampant Clown Says:

    > It is downfall?
    He actually said “Its” … not “It’s”. “Its” is a possessive, whereas “It’s” is the contracted form of “It is”. End of English lesson ;-)

  4. Todd Breiholz Says:

    The think I first noticed about this JSR is the potential acronym from the front page of the spec:

    Content Repository API for Java

    CRAPI!

  5. chloe Says:

    The bile blog feels somehow incomplete without a reference to someone (anyone, please) as crying/having cried/about to cry (etc) like little girls. Where’s the bile blog I’ve come to love?

  6. Jonathan Feinberg Says:

    No, he actually said “It’s” and edited it after my comment.

    Phooey on you.

  7. Anonymous Says:

    I like Day, the company leading this spec. I suspect they are being pushed around by the bigger players.

  8. smoo Says:

    JSR 170 is….

    (drum roll)

    WANK

    thank you.

  9. Jesus Says:

    The comments on this blog are really getting bad. Why don’t u morons take a dump on some other blog. This blog is for serious wankers who like to hear serious shit being piled on other serious wankers.

  10. Damien Says:

    Jesus… do you have a blog? Where’s the URL? Is the comment page opened for entry?

  11. MtK Says:

    What? The servlet spec is the king of the ‘mix implementation and spec’ category? Ever heard of JavaMail?

  12. Rob Abbe Says:

    Damien,

    Yes Jesus does have a weblog.

    http://jroller.com/page/jmrodri

  13. Anonymous Says:

    Actualy, this API mostly comes from Day. They have brought over many of the concepts from their product as the ‘place to start’.

    I work for one of the vendors, and I know that we don’t agree with the spec at all…but are being forced to by other players.

  14. Anonymous Says:

    I don’t understand why the java community doesn?t try and utilize existing API’s in different scenarios. For instance jsr-170 for the most part already exists. Security API use JAAS and for parsing through a repository use jdbc or a sax implementation. Why do some of us all ways try and create the next layer of abstraction and a more convoluted API’s.

Leave a Reply