From ahughes at redhat.com  Wed Jun  2 10:57:35 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Wed, 2 Jun 2010 18:57:35 +0100
Subject: Fix build failure with JAVAC_MAX_WARNINGS=true in sun/nio/cs
Message-ID: <AANLkTikbwDKtaMff0R13gSzpkiOFtYU3I8eF8f4ZFrK4@mail.gmail.com>

When building with JAVAC_MAX_WARNINGS=true, the build fails in
sun/nio/cs due to the use of -Werror.

The following webrev:

http://cr.openjdk.java.net/~andrew/warnings/webrev.03/

fixes the remaining warnings exposed by JAVAC_MAX_WARNINGS by:

* Removing redundant casts
* Adding generic types to a number of List, Map and Class instances
* Turning off deprecation warnings locally in make/sun/nio/cs/Makefile

Ok to push? If so, can I have a bug ID for this?

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From ahughes at redhat.com  Mon Jun  7 11:03:51 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Mon, 7 Jun 2010 19:03:51 +0100
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
Message-ID: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>

On 2 June 2010 18:57, Andrew John Hughes <ahughes at redhat.com> wrote:
> When building with JAVAC_MAX_WARNINGS=true, the build fails in
> sun/nio/cs due to the use of -Werror.
>
> The following webrev:
>
> http://cr.openjdk.java.net/~andrew/warnings/webrev.03/
>
> fixes the remaining warnings exposed by JAVAC_MAX_WARNINGS by:
>
> * Removing redundant casts
> * Adding generic types to a number of List, Map and Class instances
> * Turning off deprecation warnings locally in make/sun/nio/cs/Makefile
>
> Ok to push? If so, can I have a bug ID for this?
>
> Thanks,
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8
>

Ping! Any feedback on this?
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From xueming.shen at oracle.com  Mon Jun  7 11:06:42 2010
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 07 Jun 2010 11:06:42 -0700
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>
Message-ID: <4C0D3532.8080808@oracle.com>


Andrew, I'm going through the webrev now.  Need a little more time.

-sherman

Andrew John Hughes wrote:
> On 2 June 2010 18:57, Andrew John Hughes <ahughes at redhat.com> wrote:
>   
>> When building with JAVAC_MAX_WARNINGS=true, the build fails in
>> sun/nio/cs due to the use of -Werror.
>>
>> The following webrev:
>>
>> http://cr.openjdk.java.net/~andrew/warnings/webrev.03/
>>
>> fixes the remaining warnings exposed by JAVAC_MAX_WARNINGS by:
>>
>> * Removing redundant casts
>> * Adding generic types to a number of List, Map and Class instances
>> * Turning off deprecation warnings locally in make/sun/nio/cs/Makefile
>>
>> Ok to push? If so, can I have a bug ID for this?
>>
>> Thanks,
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>>
>>     
>
> Ping! Any feedback on this?
>   


From ahughes at redhat.com  Mon Jun  7 11:10:25 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Mon, 7 Jun 2010 19:10:25 +0100
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <4C0D3532.8080808@oracle.com>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>
	<4C0D3532.8080808@oracle.com>
Message-ID: <AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>

On 7 June 2010 19:06, Xueming Shen <xueming.shen at oracle.com> wrote:
>
> Andrew, I'm going through the webrev now. ?Need a little more time.
>
> -sherman
>
> Andrew John Hughes wrote:
>>
>> On 2 June 2010 18:57, Andrew John Hughes <ahughes at redhat.com> wrote:
>>
>>>
>>> When building with JAVAC_MAX_WARNINGS=true, the build fails in
>>> sun/nio/cs due to the use of -Werror.
>>>
>>> The following webrev:
>>>
>>> http://cr.openjdk.java.net/~andrew/warnings/webrev.03/
>>>
>>> fixes the remaining warnings exposed by JAVAC_MAX_WARNINGS by:
>>>
>>> * Removing redundant casts
>>> * Adding generic types to a number of List, Map and Class instances
>>> * Turning off deprecation warnings locally in make/sun/nio/cs/Makefile
>>>
>>> Ok to push? If so, can I have a bug ID for this?
>>>
>>> Thanks,
>>> --
>>> Andrew :-)
>>>
>>> Free Java Software Engineer
>>> Red Hat, Inc. (http://www.redhat.com)
>>>
>>> Support Free Java!
>>> Contribute to GNU Classpath and the OpenJDK
>>> http://www.gnu.org/software/classpath
>>> http://openjdk.java.net
>>>
>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8
>>>
>>>
>>
>> Ping! Any feedback on this?
>>
>
>

Ok, no rush; I didn't know if anyone had even seen the e-mail as there
was no response.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From xueming.shen at oracle.com  Mon Jun  7 15:04:52 2010
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 07 Jun 2010 15:04:52 -0700
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>	<4C0D3532.8080808@oracle.com>
	<AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>
Message-ID: <4C0D6D04.5090701@oracle.com>

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?

(2)sun/io/ByteToCharJISAutoDetect.java

   we should (if I did not miss anything) simply change the
   sun/nio/cs/ext/JISAutoDetect.getByteMask1|2 to static, then no longer 
need to
   have an instance in ByteToCharJISAutoDetect.

(3)sun/nio/cs/ext/EUC_JP_LINUX.java

     encoderJ0208 no longer needed? 

   decodeMappingJ0208.start = 0xa1;
   decodeMappingJ0208.end = 0xfe;

      seems like we should simply replace decodeMappingJ0208.start/end 
with start/end
      and the decodeMappingJ0208 is no longer necessary as well.

(4)

   again, it might be better to do something as below. The EUC_JP_xyz 
are something need to
   be re-written/-re-organized when we have time.

  short[] j0208Index1 = JIS_X_0208_Solaris_Decoder.getIndex1();
  String[]j0208Index2 = JIS_X_0208_Solaris_Decoder.getIndex2();

    int start = 0xa1;
    int end = -0xfe;

 100     protected char decodeDouble(int byte1, int byte2) {
 101             if (byte1 == 0x8e) {
 102                 return decoderJ0201.decode(byte2 - 256);
 103             }
 104 
 105             if (((byte1 < 0)
 106                 || (byte1 > j0208Index1.length))
 107                 || ((byte2 < start)
 108                 || (byte2 > end)))
 109                 return REPLACE_CHAR;
 110 
 111             char result = super.decodeDouble(byte1, byte2);
 112             if (result != '\uFFFD') {
 113                 return result;
 114             } else {
 115                 int n = (j0208Index1[byte1 - 0x80] & 0xf) *
 116                         (end - start + 1)
 117                         + (byte2 - start);
 118                 return j0208Index2[j0208Index1[byte1 - 0x80] >> 4].charAt(n);
 119             }
 120         }

    encoderJ0208 is no longer needed.

(5) sun.nio.cs.ext.PCK.java

    JIS_X_0208_Solaris_Encoder jis0208 is no longer needed

-sherman


Andrew John Hughes wrote:
> On 7 June 2010 19:06, Xueming Shen <xueming.shen at oracle.com> wrote:
>   
>> Andrew, I'm going through the webrev now.  Need a little more time.
>>
>> -sherman
>>
>> Andrew John Hughes wrote:
>>     
>>> On 2 June 2010 18:57, Andrew John Hughes <ahughes at redhat.com> wrote:
>>>
>>>       
>>>> When building with JAVAC_MAX_WARNINGS=true, the build fails in
>>>> sun/nio/cs due to the use of -Werror.
>>>>
>>>> The following webrev:
>>>>
>>>> http://cr.openjdk.java.net/~andrew/warnings/webrev.03/
>>>>
>>>> fixes the remaining warnings exposed by JAVAC_MAX_WARNINGS by:
>>>>
>>>> * Removing redundant casts
>>>> * Adding generic types to a number of List, Map and Class instances
>>>> * Turning off deprecation warnings locally in make/sun/nio/cs/Makefile
>>>>
>>>> Ok to push? If so, can I have a bug ID for this?
>>>>
>>>> Thanks,
>>>> --
>>>> Andrew :-)
>>>>
>>>> Free Java Software Engineer
>>>> Red Hat, Inc. (http://www.redhat.com)
>>>>
>>>> Support Free Java!
>>>> Contribute to GNU Classpath and the OpenJDK
>>>> http://www.gnu.org/software/classpath
>>>> http://openjdk.java.net
>>>>
>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>>>>
>>>>
>>>>         
>>> Ping! Any feedback on this?
>>>
>>>       
>>     
>
> Ok, no rush; I didn't know if anyone had even seen the e-mail as there
> was no response.
>   


From ahughes at redhat.com  Tue Jun  8 14:47:13 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Tue, 8 Jun 2010 22:47:13 +0100
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <4C0D6D04.5090701@oracle.com>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>
	<4C0D3532.8080808@oracle.com>
	<AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>
	<4C0D6D04.5090701@oracle.com>
Message-ID: <AANLkTil3ARMaCl-huOb-AVgJwaVIcF9U1LzoA43RC7U6@mail.gmail.com>

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)

> (2)sun/io/ByteToCharJISAutoDetect.java
>
> ?we should (if I did not miss anything) simply change the
> ?sun/nio/cs/ext/JISAutoDetect.getByteMask1|2 to static, then no longer need
> to
> ?have an instance in ByteToCharJISAutoDetect.
>

Well spotted!  Changed.

> (3)sun/nio/cs/ext/EUC_JP_LINUX.java
>
> ? ?encoderJ0208 no longer needed?
> ?decodeMappingJ0208.start = 0xa1;
> ?decodeMappingJ0208.end = 0xfe;
>
> ? ? seems like we should simply replace decodeMappingJ0208.start/end with
> start/end
> ? ? and the decodeMappingJ0208 is no longer necessary as well.
>

Likewise.

> (4)
>
> ?again, it might be better to do something as below. The EUC_JP_xyz are
> something need to
> ?be re-written/-re-organized when we have time.
>
> ?short[] j0208Index1 = JIS_X_0208_Solaris_Decoder.getIndex1();
> ?String[]j0208Index2 = JIS_X_0208_Solaris_Decoder.getIndex2();
>
> ? int start = 0xa1;
> ? int end = -0xfe;
>
> 100 ? ? protected char decodeDouble(int byte1, int byte2) {
> 101 ? ? ? ? ? ? if (byte1 == 0x8e) {
> 102 ? ? ? ? ? ? ? ? return decoderJ0201.decode(byte2 - 256);
> 103 ? ? ? ? ? ? }
> 104 105 ? ? ? ? ? ? if (((byte1 < 0)
> 106 ? ? ? ? ? ? ? ? || (byte1 > j0208Index1.length))
> 107 ? ? ? ? ? ? ? ? || ((byte2 < start)
> 108 ? ? ? ? ? ? ? ? || (byte2 > end)))
> 109 ? ? ? ? ? ? ? ? return REPLACE_CHAR;
> 110 111 ? ? ? ? ? ? char result = super.decodeDouble(byte1, byte2);
> 112 ? ? ? ? ? ? if (result != '\uFFFD') {
> 113 ? ? ? ? ? ? ? ? return result;
> 114 ? ? ? ? ? ? } else {
> 115 ? ? ? ? ? ? ? ? int n = (j0208Index1[byte1 - 0x80] & 0xf) *
> 116 ? ? ? ? ? ? ? ? ? ? ? ? (end - start + 1)
> 117 ? ? ? ? ? ? ? ? ? ? ? ? + (byte2 - start);
> 118 ? ? ? ? ? ? ? ? return j0208Index2[j0208Index1[byte1 - 0x80] >>
> 4].charAt(n);
> 119 ? ? ? ? ? ? }
> 120 ? ? ? ? }
>
> ? encoderJ0208 is no longer needed.
>

Fixed.

> (5) sun.nio.cs.ext.PCK.java
>
> ? JIS_X_0208_Solaris_Encoder jis0208 is no longer needed
>

Fixed.

New webrev:

http://cr.openjdk.java.net/~andrew/warnings/webrev.04/

Thanks for such a detailed review.  I just fixed the issues that came
up from javac and didn't review the resulting classes in detail.  This
should make them a little cleaner.

> -sherman
>
>
> Andrew John Hughes wrote:
>>
>> On 7 June 2010 19:06, Xueming Shen <xueming.shen at oracle.com> wrote:
>>
>>>
>>> Andrew, I'm going through the webrev now. ?Need a little more time.
>>>
>>> -sherman
>>>
>>> Andrew John Hughes wrote:
>>>
>>>>
>>>> On 2 June 2010 18:57, Andrew John Hughes <ahughes at redhat.com> wrote:
>>>>
>>>>
>>>>>
>>>>> When building with JAVAC_MAX_WARNINGS=true, the build fails in
>>>>> sun/nio/cs due to the use of -Werror.
>>>>>
>>>>> The following webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~andrew/warnings/webrev.03/
>>>>>
>>>>> fixes the remaining warnings exposed by JAVAC_MAX_WARNINGS by:
>>>>>
>>>>> * Removing redundant casts
>>>>> * Adding generic types to a number of List, Map and Class instances
>>>>> * Turning off deprecation warnings locally in make/sun/nio/cs/Makefile
>>>>>
>>>>> Ok to push? If so, can I have a bug ID for this?
>>>>>
>>>>> Thanks,
>>>>> --
>>>>> Andrew :-)
>>>>>
>>>>> Free Java Software Engineer
>>>>> Red Hat, Inc. (http://www.redhat.com)
>>>>>
>>>>> Support Free Java!
>>>>> Contribute to GNU Classpath and the OpenJDK
>>>>> http://www.gnu.org/software/classpath
>>>>> http://openjdk.java.net
>>>>>
>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8
>>>>>
>>>>>
>>>>>
>>>>
>>>> Ping! Any feedback on this?
>>>>
>>>>
>>>
>>>
>>
>> Ok, no rush; I didn't know if anyone had even seen the e-mail as there
>> was no response.
>>
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From fweimer at bfk.de  Tue Jun  8 23:55:35 2010
From: fweimer at bfk.de (Florian Weimer)
Date: Wed, 09 Jun 2010 06:55:35 +0000
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in
	sun/nio/cs
In-Reply-To: <AANLkTil3ARMaCl-huOb-AVgJwaVIcF9U1LzoA43RC7U6@mail.gmail.com>
	(Andrew John Hughes's message of "Tue\,
	8 Jun 2010 22\:47\:13 +0100")
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>
	<4C0D3532.8080808@oracle.com>
	<AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>
	<4C0D6D04.5090701@oracle.com>
	<AANLkTil3ARMaCl-huOb-AVgJwaVIcF9U1LzoA43RC7U6@mail.gmail.com>
Message-ID: <82ocfkn194.fsf@mid.bfk.de>

* 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.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

From ahughes at redhat.com  Wed Jun  9 02:11:17 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Wed, 9 Jun 2010 10:11:17 +0100
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <82ocfkn194.fsf@mid.bfk.de>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>
	<4C0D3532.8080808@oracle.com>
	<AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>
	<4C0D6D04.5090701@oracle.com>
	<AANLkTil3ARMaCl-huOb-AVgJwaVIcF9U1LzoA43RC7U6@mail.gmail.com>
	<82ocfkn194.fsf@mid.bfk.de>
Message-ID: <AANLkTilaZMJm3zza9JkISmPWzuwxdErj5LIusd-rAZjf@mail.gmail.com>

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.
>

You're right.  I think I mentally read that as an assignment, not an
and operation.

If I'm reading it right now, it would seem to just be testing the sign
bit.  byte1 < 0 would be clearer if not faster, and I'd be for
changing that, though that probably should be a separate patch.

Sherman, does the new webrev look ok to push?

> --
> Florian Weimer ? ? ? ? ? ? ? ?<fweimer at bfk.de>
> BFK edv-consulting GmbH ? ? ? http://www.bfk.de/
> Kriegsstra?e 100 ? ? ? ? ? ? ?tel: +49-721-96201-1
> D-76133 Karlsruhe ? ? ? ? ? ? fax: +49-721-96201-99
>

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From Alan.Bateman at oracle.com  Wed Jun  9 07:55:16 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 09 Jun 2010 15:55:16 +0100
Subject: 6935563: (dc) Improve connection reset/port unreachable handling [win
Message-ID: <4C0FAB54.9010500@oracle.com>


Chris - would you mind looking at this one? It's a Windows specific 
issue that rises with unconnected datagram channels when an ICMP 
destination unreachable message is received. As the channel is 
unconnected then the message should be dropped and shouldn't cause a 
Selector to wakeup. In order to get the expected behavior we need to use 
the SIO_UDP_CONNRESET control code to toggle whether we receive the 
connection reset error or not. The changes are very simple and the 
webrev is here:
   http://cr.openjdk.java.net/~alanb/6935563/webrev/

Thanks,
Alan.

From Alan.Bateman at oracle.com  Wed Jun  9 08:48:47 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 09 Jun 2010 16:48:47 +0100
Subject: 6938230: (so) SocketAdaptor.close() does not translate IOException
	resulting in Error
Message-ID: <4C0FB7DF.9010305@oracle.com>

Chris - this is networking related one so maybe you could look at it. 
The close method in the socket adapters currently attempt to translate 
any IOException thrown by the the channel close.  This is unnecessary, 
and in the case of SocketChannel's adapter, can result in an Error being 
thrown when it cannot translate the exception. The diffs attach just 
remove this translation. I don't think it's possible to create an 
automated regression test for this.

-Alan.


diff -r a21e3a29ca9d src/share/classes/sun/nio/ch/ServerSocketAdaptor.java
--- a/src/share/classes/sun/nio/ch/ServerSocketAdaptor.java     Tue Jun 
08 18:52:17 2010 -0700
+++ b/src/share/classes/sun/nio/ch/ServerSocketAdaptor.java     Wed Jun 
09 16:43:55 2010 +0100
@@ -144,11 +144,7 @@ public class ServerSocketAdaptor       
     }
 
     public void close() throws IOException {
-        try {
-            ssc.close();
-        } catch (Exception x) {
-            Net.translateException(x);
-        }
+        ssc.close();
     }
 
     public ServerSocketChannel getChannel() {
diff -r a21e3a29ca9d src/share/classes/sun/nio/ch/SocketAdaptor.java
--- a/src/share/classes/sun/nio/ch/SocketAdaptor.java   Tue Jun 08 
18:52:17 2010 -0700
+++ b/src/share/classes/sun/nio/ch/SocketAdaptor.java   Wed Jun 09 
16:43:55 2010 +0100
@@ -404,11 +404,7 @@ public class SocketAdaptor
     }
 
     public void close() throws IOException {
-        try {
-            sc.close();
-        } catch (Exception x) {
-            Net.translateToSocketException(x);
-        }
+        sc.close();
     }
 
     public void shutdownInput() throws IOException {




From chris.hegarty at oracle.com  Wed Jun  9 09:21:08 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 09 Jun 2010 17:21:08 +0100
Subject: 6938230: (so) SocketAdaptor.close() does not translate IOException
	resulting in Error
In-Reply-To: <4C0FB7DF.9010305@oracle.com>
References: <4C0FB7DF.9010305@oracle.com>
Message-ID: <4C0FBF74.7010909@oracle.com>

Alan,

This change looks fine.

-Chris.

Alan Bateman wrote:
> Chris - this is networking related one so maybe you could look at it. 
> The close method in the socket adapters currently attempt to translate 
> any IOException thrown by the the channel close.  This is unnecessary, 
> and in the case of SocketChannel's adapter, can result in an Error being 
> thrown when it cannot translate the exception. The diffs attach just 
> remove this translation. I don't think it's possible to create an 
> automated regression test for this.
> 
> -Alan.
> 
> 
> diff -r a21e3a29ca9d src/share/classes/sun/nio/ch/ServerSocketAdaptor.java
> --- a/src/share/classes/sun/nio/ch/ServerSocketAdaptor.java     Tue Jun 
> 08 18:52:17 2010 -0700
> +++ b/src/share/classes/sun/nio/ch/ServerSocketAdaptor.java     Wed Jun 
> 09 16:43:55 2010 +0100
> @@ -144,11 +144,7 @@ public class ServerSocketAdaptor           }
> 
>     public void close() throws IOException {
> -        try {
> -            ssc.close();
> -        } catch (Exception x) {
> -            Net.translateException(x);
> -        }
> +        ssc.close();
>     }
> 
>     public ServerSocketChannel getChannel() {
> diff -r a21e3a29ca9d src/share/classes/sun/nio/ch/SocketAdaptor.java
> --- a/src/share/classes/sun/nio/ch/SocketAdaptor.java   Tue Jun 08 
> 18:52:17 2010 -0700
> +++ b/src/share/classes/sun/nio/ch/SocketAdaptor.java   Wed Jun 09 
> 16:43:55 2010 +0100
> @@ -404,11 +404,7 @@ public class SocketAdaptor
>     }
> 
>     public void close() throws IOException {
> -        try {
> -            sc.close();
> -        } catch (Exception x) {
> -            Net.translateToSocketException(x);
> -        }
> +        sc.close();
>     }
> 
>     public void shutdownInput() throws IOException {
> 
> 
> 

From chris.hegarty at oracle.com  Wed Jun  9 09:30:52 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 09 Jun 2010 17:30:52 +0100
Subject: 6935563: (dc) Improve connection reset/port unreachable handling
	[win
In-Reply-To: <4C0FAB54.9010500@oracle.com>
References: <4C0FAB54.9010500@oracle.com>
Message-ID: <4C0FC1BC.4080403@oracle.com>

Alan,

The changes look good.

-Chris.

Alan Bateman wrote:
> 
> Chris - would you mind looking at this one? It's a Windows specific 
> issue that rises with unconnected datagram channels when an ICMP 
> destination unreachable message is received. As the channel is 
> unconnected then the message should be dropped and shouldn't cause a 
> Selector to wakeup. In order to get the expected behavior we need to use 
> the SIO_UDP_CONNRESET control code to toggle whether we receive the 
> connection reset error or not. The changes are very simple and the 
> webrev is here:
>   http://cr.openjdk.java.net/~alanb/6935563/webrev/
> 
> Thanks,
> Alan.

From xueming.shen at oracle.com  Wed Jun  9 10:22:14 2010
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 09 Jun 2010 10:22:14 -0700
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <AANLkTilaZMJm3zza9JkISmPWzuwxdErj5LIusd-rAZjf@mail.gmail.com>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>	<4C0D3532.8080808@oracle.com>	<AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>	<4C0D6D04.5090701@oracle.com>	<AANLkTil3ARMaCl-huOb-AVgJwaVIcF9U1LzoA43RC7U6@mail.gmail.com>	<82ocfkn194.fsf@mid.bfk.de>
	<AANLkTilaZMJm3zza9JkISmPWzuwxdErj5LIusd-rAZjf@mail.gmail.com>
Message-ID: <4C0FCDC6.9040508@oracle.com>

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.
>>
>>     
>
> You're right.  I think I mentally read that as an assignment, not an
> and operation.
>
> If I'm reading it right now, it would seem to just be testing the sign
> bit.  byte1 < 0 would be clearer if not faster, and I'd be for
> changing that, though that probably should be a separate patch.
>
> Sherman, does the new webrev look ok to push?
>
>   

(1)ByteToCharJISAutoDetect.java
    It appears we should move the maskTable1/2 initialization code out 
of the constructor block.

  37     private static byte[] maskTable1 = JISAutoDetect.getByteMask1();
  38     private static byte[] maskTable2 = JISAutoDetect.getByteMask2();

(2)EUC_JP_Open.java

 137             j0208Index1 = JIS_X_0208_Solaris_Encoder.getIndex1();
 138             j0208Index2 = JIS_X_0208_Solaris_Encoder.getIndex2();

  can be moved out of the constructor as you do for the decoder. better to
  keep them consistent (as well as the code in EUC_JP_LINUX)


(3)sun/nio/cs/ext/HKSCS.java

-            this.big5Dec = big5Dec;
+            Decoder.big5Dec = big5Dec;

 Dave is absolutely right here. big5Dec definitely should be an instance
 field instead of static, it's my bug in the original code. It should be

         private DoubleByte.Decoder big5Dec;

         protected Decoder(Charset cs,
                           DoubleByte.Decoder big5Dec,
                           char[][] b2cBmp, char[][] b2cSupp)
         {
             // super(cs, 0.5f, 1.0f);
             // need to extends DoubleByte.Decoder so the
             // sun.io can use it. this implementation
             super(cs, 0.5f, 1.0f, null, null, 0, 0);
             this.big5Dec = big5Dec;
             this.b2cBmp = b2cBmp;
             this.b2cSupp = b2cSupp;
         }


Thanks,
Sherman





From Ulf.Zibis at gmx.de  Wed Jun  9 12:43:21 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 09 Jun 2010 21:43:21 +0200
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <4C0D6D04.5090701@oracle.com>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>	<4C0D3532.8080808@oracle.com>	<AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>
	<4C0D6D04.5090701@oracle.com>
Message-ID: <4C0FEED9.9020003@gmx.de>

Hi Sherman,

I'm happy to see those enhancements.

Please allow me to note, that IIRC many of them and similar others I had 
addressed by my patches on 
https://bugs.openjdk.java.net/show_bug.cgi?id=10009x.
Unfortunately https://bugs.openjdk.java.net is down today, so I can't be 
more specific.

I would appreciate, someone would review my patches.

-Ulf

Am 08.06.2010 00:04, schrieb Xueming Shen:
> 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?
>
> (2)sun/io/ByteToCharJISAutoDetect.java
>
>   we should (if I did not miss anything) simply change the
>   sun/nio/cs/ext/JISAutoDetect.getByteMask1|2 to static, then no 
> longer need to
>   have an instance in ByteToCharJISAutoDetect.
>
> (3)sun/nio/cs/ext/EUC_JP_LINUX.java
>
>     encoderJ0208 no longer needed?
>   decodeMappingJ0208.start = 0xa1;
>   decodeMappingJ0208.end = 0xfe;
>
>      seems like we should simply replace decodeMappingJ0208.start/end 
> with start/end
>      and the decodeMappingJ0208 is no longer necessary as well.
>
> (4)
>
>   again, it might be better to do something as below. The EUC_JP_xyz 
> are something need to
>   be re-written/-re-organized when we have time.
>
>  short[] j0208Index1 = JIS_X_0208_Solaris_Decoder.getIndex1();
>  String[]j0208Index2 = JIS_X_0208_Solaris_Decoder.getIndex2();
>
>    int start = 0xa1;
>    int end = -0xfe;
>
> 100     protected char decodeDouble(int byte1, int byte2) {
> 101             if (byte1 == 0x8e) {
> 102                 return decoderJ0201.decode(byte2 - 256);
> 103             }
> 104 105             if (((byte1 < 0)
> 106                 || (byte1 > j0208Index1.length))
> 107                 || ((byte2 < start)
> 108                 || (byte2 > end)))
> 109                 return REPLACE_CHAR;
> 110 111             char result = super.decodeDouble(byte1, byte2);
> 112             if (result != '\uFFFD') {
> 113                 return result;
> 114             } else {
> 115                 int n = (j0208Index1[byte1 - 0x80] & 0xf) *
> 116                         (end - start + 1)
> 117                         + (byte2 - start);
> 118                 return j0208Index2[j0208Index1[byte1 - 0x80] >> 
> 4].charAt(n);
> 119             }
> 120         }
>
>    encoderJ0208 is no longer needed.
>
> (5) sun.nio.cs.ext.PCK.java
>
>    JIS_X_0208_Solaris_Encoder jis0208 is no longer needed
>
> -sherman
>


From Ulf.Zibis at gmx.de  Wed Jun  9 13:06:10 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 09 Jun 2010 22:06:10 +0200
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <4C0F63DD.9030509@redhat.com>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>	<4C0D3532.8080808@oracle.com>	<AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>	<4C0D6D04.5090701@oracle.com>	<AANLkTil3ARMaCl-huOb-AVgJwaVIcF9U1LzoA43RC7U6@mail.gmail.com>	<82ocfkn194.fsf@mid.bfk.de>	<AANLkTilaZMJm3zza9JkISmPWzuwxdErj5LIusd-rAZjf@mail.gmail.com>
	<4C0F63DD.9030509@redhat.com>
Message-ID: <4C0FF432.6020709@gmx.de>

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




From Alan.Bateman at oracle.com  Thu Jun 10 08:42:04 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 10 Jun 2010 16:42:04 +0100
Subject: 6934585: TEST_BUG:
	java/nio/channels/AsynchronousSocketChannel/Basic.java
Message-ID: <4C1107CC.6070404@oracle.com>


Chris - do you mind looking at this test fix? The unit test for 
AsynchronousSocketChannel has two sub-tests that connect to fixed host 
(1.2.3.4) assuming it will fail to connect and that the failure is not 
immediate. These assumptions result in intermittent failures. The webrev 
to fix these issues is here:
    http://cr.openjdk.java.net/~alanb/6934585/webrev/

Thanks,
Alan.

From ahughes at redhat.com  Thu Jun 10 14:35:16 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Thu, 10 Jun 2010 22:35:16 +0100
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <4C0FCDC6.9040508@oracle.com>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>
	<4C0D3532.8080808@oracle.com>
	<AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>
	<4C0D6D04.5090701@oracle.com>
	<AANLkTil3ARMaCl-huOb-AVgJwaVIcF9U1LzoA43RC7U6@mail.gmail.com>
	<82ocfkn194.fsf@mid.bfk.de>
	<AANLkTilaZMJm3zza9JkISmPWzuwxdErj5LIusd-rAZjf@mail.gmail.com>
	<4C0FCDC6.9040508@oracle.com>
Message-ID: <AANLkTiluxD26wZSDoVe0GBUVylSL9ZO68vjH2P0EdYdG@mail.gmail.com>

On 9 June 2010 18:22, Xueming Shen <xueming.shen at oracle.com> wrote:
> 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.
>>>
>>>
>>
>> You're right. ?I think I mentally read that as an assignment, not an
>> and operation.
>>
>> If I'm reading it right now, it would seem to just be testing the sign
>> bit. ?byte1 < 0 would be clearer if not faster, and I'd be for
>> changing that, though that probably should be a separate patch.
>>
>> Sherman, does the new webrev look ok to push?
>>
>>
>
> (1)ByteToCharJISAutoDetect.java
> ? It appears we should move the maskTable1/2 initialization code out of the
> constructor block.
>
> ?37 ? ? private static byte[] maskTable1 = JISAutoDetect.getByteMask1();
> ?38 ? ? private static byte[] maskTable2 = JISAutoDetect.getByteMask2();
>

Done.  I also made them final.

> (2)EUC_JP_Open.java
>
> 137 ? ? ? ? ? ? j0208Index1 = JIS_X_0208_Solaris_Encoder.getIndex1();
> 138 ? ? ? ? ? ? j0208Index2 = JIS_X_0208_Solaris_Encoder.getIndex2();
>
> ?can be moved out of the constructor as you do for the decoder. better to
> ?keep them consistent (as well as the code in EUC_JP_LINUX)
>

Done.  I made both sets private, static and final as well, and updated
EUC_JP, EUC_JP_LINUX, PCK and SJIS in the same way.

>
> (3)sun/nio/cs/ext/HKSCS.java
>
> - ? ? ? ? ? ?this.big5Dec = big5Dec;
> + ? ? ? ? ? ?Decoder.big5Dec = big5Dec;
>
> Dave is absolutely right here. big5Dec definitely should be an instance
> field instead of static, it's my bug in the original code. It should be
>
> ? ? ? ?private DoubleByte.Decoder big5Dec;
>
> ? ? ? ?protected Decoder(Charset cs,
> ? ? ? ? ? ? ? ? ? ? ? ? ?DoubleByte.Decoder big5Dec,
> ? ? ? ? ? ? ? ? ? ? ? ? ?char[][] b2cBmp, char[][] b2cSupp)
> ? ? ? ?{
> ? ? ? ? ? ?// super(cs, 0.5f, 1.0f);
> ? ? ? ? ? ?// need to extends DoubleByte.Decoder so the
> ? ? ? ? ? ?// sun.io can use it. this implementation
> ? ? ? ? ? ?super(cs, 0.5f, 1.0f, null, null, 0, 0);
> ? ? ? ? ? ?this.big5Dec = big5Dec;
> ? ? ? ? ? ?this.b2cBmp = b2cBmp;
> ? ? ? ? ? ?this.b2cSupp = b2cSupp;
> ? ? ? ?}
>

Cool.  One latent bug fixed too :-)


>
> Thanks,
> Sherman
>
>
>
>
>

New webrev: http://cr.openjdk.java.net/~andrew/warnings/webrev.05/

Ok to push?

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From xueming.shen at oracle.com  Thu Jun 10 15:11:06 2010
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 10 Jun 2010 15:11:06 -0700
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <AANLkTiluxD26wZSDoVe0GBUVylSL9ZO68vjH2P0EdYdG@mail.gmail.com>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>	<4C0D3532.8080808@oracle.com>	<AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>	<4C0D6D04.5090701@oracle.com>	<AANLkTil3ARMaCl-huOb-AVgJwaVIcF9U1LzoA43RC7U6@mail.gmail.com>	<82ocfkn194.fsf@mid.bfk.de>	<AANLkTilaZMJm3zza9JkISmPWzuwxdErj5LIusd-rAZjf@mail.gmail.com>	<4C0FCDC6.9040508@oracle.com>
	<AANLkTiluxD26wZSDoVe0GBUVylSL9ZO68vjH2P0EdYdG@mail.gmail.com>
Message-ID: <4C1162FA.8000808@oracle.com>

Andrew,

Thanks for working on it.

The change looks fine, except one final nit:-)

EUC_JP_Open: #127 & #140
    it appears encoderJ0208 is no longer needed.

Please run those tests at sun/nio/cs before push, I don't really trust 
my own eyes
these days:-)

Sherman
   


Andrew John Hughes wrote:
> On 9 June 2010 18:22, Xueming Shen <xueming.shen at oracle.com> wrote:
>   
>> 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.
>>>>
>>>>
>>>>         
>>> You're right.  I think I mentally read that as an assignment, not an
>>> and operation.
>>>
>>> If I'm reading it right now, it would seem to just be testing the sign
>>> bit.  byte1 < 0 would be clearer if not faster, and I'd be for
>>> changing that, though that probably should be a separate patch.
>>>
>>> Sherman, does the new webrev look ok to push?
>>>
>>>
>>>       
>> (1)ByteToCharJISAutoDetect.java
>>   It appears we should move the maskTable1/2 initialization code out of the
>> constructor block.
>>
>>  37     private static byte[] maskTable1 = JISAutoDetect.getByteMask1();
>>  38     private static byte[] maskTable2 = JISAutoDetect.getByteMask2();
>>
>>     
>
> Done.  I also made them final.
>
>   
>> (2)EUC_JP_Open.java
>>
>> 137             j0208Index1 = JIS_X_0208_Solaris_Encoder.getIndex1();
>> 138             j0208Index2 = JIS_X_0208_Solaris_Encoder.getIndex2();
>>
>>  can be moved out of the constructor as you do for the decoder. better to
>>  keep them consistent (as well as the code in EUC_JP_LINUX)
>>
>>     
>
> Done.  I made both sets private, static and final as well, and updated
> EUC_JP, EUC_JP_LINUX, PCK and SJIS in the same way.
>
>   
>> (3)sun/nio/cs/ext/HKSCS.java
>>
>> -            this.big5Dec = big5Dec;
>> +            Decoder.big5Dec = big5Dec;
>>
>> Dave is absolutely right here. big5Dec definitely should be an instance
>> field instead of static, it's my bug in the original code. It should be
>>
>>        private DoubleByte.Decoder big5Dec;
>>
>>        protected Decoder(Charset cs,
>>                          DoubleByte.Decoder big5Dec,
>>                          char[][] b2cBmp, char[][] b2cSupp)
>>        {
>>            // super(cs, 0.5f, 1.0f);
>>            // need to extends DoubleByte.Decoder so the
>>            // sun.io can use it. this implementation
>>            super(cs, 0.5f, 1.0f, null, null, 0, 0);
>>            this.big5Dec = big5Dec;
>>            this.b2cBmp = b2cBmp;
>>            this.b2cSupp = b2cSupp;
>>        }
>>
>>     
>
> Cool.  One latent bug fixed too :-)
>
>
>   
>> Thanks,
>> Sherman
>>
>>
>>
>>
>>
>>     
>
> New webrev: http://cr.openjdk.java.net/~andrew/warnings/webrev.05/
>
> Ok to push?
>
> Thanks,
>   


From chris.hegarty at oracle.com  Fri Jun 11 05:55:25 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 11 Jun 2010 13:55:25 +0100
Subject: 6934585: TEST_BUG:
	java/nio/channels/AsynchronousSocketChannel/Basic.java
In-Reply-To: <4C1107CC.6070404@oracle.com>
References: <4C1107CC.6070404@oracle.com>
Message-ID: <4C12323D.2000508@oracle.com>

Looks fine.

-Chris.

On 06/10/10 04:42 PM, Alan Bateman wrote:
>
> Chris - do you mind looking at this test fix? The unit test for
> AsynchronousSocketChannel has two sub-tests that connect to fixed host
> (1.2.3.4) assuming it will fail to connect and that the failure is not
> immediate. These assumptions result in intermittent failures. The webrev
> to fix these issues is here:
> http://cr.openjdk.java.net/~alanb/6934585/webrev/
>
> Thanks,
> Alan.

From ahughes at redhat.com  Fri Jun 11 17:35:31 2010
From: ahughes at redhat.com (Andrew John Hughes)
Date: Sat, 12 Jun 2010 01:35:31 +0100
Subject: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in 
	sun/nio/cs
In-Reply-To: <4C1162FA.8000808@oracle.com>
References: <AANLkTinoW7jm5hZiM-OImcHRqvtpb11VeqcLnp-APJDI@mail.gmail.com>
	<4C0D3532.8080808@oracle.com>
	<AANLkTilpHFt2UDFhjfLMx8Z8REXojBpynJ_S6pIV2HOG@mail.gmail.com>
	<4C0D6D04.5090701@oracle.com>
	<AANLkTil3ARMaCl-huOb-AVgJwaVIcF9U1LzoA43RC7U6@mail.gmail.com>
	<82ocfkn194.fsf@mid.bfk.de>
	<AANLkTilaZMJm3zza9JkISmPWzuwxdErj5LIusd-rAZjf@mail.gmail.com>
	<4C0FCDC6.9040508@oracle.com>
	<AANLkTiluxD26wZSDoVe0GBUVylSL9ZO68vjH2P0EdYdG@mail.gmail.com>
	<4C1162FA.8000808@oracle.com>
Message-ID: <AANLkTimBHciNRqyODsvwANi7mg-4_DvM0yb0sCcNubrB@mail.gmail.com>

On 10 June 2010 23:11, Xueming Shen <xueming.shen at oracle.com> wrote:
> Andrew,
>
> Thanks for working on it.
>

Thanks for such a through review process.

> The change looks fine, except one final nit:-)
>
> EUC_JP_Open: #127 & #140
> ? it appears encoderJ0208 is no longer needed.
>

Fixed.

> Please run those tests at sun/nio/cs before push, I don't really trust my
> own eyes
> these days:-)
>

Everything passed that passed before (sun/nio/cs/TestStringCoding
failed before and after with a SecurityException) so I pushed the fix:

http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c849dc20dc85

> Sherman
>
>
> Andrew John Hughes wrote:
>>
>> On 9 June 2010 18:22, Xueming Shen <xueming.shen at oracle.com> wrote:
>>
>>>
>>> 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.
>>>>>
>>>>>
>>>>>
>>>>
>>>> You're right. ?I think I mentally read that as an assignment, not an
>>>> and operation.
>>>>
>>>> If I'm reading it right now, it would seem to just be testing the sign
>>>> bit. ?byte1 < 0 would be clearer if not faster, and I'd be for
>>>> changing that, though that probably should be a separate patch.
>>>>
>>>> Sherman, does the new webrev look ok to push?
>>>>
>>>>
>>>>
>>>
>>> (1)ByteToCharJISAutoDetect.java
>>> ?It appears we should move the maskTable1/2 initialization code out of
>>> the
>>> constructor block.
>>>
>>> ?37 ? ? private static byte[] maskTable1 = JISAutoDetect.getByteMask1();
>>> ?38 ? ? private static byte[] maskTable2 = JISAutoDetect.getByteMask2();
>>>
>>>
>>
>> Done. ?I also made them final.
>>
>>
>>>
>>> (2)EUC_JP_Open.java
>>>
>>> 137 ? ? ? ? ? ? j0208Index1 = JIS_X_0208_Solaris_Encoder.getIndex1();
>>> 138 ? ? ? ? ? ? j0208Index2 = JIS_X_0208_Solaris_Encoder.getIndex2();
>>>
>>> ?can be moved out of the constructor as you do for the decoder. better to
>>> ?keep them consistent (as well as the code in EUC_JP_LINUX)
>>>
>>>
>>
>> Done. ?I made both sets private, static and final as well, and updated
>> EUC_JP, EUC_JP_LINUX, PCK and SJIS in the same way.
>>
>>
>>>
>>> (3)sun/nio/cs/ext/HKSCS.java
>>>
>>> - ? ? ? ? ? ?this.big5Dec = big5Dec;
>>> + ? ? ? ? ? ?Decoder.big5Dec = big5Dec;
>>>
>>> Dave is absolutely right here. big5Dec definitely should be an instance
>>> field instead of static, it's my bug in the original code. It should be
>>>
>>> ? ? ? private DoubleByte.Decoder big5Dec;
>>>
>>> ? ? ? protected Decoder(Charset cs,
>>> ? ? ? ? ? ? ? ? ? ? ? ? DoubleByte.Decoder big5Dec,
>>> ? ? ? ? ? ? ? ? ? ? ? ? char[][] b2cBmp, char[][] b2cSupp)
>>> ? ? ? {
>>> ? ? ? ? ? // super(cs, 0.5f, 1.0f);
>>> ? ? ? ? ? // need to extends DoubleByte.Decoder so the
>>> ? ? ? ? ? // sun.io can use it. this implementation
>>> ? ? ? ? ? super(cs, 0.5f, 1.0f, null, null, 0, 0);
>>> ? ? ? ? ? this.big5Dec = big5Dec;
>>> ? ? ? ? ? this.b2cBmp = b2cBmp;
>>> ? ? ? ? ? this.b2cSupp = b2cSupp;
>>> ? ? ? }
>>>
>>>
>>
>> Cool. ?One latent bug fixed too :-)
>>
>>
>>
>>>
>>> Thanks,
>>> Sherman
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> New webrev: http://cr.openjdk.java.net/~andrew/warnings/webrev.05/
>>
>> Ok to push?
>>
>> Thanks,
>>
>
>


Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From Alan.Bateman at oracle.com  Mon Jun 14 10:55:57 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 14 Jun 2010 18:55:57 +0100
Subject: 6961062: (dc) Several DatagramChannel tests timeout or fail with
	"address already in use"
Message-ID: <4C166D2D.2030201@oracle.com>

Chris - I need a reviewer to change some of the older DatagramChannel 
tests so they are don't use a fixed port (8888). They tests will hang 
indefinitely or fail with "address already in use" when port 8888 is 
used by something else. The webrev with the changes is here:
    http://cr.openjdk.java.net/~alanb/6961062/webrev/

Thanks,
Alan.

From chris.hegarty at oracle.com  Tue Jun 15 01:42:19 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 15 Jun 2010 09:42:19 +0100
Subject: 6961062: (dc) Several DatagramChannel tests timeout or fail with
	"address already in use"
In-Reply-To: <4C166D2D.2030201@oracle.com>
References: <4C166D2D.2030201@oracle.com>
Message-ID: <4C173CEB.4040402@oracle.com>

Alan,

The changes look fine. Any reason you're using the socket adapters to 
retrieve the port ;-)

-Chris.

Alan Bateman wrote:
> Chris - I need a reviewer to change some of the older DatagramChannel 
> tests so they are don't use a fixed port (8888). They tests will hang 
> indefinitely or fail with "address already in use" when port 8888 is 
> used by something else. The webrev with the changes is here:
>    http://cr.openjdk.java.net/~alanb/6961062/webrev/
> 
> Thanks,
> Alan.

From Alan.Bateman at oracle.com  Tue Jun 15 02:34:15 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 15 Jun 2010 10:34:15 +0100
Subject: 6961062: (dc) Several DatagramChannel tests timeout or fail with
	"address already in use"
In-Reply-To: <4C173CEB.4040402@oracle.com>
References: <4C166D2D.2030201@oracle.com> <4C173CEB.4040402@oracle.com>
Message-ID: <4C174917.6080401@oracle.com>

Chris Hegarty wrote:
> Alan,
>
> The changes look fine. Any reason you're using the socket adapters to 
> retrieve the port ;-)
>
> -Chris.
Thanks. Using the socket adapter is the simplest way to retrieve the 
port for these tests (these tests use the socket adapters anyway, and it 
avoids casting a SocketAddress to an InetSocketAddress).

-Alan.


From Alan.Bateman at oracle.com  Tue Jun 15 04:19:38 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 15 Jun 2010 12:19:38 +0100
Subject: 6932744: TEST_BUG: java/nio/channels/Selector/OpRead.java failing
Message-ID: <4C1761CA.7060607@oracle.com>

Chris - here's another intermittent test failure that Kelly is seeing. A 
really old test, OpRead, connects to a daytime service and expects the 
channel to be readable within 1 second. To make the test more robust 
I've replaced the dependency on the daytime service with a loopback 
connection. The webrev is here:
    http://cr.openjdk.java.net/~alanb/6932744/webrev/

Thanks,
Alan.

From chris.hegarty at oracle.com  Tue Jun 15 08:03:08 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 15 Jun 2010 16:03:08 +0100
Subject: 6932744: TEST_BUG: java/nio/channels/Selector/OpRead.java failing
In-Reply-To: <4C1761CA.7060607@oracle.com>
References: <4C1761CA.7060607@oracle.com>
Message-ID: <4C17962C.5060801@oracle.com>

The changes look fine.

One minor comment. Will InetAddress.getLocalHost ever throw 
UnknownHostException (if the hostname is not in DNS)? You could simply 
create the InetSocketAddress with "localhost". Either is fine with me.

-Chris.

Alan Bateman wrote:
> Chris - here's another intermittent test failure that Kelly is seeing. A 
> really old test, OpRead, connects to a daytime service and expects the 
> channel to be readable within 1 second. To make the test more robust 
> I've replaced the dependency on the daytime service with a loopback 
> connection. The webrev is here:
>    http://cr.openjdk.java.net/~alanb/6932744/webrev/
> 
> Thanks,
> Alan.

From Alan.Bateman at oracle.com  Tue Jun 15 08:25:00 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 15 Jun 2010 16:25:00 +0100
Subject: 6932744: TEST_BUG: java/nio/channels/Selector/OpRead.java failing
In-Reply-To: <4C17962C.5060801@oracle.com>
References: <4C1761CA.7060607@oracle.com> <4C17962C.5060801@oracle.com>
Message-ID: <4C179B4C.6020708@oracle.com>

Chris Hegarty wrote:
> The changes look fine.
>
> One minor comment. Will InetAddress.getLocalHost ever throw 
> UnknownHostException (if the hostname is not in DNS)? You could simply 
> create the InetSocketAddress with "localhost". Either is fine with me.
Thanks. I think I'll leave it as is (as I'm pretty sure we would have 
test failures across the board with both the networking and NIO tests if 
getLocalHost were to throw UHE).

