commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldhoff, Rodney" <rwald...@us.britannica.com>
Subject RE: [httpclient] patches for Cookie.java, TestCookie.java
Date Thu, 07 Feb 2002 13:38:42 GMT
> 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. 

> The patch is effectively a 
> change in the implied contract 
> between httpclient and the 
> user

Agreed.

> ....Comments?

I think I lean toward Sean's view of the world. 

Personally, as a user of most any library when I do this:

Date d = new Date();
cookie.setExpiryDate(d);
d.setTime(System.currentTimeMillis());

I think I would expect the cookie.date to remain unchanged, but I probably
wouldn't do it for fear of undefined behavior.

I especially wouldn't do this:

Date d = cookie.getExpiryDate();
d.setTime(System.currentTimeMillis());

and expect it to work the same as

cookie.setExpiryDate(new Date())).

I'm a little concerned at the performance and garbage collection
implications here (how often do we invoke getDate() and the like?), but at
the very least we should document some policy: e.g.,: that client's should
treat the result of getDate as immutable, or that the behavior is undefined
if they change it, etc. (I actually believe that would be sufficient for
now.)  

Perhaps we could/should just use the long value?

 - Rod

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