From john.r.rose at oracle.com  Wed Sep  1 11:35:43 2010
From: john.r.rose at oracle.com (john.r.rose at oracle.com)
Date: Wed, 01 Sep 2010 11:35:43 +0000
Subject: hg: jdk7/tl/langtools: 6979683: inconsistent interaction of reference
	cast with box/unbox conversions leaves out a useful case
Message-ID: <20100901113545.49B51475C2@hg.openjdk.java.net>

Changeset: d3ead6731a91
Author:    jrose
Date:      2010-09-01 03:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d3ead6731a91

6979683: inconsistent interaction of reference cast with box/unbox conversions leaves out a useful case
Summary: Allow casts which narrow and then unbox.
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/6979683/TestCast6979683_BAD34.java
+ test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD35.java
+ test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD36.java
+ test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD37.java
+ test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD38.java
+ test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD39.java
+ test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog
+ test/tools/javac/6979683/TestCast6979683_GOOD.java



From iaroslavski at mail.ru  Wed Sep  1 14:18:11 2010
From: iaroslavski at mail.ru (Vladimir Iaroslavski)
Date: Wed, 01 Sep 2010 18:18:11 +0400
Subject: Dual-Pivot Quicksort and Sorting classes: update
In-Reply-To: <4C62A7CA.7030605@mail.ru>
References: <4C62A7CA.7030605@mail.ru>
Message-ID: <4C7E60A3.2010805@mail.ru>

Hello,

Here is next update of Quicksort and Sorting classes, summary of changes:

1. Threshold for insertion sort was increased from 32 to 47.

2. Approximation of length/7 uses >> shift instead of >>> now
    (we know that length > threshold > 0)

int seventh = (length >> 3) + (length >> 6) + 1;

3. Method sort(byte[]) (and sort(byte[],int,int) uses
insertion sort for small array (<= 29) and counting sort for other
(no quicksort at all).

4. Improved message outputs in Sorting class.

Thank you,
Vladimir

Vladimir Iaroslavski wrote:
> Hello!
> 
> I updated Dual-Pivot Quicksort and Sorting classes.
> 
> http://cr.openjdk.java.net/~alanb/6976036/webrev
> 
> In compare with previous version the ratio (JDK 7 / JDK 6)
> now is (client / server): 54.35% / 42.79% (was 57.22% / 46.18%).
> 
> Summary of changes:
> 
> Sorting class: new type of test (check sum with plus operation) was added.
> Dual-Pivot Quicksort:
> 
> 1. Changes in for-loop from
> 
> for (int i = <lo> + 1; i < <hi>; i++)
> 
> to
> 
> for (int i = <lo>; ++i < <hi>; )
> 
> 2. Skip the longest ascending sequence in insertion sort:
> 
> while (left <= right && a[left - 1] <= a[left]) {
>     left++;
> }
> 
> 3. Added comment about a[i]; i++; issue.
> 
> 4. Corrected comment with value when sqan of equal to
> pivots is started: 5/7 -> 4/7.
> 
> 5. Other minor javadoc changes.
> 
> Please review the changes.
> 
> Thank you,
> Vladimir
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DualPivotQuicksort.java
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100901/e1923472/DualPivotQuicksort.java>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Sorting.java
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100901/e1923472/Sorting.java>

From martinrb at google.com  Wed Sep  1 17:00:21 2010
From: martinrb at google.com (martinrb at google.com)
Date: Wed, 01 Sep 2010 17:00:21 +0000
Subject: hg: jdk7/tl/jdk: 6981145: (se) Eliminate JNI*Critical when creating
	pipes and other cleanups
Message-ID: <20100901170030.EFDAB47628@hg.openjdk.java.net>

Changeset: bb8f48e1e042
Author:    martin
Date:      2010-09-01 09:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bb8f48e1e042

6981145: (se) Eliminate JNI*Critical when creating pipes and other cleanups
Summary: Avoid *Critical; fix compile warnings; improve readability
Reviewed-by: alanb

! make/java/nio/mapfile-linux
! make/java/nio/mapfile-solaris
! src/share/classes/sun/nio/ch/IOUtil.java
! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/PipeImpl.java
! src/solaris/classes/sun/nio/ch/PollSelectorImpl.java
! src/solaris/native/sun/nio/ch/IOUtil.c



From mandy.chung at oracle.com  Wed Sep  1 23:25:04 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 01 Sep 2010 16:25:04 -0700
Subject: Review request for a simple javadoc fix
Message-ID: <4C7EE0D0.9050703@oracle.com>

  Sherman,

Can you review the simple javadoc fix for:
   6977887: (doc) Java 6 API missing info about encoding parameter in 
storeToXML method

 > hg diff Properties.java
diff --git a/src/share/classes/java/util/Properties.java 
b/src/share/classes/java/util/Properties.java
--- a/src/share/classes/java/util/Properties.java
+++ b/src/share/classes/java/util/Properties.java
@@ -915,6 +915,10 @@
       * @param os the output stream on which to emit the XML document.
       * @param comment a description of the property list, or 
<code>null</code>
       *        if no comment is desired.
+     * @param  encoding the name of a supported
+     * <a href="../lang/package-summary.html#charenc">
+     *                  character encoding</a>
+     *
       * @throws IOException if writing to the specified output stream
       *         results in an <tt>IOException</tt>.
       * @throws NullPointerException if <code>os</code> is 
<code>null</code>,

Thanks
Mandy


From xueming.shen at oracle.com  Wed Sep  1 23:53:51 2010
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 01 Sep 2010 16:53:51 -0700
Subject: Review request for a simple javadoc fix
In-Reply-To: <4C7EE0D0.9050703@oracle.com>
References: <4C7EE0D0.9050703@oracle.com>
Message-ID: <4C7EE78F.8000901@oracle.com>

Looks fine.

Mandy Chung wrote:
>  Sherman,
>
> Can you review the simple javadoc fix for:
>   6977887: (doc) Java 6 API missing info about encoding parameter in 
> storeToXML method
>
> > hg diff Properties.java
> diff --git a/src/share/classes/java/util/Properties.java 
> b/src/share/classes/java/util/Properties.java
> --- a/src/share/classes/java/util/Properties.java
> +++ b/src/share/classes/java/util/Properties.java
> @@ -915,6 +915,10 @@
>       * @param os the output stream on which to emit the XML document.
>       * @param comment a description of the property list, or 
> <code>null</code>
>       *        if no comment is desired.
> +     * @param  encoding the name of a supported
> +     * <a href="../lang/package-summary.html#charenc">
> +     *                  character encoding</a>
> +     *
>       * @throws IOException if writing to the specified output stream
>       *         results in an <tt>IOException</tt>.
>       * @throws NullPointerException if <code>os</code> is 
> <code>null</code>,
>
> Thanks
> Mandy



From mandy.chung at oracle.com  Thu Sep  2 00:38:21 2010
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 02 Sep 2010 00:38:21 +0000
Subject: hg: jdk7/tl/jdk: 6977887: (doc) Java 6 API missing info about
	encoding parameter in storeToXML method
Message-ID: <20100902003831.055E747640@hg.openjdk.java.net>

Changeset: b200263f1b68
Author:    mchung
Date:      2010-09-01 17:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b200263f1b68

6977887: (doc) Java 6 API missing info about encoding parameter in storeToXML method
Reviewed-by: sherman

! src/share/classes/java/util/Properties.java



From kelly.ohair at oracle.com  Thu Sep  2 04:35:04 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Thu, 02 Sep 2010 04:35:04 +0000
Subject: hg: jdk7/tl/jaxp: 6981408: Upgrade jaxp to 1.4.4
Message-ID: <20100902043504.D41F84764A@hg.openjdk.java.net>

Changeset: a3fe5892cd26
Author:    ohair
Date:      2010-09-01 13:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/a3fe5892cd26

6981408: Upgrade jaxp to 1.4.4
Reviewed-by: darcy
Contributed-by: Joe Wang <huizhe.wang at oracle.com>

! jaxp.properties



From sundararajan.a at sun.com  Thu Sep  2 17:41:55 2010
From: sundararajan.a at sun.com (sundararajan.a at sun.com)
Date: Thu, 02 Sep 2010 17:41:55 +0000
Subject: hg: jdk7/tl/langtools: 6458749:
	TypeParameterElement.getEnclosedElements throws NPE within javac.
Message-ID: <20100902174159.42F0347678@hg.openjdk.java.net>

Changeset: f37253c9e082
Author:    sundar
Date:      2010-09-02 23:10 +0530
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f37253c9e082

6458749: TypeParameterElement.getEnclosedElements throws NPE within javac.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/T6458749.java



From joe.darcy at oracle.com  Fri Sep  3 00:33:54 2010
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 02 Sep 2010 17:33:54 -0700
Subject: Code review request for 4881419 The type of X[].clone() should be X[]
Message-ID: <4C804272.9060408@oracle.com>

Hello.

Please review my spec clarification fix for

    4881419 "The type of X[].clone() should be X[]"
    http://cr.openjdk.java.net/~darcy/4881419/

The statement about the return type of the clone method for an array is 
given in JLSv3 section 6.4.5:
http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.4.5

Thanks,

-Joe


From martinrb at google.com  Fri Sep  3 00:46:55 2010
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 2 Sep 2010 17:46:55 -0700
Subject: Code review request for 4881419 The type of X[].clone() should be
	X[]
In-Reply-To: <4C804272.9060408@oracle.com>
References: <4C804272.9060408@oracle.com>
Message-ID: <AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>

The usage T[] suggests that T is a reference type, as with generics, which
is not the case here.

More precisely, both the runtime types and compiletime types of the object
returned from clone of any array is identical to its input.
Is there a non-confusing way of saying that?

Martin

On Thu, Sep 2, 2010 at 17:33, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello.
>
> Please review my spec clarification fix for
>
>   4881419 "The type of X[].clone() should be X[]"
>   http://cr.openjdk.java.net/~darcy/4881419/<http://cr.openjdk.java.net/%7Edarcy/4881419/>
>
> The statement about the return type of the clone method for an array is
> given in JLSv3 section 6.4.5:
> http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.4.5
>
> Thanks,
>
> -Joe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100902/011b8b95/attachment.html>

From joe.darcy at oracle.com  Fri Sep  3 00:50:28 2010
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 02 Sep 2010 17:50:28 -0700
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>
References: <4C804272.9060408@oracle.com>
	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>
Message-ID: <4C804654.8020909@oracle.com>

Martin Buchholz wrote:
> The usage T[] suggests that T is a reference type, as with generics, 
> which is not the case here.
>
> More precisely, both the runtime types and compiletime types of the 
> object returned from clone of any array is identical to its input.
> Is there a non-confusing way of saying that?

How about

"...and that the return type of the {@code clone} method of an array 
type {@code T[]} is {@code T[]} where T is either a reference or a 
primitive type."?

-Joe

>
> Martin
>
> On Thu, Sep 2, 2010 at 17:33, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Hello.
>
>     Please review my spec clarification fix for
>
>       4881419 "The type of X[].clone() should be X[]"
>       http://cr.openjdk.java.net/~darcy/4881419/
>     <http://cr.openjdk.java.net/%7Edarcy/4881419/>
>
>     The statement about the return type of the clone method for an
>     array is given in JLSv3 section 6.4.5:
>     http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.4.5
>
>     Thanks,
>
>     -Joe
>
>



From Ulf.Zibis at gmx.de  Fri Sep  3 01:07:13 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 03 Sep 2010 03:07:13 +0200
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <4C804654.8020909@oracle.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>
	<4C804654.8020909@oracle.com>
Message-ID: <4C804A41.7080707@gmx.de>



Am 03.09.2010 02:50, schrieb Joe Darcy:
> Martin Buchholz wrote:
>> The usage T[] suggests that T is a reference type, as with generics, which is not the case here.
>>
>> More precisely, both the runtime types and compiletime types of the object returned from clone of 
>> any array is identical to its input.
>> Is there a non-confusing way of saying that?
>
> How about
>
> "...and that the return type of the {@code clone} method of an array type {@code T[]} is {@code 
> T[]} where T is either a reference or a primitive type."?
>

How about

"...and that the return type of the {@code clone} method of an array type {@code X[]} is {@code X[]} 
where X is either a *raw* reference or a primitive type."?

-Ulf

> -Joe
>
>>
>> Martin
>>
>> On Thu, Sep 2, 2010 at 17:33, Joe Darcy <joe.darcy at oracle.com <mailto:joe.darcy at oracle.com>> wrote:
>>
>>     Hello.
>>
>>     Please review my spec clarification fix for
>>
>>       4881419 "The type of X[].clone() should be X[]"
>>       http://cr.openjdk.java.net/~darcy/4881419/
>> <http://cr.openjdk.java.net/%7Edarcy/4881419/>
>>
>>     The statement about the return type of the clone method for an
>>     array is given in JLSv3 section 6.4.5:
>>     http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.4.5
>>
>>     Thanks,
>>
>>     -Joe
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100903/4cb8113d/attachment.html>

From jonathan.gibbons at oracle.com  Fri Sep  3 01:26:27 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 03 Sep 2010 01:26:27 +0000
Subject: hg: jdk7/tl/langtools: 6921495: spurious semicolons in class def
	cause empty NOPOS blocks
Message-ID: <20100903012629.5D11B47693@hg.openjdk.java.net>

Changeset: 3ff3f20471b4
Author:    jjg
Date:      2010-09-02 18:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3ff3f20471b4

6921495: spurious semicolons in class def cause empty NOPOS blocks
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/parser/ExtraSemiTest.java



From sundararajan.a at sun.com  Fri Sep  3 06:00:12 2010
From: sundararajan.a at sun.com (sundararajan.a at sun.com)
Date: Fri, 03 Sep 2010 06:00:12 +0000
Subject: hg: jdk7/tl/langtools: 6458823: Messager messages on
	TypeParamterElements to not include position information.
Message-ID: <20100903060014.4C146476A4@hg.openjdk.java.net>

Changeset: 25dd23fa2511
Author:    sundar
Date:      2010-09-03 11:25 +0530
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/25dd23fa2511

6458823: Messager messages on TypeParamterElements to not include position information.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/T6458823/MyProcessor.java
+ test/tools/javac/T6458823/T6458823.java
+ test/tools/javac/T6458823/TestClass.java



From martinrb at google.com  Fri Sep  3 06:22:56 2010
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 2 Sep 2010 23:22:56 -0700
Subject: Code review request for 4881419 The type of X[].clone() should be
	X[]
In-Reply-To: <4C804654.8020909@oracle.com>
References: <4C804272.9060408@oracle.com>
	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>
	<4C804654.8020909@oracle.com>
Message-ID: <AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>

On Thu, Sep 2, 2010 at 17:50, Joe Darcy <joe.darcy at oracle.com> wrote:

> Martin Buchholz wrote:
>
>> The usage T[] suggests that T is a reference type, as with generics, which
>> is not the case here.
>>
>> More precisely, both the runtime types and compiletime types of the object
>> returned from clone of any array is identical to its input.
>> Is there a non-confusing way of saying that?
>>
>
> How about
>
> "...and that the return type of the {@code clone} method of an array type
> {@code T[]} is {@code T[]} where T is either a reference or a primitive
> type."?
>
>
So I went and actually read the Object.clone spec, and it does indeed
guarantee that the (runtime) class of the returned value is the same as the
class of the argument, for arrays.  As for the compile-time type, an
experiment demonstrates that the return type is indeed exactly the same,
including for non-reifiable array element types, e.g. this compiles:

        Class<? extends Number>[] a
            = (Class<? extends Number>[]) (new Class<?>[42]);
        Class<? extends Number>[] clone = a.clone();


So Ulf's restriction to non-reifiable T seems not to be correct.

My suggested wording is:

"...and that the return type of the {@code clone} method of an array type
{@code T[]} is {@code T[]} where T is any reference or primitive type."

Martin "Objects have class; Variables have type"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100902/b330ffaa/attachment.html>

From sundararajan.a at sun.com  Fri Sep  3 07:15:53 2010
From: sundararajan.a at sun.com (sundararajan.a at sun.com)
Date: Fri, 03 Sep 2010 07:15:53 +0000
Subject: hg: jdk7/tl/langtools: 6956462: AssertionError exception thrown in
	the Compiler Tree API in JDK 7.
Message-ID: <20100903071555.D562B476A7@hg.openjdk.java.net>

Changeset: d54300fb3554
Author:    sundar
Date:      2010-09-03 12:36 +0530
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d54300fb3554

6956462: AssertionError exception thrown in the Compiler Tree API in JDK 7.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/T6956462/T6956462.java
+ test/tools/javac/T6956462/TestClass.java



From Ulf.Zibis at gmx.de  Fri Sep  3 10:31:20 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 03 Sep 2010 12:31:20 +0200
Subject: Code review request for 4881419 The type of X[].clone() should
	be	X[]
In-Reply-To: <AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>
	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
Message-ID: <4C80CE78.7040204@gmx.de>

  Am 03.09.2010 08:22, schrieb Martin Buchholz:
>
>
> On Thu, Sep 2, 2010 at 17:50, Joe Darcy <joe.darcy at oracle.com <mailto:joe.darcy at oracle.com>> wrote:
>
>     Martin Buchholz wrote:
>
>         The usage T[] suggests that T is a reference type, as with generics, which is not the case
>         here.
>
>         More precisely, both the runtime types and compiletime types of the object returned from
>         clone of any array is identical to its input.
>         Is there a non-confusing way of saying that?
>
>
>     How about
>
>     "...and that the return type of the {@code clone} method of an array type {@code T[]} is
>     {@code T[]} where T is either a reference or a primitive type."?
>
>
> So I went and actually read the Object.clone spec, and it does indeed guarantee that the (runtime) 
> class of the returned value is the same as the class of the argument, for arrays.  As for the 
> compile-time type, an experiment demonstrates that the return type is indeed exactly the same, 
> including for non-reifiable array element types, e.g. this compiles:
>
>         Class<? extends Number>[] a
>             = (Class<? extends Number>[]) (new Class<?>[42]);
>         Class<? extends Number>[] clone = a.clone();
>
>
> So Ulf's restriction to non-reifiable T seems not to be correct.

Oops, my English :-(
I interpreted your term "...as with generics, which is not the case here." as such reification.

>
> My suggested wording is:
>
> "...and that the return type of the {@code clone} method of an array type {@code T[]} is {@code 
> T[]} where T is any reference or primitive type."
>
> Martin "Objects have class; Variables have type"

I think the question of variable types belongs to the spec, but here in Object class's javadoc we 
should speak about objects. So I now suggest:
"...and that the returned object of the {@code clone} method of an array object of class {@code T[]} 
is of class {@code T[]} where T is any [raw]? reference or primitive class. See java language 
specification version 3, section 6.4.5"

-Ulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100903/2070db70/attachment.html>

From Ulf.Zibis at gmx.de  Fri Sep  3 13:36:56 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 03 Sep 2010 15:36:56 +0200
Subject: Code review request for 4881419 The type of X[].clone() should
	be	X[]
In-Reply-To: <4C80CE78.7040204@gmx.de>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
	<4C80CE78.7040204@gmx.de>
Message-ID: <4C80F9F8.4000703@gmx.de>

  Am 03.09.2010 12:31, schrieb Ulf Zibis:
>
> I think the question of variable types belongs to the spec, but here in Object class's javadoc we 
> should speak about objects. So I now suggest:
> "...and that the returned object of the {@code clone} method of an array object of class {@code 
> T[]} is of class {@code T[]} where T is any [raw]? reference or primitive class. See java language 
> specification version 3, section 6.4.5"
>

And additionally 2 cents: As T is often used for parameter type in context with generics, I think, X 
would leed to less misinterpretation and would match better to the according spec.

-Ulf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100903/cdedcb87/attachment.html>

From kumar.x.srinivasan at oracle.com  Fri Sep  3 15:06:27 2010
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Fri, 03 Sep 2010 15:06:27 +0000
Subject: hg: jdk7/tl/jdk: 6981001: (launcher) EnsureJREInstallation is not
	being called in order
Message-ID: <20100903150637.B5271476BA@hg.openjdk.java.net>

Changeset: b790c1ecee19
Author:    ksrini
Date:      2010-09-03 07:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b790c1ecee19

6981001: (launcher) EnsureJREInstallation is not being called in order
Reviewed-by: darcy

! src/windows/bin/java_md.c
+ test/tools/launcher/MiscTests.java
- test/tools/launcher/VerifyExceptions.java



From lana.steuck at oracle.com  Fri Sep  3 19:02:13 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 03 Sep 2010 19:02:13 +0000
Subject: hg: jdk7/tl: 4 new changesets
Message-ID: <20100903190213.4160B476C3@hg.openjdk.java.net>

Changeset: 43096cccf1ce
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/43096cccf1ce

Added tag jdk7-b105 for changeset 9f96a4269d77

! .hgtags

Changeset: 7d396ad455c3
Author:    cl
Date:      2010-08-19 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/7d396ad455c3

Added tag jdk7-b106 for changeset 43096cccf1ce

! .hgtags

Changeset: 140fdef4ddf5
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/140fdef4ddf5

Added tag jdk7-b107 for changeset 7d396ad455c3

! .hgtags

Changeset: 90357eee5234
Author:    lana
Date:      2010-09-02 22:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/90357eee5234

Merge




From lana.steuck at oracle.com  Fri Sep  3 19:02:17 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 03 Sep 2010 19:02:17 +0000
Subject: hg: jdk7/tl/corba: 3 new changesets
Message-ID: <20100903190219.B8551476C4@hg.openjdk.java.net>

Changeset: 232adb83eae8
Author:    cl
Date:      2010-08-19 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/232adb83eae8

Added tag jdk7-b106 for changeset 519daea48888

! .hgtags

Changeset: 8d810527b499
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/8d810527b499

Added tag jdk7-b107 for changeset 232adb83eae8

! .hgtags

Changeset: d6297db2b9dd
Author:    lana
Date:      2010-09-02 22:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/d6297db2b9dd

Merge




From lana.steuck at oracle.com  Fri Sep  3 19:03:44 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 03 Sep 2010 19:03:44 +0000
Subject: hg: jdk7/tl/hotspot: 65 new changesets
Message-ID: <20100903190535.410C5476C5@hg.openjdk.java.net>

Changeset: 3dc64719cf18
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3dc64719cf18

Added tag jdk7-b105 for changeset 6709c14587c2

! .hgtags

Changeset: a81afd9c293c
Author:    alanb
Date:      2010-07-16 13:14 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a81afd9c293c

6649594: Intermittent IOExceptions during dynamic attach on linux and solaris
Reviewed-by: dcubed, dholmes

! src/os/linux/vm/attachListener_linux.cpp
! src/os/solaris/vm/attachListener_solaris.cpp

Changeset: 920aa833fd16
Author:    apangin
Date:      2010-07-17 21:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/920aa833fd16

Merge


Changeset: a5c9d63a187d
Author:    apangin
Date:      2010-07-20 08:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a5c9d63a187d

6964170: Verifier crashes
Summary: Check if klassOop != NULL rather than klass_part != NULL
Reviewed-by: kamg, never

! src/share/vm/classfile/verificationType.cpp
! src/share/vm/classfile/verifier.cpp

Changeset: 7f0fdccac34f
Author:    apangin
Date:      2010-07-25 07:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7f0fdccac34f

Merge

! src/share/vm/classfile/verifier.cpp

Changeset: 3d90023429ec
Author:    aph
Date:      2010-07-28 17:38 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3d90023429ec

6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows
Reviewed-by: dcubed, dholmes

! src/os/linux/vm/globals_linux.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: a64438a2b7e8
Author:    coleenp
Date:      2010-07-28 17:57 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a64438a2b7e8

6958465: Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue
Summary: Fix compilation errors.  Made non-const references const so can be assigned with lvalue.
Reviewed-by: phh, xlu

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp

Changeset: 126ea7725993
Author:    bobv
Date:      2010-08-03 08:13 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/126ea7725993

6953477: Increase portability and flexibility of building Hotspot
Summary: A collection of portability improvements including shared code support for PPC, ARM platforms, software floating point, cross compilation support and improvements in error crash detail.
Reviewed-by: phh, never, coleenp, dholmes

! agent/src/os/linux/ps_proc.c
! make/Makefile
! make/defs.make
! make/linux/makefiles/build_vm_def.sh
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/product.make
! make/linux/makefiles/sa.make
! make/linux/makefiles/saproc.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/defs.make
! src/cpu/sparc/vm/bytecodeInterpreter_sparc.inline.hpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/interpreterRT_sparc.cpp
! src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/interpreterRT_x86_32.cpp
! src/cpu/x86/vm/javaFrameAnchor_x86.hpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/os/linux/launcher/java_md.c
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp
! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_FrameMap.cpp
! src/share/vm/c1/c1_FrameMap.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/code/vtableStubs.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/includeDB_compiler1
! src/share/vm/includeDB_core
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/bytecodeInterpreter.hpp
! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/arrayKlassKlass.cpp
! src/share/vm/oops/arrayKlassKlass.hpp
! src/share/vm/oops/compiledICHolderKlass.cpp
! src/share/vm/oops/compiledICHolderKlass.hpp
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constMethodKlass.hpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/constantPoolKlass.hpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/cpCacheKlass.hpp
! src/share/vm/oops/generateOopMap.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klassKlass.cpp
! src/share/vm/oops/klassKlass.hpp
! src/share/vm/oops/oop.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiEnvThreadState.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/javaFrameAnchor.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/sharedRuntimeTrans.cpp
! src/share/vm/runtime/signature.hpp
! src/share/vm/runtime/stubCodeGenerator.cpp
! src/share/vm/runtime/stubCodeGenerator.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/macros.hpp
! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp

Changeset: e5dfb3ccb88b
Author:    kvn
Date:      2010-07-23 10:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e5dfb3ccb88b

6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value()
Summary: Add missing is_static guard.
Reviewed-by: twisti

! src/share/vm/ci/ciField.cpp
! src/share/vm/opto/macro.cpp

Changeset: 99ceb0e99c9e
Author:    never
Date:      2010-07-26 15:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/99ceb0e99c9e

Merge


Changeset: 66c5dadb4d61
Author:    kvn
Date:      2010-07-30 10:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/66c5dadb4d61

6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path()
Summary: set Z = 0 (not equal) before repne_scan() to indicate that class was not found when RCX == 0.
Reviewed-by: never, phh

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/exceptions.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 0e35fa8ebccd
Author:    kvn
Date:      2010-08-03 15:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0e35fa8ebccd

6973963: SEGV in ciBlock::start_bci() with EA
Summary: Added more checks into ResourceObj and growableArray to verify correctness of allocation type.
Reviewed-by: never, coleenp, dholmes

! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciMethodBlocks.cpp
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/utilities/growableArray.hpp

Changeset: 0e09207fc81b
Author:    kvn
Date:      2010-08-04 17:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0e09207fc81b

6974682: CTW: assert(target != NULL) failed: must not be null
Summary: Add address table size to constant section size.
Reviewed-by: never

! src/share/vm/opto/output.cpp

Changeset: fb8abd207dbe
Author:    kvn
Date:      2010-08-06 11:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fb8abd207dbe

6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586
Summary: Tell C++ to not inline so much by using flag -xspace.
Reviewed-by: ysr

! make/solaris/makefiles/sparcWorks.make

Changeset: 2dfd013a7465
Author:    kvn
Date:      2010-08-09 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2dfd013a7465

