Code Review 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe

[gustav trede]

On 18 August 2010 12:47, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 18/08/2010 11:28, gustav trede wrote:
>
>>
>> On 18 August 2010 12:10, Chris Hegarty <chris.hegarty at oracle.com
>> <mailto:chris.hegarty at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20100818/35058c6e/attachment.html