Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 70173 invoked from network); 7 Feb 2002 14:18:50 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 7 Feb 2002 14:18:50 -0000 Received: (qmail 10103 invoked by uid 97); 7 Feb 2002 14:18:49 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 10062 invoked by uid 97); 7 Feb 2002 14:18:49 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 10051 invoked from network); 7 Feb 2002 14:18:48 -0000 Sender: Christoph.Reck@dlr.de Message-ID: <3C628CC0.3F36585C@dlr.de> Date: Thu, 07 Feb 2002 15:18:40 +0100 From: Christoph Reck Organization: DFD-DLR X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en, de MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [httpclient] patches for Cookie.java, TestCookie.java References: <921E60ADEB30D84EACA350AD31A1FD7506E2BD@chiex02> <3C62863D.90107@multitask.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: > For additional commands, e-mail: -- :) Christoph Reck -- To unsubscribe, e-mail: For additional commands, e-mail: