Re: 7130398: ProblemList.txt updates (1/2012)

2012-01-17 Thread Chris Hegarty
Alan, I'd like to use this CR to backport some similar changes to 7u4. I guess this is a request for review of the following, for 7u-dev: --- a/test/ProblemList.txt Mon Jan 16 18:05:29 2012 + +++ b/test/ProblemList.txt Tue Jan 17 12:09:17 2012 + @@ -195,6 +195,9 @@

Re: 7130398: ProblemList.txt updates (1/2012)

2012-01-17 Thread Chris Hegarty
OK, lets backport 7130398 as is to 7u4. And I'll look at 6671616. -Chris. On 01/17/12 12:23 PM, Alan Bateman wrote: On 17/01/2012 12:05, Chris Hegarty wrote: Alan, I'd like to use this CR to backport some similar changes to 7u4. I guess this is a request for review of the following, for

RFR 6671616: TEST_BUG java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol)

2012-01-17 Thread Chris Hegarty
On Solaris, this test looks in /dev/dsk for block special devices. Unfortunately, /dev/dsk is empty within a zone. Also unfortunately, on a non-zone Solaris machine, /dev/dsk is filled with symlinks to the actual device nodes. On Linux, this test looks at /dev/ide0 and /dev/scd0 which are

hg: jdk8/tl/jdk: 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol)

2012-01-17 Thread chris . hegarty
Changeset: 40d699d7f6a1 Author:chegar Date: 2012-01-17 14:10 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40d699d7f6a1 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Reviewed-by: alanb ! test/ProblemList.txt -

Re: JDK 8 code review request for initial unsigned integer arithmetic library support

2012-01-17 Thread Joe Darcy
Hi Eamonn, On 01/15/2012 09:53 AM, Eamonn McManus wrote: It's great to see this! I agree :-) I've posted a revised webrev at http://cr.openjdk.java.net/~darcy/4504839.2 More detailed responses inline. The API looks reasonable to me. For the first cut, I've favored keeping the code

Re: JDK 8 code review request for initial unsigned integer arithmetic library support

2012-01-17 Thread Eamonn McManus
Hi Joe, That looks great to me (emcmanus). One thing I noticed is that the behaviour is not explicitly specified when parseUnsignedLong is given a null String reference. But I see that is also true of the existing parseLong and valueOf(String) and decode(String), so perhaps there should be a