6975078: assert(allocated_on_res_area() || allocated_on_C_heap() || allocated_on_arena()
Summary: Pass the check in ResourceObj() if _allocation value is already set and object is allocated on stack.
Reviewed-by: dholmes, johnc

! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: f4f596978298
Author:    never
Date:      2010-08-09 17:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f4f596978298

Merge

! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 36519c19beeb
Author:    never
Date:      2010-08-10 12:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/36519c19beeb

6975027: use of movptr to set length of array
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/assembler_x86.cpp

Changeset: 4a665be40fd3
Author:    twisti
Date:      2010-08-11 01:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4a665be40fd3

6975855: don't emit deopt MH handler in C1 if not required
Summary: This CR implements the same for C1 as 6926782 for C2.
Reviewed-by: never

! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/code/nmethod.cpp

Changeset: d2ede61b7a12
Author:    twisti
Date:      2010-08-11 05:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d2ede61b7a12

6976186: integrate Shark HotSpot changes
Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure.
Reviewed-by: kvn, twisti
Contributed-by: Gary Benson <gbenson at redhat.com>

! make/Makefile
! make/linux/Makefile
! make/linux/makefiles/gcc.make
+ make/linux/makefiles/shark.make
! make/linux/makefiles/top.make
! make/linux/makefiles/vm.make
! src/cpu/zero/vm/disassembler_zero.hpp
+ src/cpu/zero/vm/shark_globals_zero.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/disassembler.cpp
+ src/share/vm/includeDB_shark
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vm_version.cpp
+ src/share/vm/shark/llvmHeaders.hpp
+ src/share/vm/shark/llvmValue.hpp
+ src/share/vm/shark/sharkBlock.cpp
+ src/share/vm/shark/sharkBlock.hpp
+ src/share/vm/shark/sharkBuilder.cpp
+ src/share/vm/shark/sharkBuilder.hpp
+ src/share/vm/shark/sharkCacheDecache.cpp
+ src/share/vm/shark/sharkCacheDecache.hpp
+ src/share/vm/shark/sharkCodeBuffer.hpp
+ src/share/vm/shark/sharkCompiler.cpp
+ src/share/vm/shark/sharkCompiler.hpp
+ src/share/vm/shark/sharkConstant.cpp
+ src/share/vm/shark/sharkConstant.hpp
+ src/share/vm/shark/sharkContext.cpp
+ src/share/vm/shark/sharkContext.hpp
+ src/share/vm/shark/sharkEntry.hpp
+ src/share/vm/shark/sharkFunction.cpp
+ src/share/vm/shark/sharkFunction.hpp
+ src/share/vm/shark/sharkInliner.cpp
+ src/share/vm/shark/sharkInliner.hpp
+ src/share/vm/shark/sharkIntrinsics.cpp
+ src/share/vm/shark/sharkIntrinsics.hpp
+ src/share/vm/shark/sharkInvariants.cpp
+ src/share/vm/shark/sharkInvariants.hpp
+ src/share/vm/shark/sharkMemoryManager.cpp
+ src/share/vm/shark/sharkMemoryManager.hpp
+ src/share/vm/shark/sharkNativeWrapper.cpp
+ src/share/vm/shark/sharkNativeWrapper.hpp
+ src/share/vm/shark/sharkRuntime.cpp
+ src/share/vm/shark/sharkRuntime.hpp
+ src/share/vm/shark/sharkStack.cpp
+ src/share/vm/shark/sharkStack.hpp
+ src/share/vm/shark/sharkState.cpp
+ src/share/vm/shark/sharkState.hpp
+ src/share/vm/shark/sharkStateScanner.cpp
+ src/share/vm/shark/sharkStateScanner.hpp
+ src/share/vm/shark/sharkTopLevelBlock.cpp
+ src/share/vm/shark/sharkTopLevelBlock.hpp
+ src/share/vm/shark/sharkType.hpp
+ src/share/vm/shark/sharkValue.cpp
+ src/share/vm/shark/sharkValue.hpp
+ src/share/vm/shark/shark_globals.cpp
+ src/share/vm/shark/shark_globals.hpp
! src/share/vm/utilities/macros.hpp

Changeset: 6c9cc03d8726
Author:    kvn
Date:      2010-08-11 10:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6c9cc03d8726

6973329: C2 with Zero based COOP produces code with broken anti-dependency on x86
Summary: Recompile without subsuming loads if RA try to clone a node with anti_dependence.
Reviewed-by: never

! src/share/vm/includeDB_compiler2
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/reg_split.cpp
+ test/compiler/6973329/Test.java

Changeset: ab3fd720516c
Author:    rasbold
Date:      2010-08-10 19:17 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ab3fd720516c

6378314: Bad warning message when agent library not found. local directory is not searched.
Summary: Print a more detailed error message for agent library load failure.
Reviewed-by: jcoomes, never, ohair, coleenp
Contributed-by: jeremymanson at google.com

! src/share/vm/runtime/thread.cpp

Changeset: 21e519b91576
Author:    dcubed
Date:      2010-08-13 07:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/21e519b91576

Merge

! src/share/vm/runtime/thread.cpp

Changeset: 688a538aa654
Author:    trims
Date:      2010-08-13 10:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/688a538aa654

Merge


Changeset: 5f3c8db59d83
Author:    trims
Date:      2010-08-13 10:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5f3c8db59d83

6977051: Bump the HS19 build number to 06
Summary: Update the HS19 build number to 06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1b81ca701fa5
Author:    trims
Date:      2010-08-17 09:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1b81ca701fa5

Merge


Changeset: 30266066c77c
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/30266066c77c

Added tag jdk7-b106 for changeset 1b81ca701fa5

! .hgtags

Changeset: 295c3ae4ab5b
Author:    trims
Date:      2010-08-19 18:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/295c3ae4ab5b

Added tag hs19-b05 for changeset cc3fdfeb54b0

! .hgtags

Changeset: bf496cbe9b74
Author:    trims
Date:      2010-08-19 18:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bf496cbe9b74

Added tag hs19-b06 for changeset 688a538aa654

! .hgtags

Changeset: e44a93947ccb
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e44a93947ccb

Added tag jdk7-b107 for changeset bf496cbe9b74

! .hgtags

Changeset: f6f3eef8a521
Author:    kevinw
Date:      2010-07-30 22:43 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f6f3eef8a521

6581734: CMS Old Gen's collection usage is zero after GC which is incorrect
Summary: Management code enabled for use by a concurrent collector.
Reviewed-by: mchung, ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
! src/share/vm/services/management.cpp
! src/share/vm/services/memoryManager.cpp
! src/share/vm/services/memoryManager.hpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/services/memoryService.hpp
+ test/gc/6581734/Test6581734.java

Changeset: 63f4675ac87d
Author:    kevinw
Date:      2010-07-31 15:10 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/63f4675ac87d

Merge

- src/os/linux/vm/vtune_linux.cpp
- src/os/solaris/vm/vtune_solaris.cpp
- src/os/windows/vm/vtune_windows.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
- src/share/vm/runtime/vtune.hpp

Changeset: 2d160770d2e5
Author:    johnc
Date:      2010-08-02 12:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2d160770d2e5

6814437: G1: remove the _new_refs array
Summary: The per-worker _new_refs array is used to hold references that point into the collection set. It is populated during RSet updating and subsequently processed. In the event of an evacuation failure it processed again to recreate the RSets of regions in the collection set. Remove the per-worker _new_refs array by processing the references directly. Use a DirtyCardQueue to hold the cards containing the references so that the RSets of regions in the collection set can be recreated when handling an evacuation failure.
Reviewed-by: iveresov, jmasa, tonyp

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/includeDB_gc_g1

Changeset: 9d7a8ab3736b
Author:    tonyp
Date:      2010-07-22 10:27 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9d7a8ab3736b

6962589: remove breadth first scanning code from parallel gc
Summary: Remove the breadth-first copying order from ParallelScavenge and use depth-first by default.
Reviewed-by: jcoomes, ysr, johnc

! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge
! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp
- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp
! src/share/vm/oops/arrayKlassKlass.cpp
! src/share/vm/oops/compiledICHolderKlass.cpp
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/klassKlass.cpp
! src/share/vm/oops/klassPS.hpp
! src/share/vm/oops/methodDataKlass.cpp
! src/share/vm/oops/methodKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlassKlass.cpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.psgc.inline.hpp
! src/share/vm/oops/symbolKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 0ce1569c90e5
Author:    tonyp
Date:      2010-08-04 13:03 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0ce1569c90e5

6963209: G1: remove the concept of abandoned pauses
Summary: As part of 6944166 we disabled the concept of abandoned pauses (i.e., if the collection set is empty, we would still try to do a pause even if it is to update the RSets and scan the roots). This changeset removes the code and structures associated with abandoned pauses.
Reviewed-by: iveresov, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp

Changeset: a03ae377b2e8
Author:    johnc
Date:      2010-08-06 10:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a03ae377b2e8

6930581: G1: assert(ParallelGCThreads > 1 || n_yielded() == _hrrs->occupied(),"Should have yielded all the ..
Summary: During RSet updating, when ParallelGCThreads is zero, references that point into the collection set are added directly the referenced region's RSet. This can cause the sparse table in the RSet to expand. RSet scanning and the "occupied" routine will then operate on different instances of the sparse table causing the assert to trip. This may also cause some cards added post expansion to be missed during RSet scanning. When ParallelGCThreads is non-zero such references are recorded on the "references to be scanned" queue and the card containing the reference is recorded in a dirty card queue for use in the event of an evacuation failure. Employ the parallel code in the serial case to avoid expanding the RSets of regions in the collection set.
Reviewed-by: iveresov, ysr, tonyp

! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp

Changeset: 5f429ee79634
Author:    jcoomes
Date:      2010-08-09 05:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5f429ee79634

6966222: G1: simplify TaskQueue overflow handling
Reviewed-by: tonyp, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/utilities/taskqueue.cpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: 94251661de76
Author:    jcoomes
Date:      2010-08-09 18:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/94251661de76

6970376: ParNew: shared TaskQueue statistics
Reviewed-by: ysr

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp

Changeset: a6bff45449bc
Author:    ysr
Date:      2010-08-10 14:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a6bff45449bc

6973570: OrderAccess::storestore() scales poorly on multi-socket x64 and sparc: cache-line ping-ponging
Summary: volatile store to static variable removed in favour of a volatile store to stack to avoid excessive cache coherency traffic; verified that the volatile store is not elided by any of our current compilers.
Reviewed-by: dholmes, dice, jcoomes, kvn

! src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp
! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp
! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp
! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp
! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp
! src/share/vm/runtime/orderAccess.cpp
! src/share/vm/runtime/orderAccess.hpp

Changeset: 2d6b74c9a797
Author:    jcoomes
Date:      2010-08-11 13:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2d6b74c9a797

6976378: ParNew:  stats are printed unconditionally in debug builds
Reviewed-by: tonyp

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp

Changeset: 7fcd5f39bd7a
Author:    johnc
Date:      2010-08-14 00:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7fcd5f39bd7a

Merge

- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp
! src/share/vm/oops/arrayKlassKlass.cpp
! src/share/vm/oops/compiledICHolderKlass.cpp
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/klassKlass.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: f121b2772674
Author:    trims
Date:      2010-08-18 16:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f121b2772674

Merge

- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp

Changeset: 495caa35b1b5
Author:    asaha
Date:      2010-08-17 22:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/495caa35b1b5

6977952: Test: Sync missing tests from hs16.3 to hs17.x
Reviewed-by: wrockett

+ test/compiler/6894807/IsInstanceTest.java
+ test/compiler/6894807/Test6894807.sh
+ test/runtime/6626217/IFace.java
+ test/runtime/6626217/Loader2.java
+ test/runtime/6626217/Test6626217.sh
+ test/runtime/6626217/You_Have_Been_P0wned.java
+ test/runtime/6626217/bug_21227.java
+ test/runtime/6626217/from_loader2.java
+ test/runtime/6626217/many_loader1.java.foo
+ test/runtime/6626217/many_loader2.java.foo

Changeset: be3f9c242c9d
Author:    ysr
Date:      2010-08-16 15:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/be3f9c242c9d

6948538: CMS: BOT walkers can fall into object allocation and initialization cracks
Summary: GC workers now recognize an intermediate transient state of blocks which are allocated but have not yet completed initialization. blk_start() calls do not attempt to determine the size of a block in the transient state, rather waiting for the block to become initialized so that it is safe to query its size. Audited and ensured the order of initialization of object fields (klass, free bit and size) to respect block state transition protocol. Also included some new assertion checking code enabled in debug mode.
Reviewed-by: chrisphi, johnc, poonam

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp
! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
! src/share/vm/includeDB_core
! src/share/vm/memory/blockOffsetTable.cpp
! src/share/vm/memory/blockOffsetTable.hpp
! src/share/vm/memory/blockOffsetTable.inline.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 688c3755d7af
Author:    tonyp
Date:      2010-08-17 14:40 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/688c3755d7af

6959014: G1: assert(minimum_desired_capacity <= maximum_desired_capacity) failed: sanity check
Summary: There are a few issues in the code that calculates whether to resize the heap and by how much: a) some calculations can overflow 32-bit size_t's, b) min_desired_capacity is not bounded by the max heap size, and c) the assrt that fires is in the wrong place. The fix also includes some tidying up of the related verbose code.
Reviewed-by: ysr, jmasa

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: bb847e31b836
Author:    tonyp
Date:      2010-08-17 14:40 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bb847e31b836

6974928: G1: sometimes humongous objects are allocated in young regions
Summary: as the title says, sometimes we are allocating humongous objects in young regions and we shouldn't.
Reviewed-by: ysr, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp

Changeset: b63010841f78
Author:    tonyp
Date:      2010-08-17 14:40 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b63010841f78

6975964: G1: print out a more descriptive message for evacuation failure when +PrintGCDetails is set
Summary: we're renaming "evacuation failure" to "to-space overflow". I'm also piggy-backing a small additional change which removes the "Mark closure took..." output.
Reviewed-by: ysr, johnc

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 5ed703250bff
Author:    ysr
Date:      2010-08-18 11:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5ed703250bff

6977970: CMS: concurrentMarkSweepGeneration.cpp:7947 assert(addr <= _limit) failed: sweep invariant
Summary: Allow for the possibility (when the heap is expanding) that the sweep might skip over and past, rather than necessarily step on, the sweep limit determined at the beginning of a concurrent marking cycle.
Reviewed-by: jmasa, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

Changeset: 413ad0331a0c
Author:    johnc
Date:      2010-08-18 10:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/413ad0331a0c

6977924: Changes for 6975078 produce build error with certain gcc versions
Summary: The changes introduced for 6975078 assign badHeapOopVal to the _allocation field in the ResourceObj class. In 32 bit linux builds with certain versions of gcc this assignment will be flagged as an error while compiling allocation.cpp. In 32 bit builds the constant value badHeapOopVal (which is cast to an intptr_t) is negative. The _allocation field is typed as an unsigned intptr_t and gcc catches this as an error.
Reviewed-by: jcoomes, ysr, phh

! src/share/vm/memory/allocation.cpp

Changeset: effb55808a18
Author:    johnc
Date:      2010-08-18 17:44 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/effb55808a18

Merge


Changeset: 1b0104ab1e5e
Author:    tonyp
Date:      2010-08-19 14:08 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1b0104ab1e5e

Merge


Changeset: 0e509ddd9962
Author:    trims
Date:      2010-08-20 03:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0e509ddd9962

6978726: Bump the HS19 build number to 07
Summary: Update the HS19 build number to 07
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 09cdb1e1c77b
Author:    trims
Date:      2010-08-20 04:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/09cdb1e1c77b

Merge

- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp

Changeset: 71faaa8e3ccc
Author:    never
Date:      2010-08-12 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/71faaa8e3ccc

6974176: ShouldNotReachHere, instanceKlass.cpp:1426
Reviewed-by: kvn, twisti

! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp

Changeset: da877bdc9000
Author:    never
Date:      2010-08-12 23:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/da877bdc9000

6975006: assert(check.is_deoptimized_frame()) failed: missed deopt
Reviewed-by: kvn, twisti

! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/safepoint.hpp
! src/share/vm/runtime/thread.cpp

Changeset: a62d332029cf
Author:    never
Date:      2010-08-13 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a62d332029cf

6976372: #  assert(_owner == Thread::current()) failed: invariant
Reviewed-by: kvn, twisti

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 13b87063b4d8
Author:    twisti
Date:      2010-08-18 01:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/13b87063b4d8

6977640: Zero and Shark fixes
Summary: A number of fixes for Zero and Shark.
Reviewed-by: twisti
Contributed-by: Gary Benson <gbenson at redhat.com>

! src/cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp
! src/cpu/zero/vm/javaFrameAnchor_zero.hpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp

Changeset: f55c4f82ab9d
Author:    never
Date:      2010-08-19 14:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f55c4f82ab9d

6978249: spill between cpu and fpu registers when those moves are fast
Reviewed-by: kvn

! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/init.cpp

Changeset: ee5cc9e78493
Author:    never
Date:      2010-08-20 09:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ee5cc9e78493

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/thread.cpp

Changeset: 52f2bc645da5
Author:    ysr
Date:      2010-08-19 12:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/52f2bc645da5

6978533: CMS: Elide BOT  update asserts until 6977974 is fixed correctly
Reviewed-by: jcoomes, jmasa, tonyp

! src/share/vm/memory/blockOffsetTable.hpp

Changeset: 66b9f90a9211
Author:    tonyp
Date:      2010-08-20 13:17 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/66b9f90a9211

Merge


Changeset: 26faca352942
Author:    tonyp
Date:      2010-08-20 12:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/26faca352942

Merge


Changeset: 571f6b35140b
Author:    trims
Date:      2010-08-20 12:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/571f6b35140b

6978889: Remove premature change of build number to Hotspot 19 Build 07
Summary: Change the build number back to 06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: b0b9d64ed9bc
Author:    trims
Date:      2010-08-20 14:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b0b9d64ed9bc

6978915: Remove Mercurial tags for Hotspot 19 Build 06
Summary: Delete the hs19-b06 Hg tag, as it was put on incorrectly
Reviewed-by: jcoomes

! .hgtags

Changeset: 6c43216df135
Author:    trims
Date:      2010-08-31 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6c43216df135

Merge

! .hgtags

Changeset: 0803c0f69b51
Author:    trims
Date:      2010-08-31 17:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0803c0f69b51

Added tag hs19-b06 for changeset 6c43216df135

! .hgtags



From lana.steuck at oracle.com  Fri Sep  3 19:06:09 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 03 Sep 2010 19:06:09 +0000
Subject: hg: jdk7/tl/jaxp: 4 new changesets
Message-ID: <20100903190609.CDA82476C6@hg.openjdk.java.net>

Changeset: 5ba8469212a6
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/5ba8469212a6

Added tag jdk7-b105 for changeset 3233b9a4c12e

! .hgtags

Changeset: 20ee37c1372a
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/20ee37c1372a

Added tag jdk7-b106 for changeset 5ba8469212a6

! .hgtags

Changeset: 7d379f8934ca
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/7d379f8934ca

Added tag jdk7-b107 for changeset 20ee37c1372a

! .hgtags

Changeset: 4a249814b147
Author:    lana
Date:      2010-09-02 22:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/4a249814b147

Merge




From lana.steuck at oracle.com  Fri Sep  3 19:06:14 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 03 Sep 2010 19:06:14 +0000
Subject: hg: jdk7/tl/jaxws: 4 new changesets
Message-ID: <20100903190614.43BA8476C7@hg.openjdk.java.net>

Changeset: bc45ccc5bcca
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/bc45ccc5bcca

Added tag jdk7-b105 for changeset 39eb4f3031f4

! .hgtags

Changeset: 017612ea6af4
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/017612ea6af4

Added tag jdk7-b106 for changeset bc45ccc5bcca

! .hgtags

Changeset: b1ca39340238
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/b1ca39340238

Added tag jdk7-b107 for changeset 017612ea6af4

! .hgtags

Changeset: 5dd2cc894d0c
Author:    lana
Date:      2010-09-02 22:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/5dd2cc894d0c

Merge




From lana.steuck at oracle.com  Fri Sep  3 19:07:02 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 03 Sep 2010 19:07:02 +0000
Subject: hg: jdk7/tl/jdk: 18 new changesets
Message-ID: <20100903190955.B05EC476C8@hg.openjdk.java.net>

Changeset: 9ad95be9deae
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9ad95be9deae

Added tag jdk7-b105 for changeset 3b0abcb51280

! .hgtags

Changeset: f8bbf376595c
Author:    yhuang
Date:      2010-08-11 02:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8bbf376595c

6959252: convert the anonymous arrays to named arrays in Java List Resource files
Reviewed-by: katakai, psun

! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java
! src/share/classes/sun/applet/resources/MsgAppletViewer.java
! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java
! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii.java

Changeset: 413cede85120
Author:    yhuang
Date:      2010-08-13 01:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/413cede85120

Merge

- test/java/net/Socket/AccurateTimeout.java

Changeset: b91ef6b60f4e
Author:    cl
Date:      2010-08-16 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b91ef6b60f4e

Merge


Changeset: 882103f334bb
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/882103f334bb

Added tag jdk7-b106 for changeset b91ef6b60f4e

! .hgtags

Changeset: 17a5d84b7561
Author:    cl
Date:      2010-08-26 16:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/17a5d84b7561

Added tag jdk7-b107 for changeset 882103f334bb

! .hgtags

Changeset: d47bd9d94ba4
Author:    dlila
Date:      2010-08-10 13:19 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d47bd9d94ba4

6967436: lines longer than 2^15 can fill window.
6967433: dashed lines broken when using scaling transforms.
Summary: converted pisces to floating point. Also, using better AA algorithm
Reviewed-by: flar

! src/share/classes/sun/java2d/pisces/Dasher.java
! src/share/classes/sun/java2d/pisces/LineSink.java
- src/share/classes/sun/java2d/pisces/PiscesMath.java
! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
! src/share/classes/sun/java2d/pisces/Renderer.java
! src/share/classes/sun/java2d/pisces/Stroker.java
- src/share/classes/sun/java2d/pisces/Transform4.java

Changeset: 4285edea9ddb
Author:    dlila
Date:      2010-08-11 10:05 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4285edea9ddb

6976265: No STROKE_CONTROL
Summary: implemented it in sun.java2d.pisces by adding a PathIterator.
Reviewed-by: flar

! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java

Changeset: 0576f6cc0463
Author:    lana
Date:      2010-08-12 19:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0576f6cc0463

Merge

- test/java/net/Socket/AccurateTimeout.java

Changeset: 654145d6560a
Author:    lana
Date:      2010-08-23 19:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/654145d6560a

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java

Changeset: d0e314d59f84
Author:    malenkov
Date:      2010-08-10 19:29 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d0e314d59f84

6960267: JTable.getRowHeight() returns value different from the specified default (16.0) with GTK L&F
Reviewed-by: peterz

! src/share/classes/javax/swing/JTable.java

Changeset: 58626b4eedcb
Author:    lana
Date:      2010-08-12 11:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/58626b4eedcb

Merge

- test/java/net/Socket/AccurateTimeout.java

Changeset: 23f72ec0d8e8
Author:    peytoia
Date:      2010-08-23 14:14 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/23f72ec0d8e8

6977550: (tz) Support tzdata2010l
Reviewed-by: okutsu

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/backward
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/zone.tab
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java

Changeset: a18a82d2d506
Author:    lana
Date:      2010-08-23 19:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a18a82d2d506

Merge


Changeset: 62d37c19c213
Author:    lana
Date:      2010-08-23 19:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/62d37c19c213

Merge

- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: 043d2736d44c
Author:    lana
Date:      2010-08-29 22:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/043d2736d44c

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: 80a8742483bf
Author:    lana
Date:      2010-09-02 22:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/80a8742483bf

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java

Changeset: 10728041e814
Author:    lana
Date:      2010-09-03 12:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/10728041e814

Merge

- test/tools/launcher/VerifyExceptions.java



From lana.steuck at oracle.com  Fri Sep  3 19:11:13 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 03 Sep 2010 19:11:13 +0000
Subject: hg: jdk7/tl/langtools: 7 new changesets
Message-ID: <20100903191126.F1AB6476C9@hg.openjdk.java.net>

Changeset: 112fcc00659d
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/112fcc00659d

Added tag jdk7-b105 for changeset aaecac256d39

! .hgtags

Changeset: 2c1c657f69a4
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2c1c657f69a4

Added tag jdk7-b106 for changeset 112fcc00659d

! .hgtags

Changeset: a408ebb8b3d4
Author:    cl
Date:      2010-08-26 16:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a408ebb8b3d4

Added tag jdk7-b107 for changeset 2c1c657f69a4

! .hgtags

Changeset: 0c81bff15ced
Author:    lana
Date:      2010-08-23 19:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0c81bff15ced

Merge


Changeset: ba774f919ad0
Author:    lana
Date:      2010-08-29 22:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ba774f919ad0

Merge


Changeset: 3fba23db9619
Author:    lana
Date:      2010-09-02 22:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3fba23db9619

Merge


Changeset: 68e765b1e9ed
Author:    lana
Date:      2010-09-03 12:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/68e765b1e9ed

Merge




From alan.bateman at oracle.com  Fri Sep  3 20:27:11 2010
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 03 Sep 2010 20:27:11 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100903202730.EAFF2476D4@hg.openjdk.java.net>

Changeset: 174916d435c9
Author:    alanb
Date:      2010-09-03 13:11 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/174916d435c9

6965072: Need API to create SDP sockets
Reviewed-by: michaelm

! make/com/Makefile
+ make/com/oracle/Makefile
+ make/com/oracle/net/Makefile
! make/docs/NON_CORE_PKGS.gmk
! make/java/net/FILES_c.gmk
! make/java/net/Makefile
! make/java/net/mapfile-vers
! make/java/nio/FILES_java.gmk
! make/sun/net/FILES_java.gmk
+ src/share/classes/com/oracle/net/Sdp.java
+ src/share/classes/java/net/SdpSocketImpl.java
! src/share/classes/java/net/ServerSocket.java
+ src/share/classes/sun/net/sdp/SdpSupport.java
+ src/share/classes/sun/nio/ch/Secrets.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/solaris/classes/sun/net/NetHooks.java
+ src/solaris/classes/sun/net/sdp/SdpProvider.java
- src/solaris/classes/sun/net/spi/SdpProvider.java
! src/solaris/classes/sun/nio/ch/InheritedChannel.java
+ src/solaris/native/sun/net/sdp/SdpSupport.c
- src/solaris/native/sun/net/spi/SdpProvider.c
+ test/com/oracle/net/Sanity.java
+ test/com/oracle/net/sanity.sh
! test/sun/net/sdp/ProbeIB.java
! test/sun/net/sdp/sanity.sh

Changeset: e17654f00d93
Author:    alanb
Date:      2010-09-03 21:03 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e17654f00d93

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/launcher/VerifyExceptions.java



From joe.darcy at oracle.com  Fri Sep  3 21:59:35 2010
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Fri, 03 Sep 2010 21:59:35 +0000
Subject: hg: jdk7/tl/jdk: 4881419: The type of X[].clone() should be X[]
Message-ID: <20100903215945.27035476DD@hg.openjdk.java.net>

Changeset: a6c142240837
Author:    darcy
Date:      2010-09-03 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a6c142240837

4881419: The type of X[].clone() should be X[]
Reviewed-by: martin

! src/share/classes/java/lang/Object.java



From joe.darcy at oracle.com  Fri Sep  3 22:00:59 2010
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 03 Sep 2010 15:00:59 -0700
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>
	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
Message-ID: <4C81701B.5050006@oracle.com>

Martin Buchholz wrote:
>
>
> On Thu, Sep 2, 2010 at 17:50, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Martin Buchholz wrote:
>
>         The usage T[] suggests that T is a reference type, as with
>         generics, which is not the case here.
>
>         More precisely, both the runtime types and compiletime types
>         of the object returned from clone of any array is identical to
>         its input.
>         Is there a non-confusing way of saying that?
>
>
>     How about
>
>     "...and that the return type of the {@code clone} method of an
>     array type {@code T[]} is {@code T[]} where T is either a
>     reference or a primitive type."?
>
>
> So I went and actually read the Object.clone spec, and it does indeed 
> guarantee that the (runtime) class of the returned value is the same 
> as the class of the argument, for arrays.  As for the compile-time 
> type, an experiment demonstrates that the return type is indeed 
> exactly the same, including for non-reifiable array element types, 
> e.g. this compiles:
>
>         Class<? extends Number>[] a
>             = (Class<? extends Number>[]) (new Class<?>[42]);
>         Class<? extends Number>[] clone = a.clone();
>
>
> So Ulf's restriction to non-reifiable T seems not to be correct.
>
> My suggested wording is:
>
> "...and that the return type of the {@code clone} method of an array 
> type {@code T[]} is {@code T[]} where T is any reference or primitive 
> type."
>
> Martin "Objects have class; Variables have type"

Sounds good to me; change pushed!

Thanks,

-Joe



From joe.darcy at oracle.com  Fri Sep  3 22:05:36 2010
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 03 Sep 2010 15:05:36 -0700
Subject: Code review request for 4881419 The type of X[].clone() should
	be	X[]
In-Reply-To: <4C80F9F8.4000703@gmx.de>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
	<4C80CE78.7040204@gmx.de> <4C80F9F8.4000703@gmx.de>
Message-ID: <4C817130.9070405@oracle.com>

Ulf Zibis wrote:
> Am 03.09.2010 12:31, schrieb Ulf Zibis:
>>
>> I think the question of variable types belongs to the spec, but here 
>> in Object class's javadoc we should speak about objects. So I now 
>> suggest:
>> "...and that the returned object of the {@code clone} method of an 
>> array object of class {@code T[]} is of class {@code T[]} where T is 
>> any [raw]? reference or primitive class. See java language 
>> specification version 3, section 6.4.5"
>>
>
> And additionally 2 cents: As T is often used for parameter type in 
> context with generics, I think, X would leed to less misinterpretation 
> and would match better to the according spec.
>

I think the text as suggested by Martin with the explicit definition of 
T is sufficiently clear as-is.

-Joe



From Ulf.Zibis at gmx.de  Fri Sep  3 22:31:11 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 04 Sep 2010 00:31:11 +0200
Subject: Code review request for 4881419 The type of X[].clone() should
	be	X[]
In-Reply-To: <4C817130.9070405@oracle.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
	<4C80CE78.7040204@gmx.de> <4C80F9F8.4000703@gmx.de>
	<4C817130.9070405@oracle.com>
Message-ID: <4C81772F.7030703@gmx.de>

  Am 04.09.2010 00:05, schrieb Joe Darcy:
> Ulf Zibis wrote:
>> Am 03.09.2010 12:31, schrieb Ulf Zibis:
>>>
>>> I think the question of variable types belongs to the spec, but here in Object class's javadoc 
>>> we should speak about objects. So I now suggest:
>>> "...and that the returned object of the {@code clone} method of an array object of class {@code 
>>> T[]} is of class {@code T[]} where T is any [raw]? reference or primitive class. See java 
>>> language specification version 3, section 6.4.5"
>>>
>>
>> And additionally 2 cents: As T is often used for parameter type in context with generics, I 
>> think, X would leed to less misinterpretation and would match better to the according spec.
>>
>
> I think the text as suggested by Martin with the explicit definition of T is sufficiently clear 
> as-is.
>
> -Joe

I still think, it would be more clear to speak about classes here rather then about types.
See:
         Number[] na = new Integer[123];
         na[0] = new Integer(456);
         Integer[] ia = (Integer[])na.clone();

na is of type Number[]
ia is of type Integer[] and too of type Number[]
but ia contains object of class Integer[]

-Ulf






From martinrb at google.com  Fri Sep  3 22:53:28 2010
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 3 Sep 2010 15:53:28 -0700
Subject: Code review request for 4881419 The type of X[].clone() should be
	X[]
In-Reply-To: <4C81772F.7030703@gmx.de>
References: <4C804272.9060408@oracle.com>
	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>
	<4C804654.8020909@oracle.com>
	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
	<4C80CE78.7040204@gmx.de> <4C80F9F8.4000703@gmx.de>
	<4C817130.9070405@oracle.com> <4C81772F.7030703@gmx.de>
Message-ID: <AANLkTinjstyW5=0MC2MKVB5gBjETrQm0uTDeP0F8SZ=z@mail.gmail.com>

Ulf,

The spec needs to talk about *both* class (runtime) and type (compile-time).
And now it does.

Martin

On Fri, Sep 3, 2010 at 15:31, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

>  Am 04.09.2010 00:05, schrieb Joe Darcy:
>
>  Ulf Zibis wrote:
>>
>>> Am 03.09.2010 12:31, schrieb Ulf Zibis:
>>>
>>>>
>>>> I think the question of variable types belongs to the spec, but here in
>>>> Object class's javadoc we should speak about objects. So I now suggest:
>>>> "...and that the returned object of the {@code clone} method of an array
>>>> object of class {@code T[]} is of class {@code T[]} where T is any [raw]?
>>>> reference or primitive class. See java language specification version 3,
>>>> section 6.4.5"
>>>>
>>>>
>>> And additionally 2 cents: As T is often used for parameter type in
>>> context with generics, I think, X would leed to less misinterpretation and
>>> would match better to the according spec.
>>>
>>>
>> I think the text as suggested by Martin with the explicit definition of T
>> is sufficiently clear as-is.
>>
>> -Joe
>>
>
> I still think, it would be more clear to speak about classes here rather
> then about types.
> See:
>        Number[] na = new Integer[123];
>        na[0] = new Integer(456);
>        Integer[] ia = (Integer[])na.clone();
>
> na is of type Number[]
> ia is of type Integer[] and too of type Number[]
> but ia contains object of class Integer[]
>
> -Ulf
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100903/cdab24dc/attachment.html>

From Ulf.Zibis at gmx.de  Fri Sep  3 23:13:07 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 04 Sep 2010 01:13:07 +0200
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <AANLkTinjstyW5=0MC2MKVB5gBjETrQm0uTDeP0F8SZ=z@mail.gmail.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>	<4C80CE78.7040204@gmx.de>	<4C80F9F8.4000703@gmx.de>	<4C817130.9070405@oracle.com>	<4C81772F.7030703@gmx.de>
	<AANLkTinjstyW5=0MC2MKVB5gBjETrQm0uTDeP0F8SZ=z@mail.gmail.com>
Message-ID: <4C818103.4010405@gmx.de>



  188      * The method {@code clone} for*class*  {@code Object} performs a
  189      * specific cloning operation. First, if the*class*  of this*object*does
  190      * not implement the interface {@code Cloneable}, then a
  191      * {@code CloneNotSupportedException} is thrown. Note that all arrays
  192      * are considered to implement the interface {@code Cloneable} and that
  193      * the return*type*of the {@code clone} method of an array*type*
  194      * {@code T[]} is {@code T[]}.
  195      * Otherwise, this method creates a new*instance*of the*class*  of this
  196      **object*and initializes all its fields with exactly the contents of
  197      * the corresponding fields of this*object*, as if by assignment; the
  198      * contents of the fields are not themselves cloned. Thus, this method
  199      * performs a "shallow copy" of this*object*, not a "deep copy" operation.

Hm,
the whole enclosing paragraph talks about class, object and instance, so why talk about type for the 
array case?

-Ulf


Am 04.09.2010 00:53, schrieb Martin Buchholz:
> Ulf,
>
> The spec needs to talk about *both* class (runtime) and type (compile-time).
> And now it does.
>
> Martin
>
> On Fri, Sep 3, 2010 at 15:31, Ulf Zibis <Ulf.Zibis at gmx.de <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>      Am 04.09.2010 00:05, schrieb Joe Darcy:
>
>         Ulf Zibis wrote:
>
>             Am 03.09.2010 12:31, schrieb Ulf Zibis:
>
>
>                 I think the question of variable types belongs to the spec, but here in Object
>                 class's javadoc we should speak about objects. So I now suggest:
>                 "...and that the returned object of the {@code clone} method of an array object of
>                 class {@code T[]} is of class {@code T[]} where T is any [raw]? reference or
>                 primitive class. See java language specification version 3, section 6.4.5"
>
>
>             And additionally 2 cents: As T is often used for parameter type in context with
>             generics, I think, X would leed to less misinterpretation and would match better to
>             the according spec.
>
>
>         I think the text as suggested by Martin with the explicit definition of T is sufficiently
>         clear as-is.
>
>         -Joe
>
>
>     I still think, it would be more clear to speak about classes here rather then about types.
>     See:
>            Number[] na = new Integer[123];
>            na[0] = new Integer(456);
>            Integer[] ia = (Integer[])na.clone();
>
>     na is of type Number[]
>     ia is of type Integer[] and too of type Number[]
>     but ia contains object of class Integer[]
>
>     -Ulf
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100904/c28362a1/attachment.html>

From martinrb at google.com  Fri Sep  3 23:34:23 2010
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 3 Sep 2010 16:34:23 -0700
Subject: Code review request for 4881419 The type of X[].clone() should be
	X[]
In-Reply-To: <4C818103.4010405@gmx.de>
References: <4C804272.9060408@oracle.com>
	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>
	<4C804654.8020909@oracle.com>
	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
	<4C80CE78.7040204@gmx.de> <4C80F9F8.4000703@gmx.de>
	<4C817130.9070405@oracle.com> <4C81772F.7030703@gmx.de>
	<AANLkTinjstyW5=0MC2MKVB5gBjETrQm0uTDeP0F8SZ=z@mail.gmail.com>
	<4C818103.4010405@gmx.de>
Message-ID: <AANLkTimT7UVfAa3oACYaO+XAEtNeMQo9cjXWQ5-047EZ@mail.gmail.com>

On Fri, Sep 3, 2010 at 16:13, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

>   ,
>
> the whole enclosing paragraph talks about class, object and instance, so
> why talk about type for the array case?
>
>
Because the array types don't have their own javadoc, there is no other
obvious place to document the compile-time behavior of this method for the
class for e.g. int[].


To be more precise, (but still hand-waving...), it is *as if* every array
type X has an override for clone that looked like this:

class X {

@Override X clone() { return (X) super.clone(); }

}

There is some value putting in the pseudocode above into the spec, but it is
hard to do because it's not actually legal java code, and there is no 1-1
correspondence from array types to classes.

Java does not have "self" types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100903/9df81c7e/attachment.html>