So I've one more for you. The 
test/java/nio/channels/SocketChannel/OpenLeak.java creates a security 
manager and cannot run in samevm mode. The bug for this is 6961358 and 
the fix is to simply run it in othervm mode (and remove it from the 
problem list).


diff --git a/test/java/nio/channels/SocketChannel/OpenLeak.java 
b/test/java/nio/channels/SocketChannel/OpenLeak.java
--- a/test/java/nio/channels/SocketChannel/OpenLeak.java
+++ b/test/java/nio/channels/SocketChannel/OpenLeak.java
@@ -25,6 +25,8 @@
  * @bug 6548464
  * @summary SocketChannel.open(SocketAddress) leaks file descriptor if
  *     connection cannot be established
+ * @build OpenLeak
+ * @run main/othervm OpenLeak
  */

Do you mind reviewing this too?

-Alan




From chris.hegarty at oracle.com  Tue Jun 15 08:31:30 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 15 Jun 2010 16:31:30 +0100
Subject: 6932744: TEST_BUG: java/nio/channels/Selector/OpRead.java failing
In-Reply-To: <4C179B4C.6020708@oracle.com>
References: <4C1761CA.7060607@oracle.com> <4C17962C.5060801@oracle.com>
	<4C179B4C.6020708@oracle.com>
Message-ID: <4C179CD2.3030506@oracle.com>

This is fine too.

-Chris

Alan Bateman wrote:
> Chris Hegarty wrote:
>> The changes look fine.
>>
>> One minor comment. Will InetAddress.getLocalHost ever throw 
>> UnknownHostException (if the hostname is not in DNS)? You could simply 
>> create the InetSocketAddress with "localhost". Either is fine with me.
> Thanks. I think I'll leave it as is (as I'm pretty sure we would have 
> test failures across the board with both the networking and NIO tests if 
> getLocalHost were to throw UHE).
> 
> So I've one more for you. The 
> test/java/nio/channels/SocketChannel/OpenLeak.java creates a security 
> manager and cannot run in samevm mode. The bug for this is 6961358 and 
> the fix is to simply run it in othervm mode (and remove it from the 
> problem list).
> 
> 
> diff --git a/test/java/nio/channels/SocketChannel/OpenLeak.java 
> b/test/java/nio/channels/SocketChannel/OpenLeak.java
> --- a/test/java/nio/channels/SocketChannel/OpenLeak.java
> +++ b/test/java/nio/channels/SocketChannel/OpenLeak.java
> @@ -25,6 +25,8 @@
>  * @bug 6548464
>  * @summary SocketChannel.open(SocketAddress) leaks file descriptor if
>  *     connection cannot be established
> + * @build OpenLeak
> + * @run main/othervm OpenLeak
>  */
> 
> Do you mind reviewing this too?
> 
> -Alan
> 
> 
> 

From Alan.Bateman at oracle.com  Wed Jun 16 03:54:21 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Jun 2010 11:54:21 +0100
Subject: 6961630: TEST_BUG: Several SocketChannel and Selector tests can fail
	with "address already in use"
Message-ID: <4C18AD5D.4040104@oracle.com>

Chris - do you mind looking at yet another webrev to address further 
intermittent failures. It's mostly older Selector and SocketChannel 
tests using fixed ports. Also one SelectorProvider test uses a small 
timeout causing it to fail periodically when the machine is loaded.  The 
webrev is here:
    http://cr.openjdk.java.net/~alanb/6961630/webrev/

Thanks,
Alan.



From chris.hegarty at oracle.com  Wed Jun 16 05:16:45 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 16 Jun 2010 13:16:45 +0100
Subject: 6961630: TEST_BUG: Several SocketChannel and Selector tests can
	fail with "address already in use"
In-Reply-To: <4C18AD5D.4040104@oracle.com>
References: <4C18AD5D.4040104@oracle.com>
Message-ID: <4C18C0AD.0@oracle.com>

The changes look fine.

I much prefer what you are doing by creating and binding the server 
socket during the construction of the server side, removing the 
readiness timing window.

-Chris.

On 06/16/10 11:54 AM, Alan Bateman wrote:
> Chris - do you mind looking at yet another webrev to address further
> intermittent failures. It's mostly older Selector and SocketChannel
> tests using fixed ports. Also one SelectorProvider test uses a small
> timeout causing it to fail periodically when the machine is loaded. The
> webrev is here:
> http://cr.openjdk.java.net/~alanb/6961630/webrev/
>
> Thanks,
> Alan.
>
>

From Alan.Bateman at oracle.com  Wed Jun 16 12:08:34 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Jun 2010 20:08:34 +0100
Subject: 6395224: (so) SocketChannel writer blocked on large buffer is not
	preempted by close method (vista)
Message-ID: <4C192132.8020408@oracle.com>


The test java/nio/channels/AsyncCloseAndInterrupt.java has been failing 
on Windows for a long time. There are a couple of issues.

The main one is that we can't asynchronously close a SocketChannel if 
there is a thread doing I/O on the channel's socket with a buffer size 
of 128k or more. The issue applies to all versions of Windows from 
Windows Server 2003 to present day. It can only be solved by limiting 
the buffer size to less than 128k. Classic networking doesn't run into 
this because it limits the buffer size to 64k on Windows (that limit 
stems from a long standing Microsoft recommendation to only use buffers 
of 64k or smaller).  While this isn't a great solution it should reduce 
the incidents of WSAENOBUFS that come up periodically with applications 
doing blocking I/O with huge buffers. I hope some day to separate the 
blocking and non-blocking paths so this should confine this to blocking I/O.

The other issues are test related. When testing DatagramChannel it binds 
to a local address but attempts to connect to the loopback address 
(different interface). This is corrected by binding to the loopback 
address. The SocketChannel connect/finishConnect tests need to be able 
to "saturate" the connection backlog, which just isn't feasible on 
Window Server editions (no problem on the consumer editions). It's not 
clear that we can create robust tests for this so for now, these 
sub-tests are skipped on Windows.

I've put the webrev here:
  http://cr.openjdk.java.net/~alanb/6395224/webrev/

Thanks,
Alan.





From chris.hegarty at oracle.com  Thu Jun 17 01:55:17 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 17 Jun 2010 09:55:17 +0100
Subject: 6395224: (so) SocketChannel writer blocked on large buffer is
	not preempted by close method (vista)
In-Reply-To: <4C192132.8020408@oracle.com>
References: <4C192132.8020408@oracle.com>
Message-ID: <4C19E2F5.1050204@oracle.com>

Alan,

I agree, the solution is not ideal but I think is probably the best we 
can do. I look forward to your changes to separate the blocking and 
non-blocking paths.

I approved this change.

-Chris.

Alan Bateman wrote:
> 
> The test java/nio/channels/AsyncCloseAndInterrupt.java has been failing 
> on Windows for a long time. There are a couple of issues.
> 
> The main one is that we can't asynchronously close a SocketChannel if 
> there is a thread doing I/O on the channel's socket with a buffer size 
> of 128k or more. The issue applies to all versions of Windows from 
> Windows Server 2003 to present day. It can only be solved by limiting 
> the buffer size to less than 128k. Classic networking doesn't run into 
> this because it limits the buffer size to 64k on Windows (that limit 
> stems from a long standing Microsoft recommendation to only use buffers 
> of 64k or smaller).  While this isn't a great solution it should reduce 
> the incidents of WSAENOBUFS that come up periodically with applications 
> doing blocking I/O with huge buffers. I hope some day to separate the 
> blocking and non-blocking paths so this should confine this to blocking 
> I/O.
> 
> The other issues are test related. When testing DatagramChannel it binds 
> to a local address but attempts to connect to the loopback address 
> (different interface). This is corrected by binding to the loopback 
> address. The SocketChannel connect/finishConnect tests need to be able 
> to "saturate" the connection backlog, which just isn't feasible on 
> Window Server editions (no problem on the consumer editions). It's not 
> clear that we can create robust tests for this so for now, these 
> sub-tests are skipped on Windows.
> 
> I've put the webrev here:
>  http://cr.openjdk.java.net/~alanb/6395224/webrev/
> 
> Thanks,
> Alan.
> 
> 
> 
> 

From Alan.Bateman at oracle.com  Thu Jun 17 11:23:43 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 17 Jun 2010 19:23:43 +0100
Subject: 4981129: (dc) DatagramSocket created by DatagramChannel does not
	provide sender info
Message-ID: <4C1A682F.5030301@oracle.com>


If a DatagramChannel's socket adapter is used to receive a datagram then 
it doesn't set the DatagramPacket's socket address (IP address/port).  
 From the bugID you can tell that this is a long standing bug. The 
changes to fix are very simple and I've put the webrev here:
    http://cr.openjdk.java.net/~alanb/4981129/webrev/

Thanks,
Alan.

From chris.hegarty at oracle.com  Fri Jun 18 02:57:19 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 18 Jun 2010 10:57:19 +0100
Subject: 4981129: (dc) DatagramSocket created by DatagramChannel does
	not provide sender info
In-Reply-To: <4C1A682F.5030301@oracle.com>
References: <4C1A682F.5030301@oracle.com>
Message-ID: <4C1B42FF.6050702@oracle.com>

The change looks good.

One minor comment, is it possible for 
DatagramChannelImpl.receive(ByteBuffer) to return the address from the 
previous packet received? Asyn interrupt or close? I'm not sure.

-Chris.

On 06/17/10 07:23 PM, Alan Bateman wrote:
>
> If a DatagramChannel's socket adapter is used to receive a datagram then
> it doesn't set the DatagramPacket's socket address (IP address/port).
>  From the bugID you can tell that this is a long standing bug. The
> changes to fix are very simple and I've put the webrev here:
> http://cr.openjdk.java.net/~alanb/4981129/webrev/
>
> Thanks,
> Alan.

From Alan.Bateman at oracle.com  Fri Jun 18 04:40:52 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 18 Jun 2010 12:40:52 +0100
Subject: 4981129: (dc) DatagramSocket created by DatagramChannel does
	not provide sender info
In-Reply-To: <4C1B42FF.6050702@oracle.com>
References: <4C1A682F.5030301@oracle.com> <4C1B42FF.6050702@oracle.com>
Message-ID: <4C1B5B44.3090305@oracle.com>

Chris Hegarty wrote:
> The change looks good.
>
> One minor comment, is it possible for 
> DatagramChannelImpl.receive(ByteBuffer) to return the address from the 
> previous packet received? Asyn interrupt or close? I'm not sure.
>
> -Chris.
Thanks for looking at this one. The DatagramChannel.receive(ByteBuffer) 
method returns the datagram's source address. If it interrupted or the 
channel is closed then an exception is thrown.

-Alan.

From forax at univ-mlv.fr  Sat Jun 19 05:04:02 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 19 Jun 2010 14:04:02 +0200
Subject: Dependencies between classe of NIO2
Message-ID: <4C1CB232.7070004@univ-mlv.fr>

It seems that Path as lot of dependencies.

Path path = Paths.get(".");
System.out.println(path.getName());

I wonder if some of them can be removed.

