On 18 August 2010 13:22, Michael McMahon <michael.x.mcma...@oracle.com>wrote:
> gustav trede wrote: > >> >> On 18 August 2010 12:10, Chris Hegarty <chris.hega...@oracle.com <mailto: >> chris.hega...@oracle.com>> wrote: >> >> Michael, >> >> java.net.HttpCookie uses static SimpleDateFormat which is not >> thread safe. I think the best solution here is to simply create >> local SimpleDateFormat as needed. >> >> Webrev: >> >> http://cr.openjdk.java.net/~chegar/6965924/webrev.00/webrev/<http://cr.openjdk.java.net/%7Echegar/6965924/webrev.00/webrev/> >> <http://cr.openjdk.java.net/%7Echegar/6965924/webrev.00/webrev/> >> >> >> >> Why not use a threadlocal dateformater ?. >> > perhaps ... > > For certain cases Its also viable to exploit the fact that its enough to >> generate a new value once per second for HTTP timestamps. >> Even if its not "needed", it would imo be nice if the JDK code itself >> could somehow act as reference / good examples of how to THINK(design) and >> implement. >> >> I suspect you're looking at this from a server perspective. This code is > involved with parsing > of incoming cookies. So, the generation of timestamps isn't being done > here. > > Yes i am quite server focused =), servers can act as http clients too, different kind of intermediate logic etc. Anyhow, my apologies for wasting your time with this not so important issue, my brain just pings on code it finds strange /. regards gustav trede