From Ulf.Zibis at gmx.de  Sat Sep  4 00:23:53 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 04 Sep 2010 02:23:53 +0200
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <AANLkTimT7UVfAa3oACYaO+XAEtNeMQo9cjXWQ5-047EZ@mail.gmail.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>	<4C80CE78.7040204@gmx.de>	<4C80F9F8.4000703@gmx.de>	<4C817130.9070405@oracle.com>	<4C81772F.7030703@gmx.de>	<AANLkTinjstyW5=0MC2MKVB5gBjETrQm0uTDeP0F8SZ=z@mail.gmail.com>	<4C818103.4010405@gmx.de>
	<AANLkTimT7UVfAa3oACYaO+XAEtNeMQo9cjXWQ5-047EZ@mail.gmail.com>
Message-ID: <4C819199.6070604@gmx.de>

  I think I still don't understand. :-(

The compile-time behaviour is well documented in JLSv3 6.4.5.

But where is the run-time behaviour documented?
Isn't the javadoc of class Object a good place?

With the term 'spec' you mean the JLS or the javadoc of class Object?

-Ulf


Am 04.09.2010 01:34, schrieb Martin Buchholz:
>
>
> On Fri, Sep 3, 2010 at 16:13, Ulf Zibis <Ulf.Zibis at gmx.de <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>       ,
>
>     the whole enclosing paragraph talks about class, object and instance, so why talk about type
>     for the array case?
>
>
> Because the array types don't have their own javadoc, there is no other obvious place to document 
> the compile-time behavior of this method for the class for e.g. int[].
>
>
> To be more precise, (but still hand-waving...), it is *as if* every array type X has an override 
> for clone that looked like this:
>
> class X {
>
> @Override X clone() { return (X) super.clone(); }
>
> }
>
> There is some value putting in the pseudocode above into the spec, but it is hard to do because 
> it's not actually legal java code, and there is no 1-1 correspondence from array types to classes.
>
> Java does not have "self" types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100904/35ef0f97/attachment.html>

From jeroen at sumatra.nl  Sat Sep  4 09:02:51 2010
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Sat, 4 Sep 2010 09:02:51 +0000
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <4C81701B.5050006@oracle.com>
References: <4C804272.9060408@oracle.com>
	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>
	<4C804654.8020909@oracle.com>
	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
	<4C81701B.5050006@oracle.com>
Message-ID: <D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>

Sorry to be late with my comment, but as a VM implementer I can't really agree with this modification. The return type of X[].clone() is clearly Object, not X{]. That illusion is a javac compiler trick. IMHO it belongs in the JLS not in the Object.clone() documentation.

Regards,
Jeroen

> -----Original Message-----
> From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-
> bounces at openjdk.java.net] On Behalf Of Joe Darcy
> Sent: Saturday, September 04, 2010 12:01 AM
> To: Martin Buchholz
> Cc: core-libs-dev
> Subject: Re: Code review request for 4881419 The type of X[].clone()
> should be X[]
> 
> Martin Buchholz wrote:
> >
> >
> > On Thu, Sep 2, 2010 at 17:50, Joe Darcy <joe.darcy at oracle.com
> > <mailto:joe.darcy at oracle.com>> wrote:
> >
> >     Martin Buchholz wrote:
> >
> >         The usage T[] suggests that T is a reference type, as with
> >         generics, which is not the case here.
> >
> >         More precisely, both the runtime types and compiletime types
> >         of the object returned from clone of any array is identical to
> >         its input.
> >         Is there a non-confusing way of saying that?
> >
> >
> >     How about
> >
> >     "...and that the return type of the {@code clone} method of an
> >     array type {@code T[]} is {@code T[]} where T is either a
> >     reference or a primitive type."?
> >
> >
> > So I went and actually read the Object.clone spec, and it does indeed
> > guarantee that the (runtime) class of the returned value is the same
> > as the class of the argument, for arrays.  As for the compile-time
> > type, an experiment demonstrates that the return type is indeed
> > exactly the same, including for non-reifiable array element types,
> > e.g. this compiles:
> >
> >         Class<? extends Number>[] a
> >             = (Class<? extends Number>[]) (new Class<?>[42]);
> >         Class<? extends Number>[] clone = a.clone();
> >
> >
> > So Ulf's restriction to non-reifiable T seems not to be correct.
> >
> > My suggested wording is:
> >
> > "...and that the return type of the {@code clone} method of an array
> > type {@code T[]} is {@code T[]} where T is any reference or primitive
> > type."
> >
> > Martin "Objects have class; Variables have type"
> 
> Sounds good to me; change pushed!
> 
> Thanks,
> 
> -Joe



From lance.andersen at oracle.com  Sat Sep  4 16:22:53 2010
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Sat, 04 Sep 2010 16:22:53 +0000
Subject: hg: jdk7/tl/jdk: 6861385: Updated SQLException subclasses to clarify
	that they may be thrown for vendor specific conditions
Message-ID: <20100904162304.4BB8947707@hg.openjdk.java.net>

Changeset: 1f99ad63eb9e
Author:    lancea
Date:      2010-09-04 12:21 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f99ad63eb9e

6861385: Updated SQLException subclasses to clarify that they may be thrown for vendor specific conditions
Reviewed-by: alanb

! src/share/classes/java/sql/SQLDataException.java
! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java
! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java
! src/share/classes/java/sql/SQLNonTransientConnectionException.java
! src/share/classes/java/sql/SQLSyntaxErrorException.java
! src/share/classes/java/sql/SQLTransactionRollbackException.java
! src/share/classes/java/sql/SQLTransientConnectionException.java



From lance.andersen at oracle.com  Sat Sep  4 17:59:30 2010
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Sat, 04 Sep 2010 17:59:30 +0000
Subject: hg: jdk7/tl/jdk: 6843995: RowSet 1.1 updates
Message-ID: <20100904175939.EA37F4770B@hg.openjdk.java.net>

Changeset: d44696691445
Author:    lancea
Date:      2010-09-04 13:56 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d44696691445

6843995: RowSet 1.1 updates
Reviewed-by: darcy, valeriep

+ src/share/classes/com/sun/rowset/RowSetFactoryImpl.java
! src/share/classes/javax/sql/rowset/CachedRowSet.java
+ src/share/classes/javax/sql/rowset/RowSetFactory.java
+ src/share/classes/javax/sql/rowset/RowSetProvider.java
! src/share/classes/javax/sql/rowset/package.html
! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java



From lance.andersen at oracle.com  Sat Sep  4 19:30:58 2010
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Sat, 04 Sep 2010 19:30:58 +0000
Subject: hg: jdk7/tl/jdk: 6680198: UnmarshalException caused by incompatible
	serialVersionUID
Message-ID: <20100904193108.4C3174770F@hg.openjdk.java.net>

Changeset: c4defe31c94a
Author:    lancea
Date:      2010-09-04 15:30 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c4defe31c94a

6680198: UnmarshalException caused by incompatible serialVersionUID
Reviewed-by: sherman

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java
! src/share/classes/com/sun/rowset/JoinRowSetImpl.java
! src/share/classes/com/sun/rowset/WebRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java
! src/share/classes/com/sun/rowset/internal/InsertRow.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/com/sun/rowset/internal/WebRowSetXmlReader.java
! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java
! src/share/classes/com/sun/rowset/providers/RIOptimisticProvider.java



From lance.andersen at oracle.com  Sat Sep  4 19:37:57 2010
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Sat, 04 Sep 2010 19:37:57 +0000
Subject: hg: jdk7/tl/jdk: 6982510: Updated SQLException subclasses from the
	outback for 6861385 so that the copyrights only have 2 years
Message-ID: <20100904193807.4296047710@hg.openjdk.java.net>

Changeset: 5cf79568f0b9
Author:    lancea
Date:      2010-09-04 15:37 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5cf79568f0b9

6982510: Updated SQLException subclasses  from the outback for 6861385 so that the copyrights only have 2 years
Reviewed-by: alanb

! src/share/classes/java/sql/SQLDataException.java
! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java
! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java
! src/share/classes/java/sql/SQLNonTransientConnectionException.java
! src/share/classes/java/sql/SQLSyntaxErrorException.java
! src/share/classes/java/sql/SQLTransactionRollbackException.java
! src/share/classes/java/sql/SQLTransientConnectionException.java



From forax at univ-mlv.fr  Sun Sep  5 14:55:19 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 05 Sep 2010 16:55:19 +0200
Subject: hg: jdk7/tl/jdk: 6843995: RowSet 1.1 updates
In-Reply-To: <20100904175939.EA37F4770B@hg.openjdk.java.net>
References: <20100904175939.EA37F4770B@hg.openjdk.java.net>
Message-ID: <4C83AF57.8060202@univ-mlv.fr>

Le 04/09/2010 19:59, lance.andersen at oracle.com a ?crit :
> Changeset: d44696691445
> Author:    lancea
> Date:      2010-09-04 13:56 -0400
> URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d44696691445
>
> 6843995: RowSet 1.1 updates
> Reviewed-by: darcy, valeriep
>
> + src/share/classes/com/sun/rowset/RowSetFactoryImpl.java
> ! src/share/classes/javax/sql/rowset/CachedRowSet.java
> + src/share/classes/javax/sql/rowset/RowSetFactory.java
> + src/share/classes/javax/sql/rowset/RowSetProvider.java
> ! src/share/classes/javax/sql/rowset/package.html
> ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
> ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java
>    

There is a bug in SyncFactory, it uses the double checked locking pattern,
which is broken in Java :)

R?mi


From Alan.Bateman at oracle.com  Sun Sep  5 17:14:21 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 05 Sep 2010 18:14:21 +0100
Subject: hg: jdk7/tl/jdk: 6843995: RowSet 1.1 updates
In-Reply-To: <4C83AF57.8060202@univ-mlv.fr>
References: <20100904175939.EA37F4770B@hg.openjdk.java.net>
	<4C83AF57.8060202@univ-mlv.fr>
Message-ID: <4C83CFED.3040007@oracle.com>

R?mi Forax wrote:
> :
> There is a bug in SyncFactory, it uses the double checked locking 
> pattern,
> which is broken in Java :)
>
> R?mi
Lance - I've created a jdbc/rowset_implementation bug to track this:
 6982530: SyncFactory synchronization problems

In addition to the R?mi's comment, it would be good to double check (pun 
intended!) for other synchronization issues in that code, for example in 
the JNDI initialization or between the setLogger and getLogger methods.

-Alan.


From lance.andersen at oracle.com  Sun Sep  5 19:56:27 2010
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 5 Sep 2010 15:56:27 -0400
Subject: hg: jdk7/tl/jdk: 6843995: RowSet 1.1 updates
In-Reply-To: <4C83CFED.3040007@oracle.com>
References: <20100904175939.EA37F4770B@hg.openjdk.java.net>
	<4C83AF57.8060202@univ-mlv.fr> <4C83CFED.3040007@oracle.com>
Message-ID: <5DE5F3BD-79A4-44B8-9BBC-68A04A456A2A@oracle.com>

Alan, Remi,

thanks for creating the CR.  That code goes back to the original RowSet release in J2SE 5.0 when the spec was  originally released.  I will look into addressing this.


Regards,
Lance
On Sep 5, 2010, at 1:14 PM, Alan Bateman wrote:

> R?mi Forax wrote:
>> :
>> There is a bug in SyncFactory, it uses the double checked locking pattern,
>> which is broken in Java :)
>> 
>> R?mi
> Lance - I've created a jdbc/rowset_implementation bug to track this:
> 6982530: SyncFactory synchronization problems
> 
> In addition to the R?mi's comment, it would be good to double check (pun intended!) for other synchronization issues in that code, for example in the JNDI initialization or between the setLogger and getLogger methods.
> 
> -Alan.




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com

	Oracle is committed to developing practices and products that help protect the environment


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100905/83b2ff0c/attachment.html>

From andreas.kohn at fredhopper.com  Mon Sep  6 15:01:52 2010
From: andreas.kohn at fredhopper.com (Andreas Kohn)
Date: Mon, 06 Sep 2010 17:01:52 +0200
Subject: BufferedInputStream#fill() hanging in SocketInputStream#read0()
Message-ID: <1283785312.3400.100.camel@tiamaria.ams.fredhopper.com>

Hi,

in an application that makes heavy use of JAX-RS, and for that reason
small HTTP connections, I frequently observe situations where
BufferedInputStream would hang like this:

"ae03a305-557e-4db6-b9b8-2bf50f056aaf" prio=10 tid=0x00002aab0175a000 nid=0x30dc runnable [0x0000000048cb3000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
        - locked <0x00002aaab605b670> (a java.io.BufferedInputStream)
        at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
        at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1072)

Typically when looking into those hangs with a debugger it seems that the HTTP response
was received fully, but the BufferedIInputStream tries to fill its buffer with more bytes than
were originally requested by the HttpClient. The HTTP server is now waiting for the client to
continue sending requests, while the client is stuck, hoping that the server will send more bytes
to fill its buffer with.

Currently the only option I have in this case is restart the application (even killing the server
does not lead to a connection reset for some reason!), which in many cases is quite unacceptable.
Disabling Keep-Alive connections helps if the hanging occurs when reading response bodies, but not
when the hanging occurs while the header is being read.


I believe this essentially the issue 6192696 (BufferedInputStream.read(byte[], int, int)
can block if the entire buffer can't be filled). I understand that this issue had had multiple
fix-attempts, which could not be done due reliance on a proper and performing #available() implementation. 

But, wouldn't it be enough to just prevent fill() from filling more than the user wanted to
read in the first place? For the HTTP example the Content-Length gives that information, and the
server will not send more than that, but on the other hand it is safe for the connection to block
until those bytes are received.

Attached is a patch that implements that idea, am I missing something here? Note that I left #read()
without arguments alone.
I've been running with this patch for a few weeks now in test environments, and it seems to have no
negative impact on classloading speed as detailed in the original bug comment trail.

Regards,
--
Andreas

-- 
Never attribute to malice that which can be adequately explained by
stupidity.                                        -- Hanlon's Razor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bis-fill-up-to-length.diff
Type: text/x-patch
Size: 1947 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100906/50bfb05b/bis-fill-up-to-length.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100906/50bfb05b/signature.asc>

From martinrb at google.com  Mon Sep  6 18:19:25 2010
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 6 Sep 2010 11:19:25 -0700
Subject: Code review request for 4881419 The type of X[].clone() should be
	X[]
In-Reply-To: <D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>
References: <4C804272.9060408@oracle.com>
	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>
	<4C804654.8020909@oracle.com>
	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
	<4C81701B.5050006@oracle.com>
	<D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>
Message-ID: <AANLkTimV3mr6K1shjwMKG_0H+03ZikHQBiXAJaNaZ7J1@mail.gmail.com>

On Sat, Sep 4, 2010 at 02:02, Jeroen Frijters <jeroen at sumatra.nl> wrote:

> Sorry to be late with my comment, but as a VM implementer I can't really
> agree with this modification. The return type of X[].clone() is clearly
> Object, not X{]. That illusion is a javac compiler trick. IMHO it belongs in
> the JLS not in the Object.clone() documentation.
>
>
I agree there is a little bit of cheating going on, but I don't agree that
the return type of X[].clone() is a "javac compiler trick".  In some sense
all compile-time types are javac-created illusions.  I do think a pointer to
the JLS may be worthwhile - the big downside with that is that such links to
the JLS are external, and as such become a maintenance problem - one needs
to "fix" all the JLS links in the API reference once every 5 years or so
when a new JLS comes out.

Martin


> Regards,
> Jeroen
>
> > -----Original Message-----
> > From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-
> > bounces at openjdk.java.net] On Behalf Of Joe Darcy
> > Sent: Saturday, September 04, 2010 12:01 AM
> > To: Martin Buchholz
> > Cc: core-libs-dev
> > Subject: Re: Code review request for 4881419 The type of X[].clone()
> > should be X[]
> >
> > Martin Buchholz wrote:
> > >
> > >
> > > On Thu, Sep 2, 2010 at 17:50, Joe Darcy <joe.darcy at oracle.com
> > > <mailto:joe.darcy at oracle.com>> wrote:
> > >
> > >     Martin Buchholz wrote:
> > >
> > >         The usage T[] suggests that T is a reference type, as with
> > >         generics, which is not the case here.
> > >
> > >         More precisely, both the runtime types and compiletime types
> > >         of the object returned from clone of any array is identical to
> > >         its input.
> > >         Is there a non-confusing way of saying that?
> > >
> > >
> > >     How about
> > >
> > >     "...and that the return type of the {@code clone} method of an
> > >     array type {@code T[]} is {@code T[]} where T is either a
> > >     reference or a primitive type."?
> > >
> > >
> > > So I went and actually read the Object.clone spec, and it does indeed
> > > guarantee that the (runtime) class of the returned value is the same
> > > as the class of the argument, for arrays.  As for the compile-time
> > > type, an experiment demonstrates that the return type is indeed
> > > exactly the same, including for non-reifiable array element types,
> > > e.g. this compiles:
> > >
> > >         Class<? extends Number>[] a
> > >             = (Class<? extends Number>[]) (new Class<?>[42]);
> > >         Class<? extends Number>[] clone = a.clone();
> > >
> > >
> > > So Ulf's restriction to non-reifiable T seems not to be correct.
> > >
> > > My suggested wording is:
> > >
> > > "...and that the return type of the {@code clone} method of an array
> > > type {@code T[]} is {@code T[]} where T is any reference or primitive
> > > type."
> > >
> > > Martin "Objects have class; Variables have type"
> >
> > Sounds good to me; change pushed!
> >
> > Thanks,
> >
> > -Joe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100906/6e5529e3/attachment.html>

From jonathan.gibbons at oracle.com  Mon Sep  6 19:55:07 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 06 Sep 2010 19:55:07 +0000
Subject: hg: jdk7/tl/langtools: 6930507: Symbols for anonymous and local
	classes made too late for use by java tree API
Message-ID: <20100906195509.1182D47771@hg.openjdk.java.net>

Changeset: ea54372637a5
Author:    jjg
Date:      2010-09-06 12:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ea54372637a5

6930507: Symbols for anonymous and local classes made too late for use by java tree API
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/api/TestGetElement.java
! test/tools/javac/processing/model/element/TestAnonClassNames.java
! test/tools/javac/processing/model/element/TestAnonSourceNames.java



From David.Holmes at oracle.com  Mon Sep  6 22:51:41 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 07 Sep 2010 08:51:41 +1000
Subject: BufferedInputStream#fill() hanging in SocketInputStream#read0()
In-Reply-To: <1283785312.3400.100.camel@tiamaria.ams.fredhopper.com>
References: <1283785312.3400.100.camel@tiamaria.ams.fredhopper.com>
Message-ID: <4C85707D.2030504@oracle.com>

Andreas,

I can't comment on the patch but I was just reading up on this issue.

It seems to me that the fundamental problem here is the very notion of 
trying to use a buffered-stream in these circumstances. Or one step 
further the notion of using a stream-metaphor for a socket in these 
circumstances is not appropriate. When you have a protocol like HTTP 
there is a very clear definition of end-of-data: request -> response. 
When you send a request you get back a response and there is a definite 
end-of-response indicator. To that end your "stream" must be protocol aware.

In a way your patch is one step towards making the stream 
protocol-aware: that there is a known expected amount of data to receive.

Sorry not particularly helpful ... this just reminded me of 20+ years 
ago in Data Comms classes writing protocol specific packet processing 
code :) streams are only good when there is a continuous flow of data to 
read.

David

Andreas Kohn said the following on 09/07/10 01:01:
> Hi,
> 
> in an application that makes heavy use of JAX-RS, and for that reason
> small HTTP connections, I frequently observe situations where
> BufferedInputStream would hang like this:
> 
> "ae03a305-557e-4db6-b9b8-2bf50f056aaf" prio=10 tid=0x00002aab0175a000 nid=0x30dc runnable [0x0000000048cb3000]
>    java.lang.Thread.State: RUNNABLE
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>         at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
>         at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
>         - locked <0x00002aaab605b670> (a java.io.BufferedInputStream)
>         at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
>         at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
>         at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1072)
> 
> Typically when looking into those hangs with a debugger it seems that the HTTP response
> was received fully, but the BufferedIInputStream tries to fill its buffer with more bytes than
> were originally requested by the HttpClient. The HTTP server is now waiting for the client to
> continue sending requests, while the client is stuck, hoping that the server will send more bytes
> to fill its buffer with.
> 
> Currently the only option I have in this case is restart the application (even killing the server
> does not lead to a connection reset for some reason!), which in many cases is quite unacceptable.
> Disabling Keep-Alive connections helps if the hanging occurs when reading response bodies, but not
> when the hanging occurs while the header is being read.
> 
> 
> I believe this essentially the issue 6192696 (BufferedInputStream.read(byte[], int, int)
> can block if the entire buffer can't be filled). I understand that this issue had had multiple
> fix-attempts, which could not be done due reliance on a proper and performing #available() implementation. 
> 
> But, wouldn't it be enough to just prevent fill() from filling more than the user wanted to
> read in the first place? For the HTTP example the Content-Length gives that information, and the
> server will not send more than that, but on the other hand it is safe for the connection to block
> until those bytes are received.
> 
> Attached is a patch that implements that idea, am I missing something here? Note that I left #read()
> without arguments alone.
> I've been running with this patch for a few weeks now in test environments, and it seems to have no
> negative impact on classloading speed as detailed in the original bug comment trail.
> 
> Regards,
> --
> Andreas
> 
> 


From jeroen at sumatra.nl  Tue Sep  7 03:58:05 2010
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Tue, 7 Sep 2010 03:58:05 +0000
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <AANLkTimV3mr6K1shjwMKG_0H+03ZikHQBiXAJaNaZ7J1@mail.gmail.com>
References: <4C804272.9060408@oracle.com>
	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>
	<4C804654.8020909@oracle.com>
	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
	<4C81701B.5050006@oracle.com>
	<D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>
	<AANLkTimV3mr6K1shjwMKG_0H+03ZikHQBiXAJaNaZ7J1@mail.gmail.com>
Message-ID: <D395C7FC996C944EBD345AB36164F4B2372B9C6A@woyla.sumatrasoftware.com>

Martin Buchholz wrote:
> On Sat, Sep 4, 2010 at 02:02, Jeroen Frijters <jeroen at sumatra.nl> wrote:
> 
> 
> 	Sorry to be late with my comment, but as a VM implementer I can't
> really agree with this modification. The return type of X[].clone() is
> clearly Object, not X{]. That illusion is a javac compiler trick. IMHO
> it belongs in the JLS not in the Object.clone() documentation.
> 
> 
> 
> 
> I agree there is a little bit of cheating going on, but I don't agree
> that the return type of X[].clone() is a "javac compiler trick".  In
> some sense all compile-time types are javac-created illusions.

Here's what javac generates:

public static void main(java.lang.String[])
  Code:
   0:   aload_0
   1:   invokevirtual   #2; //Method "[Ljava/lang/String;".clone:()Ljava/lang/Object;
   4:   checkcast       #3; //class "[Ljava/lang/String;"
   7:   iconst_0
   8:   ldc     #4; //String
   10:  aastore
   11:  return

If you read this from the VM perspective (is there any other ;-)), you see that the VM needs to provide a public clone method on the type String[] that returns Object.

The previous text made this obvious, with the change, you explicitly need to understand the (external) fact that the text is talking about javac behavior, not a feature of the VM (or class library).

I agree that the change makes life easier for the Java developers that use Javac (i.e. the Java programming language), but since the JVM tries to be a more hospitable environment to multiple languages, I don't agree in favoring the Java programming language like this in the API docs.

Regards,
Jeroen


From David.Holmes at oracle.com  Tue Sep  7 07:35:16 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 07 Sep 2010 17:35:16 +1000
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <D395C7FC996C944EBD345AB36164F4B2372B9C6A@woyla.sumatrasoftware.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>	<4C81701B.5050006@oracle.com>	<D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>	<AANLkTimV3mr6K1shjwMKG_0H+03ZikHQBiXAJaNaZ7J1@mail.gmail.com>
	<D395C7FC996C944EBD345AB36164F4B2372B9C6A@woyla.sumatrasoftware.com>
Message-ID: <4C85EB34.4050602@oracle.com>

Jeroen Frijters said the following on 09/07/10 13:58:
> Martin Buchholz wrote:
>> On Sat, Sep 4, 2010 at 02:02, Jeroen Frijters <jeroen at sumatra.nl> wrote:
>>
>>
>> 	Sorry to be late with my comment, but as a VM implementer I can't
>> really agree with this modification. The return type of X[].clone() is
>> clearly Object, not X{]. That illusion is a javac compiler trick. IMHO
>> it belongs in the JLS not in the Object.clone() documentation.
>>
>> I agree there is a little bit of cheating going on, but I don't agree
>> that the return type of X[].clone() is a "javac compiler trick".  In
>> some sense all compile-time types are javac-created illusions.
> 
> Here's what javac generates:
> 
> public static void main(java.lang.String[])
>   Code:
>    0:   aload_0
>    1:   invokevirtual   #2; //Method "[Ljava/lang/String;".clone:()Ljava/lang/Object;
>    4:   checkcast       #3; //class "[Ljava/lang/String;"
>    7:   iconst_0
>    8:   ldc     #4; //String
>    10:  aastore
>    11:  return
> 
> If you read this from the VM perspective (is there any other ;-)), you see that the VM needs to provide a public clone method on the type String[] that returns Object.
> 
> The previous text made this obvious, with the change, you explicitly need to understand the (external) fact that the text is talking about javac behavior, not a feature of the VM (or class library).
> 
> I agree that the change makes life easier for the Java developers that use Javac (i.e. the Java programming language), but since the JVM tries to be a more hospitable environment to multiple languages, I don't agree in favoring the Java programming language like this in the API docs.

I must be missing something subtle here. Object.clone() is required to 
return an object that is the same type as the object upon which clone() 
was invoked. The change simply clarifies this fact for the case of arrays.

The fact that Object.clone() is implemented via a native call into the 
VM is simply an implementation detail. I don't see how this 
clarification changes the requirements that are placed on how the VM 
implements this - it must return an object of the correct type.

David Holmes


