Alex Miller In Defense of JSR310
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:
From http://tech.puredanger.com/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.
- Login or register to post comments
- 4261 reads
- Printer-friendly version
(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: opinali
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: 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).