commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Reck <Christoph.R...@dlr.de>
Subject Re: [httpclient] patches for Cookie.java, TestCookie.java
Date Thu, 07 Feb 2002 14:18:40 GMT
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:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>

-- 
:) Christoph Reck

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message