From alan.bateman at oracle.com  Tue Sep  7 07:38:10 2010
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 07 Sep 2010 07:38:10 +0000
Subject: hg: jdk7/tl/jdk: 6971706: sun/nio/cs/ext/* classes are duplicated
	between rt.jar, charsets.jar, and localedata.jar
Message-ID: <20100907073820.0620347789@hg.openjdk.java.net>

Changeset: cecc431cd78a
Author:    alanb
Date:      2010-09-07 08:36 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cecc431cd78a

6971706: sun/nio/cs/ext/* classes are duplicated between rt.jar, charsets.jar, and localedata.jar
Reviewed-by: ohair

! make/common/Release.gmk



From jeroen at sumatra.nl  Tue Sep  7 07:59:53 2010
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Tue, 7 Sep 2010 07:59:53 +0000
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <4C85EB34.4050602@oracle.com>
References: <4C804272.9060408@oracle.com>
	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>
	<4C804654.8020909@oracle.com>
	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>
	<4C81701B.5050006@oracle.com>
	<D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>
	<AANLkTimV3mr6K1shjwMKG_0H+03ZikHQBiXAJaNaZ7J1@mail.gmail.com>
	<D395C7FC996C944EBD345AB36164F4B2372B9C6A@woyla.sumatrasoftware.com>
	<4C85EB34.4050602@oracle.com>
Message-ID: <D395C7FC996C944EBD345AB36164F4B2372B9F61@woyla.sumatrasoftware.com>

David Holmes wrote: 
> The fact that Object.clone() is implemented via a native call into the
> VM is simply an implementation detail.

That's not what we're talking about. We're talking about the fact that arrays (appear to) have a *public* clone method. The argument is about the return type[1] of this method: according to the JLS it is X[], but according to the VMSpec it is Object. This difference is fine, but I'm arguing that the JLS fiction should be in the JLS, not in the Object.clone() documentation.

Regards,
Jeroen

[1] Not the runtime class of the object returned.


From David.Holmes at oracle.com  Tue Sep  7 08:50:32 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 07 Sep 2010 18:50:32 +1000
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <D395C7FC996C944EBD345AB36164F4B2372B9F61@woyla.sumatrasoftware.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>	<4C81701B.5050006@oracle.com>	<D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>	<AANLkTimV3mr6K1shjwMKG_0H+03ZikHQBiXAJaNaZ7J1@mail.gmail.com>
	<D395C7FC996C944EBD345AB36164F4B2372B9C6A@woyla.sumatrasoftware.com>
	<4C85EB34.4050602@oracle.com>
	<D395C7FC996C944EBD345AB36164F4B2372B9F61@woyla.sumatrasoftware.com>
Message-ID: <4C85FCD8.7090604@oracle.com>

Jeroen Frijters said the following on 09/07/10 17:59:
> David Holmes wrote:
>> The fact that Object.clone() is implemented via a native call into
>> the VM is simply an implementation detail.
> 
> That's not what we're talking about. We're talking about the fact
> that arrays (appear to) have a *public* clone method. The argument is
> about the return type[1] of this method: according to the JLS it is
> X[], but according to the VMSpec it is Object. This difference is
> fine, but I'm arguing that the JLS fiction should be in the JLS, not
> in the Object.clone() documentation.

I don't see where the VMSpec says anything about cloning ... but that 
aisde. I hadn't realized that the JLS states that arrays override 
Object.clone() rather than inheriting it - it would have been simpler to 
cover the array and non-array cases in Object.clone().

As it stands there is no actual API doc in which to put this 
information, so we really have no choice but to put it Object (having it 
only in the JLS is inadequate). That said I would call it out explicitly 
in its own paragraph, something like:

"All array types, X[], are considered to implement Cloneable and to 
override this method to return a new X[] containing the same elements as 
the original."

Cheers,
David

> 
> Regards, Jeroen
> 
> [1] Not the runtime class of the object returned.


From Alan.Bateman at oracle.com  Tue Sep  7 09:34:44 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 07 Sep 2010 10:34:44 +0100
Subject: BufferedInputStream#fill() hanging in SocketInputStream#read0()
In-Reply-To: <1283785312.3400.100.camel@tiamaria.ams.fredhopper.com>
References: <1283785312.3400.100.camel@tiamaria.ams.fredhopper.com>
Message-ID: <4C860734.9010506@oracle.com>

Andreas Kohn wrote:
> Hi,
>
> in an application that makes heavy use of JAX-RS, and for that reason
> small HTTP connections, I frequently observe situations where
> BufferedInputStream would hang like this:
>
> "ae03a305-557e-4db6-b9b8-2bf50f056aaf" prio=10 tid=0x00002aab0175a000 nid=0x30dc runnable [0x0000000048cb3000]
>    java.lang.Thread.State: RUNNABLE
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>         at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
>         at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
>         - locked <0x00002aaab605b670> (a java.io.BufferedInputStream)
>         at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
>         at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
>         at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1072)
>
> Typically when looking into those hangs with a debugger it seems that the HTTP response
> was received fully, but the BufferedIInputStream tries to fill its buffer with more bytes than
> were originally requested by the HttpClient. The HTTP server is now waiting for the client to
> continue sending requests, while the client is stuck, hoping that the server will send more bytes
> to fill its buffer with.
>
> Currently the only option I have in this case is restart the application (even killing the server
> does not lead to a connection reset for some reason!), which in many cases is quite unacceptable.
> Disabling Keep-Alive connections helps if the hanging occurs when reading response bodies, but not
> when the hanging occurs while the header is being read.
>
>
> I believe this essentially the issue 6192696 (BufferedInputStream.read(byte[], int, int)
> can block if the entire buffer can't be filled). I understand that this issue had had multiple
> fix-attempts, which could not be done due reliance on a proper and performing #available() implementation. 
>
> But, wouldn't it be enough to just prevent fill() from filling more than the user wanted to
> read in the first place? For the HTTP example the Content-Length gives that information, and the
> server will not send more than that, but on the other hand it is safe for the connection to block
> until those bytes are received.
>
> Attached is a patch that implements that idea, am I missing something here? Note that I left #read()
> without arguments alone.
> I've been running with this patch for a few weeks now in test environments, and it seems to have no
> negative impact on classloading speed as detailed in the original bug comment trail.
>
> Regards,
> --
> Andreas
>
>   
It might be good to bring up the http client part of this discussion on 
the net-dev mailing list. In the above stack trace, it looks like the 
http client is attempting to look at the first 8 bytes of the response 
to verify that it is a valid HTTP response. With your patch then I 
assume it will only read up to 8 bytes. Once it gets past this then it 
proceeds one byte at a time through the message headers looking for the 
end of the header fields. If I understand your changes correctly, then 
read() is unchanged, and so reading through the message headers will 
result in at least one fill, maybe more. The length of the message 
headers isn't known in advance and with a persistent connection then 
there isn't an immediate EOF. So my point is that maybe the http client 
code should be re-examined and not use a BIS, at least not when 
processing the message headers.

-Alan.



From Ulf.Zibis at gmx.de  Tue Sep  7 10:13:31 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 07 Sep 2010 12:13:31 +0200
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <D395C7FC996C944EBD345AB36164F4B2372B9F61@woyla.sumatrasoftware.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>	<4C81701B.5050006@oracle.com>	<D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>	<AANLkTimV3mr6K1shjwMKG_0H+03ZikHQBiXAJaNaZ7J1@mail.gmail.com>	<D395C7FC996C944EBD345AB36164F4B2372B9C6A@woyla.sumatrasoftware.com>	<4C85EB34.4050602@oracle.com>
	<D395C7FC996C944EBD345AB36164F4B2372B9F61@woyla.sumatrasoftware.com>
Message-ID: <4C86104B.30306@gmx.de>

  Am 07.09.2010 09:59, schrieb Jeroen Frijters:
> David Holmes wrote:
>> The fact that Object.clone() is implemented via a native call into the
>> VM is simply an implementation detail.
> That's not what we're talking about. We're talking about the fact that arrays (appear to) have a *public* clone method. The argument is about the return type[1] of this method: according to the JLS it is X[], but according to the VMSpec it is Object. This difference is fine, but I'm arguing that the JLS fiction should be in the JLS, not in the Object.clone() documentation.
>
> Regards,
> Jeroen
>
> [1] Not the runtime class of the object returned.

As Martin said:
"Objects have class; Variables have type"




From Ulf.Zibis at gmx.de  Tue Sep  7 10:49:39 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 07 Sep 2010 12:49:39 +0200
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <4C85FCD8.7090604@oracle.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>	<4C81701B.5050006@oracle.com>	<D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>	<AANLkTimV3mr6K1shjwMKG_0H+03ZikHQBiXAJaNaZ7J1@mail.gmail.com>	<D395C7FC996C944EBD345AB36164F4B2372B9C6A@woyla.sumatrasoftware.com>	<4C85EB34.4050602@oracle.com>	<D395C7FC996C944EBD345AB36164F4B2372B9F61@woyla.sumatrasoftware.com>
	<4C85FCD8.7090604@oracle.com>
Message-ID: <4C8618C3.7070105@gmx.de>

  Am 07.09.2010 10:50, schrieb David Holmes:
> Jeroen Frijters said the following on 09/07/10 17:59:
>> David Holmes wrote:
>>> The fact that Object.clone() is implemented via a native call into
>>> the VM is simply an implementation detail.
>>
>> That's not what we're talking about. We're talking about the fact
>> that arrays (appear to) have a *public* clone method. The argument is
>> about the return type[1] of this method: according to the JLS it is
>> X[], but according to the VMSpec it is Object. This difference is
>> fine, but I'm arguing that the JLS fiction should be in the JLS, not
>> in the Object.clone() documentation.
>
> I don't see where the VMSpec says anything about cloning ... but that aisde. I hadn't realized 
> that the JLS states that arrays override Object.clone() rather than inheriting it - it would have 
> been simpler to cover the array and non-array cases in Object.clone().
>
> As it stands there is no actual API doc in which to put this information, so we really have no 
> choice but to put it Object (having it only in the JLS is inadequate). That said I would call it 
> out explicitly in its own paragraph, something like:
>
> "All array types, X[], are considered to implement Cloneable and to override this method to return 
> a new X[] containing the same elements as the original."

+1
This statement, which describes the compile-time behaviour, more belongs to the JLS.

Jeroen, do I understand you right, that you agree with me? :
In javadoc of class Object we should better note for the run-time behaviour. In other words:
As array types clone method is considered to be silently overridden in covariant way, method clone 
of an array object X[] returns a new array of class X[], filled with it's original's content.

Additionally we could note in javadoc of method clone of class Object:
If overriding the clone method, it is recommended to use the covariant return type to avoid the need 
of casting in the calling code. Example:
class MyClass {
     @override
     public MyClass clone() {
         MyClass clone = (MyClass)super.clone();
         clone.doSomeMoreWork();
         return clone;
     }
}

-Ulf




From chris.hegarty at oracle.com  Tue Sep  7 13:08:36 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 07 Sep 2010 14:08:36 +0100
Subject: BufferedInputStream#fill() hanging in SocketInputStream#read0()
In-Reply-To: <1283785312.3400.100.camel@tiamaria.ams.fredhopper.com>
References: <1283785312.3400.100.camel@tiamaria.ams.fredhopper.com>
Message-ID: <4C863954.50501@oracle.com>

Andreas,

This stacktrace is exactly the same as what you will see if the server 
does not respond. The HTTP client is trying to read the initial 
response, but there is none. Is possible that the server is eagerly 
accepting the connection but not processing it?

BIS should not be a problem here since it wraps a SocketInputStream. 
SocketInputStream.read(byte[],int,int) will only be invoked once by BIS 
(unless the byte[] has not been filled and there is more data in the 
socket buffer). The SocketInputStream.read(byte[],int,int) will only 
block if there is no data in the buffer, otherwise it should return 
whatever is there.

A simple test shows that BIS is not a problem. Connect two sockets, wrap 
the inputstream of one with BIS, then send a small amount of data. It 
will not block (indefinitely) even though BIS is forcing a read of 8K 
from the underlying stream.

 From a performance perspective BIS is important for the HTTP client 
implementation. Without it we would be required to read the message 
headers from the socket buffer one byte at a time.

-Chris.

Andreas Kohn wrote:
> Hi,
> 
> in an application that makes heavy use of JAX-RS, and for that reason
> small HTTP connections, I frequently observe situations where
> BufferedInputStream would hang like this:
> 
> "ae03a305-557e-4db6-b9b8-2bf50f056aaf" prio=10 tid=0x00002aab0175a000 nid=0x30dc runnable [0x0000000048cb3000]
>    java.lang.Thread.State: RUNNABLE
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>         at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
>         at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
>         - locked <0x00002aaab605b670> (a java.io.BufferedInputStream)
>         at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
>         at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
>         at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1072)
> 
> Typically when looking into those hangs with a debugger it seems that the HTTP response
> was received fully, but the BufferedIInputStream tries to fill its buffer with more bytes than
> were originally requested by the HttpClient. The HTTP server is now waiting for the client to
> continue sending requests, while the client is stuck, hoping that the server will send more bytes
> to fill its buffer with.
> 
> Currently the only option I have in this case is restart the application (even killing the server
> does not lead to a connection reset for some reason!), which in many cases is quite unacceptable.
> Disabling Keep-Alive connections helps if the hanging occurs when reading response bodies, but not
> when the hanging occurs while the header is being read.
> 
> 
> I believe this essentially the issue 6192696 (BufferedInputStream.read(byte[], int, int)
> can block if the entire buffer can't be filled). I understand that this issue had had multiple
> fix-attempts, which could not be done due reliance on a proper and performing #available() implementation. 
> 
> But, wouldn't it be enough to just prevent fill() from filling more than the user wanted to
> read in the first place? For the HTTP example the Content-Length gives that information, and the
> server will not send more than that, but on the other hand it is safe for the connection to block
> until those bytes are received.
> 
> Attached is a patch that implements that idea, am I missing something here? Note that I left #read()
> without arguments alone.
> I've been running with this patch for a few weeks now in test environments, and it seems to have no
> negative impact on classloading speed as detailed in the original bug comment trail.
> 
> Regards,
> --
> Andreas
> 
> 


From Alan.Bateman at oracle.com  Tue Sep  7 15:42:10 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 07 Sep 2010 16:42:10 +0100
Subject: BufferedInputStream#fill() hanging in SocketInputStream#read0()
In-Reply-To: <4C863954.50501@oracle.com>
References: <1283785312.3400.100.camel@tiamaria.ams.fredhopper.com>
	<4C863954.50501@oracle.com>
Message-ID: <4C865D52.2020608@oracle.com>

Chris Hegarty wrote:
> Andreas,
>
> This stacktrace is exactly the same as what you will see if the server 
> does not respond. The HTTP client is trying to read the initial 
> response, but there is none. Is possible that the server is eagerly 
> accepting the connection but not processing it?
I think you're right, in which case changing BIS isn't going to help. If 
the server doesn't close the connection, and it's not terminated 
abruptly, then I assume the only way to recover in a reasonable time is 
to have set the read timeout.

-Alan.


From joe.darcy at oracle.com  Tue Sep  7 16:15:18 2010
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 07 Sep 2010 09:15:18 -0700
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <4C85FCD8.7090604@oracle.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>	<4C81701B.5050006@oracle.com>	<D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>	<AANLkTimV3mr6K1shjwMKG_0H+03ZikHQBiXAJaNaZ7J1@mail.gmail.com>	<D395C7FC996C944EBD345AB36164F4B2372B9C6A@woyla.sumatrasoftware.com>	<4C85EB34.4050602@oracle.com>	<D395C7FC996C944EBD345AB36164F4B2372B9F61@woyla.sumatrasoftware.com>
	<4C85FCD8.7090604@oracle.com>
Message-ID: <4C866516.70805@oracle.com>

David Holmes wrote:
> Jeroen Frijters said the following on 09/07/10 17:59:
>> David Holmes wrote:
>>> The fact that Object.clone() is implemented via a native call into
>>> the VM is simply an implementation detail.
>>
>> That's not what we're talking about. We're talking about the fact
>> that arrays (appear to) have a *public* clone method. The argument is
>> about the return type[1] of this method: according to the JLS it is
>> X[], but according to the VMSpec it is Object. This difference is
>> fine, but I'm arguing that the JLS fiction should be in the JLS, not
>> in the Object.clone() documentation.
>
> I don't see where the VMSpec says anything about cloning ... but that 
> aisde. I hadn't realized that the JLS states that arrays override 
> Object.clone() rather than inheriting it - it would have been simpler 
> to cover the array and non-array cases in Object.clone().

Yes, as cited in my review request, the JLS does state the return type 
of clone called on an array:

    http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.4.5

and states that the array clone overrides Object.clone.

>
> As it stands there is no actual API doc in which to put this 
> information, so we really have no choice but to put it Object (having 
> it only in the JLS is inadequate). That said I would call it out 
> explicitly in its own paragraph, something like:
>
> "All array types, X[], are considered to implement Cloneable and to 
> override this method to return a new X[] containing the same elements 
> as the original."
>

I believe the revised text

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

is more informative than the previous text and adequately covers this 
situation.

-Joe


From joe.darcy at oracle.com  Tue Sep  7 16:19:52 2010
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 07 Sep 2010 09:19:52 -0700
Subject: Code review request for 4881419 The type of X[].clone() should
	be X[]
In-Reply-To: <D395C7FC996C944EBD345AB36164F4B2372B9F61@woyla.sumatrasoftware.com>
References: <4C804272.9060408@oracle.com>	<AANLkTikKkpVKJ=Su_RwrfBcWw-NA6nD_n1uQBRL0NcOy@mail.gmail.com>	<4C804654.8020909@oracle.com>	<AANLkTikrDTV4h7y+ApnPW9X--RZX3M8OU03esnHFBpkY@mail.gmail.com>	<4C81701B.5050006@oracle.com>	<D395C7FC996C944EBD345AB36164F4B2372B718D@woyla.sumatrasoftware.com>	<AANLkTimV3mr6K1shjwMKG_0H+03ZikHQBiXAJaNaZ7J1@mail.gmail.com>	<D395C7FC996C944EBD345AB36164F4B2372B9C6A@woyla.sumatrasoftware.com>	<4C85EB34.4050602@oracle.com>
	<D395C7FC996C944EBD345AB36164F4B2372B9F61@woyla.sumatrasoftware.com>
Message-ID: <4C866628.5050805@oracle.com>

Jeroen Frijters wrote:
> David Holmes wrote: 
>   
>> The fact that Object.clone() is implemented via a native call into the
>> VM is simply an implementation detail.
>>     
>
> That's not what we're talking about. We're talking about the fact that arrays (appear to) have a *public* clone method. The argument is about the return type[1] of this method: according to the JLS it is X[], but according to the VMSpec it is Object. This difference is fine, but I'm arguing that the JLS fiction should be in the JLS, not in the Object.clone() documentation.
>
> Regards,
> Jeroen
>
> [1] Not the runtime class of the object returned.
>   

The documentation for the *Java* class libraries is written in the 
*Java* programming language and there are selected references and 
dependencies between the library and language specifications.

-Joe


From maurizio.cimadamore at oracle.com  Tue Sep  7 17:04:42 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 07 Sep 2010 17:04:42 +0000
Subject: hg: jdk7/tl/langtools: 4 new changesets
Message-ID: <20100907170450.07645477A1@hg.openjdk.java.net>

Changeset: 7ae4016c5938
Author:    mcimadamore
Date:      2010-09-07 17:31 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7ae4016c5938

6337171: javac should create bridge methods when type variable bounds restricted
Summary: javac should add synthetic overrides for inherited abstract methods in order to preserve binary compatibility
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Scope.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ src/share/classes/com/sun/tools/javac/util/Filter.java
+ test/tools/javac/generics/OverrideBridge.java

Changeset: 584365f256a7
Author:    mcimadamore
Date:      2010-09-07 17:32 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/584365f256a7

6979327: method handle invocation should use casts instead of type parameters to specify return type
Summary: infer return type for polymorphic signature calls according to updated JSR 292 draft
Reviewed-by: jjg
Contributed-by: john.r.rose at oracle.com

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/Names.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java
+ test/tools/javac/diags/examples/UnsupportedExoticID.java
! test/tools/javac/meth/InvokeDyn.java
+ test/tools/javac/meth/InvokeDynTrans.java
+ test/tools/javac/meth/InvokeDynTrans.out
! test/tools/javac/meth/InvokeMH.java
+ test/tools/javac/meth/InvokeMHTrans.java
+ test/tools/javac/meth/InvokeMHTrans.out
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
! test/tools/javac/quid/QuotedIdent.java
! test/tools/javac/quid/QuotedIdent2.java

Changeset: 12d8f7e417fd
Author:    mcimadamore
Date:      2010-09-07 17:32 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/12d8f7e417fd

6981185: com.sun.tools.model.JavacTypes.contains() calls Type.contains instead of Types.containsType
Summary: wrong implementation is causing trivial containment tests to fail unexpectedly (when such tests are executed using compiler API)
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
+ test/tools/javac/api/TestContainTypes.java

Changeset: bfdfc13fe641
Author:    mcimadamore
Date:      2010-09-07 17:33 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bfdfc13fe641

6970584: Flow.java should be more error-friendly
Summary: Added a post-attribution visitor that fixup uninitialized types/symbol in AST after erroneous attribution
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/failover/CheckAttributedTree.java
+ test/tools/javac/failover/FailOver01.java
+ test/tools/javac/failover/FailOver01.out
+ test/tools/javac/failover/FailOver02.java
+ test/tools/javac/failover/FailOver02.out
+ test/tools/javac/failover/FailOver03.java
+ test/tools/javac/failover/FailOver03.out
+ test/tools/javac/failover/FailOver04.java
+ test/tools/javac/failover/FailOver04.out
+ test/tools/javac/failover/FailOver05.java
+ test/tools/javac/failover/FailOver05.out
+ test/tools/javac/failover/FailOver06.java
+ test/tools/javac/failover/FailOver06.out
+ test/tools/javac/failover/FailOver07.java
+ test/tools/javac/failover/FailOver07.out
+ test/tools/javac/failover/FailOver08.java
+ test/tools/javac/failover/FailOver08.out
+ test/tools/javac/failover/FailOver09.java
+ test/tools/javac/failover/FailOver09.out
+ test/tools/javac/failover/FailOver10.java
+ test/tools/javac/failover/FailOver10.out
+ test/tools/javac/failover/FailOver11.java
+ test/tools/javac/failover/FailOver11.out
+ test/tools/javac/failover/FailOver12.java
+ test/tools/javac/failover/FailOver12.out
+ test/tools/javac/failover/FailOver13.java
+ test/tools/javac/failover/FailOver13.out
+ test/tools/javac/failover/FailOver14.java
+ test/tools/javac/failover/FailOver14.out



From kelly.ohair at oracle.com  Tue Sep  7 22:57:49 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Tue, 07 Sep 2010 22:57:49 +0000
Subject: hg: jdk7/tl: 2 new changesets
Message-ID: <20100907225749.BEC3E477B7@hg.openjdk.java.net>

Changeset: d6ea39e0d3eb
Author:    ohair
Date:      2010-09-07 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/d6ea39e0d3eb

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: b331aef4bef0
Author:    ohair
Date:      2010-09-07 15:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/b331aef4bef0

Merge




From kelly.ohair at oracle.com  Tue Sep  7 22:57:55 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Tue, 07 Sep 2010 22:57:55 +0000
Subject: hg: jdk7/tl/corba: 2 new changesets
Message-ID: <20100907225756.B9F55477B8@hg.openjdk.java.net>

Changeset: 3821536d79ab
Author:    ohair
Date:      2010-09-07 15:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/3821536d79ab

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 0a91416c1402
Author:    ohair
Date:      2010-09-07 15:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/0a91416c1402

Merge

- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk



From kelly.ohair at oracle.com  Tue Sep  7 22:58:10 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Tue, 07 Sep 2010 22:58:10 +0000
Subject: hg: jdk7/tl/jaxp: 2 new changesets
Message-ID: <20100907225810.311F3477B9@hg.openjdk.java.net>

Changeset: cc845b339690
Author:    ohair
Date:      2010-09-07 15:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/cc845b339690

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: e58a0bea47f6
Author:    ohair
Date:      2010-09-07 15:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/e58a0bea47f6

Merge




From kelly.ohair at oracle.com  Tue Sep  7 22:58:15 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Tue, 07 Sep 2010 22:58:15 +0000
Subject: hg: jdk7/tl/jaxws: 2 new changesets
Message-ID: <20100907225815.9E8EC477BA@hg.openjdk.java.net>

Changeset: 06c51671c84b
Author:    ohair
Date:      2010-09-07 15:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/06c51671c84b

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 74737bd256fa
Author:    ohair
Date:      2010-09-07 15:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/74737bd256fa

Merge




From kelly.ohair at oracle.com  Tue Sep  7 22:58:28 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Tue, 07 Sep 2010 22:58:28 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100907225857.034DF477BB@hg.openjdk.java.net>

Changeset: df049d0b973f
Author:    ohair
Date:      2010-09-07 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df049d0b973f

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 299955417217
Author:    ohair
Date:      2010-09-07 15:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/299955417217

Merge

- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/tools/launcher/VerifyExceptions.java



From kelly.ohair at oracle.com  Tue Sep  7 22:59:14 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Tue, 07 Sep 2010 22:59:14 +0000
Subject: hg: jdk7/tl/langtools: 2 new changesets
Message-ID: <20100907225918.3959B477BC@hg.openjdk.java.net>

Changeset: 47e7ff871196
Author:    ohair
Date:      2010-09-07 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/47e7ff871196

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: c388fa8c6a43
Author:    ohair
Date:      2010-09-07 15:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c388fa8c6a43

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh



From joe.darcy at oracle.com  Thu Sep  9 00:08:57 2010
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 09 Sep 2010 00:08:57 +0000
Subject: hg: jdk7/tl/jdk: 6294399: (reflect) Constructor.getName() returns
	fully qualified name of declaring class
Message-ID: <20100909000916.DBBDF47818@hg.openjdk.java.net>

Changeset: fa00d112bb00
Author:    darcy
Date:      2010-09-08 17:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa00d112bb00

6294399: (reflect) Constructor.getName() returns fully qualified name of declaring class
Reviewed-by: alanb

! src/share/classes/java/lang/reflect/Constructor.java



From sundararajan.a at sun.com  Thu Sep  9 04:13:34 2010
From: sundararajan.a at sun.com (sundararajan.a at sun.com)
Date: Thu, 09 Sep 2010 04:13:34 +0000
Subject: hg: jdk7/tl/langtools: 6900149: IllegalStateException when compiling
	same files and DiagnosticListener is set.
Message-ID: <20100909041338.AA4144782E@hg.openjdk.java.net>

Changeset: 014cf6234586
Author:    sundar
Date:      2010-09-09 09:42 +0530
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/014cf6234586

6900149: IllegalStateException when compiling same files and DiagnosticListener is set.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/T6900149.java



From kumar.x.srinivasan at oracle.com  Thu Sep  9 18:51:21 2010
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Thu, 09 Sep 2010 18:51:21 +0000
Subject: hg: jdk7/tl/jdk: 6390477: (launcher) replace unsafe usages of sprintf
	with snprintf
Message-ID: <20100909185130.6623D47859@hg.openjdk.java.net>

Changeset: da7835e74005
Author:    ksrini
Date:      2010-09-09 11:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da7835e74005

6390477: (launcher) replace unsafe usages of sprintf with snprintf
Reviewed-by: darcy, mchung

! src/share/bin/java.c
! src/solaris/bin/java_md.c
! src/windows/bin/java_md.c



From jonathan.gibbons at oracle.com  Thu Sep  9 20:31:40 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 09 Sep 2010 20:31:40 +0000
Subject: hg: jdk7/tl/langtools: 6983239: TreeScanner does not scan default
	value for method
Message-ID: <20100909203144.ECF464785F@hg.openjdk.java.net>

Changeset: fc73f83cd563
Author:    jjg
Date:      2010-09-09 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fc73f83cd563

6983239: TreeScanner does not scan default value for method
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/util/TreeScanner.java
! test/tools/javac/api/T6392782.java
+ test/tools/javac/tree/AbstractTreeScannerTest.java
+ test/tools/javac/tree/JavacTreeScannerTest.java
+ test/tools/javac/tree/SourceTreeScannerTest.java
- test/tools/javac/tree/TreeScannerTest.java



From mlists at juma.me.uk  Fri Sep 10 12:12:48 2010
From: mlists at juma.me.uk (Ismael Juma)
Date: Fri, 10 Sep 2010 12:12:48 +0000 (UTC)
Subject: java.lang.reflect.Array.get/set performance
Message-ID: <loom.20100910T135959-221@post.gmane.org>

Hey all,

The approach used for Arrays in Scala was changed in 2.8 and initially 
java.lang.reflect.Array.get/set was used in certain cases. That was changed at 
the end of last year[1] after it was pointed out that the performance of those 
methods was less than desirable[2].

The interesting conclusion from that thread was that a simple instanceof check 
for each array type is faster than using java.lang.reflect.Array.get/set. Given 
those results, is there a good reason for not replacing the existing native 
methods with pure Java methods that simply use instanceof for each array type?

Best,
Ismael

[1] https://lampsvn.epfl.ch/trac/scala/changeset/20267
[2] http://www.scala-lang.org/node/4602




From chris.hegarty at oracle.com  Fri Sep 10 14:57:37 2010
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 10 Sep 2010 14:57:37 +0000
Subject: hg: jdk7/tl/jdk: 6980517: TEST_BUG
	sun\net\www\http\ChunkedInputStream\ChunkedEncodingTest.java
	NullPointerException
Message-ID: <20100910145746.EBBC74789E@hg.openjdk.java.net>

Changeset: 6960b4f07bf9
Author:    chegar
Date:      2010-09-10 15:57 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6960b4f07bf9

6980517: TEST_BUG sun\net\www\http\ChunkedInputStream\ChunkedEncodingTest.java NullPointerException
Reviewed-by: michaelm

! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingTest.java



From alan.bateman at oracle.com  Fri Sep 10 17:54:04 2010
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 10 Sep 2010 17:54:04 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20100910175432.8AF00478A6@hg.openjdk.java.net>

Changeset: 55eb9f25bf7a
Author:    alanb
Date:      2010-09-10 16:36 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/55eb9f25bf7a

6881498: (file) Re-examine DirectoryStream exception handling
Reviewed-by: forax

! make/java/nio/FILES_java.gmk
+ src/share/classes/java/nio/file/DirectoryIteratorException.java
! src/share/classes/java/nio/file/DirectoryStream.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/SecureDirectoryStream.java
! src/share/classes/java/util/ConcurrentModificationException.java
! src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java
! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java
! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java
! test/java/nio/file/DirectoryStream/Basic.java
! test/java/nio/file/DirectoryStream/SecureDS.java
+ test/java/nio/file/etc/Exceptions.java

Changeset: b1f49e54be97
Author:    alanb
Date:      2010-09-10 18:48 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b1f49e54be97

6983794: TEST_BUG: test/java/nio/channels/Selector/ConnectWrite.java failing
Reviewed-by: chegar

! test/java/nio/channels/Selector/ConnectWrite.java

Changeset: 186d0259f5d6
Author:    alanb
Date:      2010-09-10 18:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/186d0259f5d6

Merge




From lance.andersen at oracle.com  Fri Sep 10 19:26:46 2010
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Fri, 10 Sep 2010 19:26:46 +0000
Subject: hg: jdk7/tl/jdk: 6589685: JDBC 4.1 updates
Message-ID: <20100910192655.F0516478AC@hg.openjdk.java.net>

Changeset: c786a9c927fd
Author:    lancea
Date:      2010-09-10 15:26 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c786a9c927fd

6589685: JDBC 4.1 updates
Reviewed-by: darcy

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/Connection.java
! src/share/classes/java/sql/DatabaseMetaData.java
! src/share/classes/java/sql/Date.java
! src/share/classes/java/sql/Driver.java
! src/share/classes/java/sql/PreparedStatement.java
+ src/share/classes/java/sql/PseudoColumnUsage.java
! src/share/classes/java/sql/ResultSet.java
! src/share/classes/java/sql/SQLPermission.java
! src/share/classes/java/sql/Statement.java
! src/share/classes/java/sql/Timestamp.java
! src/share/classes/javax/sql/CommonDataSource.java



From forax at univ-mlv.fr  Fri Sep 10 20:55:55 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 10 Sep 2010 22:55:55 +0200
Subject: hg: jdk7/tl/jdk: 6589685: JDBC 4.1 updates
In-Reply-To: <20100910192655.F0516478AC@hg.openjdk.java.net>
References: <20100910192655.F0516478AC@hg.openjdk.java.net>
Message-ID: <4C8A9B5B.6060709@univ-mlv.fr>

Le 10/09/2010 21:26, lance.andersen at oracle.com a ?crit :
> Changeset: c786a9c927fd
> Author:    lancea
> Date:      2010-09-10 15:26 -0400
> URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c786a9c927fd
>
> 6589685: JDBC 4.1 updates
> Reviewed-by: darcy
>
> ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
> ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
> ! src/share/classes/java/sql/CallableStatement.java
> ! src/share/classes/java/sql/Connection.java
> ! src/share/classes/java/sql/DatabaseMetaData.java
> ! src/share/classes/java/sql/Date.java
> ! src/share/classes/java/sql/Driver.java
> ! src/share/classes/java/sql/PreparedStatement.java
> + src/share/classes/java/sql/PseudoColumnUsage.java
> ! src/share/classes/java/sql/ResultSet.java
> ! src/share/classes/java/sql/SQLPermission.java
> ! src/share/classes/java/sql/Statement.java
> ! src/share/classes/java/sql/Timestamp.java
> ! src/share/classes/javax/sql/CommonDataSource.java
>
>    

Hi Lance,
in getPseudoColumns doc comments, Pseudo is written 'Psuedo' twice.

R?mi
  





From lance.andersen at oracle.com  Fri Sep 10 21:06:13 2010
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 10 Sep 2010 17:06:13 -0400
Subject: hg: jdk7/tl/jdk: 6589685: JDBC 4.1 updates
In-Reply-To: <4C8A9B5B.6060709@univ-mlv.fr>
References: <20100910192655.F0516478AC@hg.openjdk.java.net>
	<4C8A9B5B.6060709@univ-mlv.fr>
Message-ID: <C22B9D56-64DF-432F-A1D4-3D377F8E37D3@oracle.com>

Hi Remi,

Thank you for catching the typo, thought i caught that but sometimes you see what you want to see :-)

I will enter a CR and fix the typo.

Regards
Lance
On Sep 10, 2010, at 4:55 PM, R?mi Forax wrote:

> Le 10/09/2010 21:26, lance.andersen at oracle.com a ?crit :
>> Changeset: c786a9c927fd
>> Author:    lancea
>> Date:      2010-09-10 15:26 -0400
>> URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c786a9c927fd
>> 
>> 6589685: JDBC 4.1 updates
>> Reviewed-by: darcy
>> 
>> ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
>> ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
>> ! src/share/classes/java/sql/CallableStatement.java
>> ! src/share/classes/java/sql/Connection.java
>> ! src/share/classes/java/sql/DatabaseMetaData.java
>> ! src/share/classes/java/sql/Date.java
>> ! src/share/classes/java/sql/Driver.java
>> ! src/share/classes/java/sql/PreparedStatement.java
>> + src/share/classes/java/sql/PseudoColumnUsage.java
>> ! src/share/classes/java/sql/ResultSet.java
>> ! src/share/classes/java/sql/SQLPermission.java
>> ! src/share/classes/java/sql/Statement.java
>> ! src/share/classes/java/sql/Timestamp.java
>> ! src/share/classes/javax/sql/CommonDataSource.java
>> 
>>   
> 
> Hi Lance,
> in getPseudoColumns doc comments, Pseudo is written 'Psuedo' twice.
> 
> R?mi
> 
> 
> 




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com

	Oracle is committed to developing practices and products that help protect the environment


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100910/0545b025/attachment.html>

From lance.andersen at oracle.com  Fri Sep 10 22:51:57 2010
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Fri, 10 Sep 2010 22:51:57 +0000
Subject: hg: jdk7/tl/jdk: 6983984: Fixed typo in
	DatabaseMetaData.getPseudoColumns() javadocs
Message-ID: <20100910225207.8A354478B3@hg.openjdk.java.net>

Changeset: 73872b992aab
Author:    lancea
Date:      2010-09-10 18:51 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/73872b992aab

6983984: Fixed typo in DatabaseMetaData.getPseudoColumns() javadocs
Reviewed-by: darcy

! src/share/classes/java/sql/DatabaseMetaData.java



From forax at univ-mlv.fr  Sat Sep 11 13:45:39 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 11 Sep 2010 15:45:39 +0200
Subject: hg: jdk7/tl/jdk: 6589685: JDBC 4.1 updates
In-Reply-To: <C22B9D56-64DF-432F-A1D4-3D377F8E37D3@oracle.com>
References: <20100910192655.F0516478AC@hg.openjdk.java.net>
	<4C8A9B5B.6060709@univ-mlv.fr>
	<C22B9D56-64DF-432F-A1D4-3D377F8E37D3@oracle.com>
Message-ID: <4C8B8803.7040800@univ-mlv.fr>

Le 10/09/2010 23:06, Lance Andersen a ?crit :
> Hi Remi,
>
> Thank you for catching the typo, thought i caught that but sometimes 
> you see what you want to see :-)

Knowing that the other anagram of psuedo is souped,
I was wondering if it was not a hidden message:
'JDBC 4.1 is a souped up JDBC' :)

>
> I will enter a CR and fix the typo.
>
> Regards
> Lance

cheers,
R?mi


From weijun.wang at sun.com  Mon Sep 13 01:33:28 2010
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Mon, 13 Sep 2010 01:33:28 +0000
Subject: hg: jdk7/tl/jdk: 6845220: Need to update Policytool for Rowset 1.1
	and JDBC 4.1 MR added permissions
Message-ID: <20100913013405.982364791F@hg.openjdk.java.net>

Changeset: f7915efcba1b
Author:    weijun
Date:      2010-09-13 09:32 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f7915efcba1b

6845220: Need to update Policytool for Rowset 1.1 and JDBC 4.1 MR added permissions
Reviewed-by: lancea

! src/share/classes/sun/security/tools/policytool/PolicyTool.java



From chris.hegarty at oracle.com  Mon Sep 13 10:53:40 2010
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 13 Sep 2010 10:53:40 +0000
Subject: hg: jdk7/tl/jdk: 6978087: jsr166y Updates
Message-ID: <20100913105351.247B047934@hg.openjdk.java.net>

Changeset: be1ca1f90114
Author:    dl
Date:      2010-09-13 09:55 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/be1ca1f90114

6978087: jsr166y Updates
Summary: Simplify the ForkJoinPool API, reworking some of the internals
Reviewed-by: martin, dholmes, chegar

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/Phaser.java
! test/java/util/concurrent/forkjoin/Integrate.java



From jonathan.gibbons at oracle.com  Mon Sep 13 18:36:06 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 13 Sep 2010 18:36:06 +0000
Subject: hg: jdk7/tl/langtools: 6965264: langtools build should use
	${ant.core.lib} instead of ${ant.home}/lib/ant.jar
Message-ID: <20100913183608.F006247947@hg.openjdk.java.net>

Changeset: 80505c2026e7
Author:    jjg
Date:      2010-09-13 11:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/80505c2026e7

6965264: langtools build should use ${ant.core.lib} instead of ${ant.home}/lib/ant.jar
Reviewed-by: mcimadamore
Contributed-by: jesse.glick at oracle.com

! make/build.xml



From jonathan.gibbons at oracle.com  Mon Sep 13 18:41:07 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 13 Sep 2010 18:41:07 +0000
Subject: hg: jdk7/tl/langtools: 6978974: [langtools] <findbugs> task should
	use ${target.java.home}
Message-ID: <20100913184109.748D847948@hg.openjdk.java.net>

Changeset: e92ae290fb47
Author:    jjg
Date:      2010-09-13 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e92ae290fb47

6978974: [langtools] <findbugs> task should use ${target.java.home}
Reviewed-by: mcimadamore

! make/build.xml



From weijun.wang at sun.com  Tue Sep 14 02:18:43 2010
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Tue, 14 Sep 2010 02:18:43 +0000
Subject: hg: jdk7/tl/jdk: 6982840:
	sun/security/tools/jarsigner/emptymanifest.sh fails
Message-ID: <20100914021852.9CAB74795B@hg.openjdk.java.net>

Changeset: 5c3bad1d7f8a
Author:    weijun
Date:      2010-09-14 10:18 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5c3bad1d7f8a

6982840: sun/security/tools/jarsigner/emptymanifest.sh fails
Reviewed-by: dholmes

! test/sun/security/tools/jarsigner/emptymanifest.sh



From alan.bateman at oracle.com  Wed Sep 15 14:15:27 2010
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 15 Sep 2010 14:15:27 +0000
Subject: hg: jdk7/tl/jdk: 6984545: (fc) transferFrom does not throw
	NonReadableChannelException when target is size 0 and non-readable
Message-ID: <20100915141546.9D55D479C1@hg.openjdk.java.net>

Changeset: a248eb631aa2
Author:    alanb
Date:      2010-09-15 15:13 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a248eb631aa2

6984545: (fc) transferFrom does not throw NonReadableChannelException when target is size 0 and non-readable
Reviewed-by: forax

! src/share/classes/sun/nio/ch/FileChannelImpl.java
! test/java/nio/channels/FileChannel/Transfer.java



From mandy.chung at oracle.com  Wed Sep 15 23:48:12 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 15 Sep 2010 16:48:12 -0700
Subject: Code review request for 6888546
Message-ID: <4C915B3C.30209@oracle.com>

  Hi Alan,

Can you review the fix for:
    6888546: restore System.initializeSystemClasses

Webrev at:
    http://cr.openjdk.java.net/~mchung/6888546/webrev.00/

With the fix for 6612680, the download manager won't start until the VM 
completes its initialization.  This is to remove the workaround added 
for jkernel in the fix for 6797688.

Thanks
Mandy




From Alan.Bateman at oracle.com  Thu Sep 16 00:57:12 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Sep 2010 17:57:12 -0700
Subject: Code review request for 6888546
In-Reply-To: <4C915B3C.30209@oracle.com>
References: <4C915B3C.30209@oracle.com>
Message-ID: <4C916B68.6030803@oracle.com>

Mandy Chung wrote:
>  Hi Alan,
>
> Can you review the fix for:
>    6888546: restore System.initializeSystemClasses
>
> Webrev at:
>    http://cr.openjdk.java.net/~mchung/6888546/webrev.00/
>
> With the fix for 6612680, the download manager won't start until the 
> VM completes its initialization.  This is to remove the workaround 
> added for jkernel in the fix for 6797688.
>
> Thanks
> Mandy
>
Good to see this restored.  I assume the comment should just be 
"register shared secrets" as the shutdown hooks aren't setup there.

-Alan


From mandy.chung at oracle.com  Thu Sep 16 01:03:13 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 15 Sep 2010 18:03:13 -0700
Subject: Code review request for 6888546
In-Reply-To: <4C916B68.6030803@oracle.com>
References: <4C915B3C.30209@oracle.com> <4C916B68.6030803@oracle.com>
Message-ID: <4C916CD1.3090804@oracle.com>

  On 9/15/10 5:57 PM, Alan Bateman wrote:
> Mandy Chung wrote:
>>  Hi Alan,
>>
>> Can you review the fix for:
>>    6888546: restore System.initializeSystemClasses
>>
>> Webrev at:
>>    http://cr.openjdk.java.net/~mchung/6888546/webrev.00/
>>
>> With the fix for 6612680, the download manager won't start until the 
>> VM completes its initialization.  This is to remove the workaround 
>> added for jkernel in the fix for 6797688.
>>
>> Thanks
>> Mandy
>>
> Good to see this restored.  I assume the comment should just be 
> "register shared secrets" as the shutdown hooks aren't setup there.

Thanks for the review.  Will update the comment.

Mandy


From pbenedict at apache.org  Thu Sep 16 01:10:16 2010
From: pbenedict at apache.org (Paul Benedict)
Date: Wed, 15 Sep 2010 20:10:16 -0500
Subject: hg: jdk7/tl/jdk: 6589685: JDBC 4.1 updates
Message-ID: <AANLkTim65ZqW=567Ait3C+9bR4oGrOVEgVFTA1h_Hz3h@mail.gmail.com>

Lance,

There is a small typo in the javadoc. For method
generatedKeyAlwaysReturned, "indexe(s)" should be "index(es)"

Paul


From ptisnovs at redhat.com  Thu Sep 16 11:29:06 2010
From: ptisnovs at redhat.com (ptisnovs at redhat.com)
Date: Thu, 16 Sep 2010 11:29:06 +0000
Subject: hg: jdk7/tl/jdk: 6984543: Test
	sun/java2d/DirectX/OnScreenRenderingResizeTest fails on GNOME
Message-ID: <20100916112915.DBB0847A02@hg.openjdk.java.net>

Changeset: 441e86ab3233
Author:    ptisnovs
Date:      2010-09-16 13:25 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/441e86ab3233

6984543: Test sun/java2d/DirectX/OnScreenRenderingResizeTest fails on GNOME
Summary: Testcase correction.
Reviewed-by: art

! test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java



From ekabanov at gmail.com  Thu Sep 16 12:56:48 2010
From: ekabanov at gmail.com (Jevgeni Kabanov)
Date: Thu, 16 Sep 2010 15:56:48 +0300
Subject: A small ClassLoader change proposal
Message-ID: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>

Hi guys,

I'd like to contribute two new classes to the JDK7 and add a new package-visible field to the ClassLoader. These classes would be meant for the framework and server developers to allow for greater control over the references between classes in different class loaders. Specifically the goal would be to prevent the notoriously common classloader leaks. The motivation is partially described here:
http://dow.ngra.de/2009/06/15/classloaderlocal-how-to-avoid-classloader-leaks-on-application-redeploy/
That blog post also describes a way to backport it to older Java versions, unfortunately we found that the described approach will not work in some esoteric cases.

The pseudo-code follows. It's not really optimized or even tested and is only meant to illustrate the functionality and complexity of the proposal. I'd like to hear your feedback on this.

class ClassLoader {
  Map localMap = new HashMap();
  //...
}

public class ClassLoaderLocal {
  private Object key = new Object();
 
  public Object get(ClassLoader cl) {
    cl.localMap.get(key);
  }
 
  public void set(ClassLoader cl, Object value) {
    cl.localMap.put(key, value);
  }
}

public class ClassLoaderWeakReference extends Reference {
  private final WeakReference clRef;
  private final ClassLoaderLocal cll = new ClassLoaderLocal();
  public ClassLoaderWeakReference(Object target) {
     clRef = new WeakReference(target.getClass().getClassLoader());
     cll.set(target.getClass().getClassLoader(), target);
  }
  
  public Object get() {
    if (clRef.get() == null) 
      return null;
    return cll.get((ClassLoader) clRef.get());
  }
}

Jevgeni Kabanov: Founder & CTO at ZeroTurnaround
jevgeni at zeroturnaround.com | Skype: ekabanov | http://twitter.com/ekabanov
"jrebel is r0x: http://bit.ly/6fRGji" - mschambeck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/1a1c062e/attachment.html>

From jeffhain at rocketmail.com  Thu Sep 16 13:33:20 2010
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Thu, 16 Sep 2010 13:33:20 +0000 (GMT)
Subject: Dual-Pivot Quicksort and Sorting classes: introspective sort
Message-ID: <862538.43364.qm@web29207.mail.ird.yahoo.com>

Hello.

I talked with?Vladimir?about using introspective sort along with the new 
dual-pivot quicksort,
but it's maybe worth to bring this discussions into this list (as Vladimir 
advised me):
?
The idea of introspective sort (David Musser, 1997) is to use the usual quick 
sort + insertion sort combo,
unless quick sort goes quadratic, in which case remaining sorting is done using 
a sort that is O(N*log(N))
in worst case.
Insertion sort is therefore O(N*log(N)) in worst case, which might be needed by 
some applications
(if you want to be sure that treatments won't hand for too long, or that if 
treatments hang, it's not due
to sorting, to?reduce investigations possibilities).
?
The determination whether quick sort "goes quadratic" or not, can be done very 
simply,
using an int "maxDepth" variable, initialized with some value proportional to 
the logarithm of
initial sort range width, and decremented on each quick sort recursion : when 
this value
reaches zero, i.e. when quick sort did too many recursions, remaining sorting is 
done with
the O(N*log(N))-in-worst-case backup sort, instead of partitioning again with 
quick sort.
For some sorting range widths (50 ? 100 ?), it might not be worth to bother with 
these
anti-quadratic considerations: in that cases, non-introspective sort could be 
used,
or introspective sort using Integer.MAX_VALUE as "maxDepth".

I think heap sort is a good O(N*log(N)) backup sort, because unlike merge sort,
it does not require the creation of a new array, which could cause problem in 
case
this array would be huge (all we ask to this backup sort is to finish the 
sorting not
quadratically, and not to possibly add more trouble by messing up with?memory,
even though it could be a tad faster in some cases with?latest garbage 
collectors).

Summary:
Introspective sort cost:
- have to initialize a counter using a logarithmic or 
optimized-pseudo-logarithmic?method,
- have to decrement and check the counter at each quick sort recursion,
- have to implement heap sort?for use when quick sort goes quadratic.
Introspective sort benefit:
- O(N*log(N)) in worst case, while almost as fast as non-introspective sort in 
general case.

Regards,

Jeff



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/6b3161fd/attachment.html>

From forax at univ-mlv.fr  Thu Sep 16 13:33:59 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 16 Sep 2010 15:33:59 +0200
Subject: A small ClassLoader change proposal
In-Reply-To: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
Message-ID: <4C921CC7.4080606@univ-mlv.fr>

  So you want to create a classloader local like there is a thread local.

You can subclass ClassLoader and put your field in the newly created class.
Why do you need to put your localMap in java.lang.Classloader ?

R?mi

Le 16/09/2010 14:56, Jevgeni Kabanov a ?crit :
> Hi guys,
>
> I'd like to contribute two new classes to the JDK7 and add a new 
> package-visible field to the ClassLoader. These classes would be meant 
> for the framework and server developers to allow for greater control 
> over the references between classes in different class loaders. 
> Specifically the goal would be to prevent the notoriously common 
> classloader leaks. The motivation is partially described here:
> http://dow.ngra.de/2009/06/15/classloaderlocal-how-to-avoid-classloader-leaks-on-application-redeploy/
> That blog post also describes a way to backport it to older Java 
> versions, unfortunately we found that the described approach will not 
> work in some esoteric cases.
>
> The pseudo-code follows. It's not really optimized or even tested and 
> is only meant to illustrate the functionality and complexity of the 
> proposal. I'd like to hear your feedback on this.
>
> class ClassLoader {
>   Map localMap = new HashMap();
>   //...
> }
>
> public class ClassLoaderLocal {
>   private Object key = new Object();
>   public Object get(ClassLoader cl) {
>     cl.localMap.get(key);
>   }
>   public void set(ClassLoader cl, Object value) {
>     cl.localMap.put(key, value);
>   }
> }
>
> public class ClassLoaderWeakReference extends Reference {
>   private final WeakReference clRef;
>   private final ClassLoaderLocal cll = new ClassLoaderLocal();
>   public ClassLoaderWeakReference(Object target) {
>      clRef = new WeakReference(target.getClass().getClassLoader());
>      cll.set(target.getClass().getClassLoader(), target);
>   }
>   public Object get() {
>     if (clRef.get() == null)
>       return null;
>     return cll.get((ClassLoader) clRef.get());
>   }
> }
>
> me*Jevgeni Kabanov*: Founder & CTO at ZeroTurnaround 
> <http:/www.zeroturnaround.com/>
> jevgeni at zeroturnaround.com <mailto:jevgeni at zeroturnaround.com> | 
> Skype: ekabanov <skype:ekabanov?chat> | http://twitter.com/ekabanov
> "jrebel is r0x: http://bit.ly/6fRGji" - mschambeck 
> <http://twitter.com/mschambeck>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/629421ee/attachment.html>

From ekabanov at gmail.com  Thu Sep 16 13:44:17 2010
From: ekabanov at gmail.com (Jevgeni Kabanov)
Date: Thu, 16 Sep 2010 16:44:17 +0300
Subject: A small ClassLoader change proposal
In-Reply-To: <4C921CC7.4080606@univ-mlv.fr>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
	<4C921CC7.4080606@univ-mlv.fr>
Message-ID: <02005F96-C4CC-40A6-AD25-33C6699FAC28@gmail.com>

On 16.09.2010, at 16:33, R?mi Forax wrote:

> So you want to create a classloader local like there is a thread local.
> 
> You can subclass ClassLoader and put your field in the newly created class.
> Why do you need to put your localMap in java.lang.Classloader ?

Because I want it to work with any class loader, not just the ones created by me. In a typical Java EE app you have a lot of custom class loaders created by the container, frameworks and the app. I want to be able to hold a reference to an object, without having to think about what happens when that app is redeployed.

JK

From ekabanov at gmail.com  Thu Sep 16 14:06:56 2010
From: ekabanov at gmail.com (Jevgeni Kabanov)
Date: Thu, 16 Sep 2010 17:06:56 +0300
Subject: A small ClassLoader change proposal
In-Reply-To: <E335628C-60AF-47E2-B915-2ACEA6149DFD@redhat.com>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
	<4C921CC7.4080606@univ-mlv.fr>
	<02005F96-C4CC-40A6-AD25-33C6699FAC28@gmail.com>
	<E335628C-60AF-47E2-B915-2ACEA6149DFD@redhat.com>
Message-ID: <99F2CDF5-25FC-427C-A66A-E1634143CED1@gmail.com>

Yep, ephemerons would be great, but they failed to materialize so far and need support from the GC AFAIK. Whereas this is just one field in the ClassLoader which solves very real problems in a lot of use cases. The truth is that class loaders are leaking in most of the user applications I had access to and having a WeakClassLoaderReference would help a great deal to write libraries that don't leak them. And if the ClassLoaderLocal seems complicating, there's no real need to expose it, as the new reference type is what is needed most. Also, unlike ephemerons, this is backportable.

On 16.09.2010, at 16:53, David M. Lloyd wrote:

> This comes up from time to time.  I proposed a very similar thing a while ago and was shot down ("wait for ephemeron support!").
> 
> http://dmlloyd.blogspot.com/2009/02/class-local-data.html
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001168.html
> 
> On Sep 16, 2010, at 8:44 AM, Jevgeni Kabanov wrote:
> 
>> On 16.09.2010, at 16:33, R?mi Forax wrote:
>> 
>>> So you want to create a classloader local like there is a thread local.
>>> 
>>> You can subclass ClassLoader and put your field in the newly created class.
>>> Why do you need to put your localMap in java.lang.Classloader ?
>> 
>> Because I want it to work with any class loader, not just the ones created by me. In a typical Java EE app you have a lot of custom class loaders created by the container, frameworks and the app. I want to be able to hold a reference to an object, without having to think about what happens when that app is redeployed.
>> 
>> JK
> 
> - DML
> 


Jevgeni Kabanov: Founder & CTO at ZeroTurnaround
jevgeni at zeroturnaround.com | Skype: ekabanov | http://twitter.com/ekabanov
"first and only jetty context reload of the day (java inheritance change). Love #JRebel" - Ivar Abrahamsen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/46877093/attachment.html>

From crazybob at crazybob.org  Thu Sep 16 14:13:37 2010
From: crazybob at crazybob.org (Bob Lee)
Date: Thu, 16 Sep 2010 09:13:37 -0500
Subject: A small ClassLoader change proposal
In-Reply-To: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
Message-ID: <AANLkTik2VKqMhA66Rk7FDPgGnQmUGVSyBZkpu5UeCHSz@mail.gmail.com>

Jevgeni,

The best long term solution for the VM is
ephemerons<http://en.wikipedia.org/wiki/Ephemeron>.
They're not slated for Java 7 or even 8 yet though.

I implemented "class loader locals" as a library years ago. Unfortunately, I
don't have the code anymore because I didn't end up using them.

The internals went something like this:

public class ClassLoaderLocals {
  public static final Map values = new ConcurrenHashMap();
}

(I used synchronization at the time.)

Now, force each ClassLoader to load its own copy of ClassLoaderLocals. If
you reflectively invoke defineClass() instead of calling loadClass(), the
ClassLoader won't check its parent loader for ClassLoaderLocals.

Finally, paper over this with a nice, ThreadLocal-like API that hides the
ugly reflection.

Bob

On Thu, Sep 16, 2010 at 7:56 AM, Jevgeni Kabanov <ekabanov at gmail.com> wrote:

> Hi guys,
>
> I'd like to contribute two new classes to the JDK7 and add a new
> package-visible field to the ClassLoader. These classes would be meant for
> the framework and server developers to allow for greater control over the
> references between classes in different class loaders. Specifically the goal
> would be to prevent the notoriously common classloader leaks. The motivation
> is partially described here:
>
> http://dow.ngra.de/2009/06/15/classloaderlocal-how-to-avoid-classloader-leaks-on-application-redeploy/
> That blog post also describes a way to backport it to older Java versions,
> unfortunately we found that the described approach will not work in some
> esoteric cases.
>
> The pseudo-code follows. It's not really optimized or even tested and is
> only meant to illustrate the functionality and complexity of the proposal.
> I'd like to hear your feedback on this.
>
> class ClassLoader {
>   Map localMap = new HashMap();
>   //...
> }
>
> public class ClassLoaderLocal {
>   private Object key = new Object();
>
>   public Object get(ClassLoader cl) {
>     cl.localMap.get(key);
>   }
>
>   public void set(ClassLoader cl, Object value) {
>     cl.localMap.put(key, value);
>   }
> }
>
> public class ClassLoaderWeakReference extends Reference {
>   private final WeakReference clRef;
>   private final ClassLoaderLocal cll = new ClassLoaderLocal();
>   public ClassLoaderWeakReference(Object target) {
>      clRef = new WeakReference(target.getClass().getClassLoader());
>      cll.set(target.getClass().getClassLoader(), target);
>   }
>
>   public Object get() {
>     if (clRef.get() == null)
>       return null;
>     return cll.get((ClassLoader) clRef.get());
>   }
> }
>
> [image: me]*Jevgeni Kabanov*: Founder & CTO at ZeroTurnaround<http:/www.zeroturnaround.com/>
> jevgeni at zeroturnaround.com | Skype: ekabanov | http://twitter.com/ekabanov
> "jrebel is r0x: http://bit.ly/6fRGji" - mschambeck<http://twitter.com/mschambeck>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/686298b9/attachment.html>

From forax at univ-mlv.fr  Thu Sep 16 14:21:17 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 16 Sep 2010 16:21:17 +0200
Subject: A small ClassLoader change proposal
In-Reply-To: <E335628C-60AF-47E2-B915-2ACEA6149DFD@redhat.com>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
	<4C921CC7.4080606@univ-mlv.fr>
	<02005F96-C4CC-40A6-AD25-33C6699FAC28@gmail.com>
	<E335628C-60AF-47E2-B915-2ACEA6149DFD@redhat.com>
Message-ID: <4C9227DD.1060009@univ-mlv.fr>

  Le 16/09/2010 15:53, David M. Lloyd a ?crit :
> This comes up from time to time.  I proposed a very similar thing a 
> while ago and was shot down ("wait for ephemeron support!").
>
> http://dmlloyd.blogspot.com/2009/02/class-local-data.html
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001168.html

David,
class locals was recently introduced in java.dyn:
http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4ed243e9e9d9

R?mi

>
> On Sep 16, 2010, at 8:44 AM, Jevgeni Kabanov wrote:
>
>> On 16.09.2010, at 16:33, R?mi Forax wrote:
>>
>>> So you want to create a classloader local like there is a thread local.
>>>
>>> You can subclass ClassLoader and put your field in the newly created 
>>> class.
>>> Why do you need to put your localMap in java.lang.Classloader ?
>>
>> Because I want it to work with any class loader, not just the ones 
>> created by me. In a typical Java EE app you have a lot of custom 
>> class loaders created by the container, frameworks and the app. I 
>> want to be able to hold a reference to an object, without having to 
>> think about what happens when that app is redeployed.
>>
>> JK
>
> - DML
>



From ekabanov at gmail.com  Thu Sep 16 14:22:39 2010
From: ekabanov at gmail.com (Jevgeni Kabanov)
Date: Thu, 16 Sep 2010 17:22:39 +0300
Subject: A small ClassLoader change proposal
In-Reply-To: <AANLkTik2VKqMhA66Rk7FDPgGnQmUGVSyBZkpu5UeCHSz@mail.gmail.com>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
	<AANLkTik2VKqMhA66Rk7FDPgGnQmUGVSyBZkpu5UeCHSz@mail.gmail.com>
Message-ID: <E1101457-EB78-4820-B8D1-A33EA4B44509@gmail.com>

Bob, if you check the link to the blog post, it described such an implementation that I did a while ago. Unfortunately what I found out is that it doesn't work with some class loaders. Mainly because there are class loaders that at some point in their life cycle will throw an exception when a loadClass() is issued, and even if you use defineClass() a loadClass() is still issued for java.lang.Object when defining your class for the first time, causing an exception. So in the end I'm not using that code either, but I would be using it if it was safe.

On 16.09.2010, at 17:13, Bob Lee wrote:

> Jevgeni,
> 
> The best long term solution for the VM is ephemerons. They're not slated for Java 7 or even 8 yet though.
> 
> I implemented "class loader locals" as a library years ago. Unfortunately, I don't have the code anymore because I didn't end up using them.
> 
> The internals went something like this:
> 
> public class ClassLoaderLocals {
>   public static final Map values = new ConcurrenHashMap(); 
> }
> 
> (I used synchronization at the time.)
> 
> Now, force each ClassLoader to load its own copy of ClassLoaderLocals. If you reflectively invoke defineClass() instead of calling loadClass(), the ClassLoader won't check its parent loader for ClassLoaderLocals.
> 
> Finally, paper over this with a nice, ThreadLocal-like API that hides the ugly reflection.
> 
> Bob
> 
> On Thu, Sep 16, 2010 at 7:56 AM, Jevgeni Kabanov <ekabanov at gmail.com> wrote:
> Hi guys,
> 
> I'd like to contribute two new classes to the JDK7 and add a new package-visible field to the ClassLoader. These classes would be meant for the framework and server developers to allow for greater control over the references between classes in different class loaders. Specifically the goal would be to prevent the notoriously common classloader leaks. The motivation is partially described here:
> http://dow.ngra.de/2009/06/15/classloaderlocal-how-to-avoid-classloader-leaks-on-application-redeploy/
> That blog post also describes a way to backport it to older Java versions, unfortunately we found that the described approach will not work in some esoteric cases.
> 
> The pseudo-code follows. It's not really optimized or even tested and is only meant to illustrate the functionality and complexity of the proposal. I'd like to hear your feedback on this.
> 
> class ClassLoader {
>   Map localMap = new HashMap();
>   //...
> }
> 
> public class ClassLoaderLocal {
>   private Object key = new Object();
>  
>   public Object get(ClassLoader cl) {
>     cl.localMap.get(key);
>   }
>  
>   public void set(ClassLoader cl, Object value) {
>     cl.localMap.put(key, value);
>   }
> }
> 
> public class ClassLoaderWeakReference extends Reference {
>   private final WeakReference clRef;
>   private final ClassLoaderLocal cll = new ClassLoaderLocal();
>   public ClassLoaderWeakReference(Object target) {
>      clRef = new WeakReference(target.getClass().getClassLoader());
>      cll.set(target.getClass().getClassLoader(), target);
>   }
>   
>   public Object get() {
>     if (clRef.get() == null) 
>       return null;
>     return cll.get((ClassLoader) clRef.get());
>   }
> }
> 
> Jevgeni Kabanov: Founder & CTO at ZeroTurnaround
> jevgeni at zeroturnaround.com | Skype: ekabanov | http://twitter.com/ekabanov
> "jrebel is r0x: http://bit.ly/6fRGji" - mschambeck
> 
> 


Jevgeni Kabanov: Founder & CTO at ZeroTurnaround
jevgeni at zeroturnaround.com | Skype: ekabanov | http://twitter.com/ekabanov
"Planning to give #JRebel 3.0 a try. No more Java restarting." - Jan Van Hoecke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/0e3a8518/attachment.html>

From forax at univ-mlv.fr  Thu Sep 16 14:34:20 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 16 Sep 2010 16:34:20 +0200
Subject: A small ClassLoader change proposal
In-Reply-To: <02005F96-C4CC-40A6-AD25-33C6699FAC28@gmail.com>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
	<4C921CC7.4080606@univ-mlv.fr>
	<02005F96-C4CC-40A6-AD25-33C6699FAC28@gmail.com>
Message-ID: <4C922AEC.30808@univ-mlv.fr>

  Le 16/09/2010 15:44, Jevgeni Kabanov a ?crit :
> On 16.09.2010, at 16:33, R?mi Forax wrote:
>
>> So you want to create a classloader local like there is a thread local.
>>
>> You can subclass ClassLoader and put your field in the newly created class.
>> Why do you need to put your localMap in java.lang.Classloader ?
> Because I want it to work with any class loader, not just the ones created by me. In a typical Java EE app you have a lot of custom class loaders created by the container, frameworks and the app. I want to be able to hold a reference to an object, without having to think about what happens when that app is redeployed.
>
> JK

Why not rewriting libraries classloaders to introduce the classlocal map ?
You're JRebel after all :)

R?mi


From ekabanov at gmail.com  Thu Sep 16 14:37:56 2010
From: ekabanov at gmail.com (Jevgeni Kabanov)
Date: Thu, 16 Sep 2010 17:37:56 +0300
Subject: A small ClassLoader change proposal
In-Reply-To: <4C922AEC.30808@univ-mlv.fr>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
	<4C921CC7.4080606@univ-mlv.fr>
	<02005F96-C4CC-40A6-AD25-33C6699FAC28@gmail.com>
	<4C922AEC.30808@univ-mlv.fr>
Message-ID: <BF85655A-5FEA-440D-8322-AA2E035D49F8@gmail.com>

On 16.09.2010, at 17:34, R?mi Forax wrote:

> Le 16/09/2010 15:44, Jevgeni Kabanov a ?crit :
>> On 16.09.2010, at 16:33, R?mi Forax wrote:
>> 
>>> So you want to create a classloader local like there is a thread local.
>>> 
>>> You can subclass ClassLoader and put your field in the newly created class.
>>> Why do you need to put your localMap in java.lang.Classloader ?
>> Because I want it to work with any class loader, not just the ones created by me. In a typical Java EE app you have a lot of custom class loaders created by the container, frameworks and the app. I want to be able to hold a reference to an object, without having to think about what happens when that app is redeployed.
>> 
>> JK
> 
> Why not rewriting libraries classloaders to introduce the classlocal map ?
> You're JRebel after all :)

*cough* Why, that's an idea! *cough* 

JK



From crazybob at crazybob.org  Thu Sep 16 14:51:02 2010
From: crazybob at crazybob.org (Bob Lee)
Date: Thu, 16 Sep 2010 09:51:02 -0500
Subject: A small ClassLoader change proposal
In-Reply-To: <E1101457-EB78-4820-B8D1-A33EA4B44509@gmail.com>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
	<AANLkTik2VKqMhA66Rk7FDPgGnQmUGVSyBZkpu5UeCHSz@mail.gmail.com>
	<E1101457-EB78-4820-B8D1-A33EA4B44509@gmail.com>
Message-ID: <AANLkTikeabEz3x-DBMQqx3hCE40Xpcr-J-1JQ0o0vtGP@mail.gmail.com>

On Thu, Sep 16, 2010 at 9:22 AM, Jevgeni Kabanov <ekabanov at gmail.com> wrote:

> Bob, if you check the link to the blog post, it described such an
> implementation that I did a while ago.
>

Doh! Sorry for not reading that.


> Unfortunately what I found out is that it doesn't work with some class
> loaders. Mainly because there are class loaders that at some point in their
> life cycle will throw an exception when a loadClass() is issued, and even if
> you use defineClass() a loadClass() is still issued for java.lang.Object
> when defining your class for the first time, causing an exception. So in the
> end I'm not using that code either, but I would be using it if it was safe.
>

Ugh. That's unfortunate.

You could submit a patch to OpenJDK. Patching ClassLoader on the fly sounds
like a better idea though; it'd take years before you'd be able to use a
patch.

You could patch all ClassLoader subclasses instead. That would be easier to
do on the fly than patching ClassLoader itself. You'd instrument loadClass()
so that if you're loading ClassLoaderLocals, it would run your loadClass()
code (which would retrieve classes in the system classloader) instead of the
original code which would otherwise throw an exception.

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/44d2dcdc/attachment.html>

From ekabanov at gmail.com  Thu Sep 16 14:58:27 2010
From: ekabanov at gmail.com (Jevgeni Kabanov)
Date: Thu, 16 Sep 2010 17:58:27 +0300
Subject: A small ClassLoader change proposal
In-Reply-To: <AANLkTikeabEz3x-DBMQqx3hCE40Xpcr-J-1JQ0o0vtGP@mail.gmail.com>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
	<AANLkTik2VKqMhA66Rk7FDPgGnQmUGVSyBZkpu5UeCHSz@mail.gmail.com>
	<E1101457-EB78-4820-B8D1-A33EA4B44509@gmail.com>
	<AANLkTikeabEz3x-DBMQqx3hCE40Xpcr-J-1JQ0o0vtGP@mail.gmail.com>
Message-ID: <BBD5E6D2-E77C-4A8C-8AA0-DC1AAA29823D@gmail.com>

On 16.09.2010, at 17:51, Bob Lee wrote:

>  
> Unfortunately what I found out is that it doesn't work with some class loaders. Mainly because there are class loaders that at some point in their life cycle will throw an exception when a loadClass() is issued, and even if you use defineClass() a loadClass() is still issued for java.lang.Object when defining your class for the first time, causing an exception. So in the end I'm not using that code either, but I would be using it if it was safe.
> 
> Ugh. That's unfortunate.
> 
> You could submit a patch to OpenJDK. Patching ClassLoader on the fly sounds like a better idea though; it'd take years before you'd be able to use a patch.

Unfortunately you can't patch the ClassLoader like that via Instrumentation (it adds a new field), and I wouldn't like to enforce the bootstrap override as it's way clumsier than a -javaagent.

I will find some kind of solution that'll work for me, but it just seemed to me such a small change that the JDK7 could carry it and make someone else's life easier in the future. 

> You could patch all ClassLoader subclasses instead. That would be easier to do on the fly than patching ClassLoader itself. You'd instrument loadClass() so that if you're loading ClassLoaderLocals, it would run your loadClass() code (which would retrieve classes in the system classloader) instead of the original code which would otherwise throw an exception.

Yep, that's pretty much what I'm doing/thinking of doing right now. But it needs special handling for URLClassLoader that is defined in the bootstrap and some others. It's a pretty complicated solution to a pretty small and common problem, all-in-all.

JK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/f20054fd/attachment.html>

From jonathan.gibbons at oracle.com  Thu Sep 16 16:56:12 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 16 Sep 2010 16:56:12 +0000
Subject: hg: jdk7/tl/langtools: 6985181: Annotations lost from classfile
Message-ID: <20100916165614.365BA47A0E@hg.openjdk.java.net>

Changeset: 6e2ccba61117
Author:    jjg
Date:      2010-09-16 09:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6e2ccba61117

6985181: Annotations lost from classfile
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
+ test/tools/javac/T6985181.java



From jonathan.gibbons at oracle.com  Thu Sep 16 16:57:08 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 16 Sep 2010 16:57:08 +0000
Subject: hg: jdk7/tl/langtools: 6985115: tests create too much output
Message-ID: <20100916165710.3CBC047A0F@hg.openjdk.java.net>

Changeset: bbc9765d9ec6
Author:    jjg
Date:      2010-09-16 09:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bbc9765d9ec6

6985115: tests create too much output
Reviewed-by: mcimadamore

! test/tools/javac/T6855236.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/tree/AbstractTreeScannerTest.java
! test/tools/javac/tree/JavacTreeScannerTest.java
! test/tools/javac/tree/SourceTreeScannerTest.java
! test/tools/javap/T6868539.java
! test/tools/javap/T6980017.java



From lance.andersen at oracle.com  Thu Sep 16 17:58:25 2010
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 16 Sep 2010 13:58:25 -0400
Subject: hg: jdk7/tl/jdk: 6589685: JDBC 4.1 updates
In-Reply-To: <AANLkTim65ZqW=567Ait3C+9bR4oGrOVEgVFTA1h_Hz3h@mail.gmail.com>
References: <AANLkTim65ZqW=567Ait3C+9bR4oGrOVEgVFTA1h_Hz3h@mail.gmail.com>
Message-ID: <3C9D7874-5079-4521-8DC1-7A091830FD1A@oracle.com>

Hi Paul,

Thanks for pointing out the typo.  I have created a CR for this and am waiting on the review to put it back.

Regards
Lance
On Sep 15, 2010, at 9:10 PM, Paul Benedict wrote:

> Lance,
> 
> There is a small typo in the javadoc. For method
> generatedKeyAlwaysReturned, "indexe(s)" should be "index(es)"
> 
> Paul




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com

	Oracle is committed to developing practices and products that help protect the environment


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/ed76cd8e/attachment.html>

From mandy.chung at oracle.com  Thu Sep 16 23:30:33 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 16 Sep 2010 16:30:33 -0700
Subject: Code Review Request for 6977738
Message-ID: <4C92A899.8000407@oracle.com>



Fix 6977738: Deadlock between java.lang.ClassLoader and java.util.Properties

Webrev at:
    http://cr.openjdk.java.net/~mchung/6977738/webrev.00/

ClassLoader.getResource locking the system properties object is
deadlock prone. For example, the sun.misc.Launcher.getBootstrapClassPath()
method is a synchronized method. A thread calling
ClassLoader.getResource method attempts to synchronize on
the system properties object while holding sun.misc.Launcher.class.
It will deadlock if there is another thread is holding the monitor
lock of the system properties object (e.g. calls the Properties.save()
method) while it attempts to load a resource file.  In addition,
ClassLoader.getResource may invoke the ZipFile initialization that
also needs to get the system property.

This fix caches the system properties at initialization so that
the ZipFile and Launcher will read the system property from the
private Properties object.  In addition, I make some minor
changes in Properties.save and storeToXML method to confine the
synchronization needed and also have the DownloadManager to
maintain its bootclasspath.

Thanks
Mandy



From David.Holmes at oracle.com  Fri Sep 17 01:05:42 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 17 Sep 2010 11:05:42 +1000
Subject: Code Review Request for 6977738
In-Reply-To: <4C92A899.8000407@oracle.com>
References: <4C92A899.8000407@oracle.com>
Message-ID: <4C92BEE6.7040800@oracle.com>

Hi Mandy,

This seems quite an involved solution compared to what is described in 
the CR. The lazy initialization of the bcp seems to be a main part of 
the problem (or rather the requisite synchronization thereof). Do we 
really need to lazily initialize the bcp?

Even if we do, can we not simply avoid the nested locking by only 
locking when needing to initialize the bcp (and cache it in a volatile) 
and move the getProperty outside of that synchronized section. No nested 
locking so no deadlocks.

Cheers,
David


Mandy Chung said the following on 09/17/10 09:30:
> 
> 
> Fix 6977738: Deadlock between java.lang.ClassLoader and 
> java.util.Properties
> 
> Webrev at:
>    http://cr.openjdk.java.net/~mchung/6977738/webrev.00/
> 
> ClassLoader.getResource locking the system properties object is
> deadlock prone. For example, the sun.misc.Launcher.getBootstrapClassPath()
> method is a synchronized method. A thread calling
> ClassLoader.getResource method attempts to synchronize on
> the system properties object while holding sun.misc.Launcher.class.
> It will deadlock if there is another thread is holding the monitor
> lock of the system properties object (e.g. calls the Properties.save()
> method) while it attempts to load a resource file.  In addition,
> ClassLoader.getResource may invoke the ZipFile initialization that
> also needs to get the system property.
> 
> This fix caches the system properties at initialization so that
> the ZipFile and Launcher will read the system property from the
> private Properties object.  In addition, I make some minor
> changes in Properties.save and storeToXML method to confine the
> synchronization needed and also have the DownloadManager to
> maintain its bootclasspath.
> 
> Thanks
> Mandy
> 


From tom.hawtin at oracle.com  Fri Sep 17 01:55:14 2010
From: tom.hawtin at oracle.com (tom.hawtin at oracle.com)
Date: Fri, 17 Sep 2010 02:55:14 +0100
Subject: A small ClassLoader change proposal
In-Reply-To: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
References: <65B6F4D9-7021-4971-A2F1-2A12E7A26B57@gmail.com>
Message-ID: <4C92CA82.8020507@oracle.com>

On 16/09/2010 13:56, Jevgeni Kabanov wrote:

> I'd like to contribute two new classes to the JDK7 and add a new
> package-visible field to the ClassLoader. These classes would be meant
> for the framework and server developers to allow for greater control
> over the references between classes in different class loaders.
> Specifically the goal would be to prevent the notoriously common
> classloader leaks. The motivation is partially described here:
> http://dow.ngra.de/2009/06/15/classloaderlocal-how-to-avoid-classloader-leaks-on-application-redeploy/
> That blog post also describes a way to backport it to older Java
> versions, unfortunately we found that the described approach will not
> work in some esoteric cases.

For reference, there are two existing CRs relating to this.

Bug ID: 6389107 (ref) Request Reference.link(Object,Object) for "biweak" 
caches

       (1 vote)

Bug ID: 6493635 (cl) ClassLoader-local variables similar to ThreadLocal

      (2 votes)

Tom


From mandy.chung at oracle.com  Fri Sep 17 03:27:19 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 16 Sep 2010 20:27:19 -0700
Subject: Code Review Request for 6977738
In-Reply-To: <4C92BEE6.7040800@oracle.com>
References: <4C92A899.8000407@oracle.com> <4C92BEE6.7040800@oracle.com>
Message-ID: <4C92E017.2000807@oracle.com>

  Hi David,

On 9/16/10 6:05 PM, David Holmes wrote:
> Hi Mandy,
>
> This seems quite an involved solution compared to what is described in 
> the CR. The lazy initialization of the bcp seems to be a main part of 
> the problem (or rather the requisite synchronization thereof). Do we 
> really need to lazily initialize the bcp?
>

My initial fix was to initialize the bcp outside of the synchronized 
section as part of the Launcher initialization code.  I later found that 
java.util.zip.ZipFile static initializer also gets a system property 
that will run into a deadlock if the system properties object is locked 
by another thread.

> Even if we do, can we not simply avoid the nested locking by only 
> locking when needing to initialize the bcp (and cache it in a 
> volatile) and move the getProperty outside of that synchronized 
> section. No nested locking so no deadlocks.
>

I could cache the bcp.   To fix this bug, it also need to cache 
"sun.zip.disableMemoryMapping" system property.  Instead of caching 
individual system properties, I go with caching the Properties object in 
case other part in the lib also avoids any new locking issue found in 
the future.

Mandy

> Cheers,
> David
>
>
> Mandy Chung said the following on 09/17/10 09:30:
>>
>>
>> Fix 6977738: Deadlock between java.lang.ClassLoader and 
>> java.util.Properties
>>
>> Webrev at:
>>    http://cr.openjdk.java.net/~mchung/6977738/webrev.00/
>>
>> ClassLoader.getResource locking the system properties object is
>> deadlock prone. For example, the 
>> sun.misc.Launcher.getBootstrapClassPath()
>> method is a synchronized method. A thread calling
>> ClassLoader.getResource method attempts to synchronize on
>> the system properties object while holding sun.misc.Launcher.class.
>> It will deadlock if there is another thread is holding the monitor
>> lock of the system properties object (e.g. calls the Properties.save()
>> method) while it attempts to load a resource file.  In addition,
>> ClassLoader.getResource may invoke the ZipFile initialization that
>> also needs to get the system property.
>>
>> This fix caches the system properties at initialization so that
>> the ZipFile and Launcher will read the system property from the
>> private Properties object.  In addition, I make some minor
>> changes in Properties.save and storeToXML method to confine the
>> synchronization needed and also have the DownloadManager to
>> maintain its bootclasspath.
>>
>> Thanks
>> Mandy
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/5b7f6b5e/attachment.html>

From lance.andersen at oracle.com  Fri Sep 17 17:34:36 2010
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Fri, 17 Sep 2010 17:34:36 +0000
Subject: hg: jdk7/tl/jdk: 4 new changesets
Message-ID: <20100917173525.6165B47A58@hg.openjdk.java.net>

Changeset: 7794d718ffe2
Author:    lancea
Date:      2010-09-17 13:23 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7794d718ffe2

6983452: SyncProvider issue for JoinRowSet implementation
Reviewed-by: darcy, ohair

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java

Changeset: 1cb444a3d5cd
Author:    lancea
Date:      2010-09-17 13:26 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1cb444a3d5cd

6984864: Exception when running acceptChanges with custom SyncProvider
Reviewed-by: darcy, ohair

! src/share/classes/com/sun/rowset/JoinRowSetImpl.java

Changeset: 095a5e5a025a
Author:    lancea
Date:      2010-09-17 13:30 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/095a5e5a025a

6985400: DatabaseMetaData.generatedKeyAlwaysReturned, "indexe(s)" should be "index(es)"
Reviewed-by: darcy, ohair

! src/share/classes/java/sql/DatabaseMetaData.java

Changeset: 291a5c52f9d0
Author:    lancea
Date:      2010-09-17 13:33 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/291a5c52f9d0

6985725: RowSetProvider has typo for the property javax.sql.rowset.RowSetFactory in the javadoc
Reviewed-by: darcy, ohair

! src/share/classes/javax/sql/rowset/RowSetProvider.java



From mandy.chung at oracle.com  Fri Sep 17 21:16:53 2010
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 17 Sep 2010 21:16:53 +0000
Subject: hg: jdk7/tl/jdk: 6888546: restore System.initializeSystemClasses
Message-ID: <20100917211711.2B3F247A6A@hg.openjdk.java.net>

Changeset: 605b327f4830
Author:    mchung
Date:      2010-09-17 14:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/605b327f4830

6888546: restore System.initializeSystemClasses
Summary: restore System.initializeSystemClasses prior to fix for 6797688
Reviewed-by: alanb

! src/share/classes/java/lang/System.java



From martinrb at google.com  Fri Sep 17 21:39:32 2010
From: martinrb at google.com (martinrb at google.com)
Date: Fri, 17 Sep 2010 21:39:32 +0000
Subject: hg: jdk7/tl/jdk: 6981138: (process) Process.waitFor() may hang if
	subprocess has live descendants (lnx)
Message-ID: <20100917213941.C50EC47A6B@hg.openjdk.java.net>

Changeset: 48d7f8c4cd60
Author:    martin
Date:      2010-09-17 14:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/48d7f8c4cd60

6981138: (process) Process.waitFor() may hang if subprocess has live descendants (lnx)
Summary: Do exit status handling before trying to close streams
Reviewed-by: alanb, dholmes

! src/solaris/classes/java/lang/UNIXProcess.java.linux
! test/java/lang/ProcessBuilder/Basic.java



From martinrb at google.com  Fri Sep 17 21:55:24 2010
From: martinrb at google.com (martinrb at google.com)
Date: Fri, 17 Sep 2010 21:55:24 +0000
Subject: hg: jdk7/tl/jdk: 6981157: Improve UnknownHostException with EAI error
	details and other cleanups
Message-ID: <20100917215533.622D547A6D@hg.openjdk.java.net>

Changeset: b5d37597c815
Author:    martin
Date:      2010-09-17 14:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b5d37597c815

6981157: Improve UnknownHostException with EAI error details and other cleanups
Summary: generify; remove compiler warnings, typos, casts; return status information via gai_strerror when getaddrinfo fails; show full stack of native failures
Reviewed-by: michaelm, alanb

! src/share/classes/java/net/InetAddress.java
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/solaris/native/java/net/net_util_md.c
! src/solaris/native/java/net/net_util_md.h



From lance.andersen at oracle.com  Sat Sep 18 10:10:20 2010
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Sat, 18 Sep 2010 10:10:20 +0000
Subject: hg: jdk7/tl/jdk: 6984044: RowSet source needs to rebrand vendor
	references
Message-ID: <20100918101042.658CE47A88@hg.openjdk.java.net>

Changeset: 0d78b3eedecc
Author:    lancea
Date:      2010-09-18 06:09 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0d78b3eedecc

6984044: RowSet source needs to rebrand vendor references
Reviewed-by: darcy, ohair

! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java
! src/share/classes/com/sun/rowset/providers/RIOptimisticProvider.java
! src/share/classes/com/sun/rowset/providers/RIXMLProvider.java
! src/share/classes/javax/sql/rowset/CachedRowSet.java
! src/share/classes/javax/sql/rowset/WebRowSet.java
! src/share/classes/javax/sql/rowset/rowset.properties
! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java
! src/share/classes/javax/sql/rowset/spi/package.html



From maurizio.cimadamore at oracle.com  Sat Sep 18 16:58:17 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Sat, 18 Sep 2010 16:58:17 +0000
Subject: hg: jdk7/tl/langtools: 2 new changesets
Message-ID: <20100918165821.7870F47A96@hg.openjdk.java.net>

Changeset: 50f9ac2f4730
Author:    mcimadamore
Date:      2010-09-18 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/50f9ac2f4730

6980862: too aggressive compiler optimization causes stale results of Types.implementation()
Summary: use a scope counter in order to determine when/if the implementation cache entries are stale
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Scope.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java

Changeset: 77cc34d5e548
Author:    mcimadamore
Date:      2010-09-18 09:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/77cc34d5e548

5088624: cannot find symbol message should be more intelligent
Summary: Resolve.java should keep track of all candidates found during a method resolution sweep to generate more meaningful diagnostics
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java
! test/tools/javac/6758789/T6758789a.out
! test/tools/javac/6840059/T6840059.out
! test/tools/javac/6857948/T6857948.out
! test/tools/javac/Diagnostics/6722234/T6722234a_1.out
! test/tools/javac/Diagnostics/6722234/T6722234a_2.out
! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
! test/tools/javac/Diagnostics/6722234/T6722234c.out
! test/tools/javac/Diagnostics/6799605/T6799605.out
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/Diagnostics/6862608/T6862608b.out
! test/tools/javac/T6326754.out
! test/tools/javac/diags/Example.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java
+ test/tools/javac/diags/examples/InapplicableSymbols.java
! test/tools/javac/diags/examples/IncompatibleTypes1.java
+ test/tools/javac/diags/examples/InferArgsLengthMismatch.java
! test/tools/javac/diags/examples/KindnameConstructor.java
! test/tools/javac/diags/examples/NoArgs.java
+ test/tools/javac/diags/examples/VarargsArgumentMismatch.java
! test/tools/javac/diags/examples/WhereCaptured.java
! test/tools/javac/diags/examples/WhereCaptured1.java
! test/tools/javac/diags/examples/WhereTypeVar.java
! test/tools/javac/generics/diamond/neg/Neg06.out
! test/tools/javac/generics/inference/6315770/T6315770.out
! test/tools/javac/generics/inference/6611449/T6611449.out
! test/tools/javac/generics/inference/6638712/T6638712a.out
! test/tools/javac/generics/inference/6638712/T6638712b.out
! test/tools/javac/generics/inference/6638712/T6638712c.out
! test/tools/javac/generics/inference/6638712/T6638712d.out
! test/tools/javac/generics/inference/6638712/T6638712e.out



From maurizio.cimadamore at oracle.com  Sat Sep 18 21:25:07 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Sat, 18 Sep 2010 21:25:07 +0000
Subject: hg: jdk7/tl/langtools: 6863465: javac doesn't detect circular
	subclass dependencies via qualified names
Message-ID: <20100918212509.634EB47AA0@hg.openjdk.java.net>

Changeset: 0c1ef2af7a8e
Author:    mcimadamore
Date:      2010-09-18 14:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0c1ef2af7a8e

6863465: javac doesn't detect circular subclass dependencies via qualified names
Summary: class inheritance circularity check should look at trees, not just symbols
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+ test/tools/javac/6863465/T6863465a.java
+ test/tools/javac/6863465/T6863465a.out
+ test/tools/javac/6863465/T6863465b.java
+ test/tools/javac/6863465/T6863465b.out
+ test/tools/javac/6863465/T6863465c.java
+ test/tools/javac/6863465/T6863465c.out
+ test/tools/javac/6863465/T6863465d.java
+ test/tools/javac/6863465/T6863465d.out
+ test/tools/javac/6863465/TestCircularClassfile.java
! test/tools/javac/CyclicInheritance.out
! test/tools/javac/NameCollision.out



From martinrb at google.com  Tue Sep 21 01:16:07 2010
From: martinrb at google.com (martinrb at google.com)
Date: Tue, 21 Sep 2010 01:16:07 +0000
Subject: hg: jdk7/tl/jdk: 6981113: Add ConcurrentLinkedDeque
Message-ID: <20100921011628.DBEF347B0C@hg.openjdk.java.net>

Changeset: 902486a8e414
Author:    dl
Date:      2010-09-20 18:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/902486a8e414

6981113: Add ConcurrentLinkedDeque
Summary: Extend techniques developed for ConcurrentLinkedQueue and LinkedTransferQueue to implement a non-blocking concurrent Deque with interior removes.
Reviewed-by: martin, dholmes, chegar

! make/java/java/FILES_java.gmk
+ src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! test/java/util/Collection/BiggernYours.java
! test/java/util/Collection/IteratorAtEnd.java
! test/java/util/Collection/MOAT.java
! test/java/util/Collections/RacingCollections.java
! test/java/util/Deque/ChorusLine.java
! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java
! test/java/util/concurrent/ConcurrentQueues/GCRetention.java
! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java
! test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java
! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java



From chris.hegarty at oracle.com  Tue Sep 21 14:58:58 2010
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 21 Sep 2010 14:58:58 +0000
Subject: hg: jdk7/tl/jdk: 6672144: HttpURLConnection.getInputStream sends POST
	request after failed chunked
Message-ID: <20100921145918.F412F47B2B@hg.openjdk.java.net>

Changeset: cd4aad589b3f
Author:    chegar
Date:      2010-09-21 15:58 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd4aad589b3f

6672144: HttpURLConnection.getInputStream sends POST request after failed chunked
Reviewed-by: michaelm

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/http/HttpClient/StreamingRetry.java



From chris.hegarty at oracle.com  Tue Sep 21 15:08:56 2010
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 21 Sep 2010 15:08:56 +0000
Subject: hg: jdk7/tl/jdk: 6986050: Small clarifications and fixes for ForkJoin
Message-ID: <20100921150906.4BDB447B2D@hg.openjdk.java.net>

Changeset: f5d25402ed53
Author:    dl
Date:      2010-09-21 16:06 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f5d25402ed53

6986050: Small clarifications and fixes for ForkJoin
Summary: Clarify FJ.get on throw InterruptedException, propagate ThreadFactory, shutdown transition
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! src/share/classes/java/util/concurrent/RecursiveAction.java



From sundararajan.a at sun.com  Wed Sep 22 15:32:23 2010
From: sundararajan.a at sun.com (sundararajan.a at sun.com)
Date: Wed, 22 Sep 2010 15:32:23 +0000
Subject: hg: jdk7/tl/langtools: 6587674: NoClassdefFound when anonymously
	extending a class.
Message-ID: <20100922153227.D248C47B60@hg.openjdk.java.net>

Changeset: da7ca56d092c
Author:    sundar
Date:      2010-09-22 20:53 +0530
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/da7ca56d092c

6587674: NoClassdefFound when anonymously extending a class.
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T6587674.java



From daniel.daugherty at oracle.com  Wed Sep 22 19:45:14 2010
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Wed, 22 Sep 2010 19:45:14 +0000
Subject: hg: jdk7/tl/jdk: 6949710: 3/3 the GC'able nature of Logging objects
	needs to be made brutally clear
Message-ID: <20100922194535.7F02A47B6C@hg.openjdk.java.net>

Changeset: 4927d1319b2f
Author:    dcubed
Date:      2010-09-22 07:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4927d1319b2f

6949710: 3/3 the GC'able nature of Logging objects needs to be made brutally clear
Summary: Add words in more places to make it clear that Logger objects are GC'able unless there is a strong reference.
Reviewed-by: dholmes, andrew

! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java



From jonathan.gibbons at oracle.com  Wed Sep 22 19:53:15 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 22 Sep 2010 19:53:15 +0000
Subject: hg: jdk7/tl/langtools: 6986772: langtools netbeans build should use
	${ant.core.lib} instead of ${ant.home}/lib/ant.jar
Message-ID: <20100922195320.0127F47B6D@hg.openjdk.java.net>

Changeset: 3eea38ce151c
Author:    jjg
Date:      2010-09-22 12:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3eea38ce151c

6986772: langtools netbeans build should use ${ant.core.lib} instead of ${ant.home}/lib/ant.jar
Reviewed-by: ohair

! make/netbeans/langtools/build.xml



From kelly.ohair at oracle.com  Thu Sep 23 00:09:47 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Thu, 23 Sep 2010 00:09:47 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100923001031.6AADD47B84@hg.openjdk.java.net>

Changeset: 4db5c4867a78
Author:    ohair
Date:      2010-09-22 11:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4db5c4867a78

6946527: rebranding system properties per Oracle Requirements (vendor)
Summary: Changes from "Sun Microsystems, Inc." to "Oracle Corporation" in the java.vendor, java.specification.vendor and java.vendor.url Java system properties. Also change of Windows COMPANY file property from "Oracle" to "Oracle Corporation".
Reviewed-by: lancea, flar

! make/common/shared/Defs.gmk
! src/share/native/java/lang/System.c

Changeset: 378ea143ff5f
Author:    ohair
Date:      2010-09-22 12:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/378ea143ff5f

Merge




From weijun.wang at sun.com  Thu Sep 23 02:46:39 2010
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Thu, 23 Sep 2010 02:46:39 +0000
Subject: hg: jdk7/tl/jdk: 6982971: TEST failure:
	com/sun/security/sasl/ntlm/NTLMTest.java
Message-ID: <20100923024655.592B647B8B@hg.openjdk.java.net>

Changeset: ca630e91d473
Author:    weijun
Date:      2010-09-23 10:46 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ca630e91d473

6982971: TEST failure: com/sun/security/sasl/ntlm/NTLMTest.java
Reviewed-by: wetmore

! test/com/sun/security/sasl/ntlm/NTLMTest.java



From mandy.chung at oracle.com  Thu Sep 23 06:34:27 2010
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 23 Sep 2010 06:34:27 +0000
Subject: hg: jdk7/tl/jdk: 6984036: servicetag vendor rebranding issues
Message-ID: <20100923063437.3BA1A47B95@hg.openjdk.java.net>

Changeset: 60cff062f66d
Author:    mchung
Date:      2010-09-22 21:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/60cff062f66d

6984036: servicetag vendor rebranding issues
Summary: Update product_vendor field to use java.vendor system property
Reviewed-by: ohair

! src/share/classes/com/sun/servicetag/Installer.java
! src/share/classes/com/sun/servicetag/RegistrationData.java
! src/share/classes/com/sun/servicetag/Registry.java
! src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
! test/com/sun/servicetag/JavaServiceTagTest.java
! test/com/sun/servicetag/JavaServiceTagTest1.java
! test/com/sun/servicetag/Util.java
! test/com/sun/servicetag/environ.properties
! test/com/sun/servicetag/missing-environ-field.xml
! test/com/sun/servicetag/newer-registry-version.xml
! test/com/sun/servicetag/registration.xml
! test/com/sun/servicetag/servicetag1.properties
! test/com/sun/servicetag/servicetag2.properties
! test/com/sun/servicetag/servicetag3.properties
! test/com/sun/servicetag/servicetag4.properties
! test/com/sun/servicetag/servicetag5.properties



From kelly.ohair at oracle.com  Fri Sep 24 21:29:42 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Fri, 24 Sep 2010 21:29:42 +0000
Subject: hg: jdk7/tl: 2 new changesets
Message-ID: <20100924212942.EC0A547BF8@hg.openjdk.java.net>

Changeset: ed13debe9a5e
Author:    ohair
Date:      2010-09-24 14:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/ed13debe9a5e

6987114: Fix top level "test" Makefile logic, add jdk/make/Makefile test target
Reviewed-by: mchung

! Makefile

Changeset: 27d945094f81
Author:    ohair
Date:      2010-09-24 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/27d945094f81

6987117: Add jprt test sets
Reviewed-by: mchung

! make/jprt.properties



From kelly.ohair at oracle.com  Fri Sep 24 21:30:04 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Fri, 24 Sep 2010 21:30:04 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100924213033.DB7CA47BF9@hg.openjdk.java.net>

Changeset: 9a837f410672
Author:    ohair
Date:      2010-09-24 14:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9a837f410672

6987117: Add jprt test sets
Reviewed-by: mchung

! make/jprt.properties

Changeset: 8503c7f3a354
Author:    ohair
Date:      2010-09-24 14:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8503c7f3a354

6987114: Fix top level "test" Makefile logic, add jdk/make/Makefile test target
6987113: Remove SCCS logic from makefiles
Reviewed-by: mchung

! make/Makefile
! make/common/Cscope.gmk
! make/common/Defs.gmk
- make/common/Rules-SCCS.gmk
! make/common/shared/Defs-utils.gmk
! test/ProblemList.txt



From weijun.wang at sun.com  Sat Sep 25 02:29:46 2010
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Sat, 25 Sep 2010 02:29:46 +0000
Subject: hg: jdk7/tl/jdk: 6986868: TEST failure:
	sun/security/tools/jarsigner/crl.sh
Message-ID: <20100925022957.CE78847C15@hg.openjdk.java.net>

Changeset: 9eb9485ec45b
Author:    weijun
Date:      2010-09-25 10:21 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9eb9485ec45b

6986868: TEST failure: sun/security/tools/jarsigner/crl.sh
Reviewed-by: ohair

! test/sun/security/tools/jarsigner/crl.sh



From lana.steuck at oracle.com  Sun Sep 26 06:35:19 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 26 Sep 2010 06:35:19 +0000
Subject: hg: jdk7/tl: 12 new changesets
Message-ID: <20100926063519.96DDD47C4D@hg.openjdk.java.net>

Changeset: 0df9c57eb80d
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/0df9c57eb80d

Added tag jdk7-b108 for changeset 140fdef4ddf5

! .hgtags

Changeset: 81dfc728d7bb
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/81dfc728d7bb

Merge


Changeset: f241877c0ac9
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/f241877c0ac9

Added tag jdk7-b109 for changeset 81dfc728d7bb

! .hgtags

Changeset: 782c0c738f6d
Author:    ohair
Date:      2010-09-08 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/782c0c738f6d

6974017: Upgrade required Solaris Studio compilers to 5.10 (12 update 1 + patches)
Reviewed-by: jcoomes

! README-builds.html

Changeset: 973560f0387d
Author:    cl
Date:      2010-09-08 17:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/973560f0387d

Merge


Changeset: c129c592e9d6
Author:    ohair
Date:      2010-09-09 17:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/c129c592e9d6

6982137: Rebranding pass 2 - missed copyright changes
Reviewed-by: mbykov

! make/templates/gpl-cp-header
! make/templates/gpl-header

Changeset: 2a02d4a6955c
Author:    cl
Date:      2010-09-15 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/2a02d4a6955c

Merge


Changeset: 9702d6fef68e
Author:    cl
Date:      2010-09-16 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/9702d6fef68e

Added tag jdk7-b110 for changeset 2a02d4a6955c

! .hgtags

Changeset: 989da1ce9287
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/989da1ce9287

Added tag jdk7-b111 for changeset 9702d6fef68e

! .hgtags

Changeset: 87e98a1df774
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/87e98a1df774

Merge


Changeset: b852103caf73
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/b852103caf73

Merge


Changeset: befdbb69155b
Author:    lana
Date:      2010-09-25 10:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/befdbb69155b

Merge




From lana.steuck at oracle.com  Sun Sep 26 06:35:25 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 26 Sep 2010 06:35:25 +0000
Subject: hg: jdk7/tl/corba: 7 new changesets
Message-ID: <20100926063530.0E0D947C4E@hg.openjdk.java.net>

Changeset: 74d57b218468
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/74d57b218468

Added tag jdk7-b108 for changeset 8d810527b499

! .hgtags

Changeset: c3dd858e09b2
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/c3dd858e09b2

Merge


Changeset: 0e1f80fda227
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/0e1f80fda227

Added tag jdk7-b109 for changeset c3dd858e09b2

! .hgtags

Changeset: 640fa4d4e2ad
Author:    cl
Date:      2010-09-16 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/640fa4d4e2ad

Added tag jdk7-b110 for changeset 0e1f80fda227

! .hgtags

Changeset: 21c218f9a7be
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/21c218f9a7be

Added tag jdk7-b111 for changeset 640fa4d4e2ad

! .hgtags

Changeset: ae60f98d2f42
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/ae60f98d2f42

Merge

- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk

Changeset: cc67fdc4fee9
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/cc67fdc4fee9

Merge

- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk



From lana.steuck at oracle.com  Sun Sep 26 06:36:20 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 26 Sep 2010 06:36:20 +0000
Subject: hg: jdk7/tl/hotspot: 5 new changesets
Message-ID: <20100926063630.477B747C4F@hg.openjdk.java.net>

Changeset: 2fe09e2e70d0
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2fe09e2e70d0

Added tag jdk7-b108 for changeset e44a93947ccb

! .hgtags

Changeset: cc4bb3022b31
Author:    cl
Date:      2010-09-09 14:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cc4bb3022b31

Merge

! .hgtags
- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp

Changeset: 2f25f2b8de27
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2f25f2b8de27

Added tag jdk7-b109 for changeset cc4bb3022b31

! .hgtags

Changeset: 07b042e13dde
Author:    cl
Date:      2010-09-16 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/07b042e13dde

Added tag jdk7-b110 for changeset 2f25f2b8de27

! .hgtags

Changeset: 8d5897b4230f
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8d5897b4230f

Added tag jdk7-b111 for changeset 07b042e13dde

! .hgtags



From lana.steuck at oracle.com  Sun Sep 26 06:37:10 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 26 Sep 2010 06:37:10 +0000
Subject: hg: jdk7/tl/jaxp: 7 new changesets
Message-ID: <20100926063710.7F09F47C50@hg.openjdk.java.net>

Changeset: 840d6acde4e8
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/840d6acde4e8

Added tag jdk7-b108 for changeset 7d379f8934ca

! .hgtags

Changeset: 0f382d6120fc
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/0f382d6120fc

Merge


Changeset: d422dbdd0976
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/d422dbdd0976

Added tag jdk7-b109 for changeset 0f382d6120fc

! .hgtags

Changeset: 8106c747067c
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/8106c747067c

Added tag jdk7-b110 for changeset d422dbdd0976

! .hgtags

Changeset: 028a06f776c0
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/028a06f776c0

Added tag jdk7-b111 for changeset 8106c747067c

! .hgtags

Changeset: b23fd715a158
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/b23fd715a158

Merge


Changeset: 1b0525424288
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/1b0525424288

Merge




From lana.steuck at oracle.com  Sun Sep 26 06:37:15 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 26 Sep 2010 06:37:15 +0000
Subject: hg: jdk7/tl/jaxws: 7 new changesets
Message-ID: <20100926063715.C730947C51@hg.openjdk.java.net>

Changeset: ef7838f988c5
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/ef7838f988c5

Added tag jdk7-b108 for changeset b1ca39340238

! .hgtags

Changeset: 4f626e0d70bd
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/4f626e0d70bd

Merge


Changeset: 95ecac35fb11
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/95ecac35fb11

Added tag jdk7-b109 for changeset 4f626e0d70bd

! .hgtags

Changeset: 2575ebca96c7
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/2575ebca96c7

Added tag jdk7-b110 for changeset 95ecac35fb11

! .hgtags

Changeset: 3c8627862d07
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/3c8627862d07

Added tag jdk7-b111 for changeset 2575ebca96c7

! .hgtags

Changeset: 4635da51e3cb
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/4635da51e3cb

Merge


Changeset: 8e0f0054817f
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/8e0f0054817f

Merge




From lana.steuck at oracle.com  Sun Sep 26 06:38:53 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 26 Sep 2010 06:38:53 +0000
Subject: hg: jdk7/tl/jdk: 48 new changesets
Message-ID: <20100926064646.3152547C53@hg.openjdk.java.net>

Changeset: 4571856d4628
Author:    cl
Date:      2010-09-03 12:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4571856d4628

Added tag jdk7-b108 for changeset 17a5d84b7561

! .hgtags

Changeset: ab0d3f54a63f
Author:    cl
Date:      2010-09-09 13:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ab0d3f54a63f

Merge


Changeset: 3937dd29f45a
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3937dd29f45a

Added tag jdk7-b109 for changeset ab0d3f54a63f

! .hgtags

Changeset: c5f6cd3bd70b
Author:    ohair
Date:      2010-09-08 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c5f6cd3bd70b

6974017: Upgrade required Solaris Studio compilers to 5.10 (12 update 1 + patches)
Reviewed-by: jcoomes

! make/common/shared/Compiler-sun.gmk
! make/common/shared/Defs-versions.gmk

Changeset: 8f5a6ea8c9e9
Author:    ohair
Date:      2010-09-09 16:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8f5a6ea8c9e9

6982137: Rebranding pass 2 - missed copyright changes
Reviewed-by: mbykov

! make/templates/gpl-cp-header
! make/templates/gpl-header
! src/share/classes/java/lang/CharacterName.java
! src/share/classes/sun/font/GlyphDisposedListener.java
! src/share/classes/sun/jvmstat/monitor/Units.java
! src/share/classes/sun/jvmstat/monitor/Variability.java
! src/solaris/classes/sun/font/XRGlyphCache.java
! src/solaris/classes/sun/font/XRGlyphCacheEntry.java
! src/solaris/classes/sun/font/XRTextRenderer.java
! src/solaris/classes/sun/java2d/jules/IdleTileCache.java
! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
! src/solaris/classes/sun/java2d/jules/JulesPathBuf.java
! src/solaris/classes/sun/java2d/jules/JulesRenderingEngine.java
! src/solaris/classes/sun/java2d/jules/JulesShapePipe.java
! src/solaris/classes/sun/java2d/jules/JulesTile.java
! src/solaris/classes/sun/java2d/jules/TileWorker.java
! src/solaris/classes/sun/java2d/jules/TrapezoidList.java
! src/solaris/classes/sun/java2d/xr/DirtyRegion.java
! src/solaris/classes/sun/java2d/xr/GrowableByteArray.java
! src/solaris/classes/sun/java2d/xr/GrowableEltArray.java
! src/solaris/classes/sun/java2d/xr/GrowableIntArray.java
! src/solaris/classes/sun/java2d/xr/GrowablePointArray.java
! src/solaris/classes/sun/java2d/xr/GrowableRectArray.java
! src/solaris/classes/sun/java2d/xr/MaskTile.java
! src/solaris/classes/sun/java2d/xr/MaskTileManager.java
! src/solaris/classes/sun/java2d/xr/MutableInteger.java
! src/solaris/classes/sun/java2d/xr/XIDGenerator.java
! src/solaris/classes/sun/java2d/xr/XRBackend.java
! src/solaris/classes/sun/java2d/xr/XRBackendNative.java
! src/solaris/classes/sun/java2d/xr/XRColor.java
! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java
! src/solaris/classes/sun/java2d/xr/XRDrawImage.java
! src/solaris/classes/sun/java2d/xr/XRGraphicsConfig.java
! src/solaris/classes/sun/java2d/xr/XRMaskBlit.java
! src/solaris/classes/sun/java2d/xr/XRMaskFill.java
! src/solaris/classes/sun/java2d/xr/XRMaskImage.java
! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java
! src/solaris/classes/sun/java2d/xr/XRPaints.java
! src/solaris/classes/sun/java2d/xr/XRRenderer.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceDataProxy.java
! src/solaris/classes/sun/java2d/xr/XRUtils.java
! src/solaris/classes/sun/java2d/xr/XRVolatileSurfaceManager.java
! src/solaris/classes/sun/java2d/xr/XcbRequestCounter.java
! src/solaris/native/sun/java2d/x11/XRBackendNative.c
! src/solaris/native/sun/java2d/x11/XRSurfaceData.c
! test/com/sun/java/swing/plaf/gtk/Test6963870.java
! test/java/lang/StringBuffer/Capacity.java
! test/java/security/cert/CertificateFactory/openssl/BadFooter.java
! test/java/util/zip/GZIP/GZIPInputStreamRead.java
! test/javax/swing/JFormattedTextField/Test6462562.java
! test/javax/swing/JTabbedPane/6670274/bug6670274.java
! test/javax/swing/JTable/6768387/bug6768387.java
! test/javax/swing/JTable/6788484/bug6788484.java
! test/javax/swing/JTable/6937798/bug6937798.java
! test/javax/swing/JTableHeader/6884066/bug6884066.java
! test/javax/swing/JTableHeader/6889007/bug6889007.java
! test/javax/swing/JTextArea/6925473/bug6925473.java
! test/javax/swing/JTextArea/6940863/bug6940863.java
! test/javax/swing/JViewport/6953396/bug6953396.java
! test/javax/swing/border/Test6910490.java
! test/javax/swing/plaf/synth/SynthToolBarUI/6739756/bug6739756.java
! test/javax/swing/text/WrappedPlainView/6857057/StubBranchElement.java
! test/javax/swing/text/WrappedPlainView/6857057/StubLeafElement.java
! test/javax/swing/text/WrappedPlainView/6857057/bug6857057.java
! test/sun/security/krb5/MicroTime.java

Changeset: 448387146bb8
Author:    yhuang
Date:      2010-09-09 23:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/448387146bb8

6980510: Fix for 6959252 broke JConsole mnemonic keys
Reviewed-by: mfang, yhuang

! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java

Changeset: 9a1549d682ce
Author:    yhuang
Date:      2010-09-09 23:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9a1549d682ce

Merge


Changeset: 4aaac9fb2293
Author:    yhuang
Date:      2010-09-13 02:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4aaac9fb2293

Merge


Changeset: 176586cd040e
Author:    kamg
Date:      2010-09-13 13:10 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/176586cd040e

6983225: libjvm_db.so is not imported into solaris-x86 builds, and libjvm_dtrace.so not imported at all.
Summary: Removed sparc-only libjvm_db code and added rules for libjvm_dtrace
Reviewed-by: ohair

! make/java/redist/Makefile

Changeset: fb63a2688db8
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fb63a2688db8

Added tag jdk7-b110 for changeset 176586cd040e

! .hgtags

Changeset: c2cdc8c94b65
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2cdc8c94b65

Added tag jdk7-b111 for changeset fb63a2688db8

! .hgtags

Changeset: d4012b86a6e9
Author:    bae
Date:      2010-09-07 16:54 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d4012b86a6e9

6972495: javax/imageio/CachePremissionsTest/CachePermissionsTest.java failed
Reviewed-by: prr

! test/javax/imageio/CachePremissionsTest/CachePermissionsTest.java

Changeset: fd7eb86ac690
Author:    bae
Date:      2010-09-09 16:20 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd7eb86ac690

6523398: OSS CMM: Need to implement writing ICC profile tags in new lcms library
Reviewed-by: igor, prr

! make/sun/cmm/lcms/FILES_c_unix.gmk
! make/sun/cmm/lcms/FILES_c_windows.gmk
! make/sun/cmm/lcms/Makefile
! src/share/classes/sun/java2d/cmm/CMSManager.java
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
! src/share/native/sun/java2d/cmm/lcms/LCMS.c
! src/share/native/sun/java2d/cmm/lcms/cmscam02.c
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
! src/share/native/sun/java2d/cmm/lcms/cmscgats.c
! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c
! src/share/native/sun/java2d/cmm/lcms/cmserr.c
! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c
! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c
! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c
! src/share/native/sun/java2d/cmm/lcms/cmsio0.c
! src/share/native/sun/java2d/cmm/lcms/cmsio1.c
! src/share/native/sun/java2d/cmm/lcms/cmslut.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
+ src/share/native/sun/java2d/cmm/lcms/cmsmd5.c
! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c
! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c
+ src/share/native/sun/java2d/cmm/lcms/cmsopt.c
! src/share/native/sun/java2d/cmm/lcms/cmspack.c
! src/share/native/sun/java2d/cmm/lcms/cmspcs.c
+ src/share/native/sun/java2d/cmm/lcms/cmsplugin.c
! src/share/native/sun/java2d/cmm/lcms/cmsps2.c
! src/share/native/sun/java2d/cmm/lcms/cmssamp.c
+ src/share/native/sun/java2d/cmm/lcms/cmssm.c
+ src/share/native/sun/java2d/cmm/lcms/cmstypes.c
! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c
! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c
! src/share/native/sun/java2d/cmm/lcms/cmsxform.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
+ src/share/native/sun/java2d/cmm/lcms/lcms2.h
+ src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h
+ src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h

Changeset: abe6a61835cb
Author:    lana
Date:      2010-09-16 11:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abe6a61835cb

Merge

- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h

Changeset: 7e26538596be
Author:    art
Date:      2010-08-24 12:54 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e26538596be

6949936: Provide API for running nested events loops, similar to what modal dialogs do
Reviewed-by: ant, anthony

! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/EventQueue.java
+ src/share/classes/java/awt/SecondaryLoop.java
+ src/share/classes/java/awt/WaitDispatchSupport.java
+ test/java/awt/EventQueue/SecondaryLoopTest/SecondaryLoopTest.java

Changeset: d3fdf9e7e9c2
Author:    dav
Date:      2010-08-31 15:05 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3fdf9e7e9c2

6480547: REG: bug 4118621 which got Integrated in 1.1.8 fails in mustang from b25 onwards.
6808185: test/closed/java/awt/Menu/NullMenuLabelTest crashes
Reviewed-by: dcherepanov

! src/windows/native/sun/windows/awt_MenuItem.cpp
! src/windows/native/sun/windows/awt_TextComponent.h
! src/windows/native/sun/windows/awt_TextField.cpp
! src/windows/native/sun/windows/awt_TextField.h
+ test/java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java
! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.java
! test/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java

Changeset: 7f8a9157544a
Author:    lana
Date:      2010-09-02 12:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7f8a9157544a

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: c12a03da538b
Author:    ant
Date:      2010-09-03 11:08 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c12a03da538b

6867293: switching TAB in a browser doesn't deactivate EmbeddedFrame
Reviewed-by: dcherepanov, art

! src/windows/native/sun/windows/awt_Window.h

Changeset: 252af007f819
Author:    lana
Date:      2010-09-16 11:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/252af007f819

Merge


Changeset: 48070a2633a1
Author:    naoto
Date:      2010-08-31 11:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/48070a2633a1

4700857: RFE: separating user locale and user interface locale
Reviewed-by: okutsu

! src/share/classes/java/text/DateFormat.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/text/MessageFormat.java
! src/share/classes/java/text/NumberFormat.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/TimeZone.java
! src/share/native/java/lang/System.c
! src/share/native/java/lang/java_props.h
! src/solaris/native/java/lang/java_props_md.c
! src/windows/native/java/lang/java_props_md.c
! src/windows/native/sun/windows/awt_DataTransferer.cpp
! src/windows/native/sun/windows/awt_InputMethod.cpp
! test/java/util/Formatter/Constructors.java
+ test/java/util/Locale/LocaleCategory.sh
! test/java/util/Locale/PrintDefaultLocale.java
! test/java/util/Locale/data/deflocale.c
+ test/java/util/Locale/data/deflocale.input
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
+ test/java/util/Locale/data/deflocale.rhel5
+ test/java/util/Locale/data/deflocale.rhel5.fmtasdefault
! test/java/util/Locale/data/deflocale.sh
! test/java/util/Locale/data/deflocale.sol10
+ test/java/util/Locale/data/deflocale.sol10.fmtasdefault
+ test/java/util/Locale/data/deflocale.win7
+ test/java/util/Locale/data/deflocale.win7.fmtasdefault
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp

Changeset: 3b64274e3cda
Author:    naoto
Date:      2010-08-31 23:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b64274e3cda

6981466: Adding missing test LocaleCategory.java
Reviewed-by: okutsu

+ test/java/util/Locale/LocaleCategory.java

Changeset: de0f18fe09e7
Author:    okutsu
Date:      2010-09-01 15:19 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de0f18fe09e7

4267450: (cal) API: Need public API to calculate, format and parse "year of week"
6549953: (cal) WEEK_OF_YEAR and DAY_OF_YEAR calculation problems around Gregorian cutover
Reviewed-by: peytoia

! make/java/text/base/FILES_java.gmk
+ src/share/classes/java/text/CalendarBuilder.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/GregorianCalendar.java
+ test/java/text/Format/DateFormat/WeekDateTest.java
+ test/java/util/Calendar/WeekDateTest.java

Changeset: 513a9ae0bbdd
Author:    okutsu
Date:      2010-09-02 10:52 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/513a9ae0bbdd

Merge


Changeset: 8af4eca2e2be
Author:    lana
Date:      2010-09-01 16:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8af4eca2e2be

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: 7b92a8ecece2
Author:    lana
Date:      2010-09-02 00:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7b92a8ecece2

Merge


Changeset: b83701dcae1e
Author:    naoto
Date:      2010-09-02 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b83701dcae1e

6981759: copyright header fix for test/java/util/Locale/LocaleCategory.java
Reviewed-by: okutsu

! test/java/util/Locale/LocaleCategory.java

Changeset: 93d13ea00faf
Author:    naoto
Date:      2010-09-02 11:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93d13ea00faf

6930062: Need to remove or build as part of the test file jdk/test/java/util/Locale/data/deflocale.exe
Reviewed-by: okutsu

- test/java/util/Locale/data/deflocale.exe

Changeset: c47eb064d6ba
Author:    okutsu
Date:      2010-09-09 15:37 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c47eb064d6ba

4919632: RFE: SimpleDateFormat should fully support ISO8601 standard for timezone
Reviewed-by: peytoia

! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/SimpleDateFormat.java
+ test/java/text/Format/DateFormat/ISO8601ZoneTest.java

Changeset: 4f1eacca4e6b
Author:    peytoia
Date:      2010-09-10 17:22 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4f1eacca4e6b

6983724: redundant @exception description for Character.Subset(String name)
Reviewed-by: okutsu

! src/share/classes/java/lang/Character.java

Changeset: afae9229e4a7
Author:    okutsu
Date:      2010-09-10 17:51 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/afae9229e4a7

6912560: Timezone is not set correctly on Win Vista when Security manager is present.
6941137: DST broken in 6u18 when jre/lib/zi is moved elsewhere and replaced with symlink.
Reviewed-by: peytoia

! src/share/classes/sun/util/calendar/ZoneInfoFile.java
+ test/java/util/TimeZone/Bug6912560.java

Changeset: 4fea9ea1661d
Author:    malenkov
Date:      2010-09-10 20:48 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4fea9ea1661d

6915566: Closed swing tests failing with assert errors when run with -ea -esa
Reviewed-by: art, peterz

! src/share/classes/com/sun/java/swing/SwingUtilities3.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java
! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java

Changeset: ee4d92fb6df3
Author:    naoto
Date:      2010-09-10 15:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ee4d92fb6df3

6875847: Java Locale Enhancement
Reviewed-by: srl
Contributed-by: Yoshito Umaoka <y.umaoka at gmail.com>, Doug Felt <dougfelt at google.com>, Mark Davis <markdavis at google.com>

! make/java/java/FILES_java.gmk
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/util/Calendar.java
+ src/share/classes/java/util/IllformedLocaleException.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/spi/LocaleNameProvider.java
! src/share/classes/java/util/spi/LocaleServiceProvider.java
! src/share/classes/sun/util/LocaleServiceProviderPool.java
+ src/share/classes/sun/util/locale/AsciiUtil.java
+ src/share/classes/sun/util/locale/BaseLocale.java
+ src/share/classes/sun/util/locale/Extension.java
+ src/share/classes/sun/util/locale/InternalLocaleBuilder.java
+ src/share/classes/sun/util/locale/LanguageTag.java
+ src/share/classes/sun/util/locale/LocaleExtensions.java
+ src/share/classes/sun/util/locale/LocaleObjectCache.java
+ src/share/classes/sun/util/locale/LocaleSyntaxException.java
+ src/share/classes/sun/util/locale/ParseStatus.java
+ src/share/classes/sun/util/locale/StringTokenIterator.java
+ src/share/classes/sun/util/locale/UnicodeLocaleExtension.java
! src/share/classes/sun/util/resources/LocaleData.java
! src/share/classes/sun/util/resources/LocaleNames.properties
! src/share/classes/sun/util/resources/LocaleNames_zh.properties
! src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties
+ test/java/util/Locale/LocaleEnhanceTest.java
! test/java/util/Locale/LocaleTestFmwk.java
+ test/java/util/Locale/icuLocales.txt
+ test/java/util/Locale/serialized/java6locale_ROOT
+ test/java/util/Locale/serialized/java6locale__US
+ test/java/util/Locale/serialized/java6locale___Java
+ test/java/util/Locale/serialized/java6locale_en
+ test/java/util/Locale/serialized/java6locale_en_US
+ test/java/util/Locale/serialized/java6locale_en_US_Java
+ test/java/util/Locale/serialized/java6locale_iw_IL
+ test/java/util/Locale/serialized/java6locale_ja_JP_JP
+ test/java/util/Locale/serialized/java6locale_no_NO_NY
+ test/java/util/Locale/serialized/java6locale_th_TH_TH

Changeset: 903f44341e34
Author:    kalli
Date:      2010-09-13 15:12 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/903f44341e34

6941027: Gervill update, April 2010
Reviewed-by: amenkov

! src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java
! src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java
! src/share/classes/com/sun/media/sound/ModelInstrument.java
+ src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/SoftChannel.java
! src/share/classes/com/sun/media/sound/SoftSynthesizer.java
! src/share/classes/com/sun/media/sound/SoftVoice.java
+ test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java
+ test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java
+ test/javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java

Changeset: 3fa6114faa54
Author:    kalli
Date:      2010-09-13 15:34 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3fa6114faa54

6943053: Gervill: failures on invalid ranges and 14-bit banks
Summary: ModelStandardIndexedDirector fails on invalid ranges. Program changes with 14-bit banks where handled incorectly as 7-bit banks.
Reviewed-by: amenkov

! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/SoftChannel.java
+ test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java
+ test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java

Changeset: c610f475558d
Author:    okutsu
Date:      2010-09-14 16:47 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c610f475558d

6984418: (cal) GregorianCalendar.setWeekDate doesn't check parameter consistency in non-lenient
Reviewed-by: peytoia

! src/share/classes/java/util/GregorianCalendar.java
! test/java/util/Calendar/WeekDateTest.java

Changeset: 7fe3d0fd99b8
Author:    amenkov
Date:      2010-09-14 12:38 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fe3d0fd99b8

6944033: RFE: add PCM_FLOAT support
Reviewed-by: dav

! src/share/classes/com/sun/media/sound/AudioFloatConverter.java
! src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
! src/share/classes/com/sun/media/sound/DLSSoundbank.java
! src/share/classes/com/sun/media/sound/SoftMixingMixer.java
! src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java
! src/share/classes/com/sun/media/sound/WaveFloatFileReader.java
! src/share/classes/com/sun/media/sound/WaveFloatFileWriter.java
! src/share/classes/javax/sound/sampled/AudioFormat.java
+ test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java

Changeset: c3c28ce45273
Author:    amenkov
Date:      2010-09-14 14:07 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c3c28ce45273

4937708: AudioFormat.matches should allow NOT_SPECIFY in all fields
Reviewed-by: denis

! src/share/classes/javax/sound/sampled/AudioFormat.java
+ test/javax/sound/sampled/AudioFormat/Matches_NOT_SPECIFIED.java

Changeset: 167a6a4634f5
Author:    amenkov
Date:      2010-09-14 14:09 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/167a6a4634f5

Merge

! src/share/classes/javax/sound/sampled/AudioFormat.java

Changeset: 82e98a8dccec
Author:    amenkov
Date:      2010-09-14 14:14 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/82e98a8dccec

4933700: RFE: Add way to get device from Receiver and Transmitter
Reviewed-by: art

! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java
- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
+ src/share/classes/com/sun/media/sound/MidiDeviceReceiverEnvelope.java
+ src/share/classes/com/sun/media/sound/MidiDeviceTransmitterEnvelope.java
! src/share/classes/com/sun/media/sound/SoftReceiver.java
! src/share/classes/javax/sound/midi/MidiDevice.java
+ src/share/classes/javax/sound/midi/MidiDeviceReceiver.java
+ src/share/classes/javax/sound/midi/MidiDeviceTransmitter.java
! src/share/classes/javax/sound/midi/MidiSystem.java
+ test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java

Changeset: bb733c150f94
Author:    omajid
Date:      2010-09-14 10:45 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bb733c150f94

6979979: Rounding error in font sizes selected by the GTK Look and Feel
Summary: Use floating point font sizes
Reviewed-by: prr

! src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java
! src/share/classes/sun/font/FontUtilities.java

Changeset: 7fc59f27318c
Author:    malenkov
Date:      2010-09-14 19:12 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fc59f27318c

6978482: MetalBorders.ToolBarBorder should specify that its getBorderInsets impl accepts only JToolBar inst
Reviewed-by: alexp

! src/share/classes/com/sun/java/swing/plaf/motif/MotifBorders.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsBorders.java
! src/share/classes/javax/swing/plaf/basic/BasicBorders.java
! src/share/classes/javax/swing/plaf/metal/MetalBorders.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java
+ test/javax/swing/border/Test6978482.java

Changeset: 2ffd71748740
Author:    malenkov
Date:      2010-09-14 21:22 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2ffd71748740

6635395: javax.swing.JDialog constructors should specify IAE throwing if invalid owners passed
Reviewed-by: alexp

! src/share/classes/javax/swing/JDialog.java

Changeset: 49650448c3c7
Author:    malenkov
Date:      2010-09-14 22:05 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49650448c3c7

6977726: JColorChooser.getPreviewPanel() returnes null starting from jdk7 b105.
Reviewed-by: alexp

! src/share/classes/javax/swing/JColorChooser.java
! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java
+ test/javax/swing/JColorChooser/Test6977726.html
+ test/javax/swing/JColorChooser/Test6977726.java

Changeset: bf89c7fc48fd
Author:    malenkov
Date:      2010-09-16 09:07 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf89c7fc48fd

6741392: libmawt.so crash at Java_com_sun_java_swing_plaf_gtk_GTKEngine_nativeFinishPainting+0x4f
Reviewed-by: peterz

! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/awt/swing_GTKEngine.c

Changeset: 21562f873588
Author:    lana
Date:      2010-09-16 11:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/21562f873588

Merge

- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp

Changeset: 61f1bbd49a5e
Author:    lana
Date:      2010-09-16 11:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/61f1bbd49a5e

Merge

- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/tools/launcher/VerifyExceptions.java

Changeset: b53f226b1d91
Author:    lana
Date:      2010-09-24 16:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b53f226b1d91

Merge

- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp
- test/tools/launcher/VerifyExceptions.java

Changeset: 4b0fdb9f7cfe
Author:    lana
Date:      2010-09-25 12:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4b0fdb9f7cfe

Merge

! make/java/java/FILES_java.gmk
- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
! src/share/native/java/lang/System.c
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp



From lana.steuck at oracle.com  Sun Sep 26 06:49:41 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 26 Sep 2010 06:49:41 +0000
Subject: hg: jdk7/tl/langtools: 10 new changesets
Message-ID: <20100926065000.9B99047C54@hg.openjdk.java.net>

Changeset: f4d91b4f7153
Author:    cl
Date:      2010-09-03 12:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f4d91b4f7153

Added tag jdk7-b108 for changeset a408ebb8b3d4

! .hgtags

Changeset: 4826378eaade
Author:    cl
Date:      2010-09-09 13:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4826378eaade

Merge


Changeset: 1c13c5ea73b5
Author:    cl
Date:      2010-09-09 15:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1c13c5ea73b5

Added tag jdk7-b109 for changeset 4826378eaade

! .hgtags

Changeset: b599cc9a9c22
Author:    ohair
Date:      2010-09-09 16:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b599cc9a9c22

6982137: Rebranding pass 2 - missed copyright changes
Reviewed-by: mbykov

! test/tools/javac/generics/inference/6938454/T6938454a.java
! test/tools/javac/generics/inference/6938454/T6938454b.java

Changeset: 32da0f38d2fe
Author:    cl
Date:      2010-09-15 13:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/32da0f38d2fe

Merge


Changeset: 8bec624274ef
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8bec624274ef

Added tag jdk7-b110 for changeset 32da0f38d2fe

! .hgtags

Changeset: 7ad86852c38a
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7ad86852c38a

Added tag jdk7-b111 for changeset 8bec624274ef

! .hgtags

Changeset: c5df455918c4
Author:    lana
Date:      2010-09-16 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c5df455918c4

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/tree/TreeScannerTest.java

Changeset: fd2579b80b83
Author:    lana
Date:      2010-09-24 16:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fd2579b80b83

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/tree/TreeScannerTest.java

Changeset: 827d87221959
Author:    lana
Date:      2010-09-25 12:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/827d87221959

Merge




From Alan.Bateman at oracle.com  Mon Sep 27 15:33:48 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Sep 2010 16:33:48 +0100
Subject: Code Review Request for 6977738
In-Reply-To: <4C92A899.8000407@oracle.com>
References: <4C92A899.8000407@oracle.com>
Message-ID: <4CA0B95C.7020708@oracle.com>

Mandy Chung wrote:
>
>
> Fix 6977738: Deadlock between java.lang.ClassLoader and 
> java.util.Properties
>
> Webrev at:
>    http://cr.openjdk.java.net/~mchung/6977738/webrev.00/
>
> ClassLoader.getResource locking the system properties object is
> deadlock prone. For example, the 
> sun.misc.Launcher.getBootstrapClassPath()
> method is a synchronized method. A thread calling
> ClassLoader.getResource method attempts to synchronize on
> the system properties object while holding sun.misc.Launcher.class.
> It will deadlock if there is another thread is holding the monitor
> lock of the system properties object (e.g. calls the Properties.save()
> method) while it attempts to load a resource file.  In addition,
> ClassLoader.getResource may invoke the ZipFile initialization that
> also needs to get the system property.
>
> This fix caches the system properties at initialization so that
> the ZipFile and Launcher will read the system property from the
> private Properties object.  In addition, I make some minor
> changes in Properties.save and storeToXML method to confine the
> synchronization needed and also have the DownloadManager to
> maintain its bootclasspath.
>
> Thanks
> Mandy
>
I don't know if you are still looking for a reviewer for this one. I 
agree with David's comment that it is rather complicated.

I wonder if we better to add VM.saveSystemProperties rather than having 
VM.booted do it as a side effect. The saveSystemProperties method could 
throw IllegalStateException if booted, to catch any mis-use after VM 
initialization. It could also filter out and remove properties that 
shouldn't be visible to applications, like sun.nio.MaxDirectMemorySize 
(on that property, you could change the maxDirectMemory method so that 
it doesn't need to use setProperties and could get you back the cost of 
saving the properties).  Also, on this, VM.getSystemProperty probably 
needs a better name, maybe getSavedSystemProperty, to make it clear that 
it's not the same as System.getProperty. On that, do we have any cases 
where it will be invoked after initialization has completed? I'm just 
wondering if it needs a privileged block as these have been removed from 
the callers.

In passing, I see that make/java/java/FILES_java.gmk has sun.net.www 
classes listed in the middle of the sun.misc list. It might be good to 
re-order these while you are there.

Not wishing to add to your load, but I see XMLUtils.save is using raw 
types and maybe it could be updated while you are there (if you have 
time of course).

Typo in DownloadManager at L667 -> "How" instead of "Now".

-Alan.




From i30817 at gmail.com  Mon Sep 27 18:23:13 2010
From: i30817 at gmail.com (Paulo Levi)
Date: Mon, 27 Sep 2010 19:23:13 +0100
Subject: Swingworker do in background method does not caught and print
	exceptions?
Message-ID: <AANLkTimmEPaqmm1eaoBLgTPFFa690P6U2vTMCWAmOZHa@mail.gmail.com>

In in linux 64 bits.
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9) (6b20-1.9-0ubuntu1)
OpenJDK 64-Bit Server VM (build 17.0-b16, mixed mode)
from ubuntu repositories.

A very simple swingworker started from the EDT:

        new SwingWorker<Object, Object>() {

            @Override
            protected Object doInBackground() throws Exception {
                System.out.println("SW Ran");
                throw new NullPointerException();
            }
        }.run();
Only prints SW Ran.
It's surprising this was not noticed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100927/4d21c9d3/attachment.html>

From mandy.chung at oracle.com  Mon Sep 27 18:59:16 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 27 Sep 2010 11:59:16 -0700
Subject: Code Review Request for 6977738
In-Reply-To: <4CA0B95C.7020708@oracle.com>
References: <4C92A899.8000407@oracle.com> <4CA0B95C.7020708@oracle.com>
Message-ID: <4CA0E984.5060506@oracle.com>

  Hi Alan,

On 09/27/10 08:33, Alan Bateman wrote:
>
> I don't know if you are still looking for a reviewer for this one. I 
> agree with David's comment that it is rather complicated.
>

Thanks for reviewing it.  Yes,  I still need a reviewer for this fix.

> I wonder if we better to add VM.saveSystemProperties rather than 
> having VM.booted do it as a side effect. The saveSystemProperties 
> method could throw IllegalStateException if booted, to catch any 
> mis-use after VM initialization. It could also filter out and remove 
> properties that shouldn't be visible to applications, like 
> sun.nio.MaxDirectMemorySize (on that property, you could change the 
> maxDirectMemory method so that it doesn't need to use setProperties 
> and could get you back the cost of saving the properties). 

I agree that it's better to add a method to save the system properties 
during initialization and make it explicit.   I'll update the fix and 
send out the new webrev.


> Also, on this, VM.getSystemProperty probably needs a better name, 
> maybe getSavedSystemProperty, to make it clear that it's not the same 
> as System.getProperty. On that, do we have any cases where it will be 
> invoked after initialization has completed? I'm just wondering if it 
> needs a privileged block as these have been removed from the callers.
>

Properties.getProperty doesn't have permission check and thus there is 
no need for a privileged block for this method.  Will think about the 
method name getSavedSystemProperty will work, or maybe 
getSystemPropertyWithNoLock?

> In passing, I see that make/java/java/FILES_java.gmk has sun.net.www 
> classes listed in the middle of the sun.misc list. It might be good to 
> re-order these while you are there.
>
> Not wishing to add to your load, but I see XMLUtils.save is using raw 
> types and maybe it could be updated while you are there (if you have 
> time of course).
>
> Typo in DownloadManager at L667 -> "How" instead of "Now".
>

I can clean up the above you mention.

Mandy




From jonathan.gibbons at oracle.com  Mon Sep 27 21:06:01 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 27 Sep 2010 21:06:01 +0000
Subject: hg: jdk7/tl/langtools: 6890226: javah -version is broken
Message-ID: <20100927210607.40C3747CAC@hg.openjdk.java.net>

Changeset: f6fe12839a8a
Author:    jjg
Date:      2010-09-27 14:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f6fe12839a8a

6890226: javah -version is broken
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javah/JavahTask.java
! src/share/classes/com/sun/tools/javah/resources/l10n.properties
+ src/share/classes/com/sun/tools/javah/resources/version.properties-template
+ test/tools/javah/VersionTest.java



From jonathan.gibbons at oracle.com  Mon Sep 27 21:20:52 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 27 Sep 2010 21:20:52 +0000
Subject: hg: jdk7/tl/langtools: 6877202: Elements.getDocComment() is not
	getting JavaDocComments; ...
Message-ID: <20100927212054.A923847CAE@hg.openjdk.java.net>

Changeset: 3c9b64e55c5d
Author:    jjg
Date:      2010-09-27 14:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3c9b64e55c5d

6877202: Elements.getDocComment() is not getting JavaDocComments
6861094: javac -Xprint <file> does not print comments
6985205: access to tree positions and doc comments may be lost across annotation processing rounds
Reviewed-by: darcy

! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
+ src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java
! src/share/classes/com/sun/tools/javadoc/JavadocTool.java
! test/tools/javac/6302184/T6302184.out
! test/tools/javac/6304921/TestLog.java
! test/tools/javac/api/TestJavacTaskScanner.java
- test/tools/javac/processing/Xprint.java
+ test/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java
+ test/tools/javac/processing/model/util/elements/doccomments/a/First.java
+ test/tools/javac/processing/model/util/elements/doccomments/z/Last.java
+ test/tools/javac/processing/options/Xprint.java
+ test/tools/javac/processing/options/XprintDocComments.java
+ test/tools/javac/processing/options/XprintDocComments.out
+ test/tools/javac/tree/TreePosRoundsTest.java



From lance.andersen at oracle.com  Mon Sep 27 22:05:53 2010
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Mon, 27 Sep 2010 22:05:53 +0000
Subject: hg: jdk7/tl/jdk: 6987638: javadoc update to RowSetProvider and
	Statement
Message-ID: <20100927220619.BDCDF47CB0@hg.openjdk.java.net>

Changeset: 7b2b0131fa61
Author:    lancea
Date:      2010-09-27 18:05 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7b2b0131fa61

6987638: javadoc update to RowSetProvider and Statement
Reviewed-by: darcy, alanb

! src/share/classes/java/sql/Statement.java
! src/share/classes/javax/sql/rowset/RowSetProvider.java



From David.Holmes at oracle.com  Mon Sep 27 22:26:38 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 28 Sep 2010 08:26:38 +1000
Subject: Swingworker do in background method does not caught and print
	exceptions?
In-Reply-To: <AANLkTimmEPaqmm1eaoBLgTPFFa690P6U2vTMCWAmOZHa@mail.gmail.com>
References: <AANLkTimmEPaqmm1eaoBLgTPFFa690P6U2vTMCWAmOZHa@mail.gmail.com>
Message-ID: <4CA11A1E.80205@oracle.com>

Paulo,

Paulo Levi said the following on 09/28/10 04:23:
> In in linux 64 bits.
> java version "1.6.0_20"
> OpenJDK Runtime Environment (IcedTea6 1.9) (6b20-1.9-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 17.0-b16, mixed mode)
> from ubuntu repositories.
> 
> A very simple swingworker started from the EDT:
> 
>         new SwingWorker<Object, Object>() {
> 
>             @Override
>             protected Object doInBackground() throws Exception {
>                 System.out.println("SW Ran");
>                 throw new NullPointerException();
>             }
>         }.run();
> Only prints SW Ran.
> It's surprising this was not noticed.

SwingWorker is a RunnableFuture. The exception will be caught and stored 
for retrieval via the Future methods. Trying add a get() to the above 
and it will throw the ExecutionException:

Exception in thread "main" java.util.concurrent.ExecutionException: 
java.lang.NullPointerException
         at 
java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
         at java.util.concurrent.FutureTask.get(FutureTask.java:111)
         at javax.swing.SwingWorker.get(SwingWorker.java:601)
         at SW.main(SW.java:16)
Caused by: java.lang.NullPointerException
         at SW$1.doInBackground(SW.java:11)
         at javax.swing.SwingWorker$1.call(SwingWorker.java:296)
         at 
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
         at java.util.concurrent.FutureTask.run(FutureTask.java:166)
         at javax.swing.SwingWorker.run(SwingWorker.java:335)
         at SW.main(SW.java:14)

David Holmes


From jonathan.gibbons at oracle.com  Tue Sep 28 00:29:37 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 28 Sep 2010 00:29:37 +0000
Subject: hg: jdk7/tl/langtools: 6986246: Trees object is round-specific
Message-ID: <20100928002939.D161E47CB6@hg.openjdk.java.net>

Changeset: d4df3b6ee729
Author:    jjg
Date:      2010-09-27 17:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d4df3b6ee729

6986246: Trees object is round-specific
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! test/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java
! test/tools/javac/tree/TreePosRoundsTest.java



From michael.x.mcmahon at oracle.com  Tue Sep 28 11:04:59 2010
From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com)
Date: Tue, 28 Sep 2010 11:04:59 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100928110522.66FBF47CD6@hg.openjdk.java.net>

Changeset: b3a4add96d45
Author:    michaelm
Date:      2010-09-28 11:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b3a4add96d45

6550798: Using InputStream.skip with ResponseCache will cause partial data to be cached
Reviewed-by: chegar

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/protocol/http/6550798/TestCache.java
+ test/sun/net/www/protocol/http/6550798/test.java

Changeset: 4b637d890b6c
Author:    michaelm
Date:      2010-09-28 12:04 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4b637d890b6c

Merge




From michael.x.mcmahon at oracle.com  Tue Sep 28 13:37:05 2010
From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com)
Date: Tue, 28 Sep 2010 13:37:05 +0000
Subject: hg: jdk7/tl/jdk: 6987927: can't use -Dfile.encoding=Cp037 in net test
Message-ID: <20100928133715.0020847CDD@hg.openjdk.java.net>

Changeset: a43232b264cb
Author:    michaelm
Date:      2010-09-28 14:36 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a43232b264cb

6987927: can't use -Dfile.encoding=Cp037 in net test
Reviewed-by: chegar

- test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh



From sundararajan.a at sun.com  Tue Sep 28 17:18:37 2010
From: sundararajan.a at sun.com (sundararajan.a at sun.com)
Date: Tue, 28 Sep 2010 17:18:37 +0000
Subject: hg: jdk7/tl/langtools: 6967842: Element not returned from tree API
	for ARM resource variables.
Message-ID: <20100928171840.2E6D247CE6@hg.openjdk.java.net>

Changeset: 28b021bb889f
Author:    sundar
Date:      2010-09-28 22:46 +0530
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/28b021bb889f

6967842: Element not returned from tree API for ARM resource variables.
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/processing/model/element/TestResourceElement.java
! test/tools/javac/processing/model/element/TestResourceVariable.java



From weijun.wang at sun.com  Wed Sep 29 07:28:14 2010
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Wed, 29 Sep 2010 07:28:14 +0000
Subject: hg: jdk7/tl/jdk: 6988163: sun.security.util.Resources dup and a
	keytool doc typo
Message-ID: <20100929072824.3171047D12@hg.openjdk.java.net>

Changeset: 26c6ee936f63
Author:    weijun
Date:      2010-09-29 15:26 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/26c6ee936f63

6988163: sun.security.util.Resources dup and a keytool doc typo
Reviewed-by: xuelei

! src/share/classes/sun/security/tools/KeyTool.java
! src/share/classes/sun/security/util/Resources.java



From Alan.Bateman at oracle.com  Wed Sep 29 12:25:35 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Sep 2010 13:25:35 +0100
Subject: 6988037: fileClose prints debug message if close fails
Message-ID: <4CA3303F.6060309@oracle.com>


I need a reviewer for a small change to remove a debug message that 
someone left when fixing a bug in the java.io implementation early in 
jdk7. The debug message is printed if closing a file fails (for example 
EIO because of a NFS stale handle).  That change also added code to 
restore the file descriptor field but this isn't needed because the 
stream classes have a closed flag to ensure that they only attempt to 
close the underlying file descriptor once. Furthermore, if close fails 
then the state of the file descriptor is unspecified and so cannot be 
used again. The proposed patch is attached.

Thanks,
Alan.

diff --git a/src/solaris/native/java/io/io_util_md.c 
b/src/solaris/native/java/io/io_util_md.c
--- a/src/solaris/native/java/io/io_util_md.c
+++ b/src/solaris/native/java/io/io_util_md.c
@@ -83,8 +83,6 @@ fileClose(JNIEnv *env, jobject this, jfi
             close(devnull);
         }
     } else if (JVM_Close(fd) == -1) {
-            SET_FD(this, fd, fid); // restore fd
-            printf("JVM_Close returned -1\n");
-            JNU_ThrowIOExceptionWithLastError(env, "close failed");
+        JNU_ThrowIOExceptionWithLastError(env, "close failed");
     }
 }
diff --git a/src/windows/native/java/io/io_util_md.c 
b/src/windows/native/java/io/io_util_md.c
--- a/src/windows/native/java/io/io_util_md.c
+++ b/src/windows/native/java/io/io_util_md.c
@@ -531,7 +531,6 @@ handleClose(JNIEnv *env, jobject this, j
     SET_FD(this, -1, fid);
 
     if (CloseHandle(h) == 0) { /* Returns zero on failure */
