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/>
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?
-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
