On 18 August 2010 12:47, Chris Hegarty <chris.hega...@oracle.com> wrote:
> On 18/08/2010 11:28, 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 ?. >> > > I guess it depends on the use of HttpCookie. In the JDK HttpCookie is only > used to parse cookies sent in a HTTP response. For this type of application > potentially keeping three formatters per thread seems like a waste. This, of > course, is only one use. > > > For certain cases Its also viable to exploit the fact that its enough to >> generate a new value once per second for HTTP timestamps. >> > > I don't understand. Are you using HttpCookie in a server type context? > > No, i use my custom server code, but i do use the concept of generating HTTP DATE: header timestamp values once per second by updating the per cached file/standard responses directbytebuffers using only volatile somantics. -Chris. > > > 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. >> >> >> regards >> gustav trede >> >
