harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulex Yang (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-665) [classlib][nio]Charset.encode()/decode() should be more safer for multi thread using
Date Mon, 26 Jun 2006 11:07:30 GMT
     [ http://issues.apache.org/jira/browse/HARMONY-665?page=all ]

Paulex Yang updated HARMONY-665:

    Attachment: Harmony-665.diff

Please try this patch, thanks.

I also did some generic uplift work to reduce the Eclipse compiler warning number to 1, which
is unavoidable I think, because the casting is necessary for the result of clone().

> [classlib][nio]Charset.encode()/decode() should be more safer for multi thread using
> ------------------------------------------------------------------------------------
>          Key: HARMONY-665
>          URL: http://issues.apache.org/jira/browse/HARMONY-665
>      Project: Harmony
>         Type: Bug

>   Components: Classlib
>     Reporter: Paulex Yang
>  Attachments: Harmony-665.diff
> As discussion on the mailing list, current Harmony codes may throw exception for the
scenario below:
>          for (int i = 0; i < THREAD_NUM; i++) {
>               thread[i] = new Thread() {
>                   public void run() {
>                      sink.write(ByteBuffer.wrap("bytes"
>                                         .getBytes(ISO8859_1)));
>                     }
>         }
> String.getBytes() actually invokes Charset.encode(), while spec requires Charset.encode()
to be thread-safe. Current Harmony implementation of Charset.encode() holds lock on this Charset
instance, but doesn't synchronize on the system wide cached CharsetEncoder, so it is not safe
for multi Charset instances in multi threads to encode() concurrently. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message