commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldhoff, Rodney" <>
Subject RE: [httpclient] API design, Cookie.getExpiryDate, Cookie.setExpi ryDate
Date Thu, 07 Feb 2002 16:57:36 GMT
Yeah, lots of good ideas in there, but performance and memory use should be
a priority as well.  (Funny, I'm usually on the other side of this

dIon makes a good point with the Collections example (list.get(1).setFoo(x);
changes the value in list); and frankly I think it's fairly unreasonable
clients to treat the Cookie.getDate() value as mutable (or, to put it
another way, I think it's perfectly reasonable to tell them to treat it as
immutable).  It's not like a desire or reason to change that value leaps out
at you.

I guess I don't mind making the defensive copy as much as I mind committing
ourselves to making the defensive copy if it turns out to be a performance
or footprint issue (and it seems to me that it likely will).  If we make a
defensive copy, we should still document that the object should be
considered immutable (which begs the question, why bother to make the copy?)

-----Original Message-----
From: Sean C. Sullivan []
Sent: Thursday, February 07, 2002 10:33 AM
To: Jakarta Commons Developers List
Subject: Re: [httpclient] API design, Cookie.getExpiryDate,

My comments are below...

From: "dIon Gillard" <>
> Sean C. Sullivan wrote:
> >I updated the code for the HttpClient:
> >
> >
> >
> >
> >
> >The modification changes the behavior of Cookie.getExpiryDate
> >
> >Instead of returning the internal Date object, we return a freshly
> >instantiated Date object.
> >
> >Why:    Because java.util.Date is a mutable object.
> >
> >I created the patch files using this command:
> >
> >             cvs diff -c > Foo.patch
> >
> > -Sean
> >
> I'm not sure that the original behaviour is flawed as coded.
> The patch implies that passing setExpiryDate a Date object and then
> changing that object is a 'bad thing'. But this is the existing
> behaviour, so under the current code, I can do this:
> // uncompiled untested code
> Date d = new Date();
> cookie.setExpiryDate(d);
> d.setTime(System.currentTimeMillis());
> and based on the current code set, I expect the expiry date of the
> cookie to have changed. And ditto, on calling getExpiryDate() I expect
> to be able to change the Date and have it reflected in the cookie.
> The patch is effectively a change in the implied contract between
and the user....Comments?

I would like the HttpClient API to follow the API guidelines from Josh

  Effective Java Programming Language Guide

Josh Bloch is a Senior Software Architect at Sun.  Josh designed
the Java Collections API.

I highly recommend Josh's book.

In particular, I like these guidelines from Bloch's book:

==> Item 13:  Favor immutability  (immutable objects)

==> Item 12: Minimize the accessibility of classes and members

==> Item 6: Avoid finalizers

==> Item 21: Replace enum constructs with classes

==> Item 54: implement judiciously

==> Item 9:  Always override toString()

==> Item 10: Override clone judiciously

==> Item 15: Design and document for inheritance or else prohibit it

==> Item 17: Use interfaces only to define types

==> Item 23: Check parameters for validity

==> Item 24: Make defensive copies when needed

==> Item 25: Design method signatures carefully

==> Item 27: Return zero-length arrays, not nulls

==> Item 28: Write doc comments for all exposed API elements

==> Item 38: Adhere to generally accepted naming conventions

==> Item 47: Don't ignore exceptions


To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message