-        SET_FD(this, fd, fid); // restore fd
         JNU_ThrowIOExceptionWithLastError(env, "close failed");
     }
     return 0;



From forax at univ-mlv.fr  Wed Sep 29 14:05:24 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 29 Sep 2010 16:05:24 +0200
Subject: 6988037: fileClose prints debug message if close fails
In-Reply-To: <4CA3303F.6060309@oracle.com>
References: <4CA3303F.6060309@oracle.com>
Message-ID: <4CA347A4.3060905@univ-mlv.fr>

Looks good.

R?mi

Le 29/09/2010 14:25, Alan Bateman a ?crit :
>
> I need a reviewer for a small change to remove a debug message that 
> someone left when fixing a bug in the java.io implementation early in 
> jdk7. The debug message is printed if closing a file fails (for 
> example EIO because of a NFS stale handle).  That change also added 
> code to restore the file descriptor field but this isn't needed 
> because the stream classes have a closed flag to ensure that they only 
> attempt to close the underlying file descriptor once. Furthermore, if 
> close fails then the state of the file descriptor is unspecified and 
> so cannot be used again. The proposed patch is attached.
>
> Thanks,
> Alan.
>
> diff --git a/src/solaris/native/java/io/io_util_md.c 
> b/src/solaris/native/java/io/io_util_md.c
> --- a/src/solaris/native/java/io/io_util_md.c
> +++ b/src/solaris/native/java/io/io_util_md.c
> @@ -83,8 +83,6 @@ fileClose(JNIEnv *env, jobject this, jfi
>             close(devnull);
>         }
>     } else if (JVM_Close(fd) == -1) {
> -            SET_FD(this, fd, fid); // restore fd
> -            printf("JVM_Close returned -1\n");
> -            JNU_ThrowIOExceptionWithLastError(env, "close failed");
> +        JNU_ThrowIOExceptionWithLastError(env, "close failed");
>     }
> }
> diff --git a/src/windows/native/java/io/io_util_md.c 
> b/src/windows/native/java/io/io_util_md.c
> --- a/src/windows/native/java/io/io_util_md.c
> +++ b/src/windows/native/java/io/io_util_md.c
> @@ -531,7 +531,6 @@ handleClose(JNIEnv *env, jobject this, j
>     SET_FD(this, -1, fid);
>
>     if (CloseHandle(h) == 0) { /* Returns zero on failure */
> -        SET_FD(this, fd, fid); // restore fd
>         JNU_ThrowIOExceptionWithLastError(env, "close failed");
>     }
>     return 0;
>



From Alan.Bateman at oracle.com  Wed Sep 29 13:57:28 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Sep 2010 14:57:28 +0100
Subject: 6728842: File.setReadOnly does not make a directory read-only (win)
Message-ID: <4CA345C8.7070904@oracle.com>


I need a reviewer for a change to java.io.File's setReadOnly and 
setWritable methods so that they don't change the DOS readonly attribute 
on directories (or folders as Windows calls them). These methods have 
never worked correctly for directories on Windows because the semantics 
of this attribute is different for directories (it determines if the 
directory can be deleted, not whether is is writable, and is used by 
Windows Explorer to determine if the directory is special, sending it 
off looking for a hidden Desktop.ini file). Early on in jdk7, the 
canWrite method was changed to ignore the readonly attribute on 
directories so changing the set* methods to ignore the attribute  
restores the status quo. I should say that changing the implementation 
has some risk. If it does cause problems they we may need to include a 
compatibility switch. The alternative to ignoring the readonly attribute 
is to insert a deny rule into the directory's DACL (when on NTFS) but 
that has a lot of potential to cause problems for end-users. As part of 
the change proposed here, the SetAccess test has been changed so that it 
no longer execs "ls -l" and this fixes another bug (6464744) where the 
test fails if the sticky bit is set. The webrev with the changes is here:
  http://cr.openjdk.java.net/~alanb/6728842/webrev/

Thanks,
Alan.


From kevin.walls at oracle.com  Wed Sep 29 12:35:23 2010
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 29 Sep 2010 13:35:23 +0100
Subject: 6988037: fileClose prints debug message if close fails
In-Reply-To: <4CA3303F.6060309@oracle.com>
References: <4CA3303F.6060309@oracle.com>
Message-ID: <4CA3328B.4050509@oracle.com>


Hi Alan,

That sounds familiar and looks good. (There has been some testing with 
such a change already 8-) )

