[rfc][icedtea-web] Console Output Encoding Fix

[Jiri Vanek]

On 07/15/2014 05:07 PM, Jacob Wisor wrote:
> On 07/15/2014 04:10, Jie Kang wrote:> Hello,
>  >
>  > This patch resolves the bug here http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1858
>  >
>  > Characters such as 'ó' were not appearing in the Java Console due to the implementation of
> TeeOutputStream appending bytes to a StringBuffer in a byte-by-byte fashion ignoring the fact that
> the encodings involve multi-byte characters.
>  >
>  > Also, as far as I can tell the StringBuffer is not used by multiple threads and has been replaced
> by StringBuilder (see http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuilder.html)
>
> No, I would rather advise to stay with StringBuffer. There is no need for StringBuilder as long as
> TeeOutputStream is thread-safe.

TeaOutputStreamitself is not thread safe, but all acess to the "string" are(should! be) already 
synchronised so it should be ok to move to StringBuilder, whih have much less overhead.

>
> Generally speaking, what this code should be doing is this:
>
> import java.util.Arrays;
> [...]
> this.string.append(new String(Arrays.copyOfRange(b, off, off + len)));
>
> Flushing on every '\n' can also be incorporated. ;-)

See my much longer reply :) - 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-July/028521.html

Maybe you have arguments why write(int b) should not be fixed to. And maybe you also know if 
write(int, int,  int[], ...) may end in middle of character. I think it may.

>
> Furthermore, you may drop all of the initial parameter checking:
>
> -        if (b == null) {
> -            throw new NullPointerException();
> -        } else if ((off < 0) || (off > b.length) || (len < 0)
> -                || ((off + len) > b.length) || ((off + len) < 0)) {
> -            throw new IndexOutOfBoundsException();
> -        } else if (len == 0) {
> -            return;
> -        }
> +        if (len == 0) return;
>
> Working with these parameters will inevitably generate the correct exceptions. This is the beauty of
> RuntimeExceptions; You just do stuff and the JRE throws them for you. No double checking required. ;-)
> Additional parameter checks in public methods are only required when they may have an illegal effect
> on the internal state of the (this) object or when you want to give additional information on an
> error to the programmer.

Yes. I was looking onto this myself. Thank you for describing this.