$java -verbose:class NioFileTest
...
[Loaded java.nio.file.Paths from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.FileSystems from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.FileSystems$DefaultFileSystemHolder from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.FileSystems$DefaultFileSystemHolder$1 from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.DefaultFileSystemProvider from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.DefaultFileSystemProvider$1 from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.spi.FileSystemProvider from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.UnixFileSystemProvider from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.LinuxFileSystemProvider from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.FileSystem from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.UnixFileSystem from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.LinuxFileSystem from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.attribute.UserPrincipalLookupService from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.UnixFileSystem$4 from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.FileRef from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.Watchable from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.Path from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.AbstractPath from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.UnixPath from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.DirectoryStream$Filter from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.AbstractPath$1 from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.WatchEvent$Modifier from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.UnixNativeDispatcher from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.UnixNativeDispatcher$1 from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.attribute.BasicFileAttributes from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.nio.file.attribute.PosixFileAttributes from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.UnixFileAttributes from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.UnixFileStoreAttributes from 
/usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.UnixMountEntry from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded sun.nio.fs.Util from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.net.URI from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
[Loaded java.net.URI$Parser from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]

R?mi

From Alan.Bateman at oracle.com  Sun Jun 20 01:20:12 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 20 Jun 2010 09:20:12 +0100
Subject: Dependencies between classe of NIO2
In-Reply-To: <4C1CB232.7070004@univ-mlv.fr>
References: <4C1CB232.7070004@univ-mlv.fr>
Message-ID: <4C1DCF3C.80509@oracle.com>

R?mi Forax wrote:
> It seems that Path as lot of dependencies.
>
> Path path = Paths.get(".");
> System.out.println(path.getName());
>
> I wonder if some of them can be removed.
Thanks R?mi. I'll create a bug for this. A few initial comments below.

> :
> [Loaded java.nio.file.attribute.UserPrincipalLookupService from 
> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> [Loaded sun.nio.fs.UnixFileSystem$4 from 
> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
This is the initialization of UnixFileSystem.theLookupService, which 
should be changed to be lazily initialized.

> :
> [Loaded java.nio.file.DirectoryStream$Filter from 
> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> [Loaded sun.nio.fs.AbstractPath$1 from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> [Loaded java.nio.file.WatchEvent$Modifier from 
> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
These are the initialization of AbstractPath.acceptAllFilter and 
AbstractPath.NO_MODIFIERS. These should be changed too.

> [Loaded sun.nio.fs.UnixNativeDispatcher from 
> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> [Loaded sun.nio.fs.UnixNativeDispatcher$1 from 
> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> [Loaded java.nio.file.attribute.BasicFileAttributes from 
> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> [Loaded java.nio.file.attribute.PosixFileAttributes from 
> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> [Loaded sun.nio.fs.UnixFileAttributes from 
> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> [Loaded sun.nio.fs.UnixFileStoreAttributes from 
> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> [Loaded sun.nio.fs.UnixMountEntry from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
This a a bit trickery as it's the initialization of the native 
dispatcher (and causes initializations of a a few Unix* classes that are 
known to native code) but should be re-examined.

> [Loaded sun.nio.fs.Util from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
If I remember correctly, this class came about about String.split loaded 
all of regex. Sherman has since pushed changes (6840246) that probably 
means we can get rid of the Util class.

-Alan.

From forax at univ-mlv.fr  Mon Jun 21 15:22:32 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 22 Jun 2010 00:22:32 +0200
Subject: Dependencies between classes of NIO2
In-Reply-To: <4C1DCF3C.80509@oracle.com>
References: <4C1CB232.7070004@univ-mlv.fr> <4C1DCF3C.80509@oracle.com>
Message-ID: <4C1FE628.2080705@univ-mlv.fr>

Cool :)

Thank you,
R?mi

Le 20/06/2010 10:20, Alan Bateman a ?crit :
> R?mi Forax wrote:
>> It seems that Path as lot of dependencies.
>>
>> Path path = Paths.get(".");
>> System.out.println(path.getName());
>>
>> I wonder if some of them can be removed.
> Thanks R?mi. I'll create a bug for this. A few initial comments below.
>
>> :
>> [Loaded java.nio.file.attribute.UserPrincipalLookupService from 
>> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
>> [Loaded sun.nio.fs.UnixFileSystem$4 from 
>> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> This is the initialization of UnixFileSystem.theLookupService, which 
> should be changed to be lazily initialized.
>
>> :
>> [Loaded java.nio.file.DirectoryStream$Filter from 
>> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
>> [Loaded sun.nio.fs.AbstractPath$1 from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
>> [Loaded java.nio.file.WatchEvent$Modifier from 
>> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> These are the initialization of AbstractPath.acceptAllFilter and 
> AbstractPath.NO_MODIFIERS. These should be changed too.
>
>> [Loaded sun.nio.fs.UnixNativeDispatcher from 
>> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
>> [Loaded sun.nio.fs.UnixNativeDispatcher$1 from 
>> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
>> [Loaded java.nio.file.attribute.BasicFileAttributes from 
>> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
>> [Loaded java.nio.file.attribute.PosixFileAttributes from 
>> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
>> [Loaded sun.nio.fs.UnixFileAttributes from 
>> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
>> [Loaded sun.nio.fs.UnixFileStoreAttributes from 
>> /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
>> [Loaded sun.nio.fs.UnixMountEntry from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> This a a bit trickery as it's the initialization of the native 
> dispatcher (and causes initializations of a a few Unix* classes that 
> are known to native code) but should be re-examined.
>
>> [Loaded sun.nio.fs.Util from /usr/jdk/jdk1.7.0/jre/lib/rt.jar]
> If I remember correctly, this class came about about String.split 
> loaded all of regex. Sherman has since pushed changes (6840246) that 
> probably means we can get rid of the Util class.
>
> -Alan.


From Alan.Bateman at oracle.com  Tue Jun 22 09:41:13 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 22 Jun 2010 17:41:13 +0100
Subject: 6963027: TEST_BUG: channels and buffer tests need to run in samevm
	mode
Message-ID: <4C20E7A9.5080504@oracle.com>


I've taken a pass over the nio tests so that the jdk_nio2 test target 
(run the buffers and channels tests) now runs in samevm mode. 

The main thing with running tests in this mode is that tests need to 
release resources so that subsequent tests don't fail because all file 
descriptors are used or all socket buffers are exhausted. There are a 
couple of tests that are essentially mini-stress tests and these have 
been known to cause problems for tests that run subsequently. I've 
dialed-down several of these tests. There are a couple of tests that 
I've had to change to run explicitly in their own VM. There are various 
reasons for this, but it's mostly the tests that use memory-mapped 
files. Along the way I fixed a few other random issues but for the most 
part, the changes are easy to review.

The webrev is here:
  http://cr.openjdk.java.net/~alanb/6963027/webrev/

Kelly - I've changed test/Makefile to run this batch in samevm mode. It 
may be that we need to do a bit of re-balancing to even up the run times 
when running several batches concurrently (maybe move the buffer tests 
to jdk_nio1, or jdk_nio3 once it runs in samevm mode).

-Alan.

From kelly.ohair at oracle.com  Tue Jun 22 10:34:37 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 22 Jun 2010 10:34:37 -0700
Subject: 6963027: TEST_BUG: channels and buffer tests need to run in
	samevm mode
In-Reply-To: <4C20E7A9.5080504@oracle.com>
References: <4C20E7A9.5080504@oracle.com>
Message-ID: <5665C6F1-0615-4631-BF2F-5E14E7E5A690@oracle.com>


On Jun 22, 2010, at 9:41 AM, Alan Bateman wrote:

>
> I've taken a pass over the nio tests so that the jdk_nio2 test  
> target (run the buffers and channels tests) now runs in samevm mode.
> The main thing with running tests in this mode is that tests need to  
> release resources so that subsequent tests don't fail because all  
> file descriptors are used or all socket buffers are exhausted. There  
> are a couple of tests that are essentially mini-stress tests and  
> these have been known to cause problems for tests that run  
> subsequently. I've dialed-down several of these tests. There are a  
> couple of tests that I've had to change to run explicitly in their  
> own VM. There are various reasons for this, but it's mostly the  
> tests that use memory-mapped files. Along the way I fixed a few  
> other random issues but for the most part, the changes are easy to  
> review.
>
> The webrev is here:
> http://cr.openjdk.java.net/~alanb/6963027/webrev/
>
> Kelly - I've changed test/Makefile to run this batch in samevm mode.  
> It may be that we need to do a bit of re-balancing to even up the  
> run times when running several batches concurrently (maybe move the  
> buffer tests to jdk_nio1, or jdk_nio3 once it runs in samevm mode).

Great stuff! Thanks Alan.

I looked over the Makefile and the more obvious 'othervm' additions,  
which look fine.
Can't attest to the detailed changes to some of the tests, might be  
better to have someone
else take a look at them, but as far as I'm concerned, I approve, and  
appreciate it.

-kto

>
> -Alan.


From chris.hegarty at oracle.com  Wed Jun 23 05:25:34 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 23 Jun 2010 13:25:34 +0100
Subject: 6963027: TEST_BUG: channels and buffer tests need to run in samevm
	mode
In-Reply-To: <4C20E7A9.5080504@oracle.com>
References: <4C20E7A9.5080504@oracle.com>
Message-ID: <4C21FD3E.4090106@oracle.com>

Alan,

I've taken a look at the the patch file and the changes seem fine.

One question, do we really need the @build tag when changing to othervm 
or is this to force recompilation if there was a previous run?

-Chris.

On 06/22/10 05:41 PM, Alan Bateman wrote:
>
> I've taken a pass over the nio tests so that the jdk_nio2 test target
> (run the buffers and channels tests) now runs in samevm mode.
> The main thing with running tests in this mode is that tests need to
> release resources so that subsequent tests don't fail because all file
> descriptors are used or all socket buffers are exhausted. There are a
> couple of tests that are essentially mini-stress tests and these have
> been known to cause problems for tests that run subsequently. I've
> dialed-down several of these tests. There are a couple of tests that
> I've had to change to run explicitly in their own VM. There are various
> reasons for this, but it's mostly the tests that use memory-mapped
> files. Along the way I fixed a few other random issues but for the most
> part, the changes are easy to review.
>
> The webrev is here:
> http://cr.openjdk.java.net/~alanb/6963027/webrev/
>
> Kelly - I've changed test/Makefile to run this batch in samevm mode. It
> may be that we need to do a bit of re-balancing to even up the run times
> when running several batches concurrently (maybe move the buffer tests
> to jdk_nio1, or jdk_nio3 once it runs in samevm mode).
>
> -Alan.

From Alan.Bateman at oracle.com  Wed Jun 23 05:43:56 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Jun 2010 13:43:56 +0100
Subject: 6963027: TEST_BUG: channels and buffer tests need to run in samevm
	mode
In-Reply-To: <4C21FD3E.4090106@oracle.com>
References: <4C20E7A9.5080504@oracle.com> <4C21FD3E.4090106@oracle.com>
Message-ID: <4C22018C.6000308@oracle.com>

Chris Hegarty wrote:
> Alan,
>
> I've taken a look at the the patch file and the changes seem fine.
>
> One question, do we really need the @build tag when changing to 
> othervm or is this to force recompilation if there was a previous run?
Thanks for going through the changes.

The @build tag is really only needed for the tests that use a library 
directory list and a few other cases (like shell tests). I don't know 
how common it is to re-run and use previously compiled classes but I can 
remove the @build tags.

-Alan.

From chris.hegarty at oracle.com  Wed Jun 23 05:46:58 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 23 Jun 2010 13:46:58 +0100
Subject: 6963027: TEST_BUG: channels and buffer tests need to run in samevm
	mode
In-Reply-To: <4C22018C.6000308@oracle.com>
References: <4C20E7A9.5080504@oracle.com> <4C21FD3E.4090106@oracle.com>
	<4C22018C.6000308@oracle.com>
Message-ID: <4C220242.9000000@oracle.com>

On 06/23/10 01:43 PM, Alan Bateman wrote:
> Chris Hegarty wrote:
>> Alan,
>>
>> I've taken a look at the the patch file and the changes seem fine.
>>
>> One question, do we really need the @build tag when changing to
>> othervm or is this to force recompilation if there was a previous run?
> Thanks for going through the changes.
>
> The @build tag is really only needed for the tests that use a library
> directory list and a few other cases (like shell tests). I don't know
> how common it is to re-run and use previously compiled classes but I can
> remove the @build tags.

I don't have a problem with them, just a question. In or out, I'm ok with.

-Chris.

>
> -Alan.

From Alan.Bateman at oracle.com  Thu Jun 24 05:13:35 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Jun 2010 13:13:35 +0100
Subject: 6963828: TEST_BUG: java/nio/channels/FileTransfer.java takes too
	long (win)
Message-ID: <4C234BEF.2030405@oracle.com>


One of FileChannel tests takes an age to run on Windows (10 or 11 
minutes in some cases). All the time is spent creating a 4GB file used 
by one of the sub-tests. The change proposed here creates this big file 
as a sparse file. The result is that the test run is now sub-second on 
all machines that I tried. The webrev is here:
    http://cr.openjdk.java.net/~alanb/6963828/webrev/

-Alan.






From forax at univ-mlv.fr  Thu Jun 24 05:26:14 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 24 Jun 2010 14:26:14 +0200
Subject: 6963828: TEST_BUG: java/nio/channels/FileTransfer.java takes
	too	long (win)
In-Reply-To: <4C234BEF.2030405@oracle.com>
References: <4C234BEF.2030405@oracle.com>
Message-ID: <4C234EE6.6090103@univ-mlv.fr>

Le 24/06/2010 14:13, Alan Bateman a ?crit :
>
> One of FileChannel tests takes an age to run on Windows (10 or 11 
> minutes in some cases). All the time is spent creating a 4GB file used 
> by one of the sub-tests. The change proposed here creates this big 
> file as a sparse file. The result is that the test run is now 
> sub-second on all machines that I tried. The webrev is here:
>    http://cr.openjdk.java.net/~alanb/6963828/webrev/
>
> -Alan.

Alan, is there a way to create a RandomAccessFile form a Path ?

R?mi


From Alan.Bateman at oracle.com  Thu Jun 24 05:45:26 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Jun 2010 13:45:26 +0100
Subject: 6963828: TEST_BUG: java/nio/channels/FileTransfer.java takes
	too	long (win)
In-Reply-To: <4C234EE6.6090103@univ-mlv.fr>
References: <4C234BEF.2030405@oracle.com> <4C234EE6.6090103@univ-mlv.fr>
Message-ID: <4C235366.1000100@oracle.com>

R?mi Forax wrote:
> :
> Alan, is there a way to create a RandomAccessFile form a Path ?
Not directly so it requires using the String representation, eg:

  Path file = ..
  RandomAccessFile raf = new RandomAccessFile(file.toString(), "rw")

-Alan.





From forax at univ-mlv.fr  Thu Jun 24 06:25:24 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 24 Jun 2010 15:25:24 +0200
Subject: 6963828: TEST_BUG: java/nio/channels/FileTransfer.java takes
	too	long (win)
In-Reply-To: <4C235366.1000100@oracle.com>
References: <4C234BEF.2030405@oracle.com> <4C234EE6.6090103@univ-mlv.fr>
	<4C235366.1000100@oracle.com>
Message-ID: <4C235CC4.8090107@univ-mlv.fr>

Le 24/06/2010 14:45, Alan Bateman a ?crit :
> R?mi Forax wrote:
>> :
>> Alan, is there a way to create a RandomAccessFile form a Path ?
> Not directly so it requires using the String representation, eg:
>
>  Path file = ..
>  RandomAccessFile raf = new RandomAccessFile(file.toString(), "rw")
>
> -Alan.

It seems there is no way to directly create a FileChannel from a Path.
You have to convert the path to a string, create a 
FileInputStream/FileOutputStream
or a RandomAccessFile and called getChannel on it.

R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100624/1bc70d8c/attachment.html 

From Alan.Bateman at oracle.com  Thu Jun 24 06:31:30 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Jun 2010 14:31:30 +0100
Subject: 6963828: TEST_BUG: java/nio/channels/FileTransfer.java takes
	too	long (win)
In-Reply-To: <4C235CC4.8090107@univ-mlv.fr>
References: <4C234BEF.2030405@oracle.com> <4C234EE6.6090103@univ-mlv.fr>
	<4C235366.1000100@oracle.com> <4C235CC4.8090107@univ-mlv.fr>
Message-ID: <4C235E32.9060703@oracle.com>

R?mi Forax wrote:
> :
> It seems there is no way to directly create a FileChannel from a Path.
> You have to convert the path to a string, create a 
> FileInputStream/FileOutputStream
> or a RandomAccessFile and called getChannel on it.
Ah, you might have missed FileChannel.open.

Another way is to cast the return from Path's newByteChannel to a 
FileChannel. That is only guaranteed to work with the default provider 
of course.

-Alan.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100624/d0af7bfa/attachment.html 

From forax at univ-mlv.fr  Thu Jun 24 07:47:57 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 24 Jun 2010 16:47:57 +0200
Subject: 6963828: TEST_BUG: java/nio/channels/FileTransfer.java takes
	too	long (win)
In-Reply-To: <4C235E32.9060703@oracle.com>
References: <4C234BEF.2030405@oracle.com> <4C234EE6.6090103@univ-mlv.fr>
	<4C235366.1000100@oracle.com> <4C235CC4.8090107@univ-mlv.fr>
	<4C235E32.9060703@oracle.com>
Message-ID: <4C23701D.2070202@univ-mlv.fr>

Le 24/06/2010 15:31, Alan Bateman a ?crit :
> R?mi Forax wrote:
>> :
>> It seems there is no way to directly create a FileChannel from a Path.
>> You have to convert the path to a string, create a 
>> FileInputStream/FileOutputStream
>> or a RandomAccessFile and called getChannel on it.
> Ah, you might have missed FileChannel.open.
>
> Another way is to cast the return from Path's newByteChannel to a 
> FileChannel. That is only guaranteed to work with the default provider 
> of course.
>
> -Alan.
>

Ok, thank you.

R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100624/06edd844/attachment.html 

From chris.hegarty at oracle.com  Fri Jun 25 07:18:17 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 25 Jun 2010 15:18:17 +0100
Subject: 6963828: TEST_BUG: java/nio/channels/FileTransfer.java takes
	too long (win)
In-Reply-To: <4C234BEF.2030405@oracle.com>
References: <4C234BEF.2030405@oracle.com>
Message-ID: <4C24BAA9.7050808@oracle.com>

This change looks fine.

-Chris.

On 06/24/10 01:13 PM, Alan Bateman wrote:
>
> One of FileChannel tests takes an age to run on Windows (10 or 11
> minutes in some cases). All the time is spent creating a 4GB file used
> by one of the sub-tests. The change proposed here creates this big file
> as a sparse file. The result is that the test run is now sub-second on
> all machines that I tried. The webrev is here:
> http://cr.openjdk.java.net/~alanb/6963828/webrev/
>
> -Alan.
>
>
>
>
>

From Alan.Bateman at oracle.com  Fri Jun 25 10:27:12 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 25 Jun 2010 18:27:12 +0100
Subject: 6213702: (so) non-blocking sockets with TCP urgent disabled get still
	selected for read ops (win)
Message-ID: <4C24E6F0.40101@oracle.com>

The Windows Selector uses select and wakes up if there is OOB data 
available for reading on one of the sockets. When the OOBINLINE option 
is disabled (the default and usual case) then it can be lead to Selector 
spin or read returning 0 when there isn't any (normal) data to read.  To 
address this, we need to read and discard the OOB data so that it 
doesn't cause the channel to be selected (and allow subsequent selects 
to block). The webrev with the changes is here:
   http://cr.openjdk.java.net/~alanb/6213702/webrev/

Thanks,
Alan.



From michael.x.mcmahon at oracle.com  Mon Jun 28 03:27:27 2010
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 28 Jun 2010 11:27:27 +0100
Subject: 6213702: (so) non-blocking sockets with TCP urgent disabled get
	still selected for read ops (win)
In-Reply-To: <4C24E6F0.40101@oracle.com>
References: <4C24E6F0.40101@oracle.com>
Message-ID: <4C28790F.7020102@oracle.com>

Alan Bateman wrote:
> The Windows Selector uses select and wakes up if there is OOB data 
> available for reading on one of the sockets. When the OOBINLINE option 
> is disabled (the default and usual case) then it can be lead to 
> Selector spin or read returning 0 when there isn't any (normal) data 
> to read.  To address this, we need to read and discard the OOB data so 
> that it doesn't cause the channel to be selected (and allow subsequent 
> selects to block). The webrev with the changes is here:
>   http://cr.openjdk.java.net/~alanb/6213702/webrev/
>
> Thanks,
> Alan.
>
>
looks good to me.

- Michael.

From chris.hegarty at oracle.com  Mon Jun 28 03:54:38 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 28 Jun 2010 11:54:38 +0100
Subject: 6213702: (so) non-blocking sockets with TCP urgent disabled get
	still selected for read ops (win)
In-Reply-To: <4C28790F.7020102@oracle.com>
References: <4C24E6F0.40101@oracle.com> <4C28790F.7020102@oracle.com>
Message-ID: <4C287F6E.1010507@oracle.com>

On 06/28/10 11:27 AM, Michael McMahon wrote:
> Alan Bateman wrote:
>> The Windows Selector uses select and wakes up if there is OOB data
>> available for reading on one of the sockets. When the OOBINLINE option
>> is disabled (the default and usual case) then it can be lead to
>> Selector spin or read returning 0 when there isn't any (normal) data
>> to read. To address this, we need to read and discard the OOB data so
>> that it doesn't cause the channel to be selected (and allow subsequent
>> selects to block). The webrev with the changes is here:
>> http://cr.openjdk.java.net/~alanb/6213702/webrev/
>>
>> Thanks,
>> Alan.
>>
>>
> looks good to me.

Same here, changes look fine.

-Chris.

>
> - Michael.

From Alan.Bateman at oracle.com  Tue Jun 29 11:15:44 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Jun 2010 19:15:44 +0100
Subject: 6965150: TEST_BUG:
	java/nio/channels/AsynchronousSocketChannel/Basic.java takes too long
Message-ID: <4C2A3850.70901@oracle.com>


Chris - do you mind looking at another test fix? Hopefully this is the 
latest of the test fixes for a while.  The patch here is to 
test/java/nio/channels/AsynchronousSocketChannel/Basic.java. That test 
takes up to 4mins with most of the time spent testing the connect method 
where the underlying connect needs to timeout. I've just replaced this 
connect with an attempt to establish a local connection and so it will 
fail immediately.

Thanks,

-Alan.



diff --git a/test/java/nio/channels/AsynchronousSocketChannel/Basic.java 
b/test/java/nio/channels/AsynchronousSocketChannel/Basic.java
--- a/test/java/nio/channels/AsynchronousSocketChannel/Basic.java
+++ b/test/java/nio/channels/AsynchronousSocketChannel/Basic.java
@@ -194,12 +194,13 @@ public class Basic {
         if (!(connectException.get() instanceof ClosedChannelException))
             throw new RuntimeException("ClosedChannelException expected");
 
-        System.out.println("-- connect to non-existent host --");
+        // shutdown listener
+        server.close();
 
         // test that failure to connect closes the channel
         ch = AsynchronousSocketChannel.open();
         try {
-            ch.connect(genSocketAddress()).get();
+            ch.connect(server.address()).get();
         } catch (ExecutionException x) {
             // failed to establish connection
             if (ch.isOpen())
@@ -207,8 +208,6 @@ public class Basic {
         } finally {
             ch.close();
         }
-
-        server.close();
     }
 
     static void testCloseWhenPending() throws Exception {




From chris.hegarty at oracle.com  Wed Jun 30 02:13:15 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 30 Jun 2010 10:13:15 +0100
Subject: 6965150: TEST_BUG:
	java/nio/channels/AsynchronousSocketChannel/Basic.java takes too long
In-Reply-To: <4C2A3850.70901@oracle.com>
References: <4C2A3850.70901@oracle.com>
Message-ID: <4C2B0AAB.2040003@oracle.com>

Alan, this change looks fine since you are just checking that the 
channel is no longer open.

-Chris.

On 06/29/10 19:15, Alan Bateman wrote:
>
> Chris - do you mind looking at another test fix? Hopefully this is the
> latest of the test fixes for a while. The patch here is to
> test/java/nio/channels/AsynchronousSocketChannel/Basic.java. That test
> takes up to 4mins with most of the time spent testing the connect method
> where the underlying connect needs to timeout. I've just replaced this
> connect with an attempt to establish a local connection and so it will
> fail immediately.
>
> Thanks,
>
> -Alan.
>
>
>
> diff --git a/test/java/nio/channels/AsynchronousSocketChannel/Basic.java
> b/test/java/nio/channels/AsynchronousSocketChannel/Basic.java
> --- a/test/java/nio/channels/AsynchronousSocketChannel/Basic.java
> +++ b/test/java/nio/channels/AsynchronousSocketChannel/Basic.java
> @@ -194,12 +194,13 @@ public class Basic {
> if (!(connectException.get() instanceof ClosedChannelException))
> throw new RuntimeException("ClosedChannelException expected");
>
> - System.out.println("-- connect to non-existent host --");
> + // shutdown listener
> + server.close();
>
> // test that failure to connect closes the channel
> ch = AsynchronousSocketChannel.open();
> try {
> - ch.connect(genSocketAddress()).get();
> + ch.connect(server.address()).get();
> } catch (ExecutionException x) {
> // failed to establish connection
> if (ch.isOpen())
> @@ -207,8 +208,6 @@ public class Basic {
> } finally {
> ch.close();
> }
> -
> - server.close();
> }
>
> static void testCloseWhenPending() throws Exception {
>
>
>

From hjohn at xs4all.nl  Wed Jun 30 09:00:55 2010
From: hjohn at xs4all.nl (John Hendrikx)
Date: Wed, 30 Jun 2010 18:00:55 +0200
Subject: FileStore... getRootPath() ?
Message-ID: <4C2B6A37.10802@xs4all.nl>

Dear list,

I have a use case for NIO2, where I wish to present the user with a list 
of FileStore's (or roots) from which to select one depending on 
available space on the store.  A loop as follows gives me the relevant 
information in Java at the moment:

for(FileStore store : FileSystems.getDefault().getFileStores()) {
  System.out.println(store);
}

This will print a list like this:

(C:)
data (D:)
New Volume (F:)
etc...

or on Linux:

/ (/dev/hda2)
/lib/init/rw (tmpfs)
/proc (proc)
/sys (sysfs)
/proc/bus/usb (procbususb)
/dev (udev)
/dev/shm (tmpfs)
/dev/pts (devpts)
/sys/fs/fuse/connections (fusectl)
/data (/dev/md0)
/temp (/dev/mapper/temp)
/raid1 (/dev/mapper/raid1)
/raid2 (/dev/mapper/raid2) 


It is fairly trivial to filter this list to only the stores useful to 
the user (by discarding items with "non-sensical" 
useableSpace()/totalSpace() values, ie. both being zero).

However, it turns out that after finding this treasure of information, I 
cannot make use of it without parsing toString() of FileStore, as there 
is no method to go from a FileStore to a (root) Path.

Is this an oversight or is there perhaps an even more elegant way to 
find this information?

Note that even on Linux, with just "one" root (/), the added choice for 
other volumes (which have different free space values) is invaluable for 
the user.  In other words, I'd like to present the user with the choice 
of for example: /, /data, /temp, /raid1 and /raid2.

Thanks,
--John


From forax at univ-mlv.fr  Wed Jun 30 09:49:40 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 30 Jun 2010 18:49:40 +0200
Subject: FileStore... getRootPath() ?
In-Reply-To: <4C2B6A37.10802@xs4all.nl>
References: <4C2B6A37.10802@xs4all.nl>
Message-ID: <4C2B75A4.3030907@univ-mlv.fr>

Le 30/06/2010 18:00, John Hendrikx a ?crit :
> Dear list,
>
> I have a use case for NIO2, where I wish to present the user with a 
> list of FileStore's (or roots) from which to select one depending on 
> available space on the store.  A loop as follows gives me the relevant 
> information in Java at the moment:
>
> for(FileStore store : FileSystems.getDefault().getFileStores()) {
>  System.out.println(store);
> }
>
> This will print a list like this:
>
> (C:)
> data (D:)
> New Volume (F:)
> etc...
>
> or on Linux:
>
> / (/dev/hda2)
> /lib/init/rw (tmpfs)
> /proc (proc)
> /sys (sysfs)
> /proc/bus/usb (procbususb)
> /dev (udev)
> /dev/shm (tmpfs)
> /dev/pts (devpts)
> /sys/fs/fuse/connections (fusectl)
> /data (/dev/md0)
> /temp (/dev/mapper/temp)
> /raid1 (/dev/mapper/raid1)
> /raid2 (/dev/mapper/raid2)
>
> It is fairly trivial to filter this list to only the stores useful to 
> the user (by discarding items with "non-sensical" 
> useableSpace()/totalSpace() values, ie. both being zero).
>
> However, it turns out that after finding this treasure of information, 
> I cannot make use of it without parsing toString() of FileStore, as 
> there is no method to go from a FileStore to a (root) Path.
>
> Is this an oversight or is there perhaps an even more elegant way to 
> find this information?
>
> Note that even on Linux, with just "one" root (/), the added choice 
> for other volumes (which have different free space values) is 
> invaluable for the user.  In other words, I'd like to present the user 
> with the choice of for example: /, /data, /temp, /raid1 and /raid2.
>
> Thanks,
> --John
>


You can use fileSystem.getRootDirectories() and use getFileStore()
on the resulting paths.

R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100630/1b320039/attachment.html 

From hjohn at xs4all.nl  Wed Jun 30 10:51:22 2010
From: hjohn at xs4all.nl (John Hendrikx)
Date: Wed, 30 Jun 2010 19:51:22 +0200
Subject: FileStore... getRootPath() ?
In-Reply-To: <4C2B75A4.3030907@univ-mlv.fr>
References: <4C2B6A37.10802@xs4all.nl> <4C2B75A4.3030907@univ-mlv.fr>
Message-ID: <4C2B841A.5020204@xs4all.nl>

R?mi Forax wrote:
> Le 30/06/2010 18:00, John Hendrikx a ?crit :
>> Dear list,
>>
>> I have a use case for NIO2, where I wish to present the user with a 
>> list of FileStore's (or roots) from which to select one depending on 
>> available space on the store.  A loop as follows gives me the 
>> relevant information in Java at the moment:
>>
>> for(FileStore store : FileSystems.getDefault().getFileStores()) {
>>  System.out.println(store);
>> }
>>
>> This will print a list like this:
>>
>> (C:)
>> data (D:)
>> New Volume (F:)
>> etc...
>>
>> or on Linux:
>>
>> / (/dev/hda2)
>> /lib/init/rw (tmpfs)
>> /proc (proc)
>> /sys (sysfs)
>> /proc/bus/usb (procbususb)
>> /dev (udev)
>> /dev/shm (tmpfs)
>> /dev/pts (devpts)
>> /sys/fs/fuse/connections (fusectl)
>> /data (/dev/md0)
>> /temp (/dev/mapper/temp)
>> /raid1 (/dev/mapper/raid1)
>> /raid2 (/dev/mapper/raid2)
>>
>> It is fairly trivial to filter this list to only the stores useful to 
>> the user (by discarding items with "non-sensical" 
>> useableSpace()/totalSpace() values, ie. both being zero).
>>
>> However, it turns out that after finding this treasure of 
>> information, I cannot make use of it without parsing toString() of 
>> FileStore, as there is no method to go from a FileStore to a (root) 
>> Path.
>>
>> Is this an oversight or is there perhaps an even more elegant way to 
>> find this information?
>>
>> Note that even on Linux, with just "one" root (/), the added choice 
>> for other volumes (which have different free space values) is 
>> invaluable for the user.  In other words, I'd like to present the 
>> user with the choice of for example: /, /data, /temp, /raid1 and /raid2.
>>
>> Thanks,
>> --John
>>
>
>
> You can use fileSystem.getRootDirectories() and use getFileStore()
> on the resulting paths.
>
> R?mi
>
This unfortunately only returns "/" on Linux (b99), which is correct I 
suppose for a function with such a name.  It still does not allow a list 
of distinct volumes that are available (like df -h would show).  ie:

Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2              19G   13G  5.1G  72% /
tmpfs                 2.0G   12K  2.0G   1% /lib/init/rw
udev                   10M  396K  9.7M   4% /dev
tmpfs                 2.0G     0  2.0G   0% /dev/shm
/dev/md0              9.2G  902M  8.3G  10% /data
/dev/mapper/temp      345G  344G  532M 100% /temp
/dev/mapper/raid1     3.7T  2.5T  1.2T  68% /raid1
/dev/mapper/raid2     3.7T  2.2T  1.5T  60% /raid2

In other words, I'd present the user with only "/" which has 5.1 GB 
free, not quite an accurate state of affairs for the above system.

--John

From Alan.Bateman at oracle.com  Wed Jun 30 13:48:38 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 30 Jun 2010 21:48:38 +0100
Subject: FileStore... getRootPath() ?
In-Reply-To: <4C2B6A37.10802@xs4all.nl>
References: <4C2B6A37.10802@xs4all.nl>
Message-ID: <4C2BADA6.9090009@oracle.com>

John Hendrikx wrote:
> :
>
> Is this an oversight or is there perhaps an even more elegant way to 
> find this information?
>
> Note that even on Linux, with just "one" root (/), the added choice 
> for other volumes (which have different free space values) is 
> invaluable for the user.  In other words, I'd like to present the user 
> with the choice of for example: /, /data, /temp, /raid1 and /raid2.
I think you're looking for the mount points, which FileStore doesn't 
currently make available - it could do, but needs a bit of research to 
make sure that we wouldn't have any issues on other platforms. That 
said,  it's not clear to me that you'd want to present all of them to 
the end-user and there probably isn't an easy way to filter them either.

-Alan.

From hjohn at xs4all.nl  Wed Jun 30 14:43:33 2010
From: hjohn at xs4all.nl (John Hendrikx)
Date: Wed, 30 Jun 2010 23:43:33 +0200
Subject: FileStore... getRootPath() ?
In-Reply-To: <4C2BADA6.9090009@oracle.com>
References: <4C2B6A37.10802@xs4all.nl> <4C2BADA6.9090009@oracle.com>
Message-ID: <4C2BBA85.7030801@xs4all.nl>

Alan Bateman wrote:
> John Hendrikx wrote:
>> :
>>
>> Is this an oversight or is there perhaps an even more elegant way to 
>> find this information?
>>
>> Note that even on Linux, with just "one" root (/), the added choice 
>> for other volumes (which have different free space values) is 
>> invaluable for the user.  In other words, I'd like to present the 
>> user with the choice of for example: /, /data, /temp, /raid1 and /raid2.
> I think you're looking for the mount points, which FileStore doesn't 
> currently make available - it could do, but needs a bit of research to 
> make sure that we wouldn't have any issues on other platforms. 
Yes, the mount points would be the information I'd be looking for.  For 
the moment, it seems that the list of available FileStores matches 
pretty closely (atleast on Windows and Linux... I could test on Solaris 
as well).
> That said,  it's not clear to me that you'd want to present all of 
> them to the end-user and there probably isn't an easy way to filter 
> them either.
Well, the filtering would simply do the following (for Linux, Windows 
does not need any filtering, although applying the same filter would not 
adversely affect the result):

1) spaceAttribs.totalSpace() != 0;  (eliminates /proc, /sys, etc..)
2) fileStore.type() != "tmpfs"; (eliminates /dev, /dev/shm, etc..)

And although this is a bit of a kludge, on my test systems that leaves 
me with only the mountpoints, ie.:

/ (/dev/hda2)
/data (/dev/md0)
/raid1 (/dev/mapper/raid1)
/raid2 (/dev/mapper/raid2)
/temp (/dev/mapper/temp)

Those are then easy to present in a multi-column list with total size 
and free space information.

Reasons for needing such a list:

1) Allowing the user to select an entire volume (for backup, or 
(restore) destination) for example.
2) Giving the user a start point for navigating the directory tree (on 
Windows the drive letters work, although My Computer would be better.  
On Linux "/" works, but is clumsy... most native apps will have a list 
of mount points somewhere).
3) Informational.  Free and Total space shown in a monitoring 
application or perhaps to select a suitable location to install 
something big (with sufficient free space) :)

I realize what I'm trying to do is probably a bit beyond NIO2's scope -- 
but providing the user with a fully functional view of the filesystems 
on a (any?) system is now close to possible (hence why I'm trying this).

--John