Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

In Defense of JSR310

11.03.2008
| 5261 views |
  • submit to reddit

I just ran across this ridiculous assessment of JSR 310 and had to comment. I tried to comment on the blog but it was flagged as spam.

My response:

I agree that naming is at the heart of writing good APIs but I have to object to this characterization of JSR 310.

The JSR 310 APIs are the result of a great deal of extensive and open discussion on the 310 mailing list. There have been lengthy discussions on naming of all of the major classes and concepts in the API and Stephen Colebourne (the spec lead and also creator of Joda Time) has been an impressive leader in this regard - asking for feedback, guiding the discussion, and generally driving consensus without dictating a “right” answer.

I’m not affiliated with the JSR, but I’ve followed a bunch of them and the JSR 310 process has been the most open, welcoming, and skillful that I can think of, so I hate to see it spoken of in a negative light.

With respect to the naming instances you mentioned, there is a whole set of concepts that lead logically to the name ZonedDateTime. If you bothered to read any docs, that would make more sense. I recall there being a long debate about other possible names for this class in particular. It was not chosen in haste.

With respect to Clock.system(), Clock is effectively a facade for access to a clock, of which the default instance is based on the system clock. It’s set up this way so that you can implement Clock yourself and control the passage of time for testing (see my blog for more).

If you’d like to get involved and give your feedback, I’d recommend reading the mailing list archives and participating yourself, not casting aspersions in ignorance. I think you’ll find the JSR 310 community to be quite willing and helpful to explain the API decisions.

From http://tech.puredanger.com/
Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Osvaldo Doederlein replied on Mon, 2008/11/03 - 9:03am

-1 to "fluent" stuff that uses immutable builder classes, like the blog's sample PeriodBulder. With this implementation, each invocation creates a new temp object. The builder object should be mutable, each method returning 'this' (the StringBuffer chaining pattern). Only the product of the builder (a Period object) should be immutable. Otherwise, complex building "sentences" will impose a completely stupid overhead of allocation and GC.

Porter Woodward replied on Mon, 2008/11/03 - 10:32am in response to: Osvaldo Doederlein

Depends on the nature of the object to be constructed.  Some should be immutable, some should not.  In essence, any field of the object under construction that should be both private and final - will result in requiring an immutable builder.  A good example might be an account transfer type object - wherein the account number is set once and is final (immutable) as well as the ammount(s) to transfer.

 In short - where some fields of an object are non optional in order for it to effectively "be" that type of object - you'll find that immutable builders enforce a behavioral contract.  In the instance of the period builder - calling build() w/o having handed in any sort of durations (year, month, etc) - results in a useless object.  A period without a duration is no period at all.

 

Osvaldo Doederlein replied on Mon, 2008/11/03 - 11:20am in response to: Porter Woodward

[quote=pwoodward]

Depends on the nature of the object to be constructed.  Some should be immutable, some should not.  In essence, any field of the object under construction that should be both private and final - will result in requiring an immutable builder.  A good example might be an account transfer type object - wherein the account number is set once and is final (immutable) as well as the ammount(s) to transfer.

[/quote]

I was focusing on the JSR310 API, and IMHO all date/time/period/etc. objects should be immutable; it seems that's the design adopted by this JSR. For a more general discussion of the "fluent API" pattern, I agree that you can use it to produce both immutable and mutable objects. (Although I feel that this pattern maps more nicely to immutable "product" objects.)

But I vehemently disagree with the design of immutable builders. The only advantage of that option is providing some initial defaults for the constructed objects, without allowing the client to corrupt such defaults. But you can obtain the same effect by providing a factory method that returns a new builder object configured with the correct defaults. Yep, this adds some overhead - allocating one object, and assigning some fields - to this initial call. OTOH, it's a single allocation, so it's a smaller overhead than mutable builders in all scenarios - except the extremely rare scenario of building an object that contains only the default values (e.g., writing just "Period.of.build()", which btw is not very 'fluent', and gets even worse with the proposed implicit cast).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.