> 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