Regards
Kevin

On 29/09/2010 13:25, Alan Bateman wrote:
>
> I need a reviewer for a small change to remove a debug message that 
> someone left when fixing a bug in the java.io implementation early in 
> jdk7. The debug message is printed if closing a file fails (for 
> example EIO because of a NFS stale handle).  That change also added 
> code to restore the file descriptor field but this isn't needed 
> because the stream classes have a closed flag to ensure that they only 
> attempt to close the underlying file descriptor once. Furthermore, if 
> close fails then the state of the file descriptor is unspecified and 
> so cannot be used again. The proposed patch is attached.
>
> Thanks,
> Alan.
>
> diff --git a/src/solaris/native/java/io/io_util_md.c 
> b/src/solaris/native/java/io/io_util_md.c
> --- a/src/solaris/native/java/io/io_util_md.c
> +++ b/src/solaris/native/java/io/io_util_md.c
> @@ -83,8 +83,6 @@ fileClose(JNIEnv *env, jobject this, jfi
>             close(devnull);
>         }
>     } else if (JVM_Close(fd) == -1) {
> -            SET_FD(this, fd, fid); // restore fd
> -            printf("JVM_Close returned -1\n");
> -            JNU_ThrowIOExceptionWithLastError(env, "close failed");
> +        JNU_ThrowIOExceptionWithLastError(env, "close failed");
>     }
> }
> diff --git a/src/windows/native/java/io/io_util_md.c 
> b/src/windows/native/java/io/io_util_md.c
> --- a/src/windows/native/java/io/io_util_md.c
> +++ b/src/windows/native/java/io/io_util_md.c
> @@ -531,7 +531,6 @@ handleClose(JNIEnv *env, jobject this, j
>     SET_FD(this, -1, fid);
>
>     if (CloseHandle(h) == 0) { /* Returns zero on failure */
> -        SET_FD(this, fd, fid); // restore fd
>         JNU_ThrowIOExceptionWithLastError(env, "close failed");
>     }
>     return 0;
>



From forax at univ-mlv.fr  Wed Sep 29 14:40:49 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 29 Sep 2010 16:40:49 +0200
Subject: 6728842: File.setReadOnly does not make a directory read-only
	(win)
In-Reply-To: <4CA345C8.7070904@oracle.com>
References: <4CA345C8.7070904@oracle.com>
Message-ID: <4CA34FF1.6070604@univ-mlv.fr>

Le 29/09/2010 15:57, Alan Bateman a ?crit :
>
> I need a reviewer for a change to java.io.File's setReadOnly and 
> setWritable methods so that they don't change the DOS readonly 
> attribute on directories (or folders as Windows calls them). These 
> methods have never worked correctly for directories on Windows because 
> the semantics of this attribute is different for directories (it 
> determines if the directory can be deleted, not whether is is 
> writable, and is used by Windows Explorer to determine if the 
> directory is special, sending it off looking for a hidden Desktop.ini 
> file). Early on in jdk7, the canWrite method was changed to ignore the 
> readonly attribute on directories so changing the set* methods to 
> ignore the attribute  restores the status quo. I should say that 
> changing the implementation has some risk. If it does cause problems 
> they we may need to include a compatibility switch. The alternative to 
> ignoring the readonly attribute is to insert a deny rule into the 
> directory's DACL (when on NTFS) but that has a lot of potential to 
> cause problems for end-users. As part of the change proposed here, the 
> SetAccess test has been changed so that it no longer execs "ls -l" and 
> this fixes another bug (6464744) where the test fails if the sticky 
> bit is set. The webrev with the changes is here:
>  http://cr.openjdk.java.net/~alanb/6728842/webrev/
>
> Thanks,
> Alan.

There is a small copy/paste error in setAccess.doTest() for Windows 
specific tests,
the exception message of the thrown Exception doesn't match the test.

                      // setWritable should fail on directories because the DOS readonly
  148                 // attribute prevents a directory from being deleted.
  149                 if (f.setWritable(false, true))
  150                     throw new Exception(f + ": setWritable(false, true) Succeeded");
  151                 if (f.setWritable(false, false))
  152                     throw new Exception(f + ": setWritable(false, true) Succeeded");
  153                 if (f.setWritable(false))
  154                     throw new Exception(f + ": setWritable(false, true) Succeeded");

should be

                      // setWritable should fail on directories because the DOS readonly
  148                 // attribute prevents a directory from being deleted.
  149                 if (f.setWritable(false, true))
  150                     throw new Exception(f + ": setWritable(false, true) Succeeded");
  151                 if (f.setWritable(false, false))
  152                     throw new Exception(f + ": setWritable(false, false) Succeeded");
  153                 if (f.setWritable(false))
  154                     throw new Exception(f + ": setWritable(false) Succeeded");

Other changes look fine.

R?mi



From Alan.Bateman at oracle.com  Wed Sep 29 15:48:44 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Sep 2010 16:48:44 +0100
Subject: 6728842: File.setReadOnly does not make a directory read-only
	(win)
In-Reply-To: <4CA34FF1.6070604@univ-mlv.fr>
References: <4CA345C8.7070904@oracle.com> <4CA34FF1.6070604@univ-mlv.fr>
Message-ID: <4CA35FDC.5050804@oracle.com>

R?mi Forax wrote:
> :
> There is a small copy/paste error in setAccess.doTest() for Windows 
> specific tests,
> the exception message of the thrown Exception doesn't match the test.
Well spotted! I'll fix up these messages in the test before I push this.

-Alan.


From mandy.chung at oracle.com  Wed Sep 29 19:43:15 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 29 Sep 2010 12:43:15 -0700
Subject: Code Review Request for 6977738
In-Reply-To: <4C92A899.8000407@oracle.com>
References: <4C92A899.8000407@oracle.com>
Message-ID: <4CA396D3.6030301@oracle.com>

  Alan, David,

I revise the fix including the following:
1. Use the lazy initialization holder class idiom to initialize the bcp
variable to simplify the synchronization.

2. Group the initialization of system properties in a new private method
System.initializeSystemProperties so that it can save a copy for internal
implementation use to address the deadlock issue and remove the
properties that are intended for private internal use from public access
before initializing the System.props.  This removes the 2 calls to
System.setProperties.

3. Reorder sun.net.* in FILES_java.gmk

The new webrev is at:
    http://cr.openjdk.java.net/~mchung/6977738/webrev.01/

Thanks
Mandy

On 09/16/10 16:30, Mandy Chung wrote:
>
>
> Fix 6977738: Deadlock between java.lang.ClassLoader and 
> java.util.Properties
>
> Webrev at:
>    http://cr.openjdk.java.net/~mchung/6977738/webrev.00/
>
> ClassLoader.getResource locking the system properties object is
> deadlock prone. For example, the 
> sun.misc.Launcher.getBootstrapClassPath()
> method is a synchronized method. A thread calling
> ClassLoader.getResource method attempts to synchronize on
> the system properties object while holding sun.misc.Launcher.class.
> It will deadlock if there is another thread is holding the monitor
> lock of the system properties object (e.g. calls the Properties.save()
> method) while it attempts to load a resource file.  In addition,
> ClassLoader.getResource may invoke the ZipFile initialization that
> also needs to get the system property.
>
> This fix caches the system properties at initialization so that
> the ZipFile and Launcher will read the system property from the
> private Properties object.  In addition, I make some minor
> changes in Properties.save and storeToXML method to confine the
> synchronization needed and also have the DownloadManager to
> maintain its bootclasspath.
>
> Thanks
> Mandy
>



From jonathan.gibbons at oracle.com  Wed Sep 29 21:02:37 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 29 Sep 2010 21:02:37 +0000
Subject: hg: jdk7/tl/langtools: 6502392: Invalid relative names for
	Filer.createResource and Filer.getResource
Message-ID: <20100929210239.49A0D47D32@hg.openjdk.java.net>

Changeset: f94af0667151
Author:    jjg
Date:      2010-09-29 14:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f94af0667151

6502392: Invalid relative names for Filer.createResource and Filer.getResource
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
+ test/tools/javac/processing/filer/TestInvalidRelativeNames.java



From joe.darcy at oracle.com  Thu Sep 30 06:28:48 2010
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 30 Sep 2010 06:28:48 +0000
Subject: hg: jdk7/tl/langtools: 6983738: Use a JavacTestingAbstractProcessor
Message-ID: <20100930062850.A7E4A47D4F@hg.openjdk.java.net>

Changeset: d2aaaec153e8
Author:    darcy
Date:      2010-09-29 23:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d2aaaec153e8

6983738: Use a JavacTestingAbstractProcessor
Reviewed-by: jjg

+ test/tools/javac/lib/JavacTestingAbstractProcessor.java
! test/tools/javac/processing/6348499/A.java
! test/tools/javac/processing/6348499/T6348499.java
! test/tools/javac/processing/6359313/T6359313.java
! test/tools/javac/processing/6365040/ProcBar.java
! test/tools/javac/processing/6365040/ProcFoo.java
! test/tools/javac/processing/6365040/T6365040.java
! test/tools/javac/processing/6413690/T6413690.java
! test/tools/javac/processing/6414633/A.java
! test/tools/javac/processing/6414633/T6414633.java
! test/tools/javac/processing/6430209/T6430209.java
! test/tools/javac/processing/6430209/b6341534.java
! test/tools/javac/processing/6499119/ClassProcessor.java
! test/tools/javac/processing/6511613/DummyProcessor.java
! test/tools/javac/processing/6511613/clss41701.java
! test/tools/javac/processing/6512707/T6512707.java
! test/tools/javac/processing/6634138/T6634138.java
! test/tools/javac/processing/T6439826.java
! test/tools/javac/processing/T6920317.java
! test/tools/javac/processing/environment/TestSourceVersion.java
! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java
! test/tools/javac/processing/errors/TestFatalityOfParseErrors.java
! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java
! test/tools/javac/processing/errors/TestReturnCode.java
! test/tools/javac/processing/filer/TestFilerConstraints.java
! test/tools/javac/processing/filer/TestGetResource.java
! test/tools/javac/processing/filer/TestGetResource2.java
! test/tools/javac/processing/filer/TestInvalidRelativeNames.java
! test/tools/javac/processing/filer/TestLastRound.java
! test/tools/javac/processing/filer/TestPackageInfo.java
! test/tools/javac/processing/messager/6362067/T6362067.java
! test/tools/javac/processing/messager/MessagerBasics.java
! test/tools/javac/processing/model/6194785/T6194785.java
! test/tools/javac/processing/model/6341534/T6341534.java
! test/tools/javac/processing/model/element/TestAnonClassNames.java
! test/tools/javac/processing/model/element/TestAnonSourceNames.java
! test/tools/javac/processing/model/element/TestElement.java
! test/tools/javac/processing/model/element/TestNames.java
! test/tools/javac/processing/model/element/TestPackageElement.java
! test/tools/javac/processing/model/element/TestResourceElement.java
! test/tools/javac/processing/model/element/TestResourceVariable.java
! test/tools/javac/processing/model/element/TypeParamBounds.java
! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java
! test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java
! test/tools/javac/processing/model/type/NoTypes.java
! test/tools/javac/processing/model/util/BinaryName.java
! test/tools/javac/processing/model/util/GetTypeElemBadArg.java
! test/tools/javac/processing/model/util/NoSupers.java
! test/tools/javac/processing/model/util/OverridesSpecEx.java
! test/tools/javac/processing/model/util/TypesBadArg.java
! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java
! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java
! test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java
! test/tools/javac/processing/model/util/elements/TestGetPackageOf.java
! test/tools/javac/processing/model/util/filter/TestIterables.java
! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java
! test/tools/javac/processing/werror/WError1.java
! test/tools/javac/processing/werror/WErrorGen.java
! test/tools/javac/processing/werror/WErrorLast.java



From chris.hegarty at oracle.com  Thu Sep 30 12:07:25 2010
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 30 Sep 2010 12:07:25 +0000
Subject: hg: jdk7/tl/jdk: 6987461: Handle leak when enabling
	java.net.useSystemProxies
Message-ID: <20100930120751.14E6847D61@hg.openjdk.java.net>

Changeset: 570f825ad872
Author:    chegar
Date:      2010-09-29 17:33 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/570f825ad872

6987461: Handle leak when enabling java.net.useSystemProxies
Summary: Release the registry key handle if ProxyEnable is 0
Reviewed-by: michaelm

! src/windows/native/sun/net/spi/DefaultProxySelector.c



From alan.bateman at oracle.com  Thu Sep 30 13:50:03 2010
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 30 Sep 2010 13:50:03 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100930135027.D6EC447D65@hg.openjdk.java.net>

Changeset: 04d9b09dbef9
Author:    alanb
Date:      2010-09-30 14:48 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/04d9b09dbef9

6988037: fileClose prints debug message is close fails
Reviewed-by: kevinw, forax

! src/solaris/native/java/io/io_util_md.c
! src/windows/native/java/io/io_util_md.c

Changeset: 1fe397df4aaa
Author:    alanb
Date:      2010-09-30 14:49 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1fe397df4aaa

Merge

- test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh



From Alan.Bateman at oracle.com  Thu Sep 30 14:18:55 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Sep 2010 15:18:55 +0100
Subject: Code Review Request for 6977738
In-Reply-To: <4CA396D3.6030301@oracle.com>
References: <4C92A899.8000407@oracle.com> <4CA396D3.6030301@oracle.com>
Message-ID: <4CA49C4F.6090906@oracle.com>

Mandy Chung wrote:
>  Alan, David,
>
> I revise the fix including the following:
> 1. Use the lazy initialization holder class idiom to initialize the bcp
> variable to simplify the synchronization.
>
> 2. Group the initialization of system properties in a new private method
> System.initializeSystemProperties so that it can save a copy for internal
> implementation use to address the deadlock issue and remove the
> properties that are intended for private internal use from public access
> before initializing the System.props.  This removes the 2 calls to
> System.setProperties.
>
> 3. Reorder sun.net.* in FILES_java.gmk
>
> The new webrev is at:
>    http://cr.openjdk.java.net/~mchung/6977738/webrev.01/
This looks much better (and thanks for doing the various 
drive-by-clean-ups).

I assume BootClassPathHolder should be private, and that the bcp field 
can be final.

Minor nit but but the IllegalStateExceptions thrown by 
VM.getSavedProperty capitalizes the first letter of the message whereas 
VM.saveAndRemoveProperties doesn't.

I wonder if it would be worth seeing if saveAndRemoveProperties could 
grab the value of the java.lang.Integer.IntegerCache.high property. That 
would allow us to be handle it more consistently with these other 
properties that we save during initialization. The cache initialization 
could then use VM.getSavedProperty to get the value. Might be worth 
thinking about but you would need to be careful to ensure that 
Integer.valueOf isn't called as otherwise isn't not going to work.

-Alan.


From mandy.chung at oracle.com  Thu Sep 30 17:46:27 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 30 Sep 2010 10:46:27 -0700
Subject: Code Review Request for 6977738
In-Reply-To: <4CA49C4F.6090906@oracle.com>
References: <4C92A899.8000407@oracle.com> <4CA396D3.6030301@oracle.com>
	<4CA49C4F.6090906@oracle.com>
Message-ID: <4CA4CCF3.30008@oracle.com>

  On 09/30/10 07:18, Alan Bateman wrote:
> Mandy Chung wrote:
>>  Alan, David,
>>
>> I revise the fix including the following:
>> 1. Use the lazy initialization holder class idiom to initialize the bcp
>> variable to simplify the synchronization.
>>
>> 2. Group the initialization of system properties in a new private method
>> System.initializeSystemProperties so that it can save a copy for 
>> internal
>> implementation use to address the deadlock issue and remove the
>> properties that are intended for private internal use from public access
>> before initializing the System.props.  This removes the 2 calls to
>> System.setProperties.
>>
>> 3. Reorder sun.net.* in FILES_java.gmk
>>
>> The new webrev is at:
>>    http://cr.openjdk.java.net/~mchung/6977738/webrev.01/
> This looks much better (and thanks for doing the various 
> drive-by-clean-ups).
>
> I assume BootClassPathHolder should be private, and that the bcp field 
> can be final.
>
> Minor nit but but the IllegalStateExceptions thrown by 
> VM.getSavedProperty capitalizes the first letter of the message 
> whereas VM.saveAndRemoveProperties doesn't.
>
> I wonder if it would be worth seeing if saveAndRemoveProperties could 
> grab the value of the java.lang.Integer.IntegerCache.high property. 
> That would allow us to be handle it more consistently with these other 
> properties that we save during initialization. The cache 
> initialization could then use VM.getSavedProperty to get the value. 
> Might be worth thinking about but you would need to be careful to 
> ensure that Integer.valueOf isn't called as otherwise isn't not going 
> to work.
>

Yes, I also thought of that.  I was trying to keep the change as 
minimal.   I agree that I should take this chance to clean up and handle 
private system properties consistently.   It's good not to leak the 
private internal interfaces for public access.

Joe, Sherman,

I change IntegerCache and ZipFile initialization to get the property 
value from the private system properties object (not calling 
System.getProperty).  I also remove the "sun.zip.disableMemoryMapping" 
property from the public system properties.  Can you take a look?

    http://cr.openjdk.java.net/~mchung/6977738/webrev.02

Thanks
Mandy


From jonathan.gibbons at oracle.com  Thu Sep 30 17:47:44 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 30 Sep 2010 17:47:44 +0000
Subject: hg: jdk7/tl/langtools: 6988436: Cleanup javac option handling
Message-ID: <20100930174749.2E4B447DBC@hg.openjdk.java.net>

Changeset: 7b413ac1a720
Author:    jjg
Date:      2010-09-30 10:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7b413ac1a720

6988436: Cleanup javac option handling
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javac/util/Names.java
! src/share/classes/com/sun/tools/javac/util/Options.java



From xueming.shen at oracle.com  Thu Sep 30 22:29:17 2010
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 30 Sep 2010 15:29:17 -0700
Subject: Code Review Request for # 6975829 : Perf. of gzip in existing JDKs
	is too slower than in 1.3.1
Message-ID: <4CA50F3D.8090509@oracle.com>

  Martin, Alan

Please help review the change for #6975829

http://cr.openjdk.java.net/~sherman/6975829/webrev/ 
<http://cr.openjdk.java.net/%7Esherman/6975829/webrev/>

This is again a problem triggered by the change we putback years ago for
6206933: GZipOutputStream/InputStream goes critical(calls 
JNI_Get*Critical) and causes slowness

in which we switch from using the JNI_Get*Critical to access the input bits
to using GetByteArrayregion(...) (which invloves array copy)

The test case attached in the bug report exaggeratedly use file size of the
.gz file as the buf size param for the GZIPInputStream() constructor.

         File f = new File(TESTFILE);
         DataInputStream dis = new DataInputStream(new 
GZIPInputStream(new FileInputStream(f), (int)f.length()))

and then start to read in the data in very small chunk via dis, which is 
a disaster.

While it is possible to workaround the issue easily by
a) to use a smaller buf size, such as the defualt 512
b) wrap the GZIPInputStream with a BufferedInputStream

