PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in sun/nio/cs

[Ulf Zibis]

Am 09.06.2010 11:50, schrieb Andrew Haley:
> On 09/06/10 10:11, Andrew John Hughes wrote:
>    
>> On 9 June 2010 07:55, Florian Weimer<fweimer at bfk.de>  wrote:
>>      
>>> * Andrew John Hughes:
>>>
>>>        
>>>> On 7 June 2010 23:04, Xueming Shen<xueming.shen at oracle.com>  wrote:
>>>>          
>>>>> Hi Andrew,
>>>>>
>>>>> 6959197: When building with JAVAC_MAX_WARNINGS=true, the build fails in
>>>>> sun/nio/cs due to the use of -Werror
>>>>>
>>>>> (1)sun/io/ByteTocharISO2022JP.java
>>>>>    #129,  #151
>>>>>
>>>>>    if ((byte1&  (byte)0x80) != 0){
>>>>>
>>>>>        if ((byte2&  (byte)0x80) != 0){
>>>>>
>>>>>
>>>>> (byte) casting is not necessary as well?
>>>>>
>>>>>            
>>>> It's necessary.  0x80 is an integer literal
>>>> (http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.1)
>>>> which requires a lossy narrowing conversion to byte
>>>> (http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.3)
>>>>          
>>> Doesn't the&  operator promote its arguments to int anyway?  I don't
>>> think the cast to byte makes a difference here because it does not
>>> matter if 0x80 is sign-extended or zero-extended.
>>>
>>> It might be more efficient to use "byte1<  0" and "byte2<  0" instead.
>>>        
> This code may be in a critical performance-related place.  It's quite
> possible that it's done this way because the JIT compiles it very well.
>
> So, best not to change it without knowing what the effect is.

IMO performance of sun.io coders is not that important, as they are 
kinda deprecated.

On the other hand, we could avoid twiddling here, as there are wrappers, 
which would significantly reduce JDK's footprint:

https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/milestone2/src/sun/io/
See thread: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-September/000678.html

-Ulf