If performance does not have an impact at this point, you should make a defensive copy. And when doing a cookie.getExpiryDate() also a new copy should be returned - as simple as: return new Date( this.getExpiryDate() )
See some SUN JDC technical tips on this subject: MAKING DEFENSIVE COPIES OF OBJECTS http://developer.java.sun.com/developer/JDCTechTips/2001/tt0904.html#tip1 and HOW ARGUMENTS ARE PASSED TO JAVA METHODS http://developer.java.sun.com/developer/JDCTechTips/2001/tt1009.html#tip1 :) Christoph Reck dIon Gillard wrote: > > Waldhoff, Rodney wrote: > > >>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. > > > Makes two of us, but given the code, it's not how it works :) > > >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. > > > If I ever coded the above stuff, I'd smack myself first, and then read > the docs. But take a look at various collections (vector etc.)...they > work that way, e.g. > > Date d = new Date(); > Vector v = new Vector(); > v.add(d); > d.setTime(System.currentTimeMillis()); > > >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? > > > My call would be to document that the class assumes the provided Date is > immutable, and any changes to the object are at the user's peril (insert > peril sensitive keyboard here). > > -- > dIon Gillard, Multitask Consulting > http://www.multitask.com.au/developers > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- :) Christoph Reck -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