It still appears the memory/buffer handling code in Inflater.c can be 
changed to improve
the performance in use cases similar to above mentioned scenario. The 
proposed change
is to copy no more than the size of the "user's buffer". It's an 
de-compression, so you can't
consume more bytes than you can write out in most cases. The attached 
test case shows
the performance of gzip-ing the un-compressed rt.jar by using different 
buffer size.

Again, we still need to address the "fundamental performance" issue 
caused by moving
away from JNI_Get*Critical for #6206933. But that will be a separate 
project.

-Sherman


-----------------------------------------------------------------------------
     private static int BUFSIZE = 1024 * 1024;

     public static void main(String[] args) throws Exception {

         File f = new File(args[0]);

         //gzip it into memory, yeah we have enough memoery:-)
         ByteArrayOutputStream baos = new 
ByteArrayOutputStream((int)f.length() / 2);
         GZIPOutputStream gout = new GZIPOutputStream(baos);
         FileInputStream in = new FileInputStream(args[0]);
         byte[] copyBuf = new byte[BUFSIZE];
         int n;
         while ((n = in.read(copyBuf)) != -1) {
             gout.write(copyBuf, 0, n);
         }
         in.close();
         gout.close();

         byte[] gsrc = baos.toByteArray();

         for (int i = 1; i <= 128; i <<= 1 ) {
             copyBuf = new byte[BUFSIZE / i];
             long time = System.currentTimeMillis();
             for (int j = 0; j < 20; j++) {
                 ByteArrayInputStream bais = new ByteArrayInputStream(gsrc);
                 GZIPInputStream gin = new GZIPInputStream(bais, BUFSIZE);
                 while ((gin.read(copyBuf)) != -1) {}
                 gin.close();
             }
             System.out.printf( "buf[1/%d]: %d ms%n", i, 
(System.currentTimeMillis() - time)/ 20);
         }
     }
------------------------------------------------------------------------

(1) latest jdk7
sherman at sherman-linux:/home/sherman/TL/dis$  
/net/koori/onestop/jdk/7/latest/binaries/linux-i586/bin/java Inf /tmp/rt.jar
buf[1/1]: 579 ms
buf[1/2]: 640 ms
buf[1/4]: 613 ms
buf[1/8]: 683 ms
buf[1/16]: 873 ms
buf[1/32]: 1247 ms
buf[1/64]: 1958 ms
buf[1/128]: 3379 ms

(2) with proposed fix
sherman at sherman-linux:/home/sherman/TL/dis$ java Inf 
/tmp/rt.jarbuf[1/1]: 514 ms
buf[1/2]: 546 ms
buf[1/4]: 460 ms
buf[1/8]: 413 ms
buf[1/16]: 426 ms
buf[1/32]: 448 ms
buf[1/64]: 436 ms
buf[1/128]: 448 ms