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<fwei...@bfk.de> wrote:
* Andrew John Hughes:
On 7 June 2010 23:04, Xueming Shen<xueming.s...@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
