From ahughes at redhat.com  Sun Aug  1 15:35:29 2010
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Sun, 1 Aug 2010 16:35:29 +0100
Subject: jvm load too many classes
In-Reply-To: <4C54882B.8070808@univ-mlv.fr>
References: <AANLkTinCAjwAoMEwdRMJbuQboDW8r7oBTcM-cBwQiA-O@mail.gmail.com>
	<4C5318C0.1050006@oracle.com>
	<AANLkTi=Vrj+2sWq8nBSGO18AhFodi4o3GYnwCo3uFptj@mail.gmail.com>
	<4C532F31.5040207@oracle.com> <4C54882B.8070808@univ-mlv.fr>
Message-ID: <AANLkTikNsnF+=p6J_wWAbCyBZ+9xR+Gd0oRagi43=W4L@mail.gmail.com>

On 31 July 2010 21:31, R?mi Forax <forax at univ-mlv.fr> wrote:
> Le 30/07/2010 21:59, Mandy Chung a ?crit :
>>
>> Osvaldo Doederlein wrote:
>>>
>>> I wonder if these numbers have some variation per platform?
>>
>> Yes, there are some platform-dependent classes and so some loaded
>> classes are different on different platform.
>>
>>> For me (on
>>> Windows; 32-bit JDKs), the results of this test (java -verbose:class |
>>> grep Loaded | wc -l) are:
>>>
>>> 1.5.0_22: 239
>>> 1.6.0_21: 274
>>> 1.7.0-ea-b103: 403
>>>
>> I ran the helloworld. The number of loaded classes running different jdk
>> versions are fairly close. ?What test case did you use?
>>
>> $ grep Loaded hw.verbose.jdk5u22 | wc -l
>> 303
>>
>> $ grep Loaded hw.verbose.jdk6u21 | wc -l
>> 323
>>
>> $ grep Loaded hw.verbose.jdk7 | wc -l
>> 329
>
> There is a big diff (at least on linux) if you just try to print the help of
> the VM,
> i.e pass no argument.
>
> jdk1.6.0_21: 274 classes
> jdk1.7.0b103: 364 classes
>
> I join the diff.
>
> Some classes of java.text.*, java.util.ResourceBundle* and
> some classes related to locale and currency are loaded eagerly.
>
> R?mi
>
>>
>>
>>> The diff from 1.5 to 1.6 is not bad, but JDK7 seems right now to be a
>>> heavy regression... FWIW for such a simple test. For one thing, these
>>> core-boot classes all come off the CDS file so their classloading
>>> effort is relatively very small, and the delta will certainly be much
>>> smaller for even the smallest real-world app.
>>
>> Right. ?-verbose:class prints out all loaded classes regardless of coming
>> from CDS archive or not. The number of loaded classes is one
>> metric to the startup while class loading time + clinit time are other
>> important metrics. ?So these loaded classes has small impact
>> to the startup time especially with CDS is enabled.
>>
>> Mandy
>>
>>> A+
>>> Osvaldo
>>>
>>> 2010/7/30 Mandy Chung <mandy.chung at oracle.com>:
>>>>
>>>> Yongqiang Yang wrote:
>>>>>
>>>>> hi,
>>>>>
>>>>> ? ?I just type command "java" under openjdk1.6, then the jvm will load
>>>>> 308 classes, including ? ? ? ? ? ? java/launcher/LauncherHelp,
>>>>> ? ? ? ? ? java/util/ResourceBundle,
>>>>> ? ? ? ? ? java/util/Currency,
>>>>> ? ? ? ? ? java/util/Locale,
>>>>> ? ? ? ? ? java/net/URL
>>>>>
>>>>> ? ? ? When I use jdk1.5, the jvm just load about 180 classes, not
>>>>> including the classes above.
>>>>>
>>>>> ? ? ? Could someone figure out something wrong?
>>>>
>>>> New features and bug fixes in a new release could lead to more classes
>>>> get
>>>> loaded at startup. ?We have done some work to lazily load classes if
>>>> appropriate (see CR 6798873: Reduce the number of classes loaded and
>>>> class
>>>> dependencies).
>>>>
>>>> Mandy
>>>>
>>>>
>>
>
>

Is the jdk7 here an OpenJDK build or an Oracle-provided binary?
There's likely to be a difference between the two, due to the
replacement of proprietary classes (e.g. Pisces renderer, lcms &
freetype code in OpenJDK which isn't used by the proprietary version).
-- 
Andrew :-)

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

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

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


From ik3g09 at ecs.soton.ac.uk  Mon Aug  2 20:17:25 2010
From: ik3g09 at ecs.soton.ac.uk (kammerath i. (ik3g09))
Date: Mon, 2 Aug 2010 21:17:25 +0100
Subject: Research into modifications on the primordial class loader
Message-ID: <E117AD245282BA48ABE1E16E9712070C9F3134CB46@UOS-CL-EX7-L3.soton.ac.uk>

Hello hotspot-runtime-dev, Hotspot-dev and core-libs-dev members,

After initial contact with core-libs-owner, I have been able to get a lot further.
The idea is to make certain modifications to the primordial/system-ClassLoader that lower security measures to gain a certain insight into higher reload-ability. As far as I currently understand, The Primordial ClassLoader is a mixture of system specific C files and standard Java classes. I am working with the version proposed below by Iris. 

When reloading an existing class I am so far forced to create a new classloader, as one classloader always has to return the same class object reference for the same class name. Meaning if I want to reload a class I always need an interface implemented by both the old and the new class-version to have a common type between both the custom and the system classloader, which allows me to access both versions of the class the same way (over a proxy pattern, to make references replaceable). 

Now I want to do something that one might consider as highly insecure. I want to allow a classloader to return different class object reference for the same class name. Thus I could bypass the whole interface fiddle and simply access the new object by the same type. I am aware of the fact that this means breaking the type-system/type-safe idea. As this means that two different types are considered as one without any shared inheritance. But logically they are the same type, but simply evolved. 

Where am I:

Whilst reading through ClassLoader.java I came along void addClass(Class c) [line 258] which apperently is used by the JVM to record loaded classes, would this be where I could interfere by simply not record classes annotated with reloadable or something like that. Such that when checking whether a class is already registered it simply wouldn't be, thus I could reload it (probably not).

Further along I came across getSystemClassLoader() in which I found initSystemClassLoader which lead me to Launcher.java [sun.misc.Launcher] in which I found the top-level nested class AppClassLoader, which I assume is the actual Primordial/System-ClassLoader. At least it is what ClassLoader.getSystemClassLoader() returns. In it I found a call "BootClassLoaderHook.preLoadClass(name);" is this where the C comes into play?
I couldn't find anything else in the Java sources relating to "BootClassLoaderHook". What is this doing? Is this where I can make my insecure changes? Iris also pointed out ClassLoader.c, might this be what's hooked in with this specific call? if it is, how is it "hooked in"?

I am open for any other suggestions in terms of: "where I could make changes" and "what changes I could make", to achieve the higher/different (even though less secure) reload ability. 

Many thanks in advance
Ivo
________________________________________
From: Iris Clark [iris at agathis.com] On Behalf Of irisg at alum.mit.edu [irisg at alum.mit.edu]
Sent: 01 August 2010 03:35
To: kammerath i. (ik3g09)
Subject: RE: Research on the primordial class loader

Hi, Ivo.

I didn't receive your original message.  I don't know what happened as it
isn't in the set of pending moderator requests and your message didn't seem
to make it into our archive (see the "archive link") near the top of this
page:  http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev

One way to avoid the need for moderation is to become a subscriber.  There
is a digest mode if you get inundated with mail.  Alternatively, you could
just unsubscribe as soon as you get the information you need.

I think that core-libs-dev is a fine place to ask your question.
Alternatively hotspot-dev or hotspot-runtime-dev may also be good
candidates as that is where a great deal of heavy lifting occurs for class
loading.  Here are some pointers for you to begin your investigation.  I've
selected subversion files from the JDK7 tl repository, but these files will
reside in similar locations in other JDK repositories.

http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/classes/j
ava/lang/ClassLoader.java
  java.lang.ClassLoader provides the specification for the delegation model
  and is the primary implementation.  Note that specification comments such
  as this:  "If the parent is "null", the class loader built-in to the
  virtual machine..." and the corresponding null checks are references to
  class loader implemented by the VM.

http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/native/ja
va/lang/ClassLoader.c
  The supporting libraries C code for j.l.ClassLoader.  This is where
  libraries makes the calls into the VM.

http://hg.openjdk.java.net/jdk7/tl/hotspot/file/cb4250ef73b2/src/share/vm/cl
assfile/
  I am by no means a VM expert, but I believe that this is where the VM
  implements most of class loading.  A VM engineer will be able to provide
  more details.

http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html
  I'm sure you've' already found it, but just in case... The VM
specification,
  Chapter 5 contains the complete spec for loading, linking, and
initializing:

Hope this gets you started.  My apologies for not seeing your earlier
message.

Thanks,
iris
________________________________________
From: Ivo
Sent: 29 July 2010 17:15
To: core-libs-dev at openjdk.java.net
Subject: Research on the primordial class loader

Hello core-libs-dev members,

In my research on dynamic continuous integration at run-time and dynamic
self-modification.
I reached a point where I would like to have a look at the implementation of
the 'Primordial ClassLoader'.
Which, according to what I read so far, is responsible for loading all
classes, excluding those loaded by any
custom ClassLaoder.

When I downloaded the OpenJDK source I felt a little lost, I could not quite
work out where to look.
As far as I understood,  the Primordial ClassLoader is more than just a
bunch of Java classes.
Correct me if I am wrong, but I assume it involves a few C/C++
classes/procedures?

So my question is:
Which classes are involved in the primordial classloading and which files of
the HotSpot are involved in the process?

many thanks in advance
Ivo

From joe.darcy at oracle.com  Mon Aug  2 20:37:52 2010
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Mon, 02 Aug 2010 20:37:52 +0000
Subject: hg: jdk7/tl/langtools: 6971877: Project Coin: improve semantics of
	suppressed exceptions in try-with-resources
Message-ID: <20100802203800.C1AF547E72@hg.openjdk.java.net>

Changeset: 38e2c23309f1
Author:    darcy
Date:      2010-08-02 13:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/38e2c23309f1

6971877: Project Coin: improve semantics of suppressed exceptions in try-with-resources
Reviewed-by: jjb

+ test/tools/javac/TryWithResources/TwrSuppression.java



From martinrb at google.com  Mon Aug  2 21:52:05 2010
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 2 Aug 2010 14:52:05 -0700
Subject: 6955504: (str) String[Builder/Buffer].append(char[], int, int) throws 
	OutOfMemoryError in b94
Message-ID: <AANLkTi=2ekPL_gg6q9NOp8B4xPs4gv93X502+5dNdyLv@mail.gmail.com>

Hi Chris (or others),

Here's a fix for a little bug I introduced in jdk7-b94

http://bugs.sun.com/view_bug.do?bug_id=6955504
6955504: (str) String[Builder/Buffer].append(char[],int,int) throws
OutOfMemoryError in b94
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/oome2aioobe/

I couldn't resist sneaking in a little optimization.

I'm a little disappointed that I broke a JCK test, but that this was not
noticed by openjdk QA until several builds later.  I'm thinking it's part of
the job of integrators to ensure __NO__REGRESSIONS__ and that includes jck
tests (which are much easier for integrators to run than for external
contributors).

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

From jonathan.gibbons at oracle.com  Mon Aug  2 23:31:32 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 02 Aug 2010 23:31:32 +0000
Subject: hg: jdk7/tl/langtools: 6973626: test/tools/javac/processing/* tests
	fail with assertions enabled
Message-ID: <20100802233134.6801D47E7A@hg.openjdk.java.net>

Changeset: 6318230cdb82
Author:    jjg
Date:      2010-08-02 16:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6318230cdb82

6973626: test/tools/javac/processing/* tests fail with assertions enabled
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java



From David.Holmes at oracle.com  Mon Aug  2 23:44:35 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 03 Aug 2010 09:44:35 +1000
Subject: Research into modifications on the primordial class loader
In-Reply-To: <E117AD245282BA48ABE1E16E9712070C9F3134CB46@UOS-CL-EX7-L3.soton.ac.uk>
References: <E117AD245282BA48ABE1E16E9712070C9F3134CB46@UOS-CL-EX7-L3.soton.ac.uk>
Message-ID: <4C575863.1050602@oracle.com>

Just a clarification on terminology. The native loader in the VM is the 
bootstrap loader. A class was loaded by the bootstrap loader if its 
ClassLoader is reported as "null". There is then a hierarchy of 
classloaders created:
- the extensions loader is used to add the ability to load standard 
extensions (from lib/ext if I recall correctly) these are classes that 
are treated the same as "core" classes for security purposes
- the application-class loader, aka the system classloader (bad name), 
is created to load the application class that you want to run

The application can then define its own classloaders.

For a ClassLoader to actually load a class it must use defineClass, 
which is implemented in the VM as part of the native loader. Hence any 
subterfuge has to be done inside the VM: you need to look at the 
systemDictionary and the loader_constraints, which enforce the language 
rules.

I really don't know how you would go about doing what you suggest 
because the details are the critical points here. You could define a 
ClassLoader that returned an arbitrary Class object for a given name, 
but that Class object would report it's real identity. If this was part 
of an implicit classloading process, then you'd likely get a 
ClassCastException, or some other exception if you actually tried to 
return a different Class than required.

Good luck.

David Holmes

kammerath i. (ik3g09) said the following on 08/03/10 06:17:
> Hello hotspot-runtime-dev, Hotspot-dev and core-libs-dev members,
> 
> After initial contact with core-libs-owner, I have been able to get a lot further.
> The idea is to make certain modifications to the primordial/system-ClassLoader that lower security measures to gain a certain insight into higher reload-ability. As far as I currently understand, The Primordial ClassLoader is a mixture of system specific C files and standard Java classes. I am working with the version proposed below by Iris. 
> 
> When reloading an existing class I am so far forced to create a new classloader, as one classloader always has to return the same class object reference for the same class name. Meaning if I want to reload a class I always need an interface implemented by both the old and the new class-version to have a common type between both the custom and the system classloader, which allows me to access both versions of the class the same way (over a proxy pattern, to make references replaceable). 
> 
> Now I want to do something that one might consider as highly insecure. I want to allow a classloader to return different class object reference for the same class name. Thus I could bypass the whole interface fiddle and simply access the new object by the same type. I am aware of the fact that this means breaking the type-system/type-safe idea. As this means that two different types are considered as one without any shared inheritance. But logically they are the same type, but simply evolved. 
> 
> Where am I:
> 
> Whilst reading through ClassLoader.java I came along void addClass(Class c) [line 258] which apperently is used by the JVM to record loaded classes, would this be where I could interfere by simply not record classes annotated with reloadable or something like that. Such that when checking whether a class is already registered it simply wouldn't be, thus I could reload it (probably not).
> 
> Further along I came across getSystemClassLoader() in which I found initSystemClassLoader which lead me to Launcher.java [sun.misc.Launcher] in which I found the top-level nested class AppClassLoader, which I assume is the actual Primordial/System-ClassLoader. At least it is what ClassLoader.getSystemClassLoader() returns. In it I found a call "BootClassLoaderHook.preLoadClass(name);" is this where the C comes into play?
> I couldn't find anything else in the Java sources relating to "BootClassLoaderHook". What is this doing? Is this where I can make my insecure changes? Iris also pointed out ClassLoader.c, might this be what's hooked in with this specific call? if it is, how is it "hooked in"?
> 
> I am open for any other suggestions in terms of: "where I could make changes" and "what changes I could make", to achieve the higher/different (even though less secure) reload ability. 
> 
> Many thanks in advance
> Ivo
> ________________________________________
> From: Iris Clark [iris at agathis.com] On Behalf Of irisg at alum.mit.edu [irisg at alum.mit.edu]
> Sent: 01 August 2010 03:35
> To: kammerath i. (ik3g09)
> Subject: RE: Research on the primordial class loader
> 
> Hi, Ivo.
> 
> I didn't receive your original message.  I don't know what happened as it
> isn't in the set of pending moderator requests and your message didn't seem
> to make it into our archive (see the "archive link") near the top of this
> page:  http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
> 
> One way to avoid the need for moderation is to become a subscriber.  There
> is a digest mode if you get inundated with mail.  Alternatively, you could
> just unsubscribe as soon as you get the information you need.
> 
> I think that core-libs-dev is a fine place to ask your question.
> Alternatively hotspot-dev or hotspot-runtime-dev may also be good
> candidates as that is where a great deal of heavy lifting occurs for class
> loading.  Here are some pointers for you to begin your investigation.  I've
> selected subversion files from the JDK7 tl repository, but these files will
> reside in similar locations in other JDK repositories.
> 
> http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/classes/j
> ava/lang/ClassLoader.java
>   java.lang.ClassLoader provides the specification for the delegation model
>   and is the primary implementation.  Note that specification comments such
>   as this:  "If the parent is "null", the class loader built-in to the
>   virtual machine..." and the corresponding null checks are references to
>   class loader implemented by the VM.
> 
> http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/native/ja
> va/lang/ClassLoader.c
>   The supporting libraries C code for j.l.ClassLoader.  This is where
>   libraries makes the calls into the VM.
> 
> http://hg.openjdk.java.net/jdk7/tl/hotspot/file/cb4250ef73b2/src/share/vm/cl
> assfile/
>   I am by no means a VM expert, but I believe that this is where the VM
>   implements most of class loading.  A VM engineer will be able to provide
>   more details.
> 
> http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html
>   I'm sure you've' already found it, but just in case... The VM
> specification,
>   Chapter 5 contains the complete spec for loading, linking, and
> initializing:
> 
> Hope this gets you started.  My apologies for not seeing your earlier
> message.
> 
> Thanks,
> iris
> ________________________________________
> From: Ivo
> Sent: 29 July 2010 17:15
> To: core-libs-dev at openjdk.java.net
> Subject: Research on the primordial class loader
> 
> Hello core-libs-dev members,
> 
> In my research on dynamic continuous integration at run-time and dynamic
> self-modification.
> I reached a point where I would like to have a look at the implementation of
> the 'Primordial ClassLoader'.
> Which, according to what I read so far, is responsible for loading all
> classes, excluding those loaded by any
> custom ClassLaoder.
> 
> When I downloaded the OpenJDK source I felt a little lost, I could not quite
> work out where to look.
> As far as I understood,  the Primordial ClassLoader is more than just a
> bunch of Java classes.
> Correct me if I am wrong, but I assume it involves a few C/C++
> classes/procedures?
> 
> So my question is:
> Which classes are involved in the primordial classloading and which files of
> the HotSpot are involved in the process?
> 
> many thanks in advance
> Ivo


From chris.hegarty at oracle.com  Tue Aug  3 11:04:10 2010
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 03 Aug 2010 11:04:10 +0000
Subject: hg: jdk7/tl/jdk: 6973030: NTLM proxy authentication fails with https
Message-ID: <20100803110435.9510B47E93@hg.openjdk.java.net>

Changeset: 367b90ed38b1
Author:    chegar
Date:      2010-08-03 12:03 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/367b90ed38b1

6973030: NTLM proxy authentication fails with https
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java



From sean.mullan at oracle.com  Tue Aug  3 13:56:05 2010
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Tue, 03 Aug 2010 13:56:05 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100803135623.B5EE347E9B@hg.openjdk.java.net>

Changeset: a21c46dac6cf
Author:    mullan
Date:      2010-08-03 09:39 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a21c46dac6cf

6653372: Error in java.security.KeyStore example code
Reviewed-by: weijun

! src/share/classes/java/security/KeyStore.java

Changeset: 2feeefb45a44
Author:    mullan
Date:      2010-08-03 09:55 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2feeefb45a44

Merge




From dmytro_sheyko at hotmail.com  Tue Aug  3 15:25:49 2010
From: dmytro_sheyko at hotmail.com (Dmytro Sheyko)
Date: Tue, 3 Aug 2010 22:25:49 +0700
Subject: Question on sorting
In-Reply-To: <E1OeujU-0006Ki-00.iaroslavski-mail-ru@f282.mail.ru>
References: <E1OeujU-0006Ki-00.iaroslavski-mail-ru@f282.mail.ru>
Message-ID: <SNT137-w6443C8BA93A37F4DABD44E8AAE0@phx.gbl>


Hi Vladimir,

There could be many reasons for this.
The verisimilar ones are imprecise time measurement with highly dispersed results and biased samples.

Another reason is that an attempt to divide whole array into equal-size partition not always gives us the best result.
And hence choosing "wrong" pivots could make partitions balanced slightly better.

Let me clarify this counter-intuitive statement regarding not-equal partitioning.

Consider following quite straightforward dual pivot quicksort.

sort(a[]) {
    pivot1, pivot2 = choosePivots(a);

    // partitioning
    forall (a[k] in a) {
        if (a[k] < pivot1) {
            a[k] goes to the left partition
        } else if (a[k] > pivot2) {
            a[k] goes to the right partition
        } else {
            a[k] goes to the middle partition
        }
    }

    sort(left partition);
    sort(middle partition);
    sort(right partition);
}

Here you can see that during partitioning every item is compared with one or two pivots. In our case item is compared with
the second pivot only if it greater than the first one. So what is the average number of comparison during partitioning?
If we succeed to choose pivots so that they divide whole array into 3 equal partitions we have 1*(1/3) + 2*(1/3) + 2*(1/3) = 5/3 per item.
Is this ideal? What if pivots divide array in following proportions 1/2 1/4 1/4? Then we have 1*(1/2) + 2*(1/4) + 2*(1/4) = 3/2.
3/2 is less than 5/3.

Let's find now ideal proportions of partitions taking into account number of comparison of sorting in whole.

Assume that number of comparison is A*n*ln(n) + B*n + o(n) and we divide whole array in following proportions
[alpha, (1 - alpha)/2, (1 - alpha)/2], where 0 < alpha < 1.

A*n*ln(n) + B*n =
 = n * (alpha + 2*(1 - alpha)) { partitioning }
  + A * alpha*n * ln(alpha*n) + B * alpha*n { sorting left partition }
  + 2 * A * (1-alpha)*n/2 * ln((1-alpha)*n/2) + 2 * B * (1-alpha)*n/2 { sorting middle and right partitions }

A*n*ln(n) + B*n =
 = A*alpha*n*ln(n) + A*(1-alpha)*n*ln(n) + 
 + B*alpha*n + B*(1-alpha)*n +
  + n * (alpha + 2*(1-alpha))
  + A*alpha*n*ln(alpha) + A*(1-alpha)*n*ln((1-alpha)/2)

0 = (alpha + 2*(1-alpha)) + A*alpha*ln(alpha) + A*(1-alpha)*ln((1-alpha)/2)

A = (alpha - 2) / (alpha*ln(alpha) + (1-alpha)*ln((1-alpha)/2))

alpha    A
1/12    2.078316236
2/12    1.783079278
3/12    1.617083005
4/12    1.517065378
5/12    1.461274369
6/12    1.442695041    !!!
7/12    1.463491681
8/12    1.536871653
9/12    1.699242413
10/12    2.060936332
11/12    3.143757518

It appears that the best alpha is about 1/2. Thus ideal partition is something like [1/2, 1/4, 1/4].

Of course, these consideration does not apply to the real DPQ completely. This is because in real DPQ every item is not compared with pivots in well defined order and
real DPQ contains numerous special cases, which make it harder to analyze.

Regards,
Dmytro Sheyko


> From: iaroslavski at mail.ru
> To: core-libs-dev at openjdk.java.net
> Subject: Question on sorting
> Date: Fri, 30 Jul 2010 22:55:00 +0400
> CC: iaroslavski at mail.ru
> 
> Hello,
> 
> I have performance question in sorting.
> 
> In an implementation of Dual-Pivot Quicksort 5 elements
> 
> a[e1], a[e2], a[e3], a[e4], a[e5]
> 
> where e1 = len/6, e2 = len/3, e3 = len/2, e4 = len*2/3, e5 = len*5/6,
> are sorted and then elements a[e2], a[e4] are taken as pivots.
> 
> but if I take a[e1] and a[e3] as pivots, it works 2-3% faster on
> *random* inputs.
> 
> I tried different sorting for these 5 elements: network, bubble,
> insertion - with a[e1] and a[e3] pivots it is faster than with
> a[e2] and a[e4].
> 
> If I sort these 5 elements in descending order, it works faster
> with a[e5] and a[e3] pivots.
> 
> Do you have any idea why it happens?
> 
> Thank you,
> Vladimir
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100803/64d69766/attachment.html>

From chris.hegarty at oracle.com  Tue Aug  3 15:30:18 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 03 Aug 2010 16:30:18 +0100
Subject: 6955504: (str) String[Builder/Buffer].append(char[],int,int)
	throws  OutOfMemoryError in b94
In-Reply-To: <AANLkTi=2ekPL_gg6q9NOp8B4xPs4gv93X502+5dNdyLv@mail.gmail.com>
References: <AANLkTi=2ekPL_gg6q9NOp8B4xPs4gv93X502+5dNdyLv@mail.gmail.com>
Message-ID: <4C58360A.202@oracle.com>

Martin, this change looks fine to me.

-Chris.

On 08/02/10 22:52, Martin Buchholz wrote:
> Hi Chris (or others),
>
> Here's a fix for a little bug I introduced in jdk7-b94
>
> http://bugs.sun.com/view_bug.do?bug_id=6955504
> 6955504: (str) String[Builder/Buffer].append(char[],int,int) throws
> OutOfMemoryError in b94
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/oome2aioobe/
>
> I couldn't resist sneaking in a little optimization.
>
> I'm a little disappointed that I broke a JCK test, but that this was not
> noticed by openjdk QA until several builds later.  I'm thinking it's
> part of the job of integrators to ensure __NO__REGRESSIONS__ and that
> includes jck tests (which are much easier for integrators to run than
> for external contributors).
>
> Martin


From forax at univ-mlv.fr  Tue Aug  3 15:49:28 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 03 Aug 2010 17:49:28 +0200
Subject: 6955504: (str) String[Builder/Buffer].append(char[],int,int)
	throws  OutOfMemoryError in b94
In-Reply-To: <4C58360A.202@oracle.com>
References: <AANLkTi=2ekPL_gg6q9NOp8B4xPs4gv93X502+5dNdyLv@mail.gmail.com>
	<4C58360A.202@oracle.com>
Message-ID: <4C583A88.8060005@univ-mlv.fr>

Le 03/08/2010 17:30, Chris Hegarty a ?crit :
> Martin, this change looks fine to me.
>
> -Chris.

Yes, looks fine.

R?mi

>
> On 08/02/10 22:52, Martin Buchholz wrote:
>> Hi Chris (or others),
>>
>> Here's a fix for a little bug I introduced in jdk7-b94
>>
>> http://bugs.sun.com/view_bug.do?bug_id=6955504
>> 6955504: (str) String[Builder/Buffer].append(char[],int,int) throws
>> OutOfMemoryError in b94
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/oome2aioobe/
>>
>> I couldn't resist sneaking in a little optimization.
>>
>> I'm a little disappointed that I broke a JCK test, but that this was not
>> noticed by openjdk QA until several builds later.  I'm thinking it's
>> part of the job of integrators to ensure __NO__REGRESSIONS__ and that
>> includes jck tests (which are much easier for integrators to run than
>> for external contributors).
>>
>> Martin



From kelly.ohair at oracle.com  Tue Aug  3 17:16:41 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 3 Aug 2010 10:16:41 -0700
Subject: 6955504: (str) String[Builder/Buffer].append(char[], int,
	int) throws  OutOfMemoryError in b94
In-Reply-To: <AANLkTi=2ekPL_gg6q9NOp8B4xPs4gv93X502+5dNdyLv@mail.gmail.com>
References: <AANLkTi=2ekPL_gg6q9NOp8B4xPs4gv93X502+5dNdyLv@mail.gmail.com>
Message-ID: <B28B9BFF-0F5B-401B-954A-B21C0F309164@oracle.com>


On Aug 2, 2010, at 2:52 PM, Martin Buchholz wrote:

> Hi Chris (or others),
>
> Here's a fix for a little bug I introduced in jdk7-b94
>
> http://bugs.sun.com/view_bug.do?bug_id=6955504
> 6955504: (str) String[Builder/Buffer].append(char[],int,int) throws  
> OutOfMemoryError in b94
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/oome2aioobe/
>
> I couldn't resist sneaking in a little optimization.
>
> I'm a little disappointed that I broke a JCK test, but that this was  
> not noticed by openjdk QA until several builds later.  I'm thinking  
> it's part of the job of integrators to ensure __NO__REGRESSIONS__  
> and that includes jck tests (which are much easier for integrators  
> to run than for external contributors).

The JCK tests are NO easier to run for anyone, it only gets easier if  
you have repeatedly run it over and over.
But the JCK team is making progress to make it easier, and we will try  
and run it more often.

In defense of the integrators (who are not the ones that created the  
regressions), they are doing the best they can
to find all our mistakes given the resources they have.
   * If they don't integrate quickly enough, people complain that  
their favorite change did not make it in
   * If they integrate too quickly, people complain about too many  
integrations and the regressions created by quicker integrations
   * If they find regressions and hold up an integration, people are  
upset that all the other changes are being held up
   * If the integration goes smoothly, silence. Kind of a thankless  
job, like a postal worker,... oh dear... please be nice to our  
integrators.;^}

And it is impossible to guarantee no regressions given the time and  
resources available to an integrator.
Avoiding regressions is a shared responsibility we all have.

In this case, we need to figure out how to get regular runs of JCK  
into the integration process.

-kto


>
> Martin

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

From martinrb at google.com  Tue Aug  3 18:03:03 2010
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 3 Aug 2010 11:03:03 -0700
Subject: 6955504: (str) String[Builder/Buffer].append(char[], int, int) 
	throws OutOfMemoryError in b94
In-Reply-To: <B28B9BFF-0F5B-401B-954A-B21C0F309164@oracle.com>
References: <AANLkTi=2ekPL_gg6q9NOp8B4xPs4gv93X502+5dNdyLv@mail.gmail.com>
	<B28B9BFF-0F5B-401B-954A-B21C0F309164@oracle.com>
Message-ID: <AANLkTingmz1t3X1uTNSX9JnyzH3WMe9pyZw93xj9ug8_@mail.gmail.com>

On Tue, Aug 3, 2010 at 10:16, Kelly O'Hair <kelly.ohair at oracle.com> wrote:

>
> On Aug 2, 2010, at 2:52 PM, Martin Buchholz wrote:
>
> Hi Chris (or others),
>
> Here's a fix for a little bug I introduced in jdk7-b94
>
> http://bugs.sun.com/view_bug.do?bug_id=6955504
> 6955504: (str) String[Builder/Buffer].append(char[],int,int) throws
> OutOfMemoryError in b94
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/oome2aioobe/<http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/oome2aioobe/>
>
> I couldn't resist sneaking in a little optimization.
>
> I'm a little disappointed that I broke a JCK test, but that this was not
> noticed by openjdk QA until several builds later.  I'm thinking it's part of
> the job of integrators to ensure __NO__REGRESSIONS__ and that includes jck
> tests (which are much easier for integrators to run than for external
> contributors).
>
>
> The JCK tests are NO easier to run for anyone, it only gets easier if you
> have repeatedly run it over and over.
>

Well, yes, but since running tests repeatedly is part of an integrator's
job, that means it's easier for them.


>
> And it is impossible to guarantee no regressions given the time and
> resources available to an integrator.
>


Avoiding regressions is a shared responsibility we all have.
>
> In this case, we need to figure out how to get regular runs of JCK into the
> integration process.
>
> Running JCK tests were part of the TL integration process when I left Sun.
On my watch, when I was TL integrator, I guaranteed __NO__REGRESSIONS__ (on
a defined set of tests that included the core library jck tests).

Martin


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

From martinrb at google.com  Tue Aug  3 21:20:01 2010
From: martinrb at google.com (martinrb at google.com)
Date: Tue, 03 Aug 2010 21:20:01 +0000
Subject: hg: jdk7/tl/jdk: 6955504: (str) String[Builder/Buffer].append(char[], 
	int, int) throws OutOfMemoryError in b94
Message-ID: <20100803212012.4314847EB3@hg.openjdk.java.net>

Changeset: 3b63e506b57e
Author:    martin
Date:      2010-08-03 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b63e506b57e

6955504: (str) String[Builder/Buffer].append(char[],int,int) throws OutOfMemoryError in b94
Summary: let arraycopy throw AIOOBE for invalid negative length
Reviewed-by: chegar, forax

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



From fweimer at bfk.de  Wed Aug  4 11:50:22 2010
From: fweimer at bfk.de (Florian Weimer)
Date: Wed, 04 Aug 2010 11:50:22 +0000
Subject: Additional -Xlint:serial warning
Message-ID: <82y6cm1ts1.fsf@mid.bfk.de>

The JLS does not provide binary compatibility for compiler-generated
fields (such as reference to an outer class object from an inner class
object).  This means that there is no reliable way to use such classes
in serialization even if all involved classes implement
java.io.Serializable.  A mere recompilation of unchanged sources might
result in different compiler-generated names.

Would it make sense to enhance -Xlint:serial to warn about classes
which implement java.io.Serializable and contain compiler-generated
fields?

PS: This is quite different from the frequently observed issue where a
non-static inner class cannot be serialized because the outer class is
not serializable.  Serialization works fine, but deserialization
silently results in invalid objects.

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


From iaroslavski at mail.ru  Wed Aug  4 13:43:23 2010
From: iaroslavski at mail.ru (Vladimir Iaroslavski)
Date: Wed, 04 Aug 2010 17:43:23 +0400
Subject: Question on sorting
In-Reply-To: <SNT137-w6443C8BA93A37F4DABD44E8AAE0@phx.gbl>
References: <E1OeujU-0006Ki-00.iaroslavski-mail-ru@f282.mail.ru>
	<SNT137-w6443C8BA93A37F4DABD44E8AAE0@phx.gbl>
Message-ID: <4C596E7B.5070906@mail.ru>

Hello Dmytro,

Thank you for investigation, the results are interesting.

I prepared simpler test [1], which has no recursion, it just
sorts 5 candidates and compare all elements with first (or second)
candidate. I run on array of 2000000 elements and result is:

e1/e2 267/460 on random data
e1/e2 193/200 on sorted array

and interesting fact: if I change comparison from "a[i] < pivot"
to "a[i] == pivot", it shows 189 for e1 and e2, for random and
sorted data.

I tried new schema [1/2, 1/4, 1/4], but it shows almost the same
time as [1/3, 1/3, 1/3], no improvements.

Thank you,
Vladimir

[1] ---------------------------------------------------------------
public static void sort(int[] a) {
     int step = a.length >>> 3;
     int e1 =      step;
     int e2 = e1 + step;
     int e3 = e2 + step;
     int e4 = e3 + step;
     int e5 = e4 + step;

     if (a[e1] > a[e2]) { int t = a[e1]; a[e1] = a[e2]; a[e2] = t; }
     if (a[e4] > a[e5]) { int t = a[e4]; a[e4] = a[e5]; a[e5] = t; }
     if (a[e1] > a[e3]) { int t = a[e1]; a[e1] = a[e3]; a[e3] = t; }
     if (a[e2] > a[e3]) { int t = a[e2]; a[e2] = a[e3]; a[e3] = t; }
     if (a[e1] > a[e4]) { int t = a[e1]; a[e1] = a[e4]; a[e4] = t; }
     if (a[e3] > a[e4]) { int t = a[e3]; a[e3] = a[e4]; a[e4] = t; }
     if (a[e2] > a[e5]) { int t = a[e2]; a[e2] = a[e5]; a[e5] = t; }
     if (a[e2] > a[e3]) { int t = a[e2]; a[e2] = a[e3]; a[e3] = t; }
     if (a[e4] > a[e5]) { int t = a[e4]; a[e4] = a[e5]; a[e5] = t; }

     int pivot = a[e1]; // or a[e2]

     for (int i = 0; i < a.length; i++) {
         if (a[i] < pivot);
     }
}
[/1] ---------------------------------------------------------------

Dmytro Sheyko wrote:
> Hi Vladimir,
> 
> There could be many reasons for this.
> The verisimilar ones are imprecise time measurement with highly 
> dispersed results and biased samples.
> 
> Another reason is that an attempt to divide whole array into equal-size 
> partition not always gives us the best result. And hence choosing
> "wrong" pivots could make partitions balanced slightly better.
> 
> Let me clarify this counter-intuitive statement regarding not-equal 
> partitioning.
> 
> Consider following quite straightforward dual pivot quicksort.
> 
> sort(a[]) {
>     pivot1, pivot2 = choosePivots(a);
> 
>     // partitioning
>     forall (a[k] in a) {
>         if (a[k] < pivot1) {
>             a[k] goes to the left partition
>         } else if (a[k] > pivot2) {
>             a[k] goes to the right partition
>         } else {
>             a[k] goes to the middle partition
>         }
>     }
> 
>     sort(left partition);
>     sort(middle partition);
>     sort(right partition);
> }
> 
> Here you can see that during partitioning every item is compared with 
> one or two pivots. In our case item is compared with
> the second pivot only if it greater than the first one. So what is the 
> average number of comparison during partitioning?
> If we succeed to choose pivots so that they divide whole array into 3 
> equal partitions we have 1*(1/3) + 2*(1/3) + 2*(1/3) = 5/3 per item.
> Is this ideal? What if pivots divide array in following proportions 1/2 
> 1/4 1/4? Then we have 1*(1/2) + 2*(1/4) + 2*(1/4) = 3/2.
> 3/2 is less than 5/3.
> 
> Let's find now ideal proportions of partitions taking into account 
> number of comparison of sorting in whole.
> 
> Assume that number of comparison is A*n*ln(n) + B*n + o(n) and we divide 
> whole array in following proportions
> [alpha, (1 - alpha)/2, (1 - alpha)/2], where 0 < alpha < 1.
> 
> A*n*ln(n) + B*n =
>  = n * (alpha + 2*(1 - alpha)) { partitioning }
>   + A * alpha*n * ln(alpha*n) + B * alpha*n { sorting left partition }
>   + 2 * A * (1-alpha)*n/2 * ln((1-alpha)*n/2) + 2 * B * (1-alpha)*n/2 { 
> sorting middle and right partitions }
> 
> A*n*ln(n) + B*n =
>  = A*alpha*n*ln(n) + A*(1-alpha)*n*ln(n) +
>  + B*alpha*n + B*(1-alpha)*n +
>   + n * (alpha + 2*(1-alpha))
>   + A*alpha*n*ln(alpha) + A*(1-alpha)*n*ln((1-alpha)/2)
> 
> 0 = (alpha + 2*(1-alpha)) + A*alpha*ln(alpha) + A*(1-alpha)*ln((1-alpha)/2)
> 
> A = (alpha - 2) / (alpha*ln(alpha) + (1-alpha)*ln((1-alpha)/2))
> 
> alpha    A
>  1/12    2.078316236
>  2/12    1.783079278
>  3/12    1.617083005
>  4/12    1.517065378
>  5/12    1.461274369
>  6/12    1.442695041    !!!
>  7/12    1.463491681
>  8/12    1.536871653
>  9/12    1.699242413
> 10/12    2.060936332
> 11/12    3.143757518
> 
> It appears that the best alpha is about 1/2. Thus ideal partition is 
> something like [1/2, 1/4, 1/4].
> 
> Of course, these consideration does not apply to the real DPQ 
> completely. This is because in real DPQ every item is not compared with 
> pivots in well defined order and
> real DPQ contains numerous special cases, which make it harder to analyze.
> 
> Regards,
> Dmytro Sheyko
> 
>  > From: iaroslavski at mail.ru
>  > To: core-libs-dev at openjdk.java.net
>  > Subject: Question on sorting
>  > Date: Fri, 30 Jul 2010 22:55:00 +0400
>  > CC: iaroslavski at mail.ru
>  >
>  > Hello,
>  >
>  > I have performance question in sorting.
>  >
>  > In an implementation of Dual-Pivot Quicksort 5 elements
>  >
>  > a[e1], a[e2], a[e3], a[e4], a[e5]
>  >
>  > where e1 = len/6, e2 = len/3, e3 = len/2, e4 = len*2/3, e5 = len*5/6,
>  > are sorted and then elements a[e2], a[e4] are taken as pivots.
>  >
>  > but if I take a[e1] and a[e3] as pivots, it works 2-3% faster on
>  > *random* inputs.
>  >
>  > I tried different sorting for these 5 elements: network, bubble,
>  > insertion - with a[e1] and a[e3] pivots it is faster than with
>  > a[e2] and a[e4].
>  >
>  > If I sort these 5 elements in descending order, it works faster
>  > with a[e5] and a[e3] pivots.
>  >
>  > Do you have any idea why it happens?
>  >
>  > Thank you,
>  > Vladimir


From neal at gafter.com  Wed Aug  4 15:14:27 2010
From: neal at gafter.com (Neal Gafter)
Date: Wed, 4 Aug 2010 08:14:27 -0700
Subject: Additional -Xlint:serial warning
In-Reply-To: <82y6cm1ts1.fsf@mid.bfk.de>
References: <82y6cm1ts1.fsf@mid.bfk.de>
Message-ID: <AANLkTi=5ECjg0u29wvrcgU22wYiegKRvzYjSmPeHPCau@mail.gmail.com>

Unfortunately, many inner classes are only "incidentally" serializable -
that is, they are serializable because the superclass or some implemented
interface extends Serializable.  A simple example would be an inner
exception class - even though most programs do not serialize exceptions,
this would trigger the proposed diagnostic.

On Wed, Aug 4, 2010 at 4:50 AM, Florian Weimer <fweimer at bfk.de> wrote:

> The JLS does not provide binary compatibility for compiler-generated
> fields (such as reference to an outer class object from an inner class
> object).  This means that there is no reliable way to use such classes
> in serialization even if all involved classes implement
> java.io.Serializable.  A mere recompilation of unchanged sources might
> result in different compiler-generated names.
>
> Would it make sense to enhance -Xlint:serial to warn about classes
> which implement java.io.Serializable and contain compiler-generated
> fields?
>
> PS: This is quite different from the frequently observed issue where a
> non-static inner class cannot be serialized because the outer class is
> not serializable.  Serialization works fine, but deserialization
> silently results in invalid objects.
>
> --
> Florian Weimer                <fweimer at bfk.de>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstra?e 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100804/13524666/attachment.html>

From fweimer at bfk.de  Wed Aug  4 15:24:10 2010
From: fweimer at bfk.de (Florian Weimer)
Date: Wed, 04 Aug 2010 15:24:10 +0000
Subject: Additional -Xlint:serial warning
In-Reply-To: <AANLkTi=5ECjg0u29wvrcgU22wYiegKRvzYjSmPeHPCau@mail.gmail.com>
	(Neal Gafter's message of "Wed\, 4 Aug 2010 08\:14\:27 -0700")
References: <82y6cm1ts1.fsf@mid.bfk.de>
	<AANLkTi=5ECjg0u29wvrcgU22wYiegKRvzYjSmPeHPCau@mail.gmail.com>
Message-ID: <82zkx2xuxx.fsf@mid.bfk.de>

* Neal Gafter:

> Unfortunately, many inner classes are only "incidentally" serializable -
> that is, they are serializable because the superclass or some implemented
> interface extends Serializable.  A simple example would be an inner
> exception class - even though most programs do not serialize exceptions,
> this would trigger the proposed diagnostic.

Inner exception classes probably should be non-static.  And many
incidentally serializable classes already receive a warning under
-Xlint due to a missing serialVersionUID field.

If necessary, the warning could be restricted to classes with a
declared serialVersionUID member, or class definitions explicitly
implementing the Serializable interface.

(I spent a few hours hunting down a bug caused by a mismatch between
this$0 and this$1, that's why I think something should be done about
it.)

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


From david.lloyd at redhat.com  Wed Aug  4 18:57:35 2010
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 04 Aug 2010 13:57:35 -0500
Subject: Additional -Xlint:serial warning
In-Reply-To: <AANLkTi=5ECjg0u29wvrcgU22wYiegKRvzYjSmPeHPCau@mail.gmail.com>
References: <82y6cm1ts1.fsf@mid.bfk.de>
	<AANLkTi=5ECjg0u29wvrcgU22wYiegKRvzYjSmPeHPCau@mail.gmail.com>
Message-ID: <4C59B81F.7000103@redhat.com>

As they should.  I agree that this diagnostic should exist.  If they have 
broken code which triggers the warning, I for one have no sympathy for them.

Put another way, there's no such thing as "incidental" serializability. 
Like it or not, you're taking on that contract when you extend a class 
that's serializable as surely as if you put the interface on your own class.

And yes, exceptions DO often end up serialized even when they're not 
directly intended to be, whether due to persistence, networking, or 
whatever.  It's part of the contract of Throwable, so there's no reason to 
ever expect it not to work.

On 08/04/2010 10:14 AM, Neal Gafter wrote:
> Unfortunately, many inner classes are only "incidentally" serializable -
> that is, they are serializable because the superclass or some
> implemented interface extends Serializable.  A simple example would be
> an inner exception class - even though most programs do not serialize
> exceptions, this would trigger the proposed diagnostic.
>
> On Wed, Aug 4, 2010 at 4:50 AM, Florian Weimer <fweimer at bfk.de
> <mailto:fweimer at bfk.de>> wrote:
>
>     The JLS does not provide binary compatibility for compiler-generated
>     fields (such as reference to an outer class object from an inner class
>     object).  This means that there is no reliable way to use such classes
>     in serialization even if all involved classes implement
>     java.io.Serializable.  A mere recompilation of unchanged sources might
>     result in different compiler-generated names.
>
>     Would it make sense to enhance -Xlint:serial to warn about classes
>     which implement java.io.Serializable and contain compiler-generated
>     fields?
>
>     PS: This is quite different from the frequently observed issue where a
>     non-static inner class cannot be serialized because the outer class is
>     not serializable.  Serialization works fine, but deserialization
>     silently results in invalid objects.
>
>     --
>     Florian Weimer <fweimer at bfk.de <mailto:fweimer at bfk.de>>
>     BFK edv-consulting GmbH http://www.bfk.de/
>     Kriegsstra?e 100              tel: +49-721-96201-1
>     D-76133 Karlsruhe             fax: +49-721-96201-99
>
>

-- 
- DML ?


From david.lloyd at redhat.com  Wed Aug  4 18:58:56 2010
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 04 Aug 2010 13:58:56 -0500
Subject: Additional -Xlint:serial warning
In-Reply-To: <82zkx2xuxx.fsf@mid.bfk.de>
References: <82y6cm1ts1.fsf@mid.bfk.de>	<AANLkTi=5ECjg0u29wvrcgU22wYiegKRvzYjSmPeHPCau@mail.gmail.com>
	<82zkx2xuxx.fsf@mid.bfk.de>
Message-ID: <4C59B870.9090701@redhat.com>

On 08/04/2010 10:24 AM, Florian Weimer wrote:
> Inner exception classes probably should be non-static.

You mean static, surely?

> And many  incidentally serializable classes already receive a warning under
> -Xlint due to a missing serialVersionUID field.
>
> If necessary, the warning could be restricted to classes with a
> declared serialVersionUID member, or class definitions explicitly
> implementing the Serializable interface.

No, I agree with the initial proposal, full-stop: serializable inner 
classes = warning under -Xlint:serial.
-- 
- DML ?


From maurizio.cimadamore at oracle.com  Thu Aug  5 08:46:59 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 05 Aug 2010 08:46:59 +0000
Subject: hg: jdk7/tl/langtools: 2 new changesets
Message-ID: <20100805084702.B594247F12@hg.openjdk.java.net>

Changeset: 0fe472f4a332
Author:    mcimadamore
Date:      2010-08-05 09:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0fe472f4a332

6881115: javac permits nested anno w/o mandatory attrs => IncompleteAnnotationException
Summary: default annotation value is not attributed
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/6881115/T6881115.java
+ test/tools/javac/annotations/6881115/T6881115.out

Changeset: 237f3bd52242
Author:    mcimadamore
Date:      2010-08-05 09:45 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/237f3bd52242

6857948: Calling a constructor with a doubly bogus argument causes an internal error
Summary: problem when constructor resolution returns an erroneous symbol
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/6857948/T6857948.java
+ test/tools/javac/6857948/T6857948.out



From andrei.pangin at sun.com  Thu Aug  5 12:49:32 2010
From: andrei.pangin at sun.com (andrei.pangin at sun.com)
Date: Thu, 05 Aug 2010 12:49:32 +0000
Subject: hg: jdk7/tl/jdk: 6945961: SIGSEGV in memcpy() during class loading on
	linux-i586
Message-ID: <20100805125012.7077847F1F@hg.openjdk.java.net>

Changeset: 188f156148ea
Author:    apangin
Date:      2010-08-04 20:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/188f156148ea

6945961: SIGSEGV in memcpy() during class loading on linux-i586
Summary: Check the result of strchr() in Bytecode Verifier
Reviewed-by: kamg, acorn

! src/share/native/common/check_code.c



From daniel.daugherty at oracle.com  Fri Aug  6 18:12:09 2010
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Fri, 06 Aug 2010 18:12:09 +0000
Subject: hg: jdk7/tl/jdk: 6962604: 3/3 Testcase
	sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh failure
Message-ID: <20100806181242.46FED47F5D@hg.openjdk.java.net>

Changeset: d47f5dcda481
Author:    dcubed
Date:      2010-08-06 11:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d47f5dcda481

6962604: 3/3 Testcase sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh failure
Summary: Disable MonitorVmStartTerminate.sh until 6543856 is fixed.
Reviewed-by: ohair

! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh



From lance.andersen at oracle.com  Tue Aug 10 14:19:03 2010
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Tue, 10 Aug 2010 14:19:03 +0000
Subject: hg: jdk7/tl/jdk: 6898593: java.sql.Date.valueOf no exception if date
	given is not in the JDBC date escape syntax
Message-ID: <20100810141912.AA9BB4704E@hg.openjdk.java.net>

Changeset: 3e239fe92832
Author:    lancea
Date:      2010-08-10 10:07 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3e239fe92832

6898593: java.sql.Date.valueOf no exception if date given is not in the JDBC date escape syntax
Reviewed-by: minqi

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



From maurizio.cimadamore at oracle.com  Tue Aug 10 15:20:35 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 10 Aug 2010 15:20:35 +0000
Subject: hg: jdk7/tl/langtools: 2 new changesets
Message-ID: <20100810152038.B396E47051@hg.openjdk.java.net>

Changeset: a2d8c7071f24
Author:    mcimadamore
Date:      2010-08-10 14:52 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a2d8c7071f24

6975275: diamond implementation needs some cleanup
Summary: resolution issues during diamond inference should be reported through Resolve.logResolveError()
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: ea1930f4b789
Author:    mcimadamore
Date:      2010-08-10 14:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ea1930f4b789

6975231: Regression test for 6881115 is failing with compiler output not matching expected output
Summary: missing symbols are collected in an HashSet which doesn't preserve ordering
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/annotations/6881115/T6881115.out
+ test/tools/javac/diags/examples/AnnotationMissingValues1.java



From chris.hegarty at oracle.com  Tue Aug 10 16:31:19 2010
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 10 Aug 2010 16:31:19 +0000
Subject: hg: jdk7/tl/jdk: 6882910: Unexplained lack of IP4 network ability
	when transparent IP6 to IP4 is disabled.
Message-ID: <20100810163132.5012247056@hg.openjdk.java.net>

Changeset: 1f996198877b
Author:    chegar
Date:      2010-08-10 17:30 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f996198877b

6882910: Unexplained lack of IP4 network ability when transparent IP6 to IP4 is disabled.
Reviewed-by: alanb

! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/PlainSocketImpl.c
! src/solaris/native/sun/nio/ch/Net.c



From xueming.shen at oracle.com  Tue Aug 10 20:17:57 2010
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Tue, 10 Aug 2010 20:17:57 +0000
Subject: hg: jdk7/tl/jdk: 6923794: About 40 JCK test case fail with
	AssertionError if -esa option is specified
Message-ID: <20100810201807.0018E47061@hg.openjdk.java.net>

Changeset: da5b67ac7755
Author:    sherman
Date:      2010-08-10 13:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da5b67ac7755

6923794: About 40 JCK test case fail with AssertionError if -esa option is specified
Summary: removed the assert
Reviewed-by: alanb

! src/solaris/classes/java/io/UnixFileSystem.java
! src/windows/classes/java/io/Win32FileSystem.java



From jacklusf at gmail.com  Tue Aug 10 21:42:28 2010
From: jacklusf at gmail.com (Xiaobin Lu)
Date: Tue, 10 Aug 2010 14:42:28 -0700
Subject: Thread.setName question
Message-ID: <AANLkTi=LgxCFVk05od_jTYw6AnZ-UuiSix7DFXu8wZEF@mail.gmail.com>

Would anyone please let me know why we convert the incoming argument of
Thread.setName() to a char array? Why can't we just store the incoming
argument to the name since String is immutable anyways?

Thanks,
-Xiaobin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100810/0246ee62/attachment.html>

From David.Holmes at oracle.com  Tue Aug 10 22:00:40 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 11 Aug 2010 08:00:40 +1000
Subject: Thread.setName question
In-Reply-To: <AANLkTi=LgxCFVk05od_jTYw6AnZ-UuiSix7DFXu8wZEF@mail.gmail.com>
References: <AANLkTi=LgxCFVk05od_jTYw6AnZ-UuiSix7DFXu8wZEF@mail.gmail.com>
Message-ID: <4C61CC08.6090709@oracle.com>

Hi Xiaobin,

Xiaobin Lu said the following on 08/11/10 07:42:
> Would anyone please let me know why we convert the incoming argument of 
> Thread.setName() to a char array? Why can't we just store the incoming 
> argument to the name since String is immutable anyways?

I know I've wondered the same thing in the past, and I can't recall the 
exact details of what I determined at the time. The only thing I 
presently recall is that the name is accessed directly from VM code 
(internally and things like JVMTI) - hence a raw char array is easier to 
access than a String object.

David




From jacklusf at gmail.com  Tue Aug 10 22:07:04 2010
From: jacklusf at gmail.com (Xiaobin Lu)
Date: Tue, 10 Aug 2010 15:07:04 -0700
Subject: Thread.setName question
In-Reply-To: <4C61CC08.6090709@oracle.com>
References: <AANLkTi=LgxCFVk05od_jTYw6AnZ-UuiSix7DFXu8wZEF@mail.gmail.com>
	<4C61CC08.6090709@oracle.com>
Message-ID: <AANLkTinaUe2w0jsANaS+4KX3YbxAVaWDGH7tF8Mm8f-J@mail.gmail.com>

Hi David,

Thanks for your reply. For a lot of enterprise applications (such as the one
I work for), a fair amount of time goes to that Thread.setName call which I
believe a significant portion is to do new char allocation and copy char
array etc. So I think we should give a second thought about how we can
efficiently store that field.

-Xiaobin

On Tue, Aug 10, 2010 at 3:00 PM, David Holmes <David.Holmes at oracle.com>wrote:

> Hi Xiaobin,
>
> Xiaobin Lu said the following on 08/11/10 07:42:
>
>  Would anyone please let me know why we convert the incoming argument of
>> Thread.setName() to a char array? Why can't we just store the incoming
>> argument to the name since String is immutable anyways?
>>
>
> I know I've wondered the same thing in the past, and I can't recall the
> exact details of what I determined at the time. The only thing I presently
> recall is that the name is accessed directly from VM code (internally and
> things like JVMTI) - hence a raw char array is easier to access than a
> String object.
>
> David
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100810/b5dbd7d6/attachment.html>

From David.Holmes at oracle.com  Tue Aug 10 23:19:57 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 11 Aug 2010 09:19:57 +1000
Subject: Thread.setName question
In-Reply-To: <AANLkTinaUe2w0jsANaS+4KX3YbxAVaWDGH7tF8Mm8f-J@mail.gmail.com>
References: <AANLkTi=LgxCFVk05od_jTYw6AnZ-UuiSix7DFXu8wZEF@mail.gmail.com>	<4C61CC08.6090709@oracle.com>
	<AANLkTinaUe2w0jsANaS+4KX3YbxAVaWDGH7tF8Mm8f-J@mail.gmail.com>
Message-ID: <4C61DE9D.9010605@oracle.com>

Xiaobin Lu said the following on 08/11/10 08:07:
> Thanks for your reply. For a lot of enterprise applications (such as the 
> one I work for), a fair amount of time goes to that Thread.setName call 
> which I believe a significant portion is to do new char allocation and 
> copy char array etc. So I think we should give a second thought about 
> how we can efficiently store that field.

There was an RFE for this way back in late 2002:

4745629 (thread) Thread.setName does needless string allocations (don't 
use char[])

The initial eval in 2002 stated:

"I can't imagine that this seriously impacts the performance of any real 
program.  Furthermore, changing the fields in Thread is problematic due 
to the close relationship of this class with the VM.  That said, it 
might be worth addressing this in the context of some Thread code-cleanup."

Then in 2005 it was closed as "will not fix":

"There are dependencies on the name representation being a char array in 
the JVM and this RFE must be respectfully rejected."

---

Changing both the VM and the Java code is, as you know, a real pain to 
coordinate, so there would have to be some compelling performance 
evidence to support this (assuming it can be changed). Personally I 
agree with the initial eval above - if setName is impacting your overall 
performance then your threads can not be doing too much real work and 
you would seem to be creating far too many threads - so I'd be 
interested to here more about the context in which this occurs.

Of course you are quite welcome to investigate whether such a change is 
feasible. ;-)

Cheers,
David

> 
> -Xiaobin
> 
> On Tue, Aug 10, 2010 at 3:00 PM, David Holmes <David.Holmes at oracle.com 
> <mailto:David.Holmes at oracle.com>> wrote:
> 
>     Hi Xiaobin,
> 
>     Xiaobin Lu said the following on 08/11/10 07:42:
> 
>         Would anyone please let me know why we convert the incoming
>         argument of Thread.setName() to a char array? Why can't we just
>         store the incoming argument to the name since String is
>         immutable anyways?
> 
> 
>     I know I've wondered the same thing in the past, and I can't recall
>     the exact details of what I determined at the time. The only thing I
>     presently recall is that the name is accessed directly from VM code
>     (internally and things like JVMTI) - hence a raw char array is
>     easier to access than a String object.
> 
>     David
> 
> 
> 


From iaroslavski at mail.ru  Wed Aug 11 13:38:18 2010
From: iaroslavski at mail.ru (Vladimir Iaroslavski)
Date: Wed, 11 Aug 2010 17:38:18 +0400
Subject: Dual-Pivot Quicksort and Sorting classes: update
Message-ID: <4C62A7CA.7030605@mail.ru>

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


From mandy.chung at oracle.com  Wed Aug 11 19:09:46 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Aug 2010 12:09:46 -0700
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
Message-ID: <4C62F57A.7060409@oracle.com>

  Fix for 6973831: NPE when printing stack trace of OOME

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

The VM preallocates OutOfMemoryError objects to improve OOM 
diagnosability. The constructor is not invoked since the OOME object 
allocation is done at VM initialization time and thus the new 
suppressedExceptions field is null which causes NPE when 
Throwable.printStackTrace() method is called on the VM preallocated OOM 
object.

The fix is to initialize the suppressedExceptions field to null instead 
of Collections.emptyList().  An alternative could be to initialize the 
suppressedException field in the VM after VM initialization is 
finished.  It doesn't handle the case when any new field initialized to 
be non-null is added in the OOM object in the future and it would 
require a VM synchronized change.  The libraries fix is simpler and 
preferred.

Thanks
Mandy


From brian.goetz at oracle.com  Wed Aug 11 19:35:02 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 11 Aug 2010 15:35:02 -0400
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C62F57A.7060409@oracle.com>
References: <4C62F57A.7060409@oracle.com>
Message-ID: <A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>

This code has thread-safety issues.  There is no happens-before between the writes to suppressedExceptions (and its referenced state) and the places where it is iterated (e.g., line 576).  

You could plug this hole by replacing the idiom at line 576 (and similar) with 
  for (Throwable se : getSuppressedExceptions()).  

This would be needed for all unsynchronized reads of suppressedException.  You could get away without it at the null check if you really were trying to squeeze some performance out and you didn't mind occasionally missing writes from other threads.


On Aug 11, 2010, at 3:09 PM, Mandy Chung wrote:

> Fix for 6973831: NPE when printing stack trace of OOME
> 
> Webrev at:
>   http://cr.openjdk.java.net/~mchung/6973831/webrev.00/
> 
> The VM preallocates OutOfMemoryError objects to improve OOM diagnosability. The constructor is not invoked since the OOME object allocation is done at VM initialization time and thus the new suppressedExceptions field is null which causes NPE when Throwable.printStackTrace() method is called on the VM preallocated OOM object.
> 
> The fix is to initialize the suppressedExceptions field to null instead of Collections.emptyList().  An alternative could be to initialize the suppressedException field in the VM after VM initialization is finished.  It doesn't handle the case when any new field initialized to be non-null is added in the OOM object in the future and it would require a VM synchronized change.  The libraries fix is simpler and preferred.
> 
> Thanks
> Mandy



From mandy.chung at oracle.com  Wed Aug 11 20:53:18 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Aug 2010 13:53:18 -0700
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>
References: <4C62F57A.7060409@oracle.com>
	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>
Message-ID: <4C630DBE.2050606@oracle.com>

  On 08/11/10 12:35, Brian Goetz wrote:
> This code has thread-safety issues.  There is no happens-before between the writes to suppressedExceptions (and its referenced state) and the places where it is iterated (e.g., line 576).
>
> You could plug this hole by replacing the idiom at line 576 (and similar) with
>    for (Throwable se : getSuppressedExceptions()).
>

Good point.  I fixed getSuppressedExceptions() be a synchronized method 
but missed the unsynchronized reads.

> This would be needed for all unsynchronized reads of suppressedException.  You could get away without it at the null check if you really were trying to squeeze some performance out and you didn't mind occasionally missing writes from other threads.
>
>

The updated webrev is at:
    http://cr.openjdk.java.net/~mchung/6973831/webrev.01/

I leave the unsynchronized read in the readObject() method as the 
Throwable object is still being deserialized and the 
suppressedExceptions is going to be replaced with a new list.

Thanks
Mandy

> On Aug 11, 2010, at 3:09 PM, Mandy Chung wrote:
>
>> Fix for 6973831: NPE when printing stack trace of OOME
>>
>> Webrev at:
>>    http://cr.openjdk.java.net/~mchung/6973831/webrev.00/
>>
>> The VM preallocates OutOfMemoryError objects to improve OOM diagnosability. The constructor is not invoked since the OOME object allocation is done at VM initialization time and thus the new suppressedExceptions field is null which causes NPE when Throwable.printStackTrace() method is called on the VM preallocated OOM object.
>>
>> The fix is to initialize the suppressedExceptions field to null instead of Collections.emptyList().  An alternative could be to initialize the suppressedException field in the VM after VM initialization is finished.  It doesn't handle the case when any new field initialized to be non-null is added in the OOM object in the future and it would require a VM synchronized change.  The libraries fix is simpler and preferred.
>>
>> Thanks
>> Mandy



From forax at univ-mlv.fr  Wed Aug 11 21:03:46 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 11 Aug 2010 23:03:46 +0200
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C630DBE.2050606@oracle.com>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>
	<4C630DBE.2050606@oracle.com>
Message-ID: <4C631032.50407@univ-mlv.fr>

Le 11/08/2010 22:53, Mandy Chung a ?crit :
>  On 08/11/10 12:35, Brian Goetz wrote:
>> This code has thread-safety issues.  There is no happens-before 
>> between the writes to suppressedExceptions (and its referenced state) 
>> and the places where it is iterated (e.g., line 576).
>>
>> You could plug this hole by replacing the idiom at line 576 (and 
>> similar) with
>>    for (Throwable se : getSuppressedExceptions()).
>>
>
> Good point.  I fixed getSuppressedExceptions() be a synchronized 
> method but missed the unsynchronized reads.
>
>> This would be needed for all unsynchronized reads of 
>> suppressedException.  You could get away without it at the null check 
>> if you really were trying to squeeze some performance out and you 
>> didn't mind occasionally missing writes from other threads.
>>
>>
>
> The updated webrev is at:
>    http://cr.openjdk.java.net/~mchung/6973831/webrev.01/
>
> I leave the unsynchronized read in the readObject() method as the 
> Throwable object is still being deserialized and the 
> suppressedExceptions is going to be replaced with a new list.
>
> Thanks
> Mandy

Brian, Mandy,
It seems this is not the sole thread-safety issue,
access to fields 'cause' or 'stackTrace' aren't thread safe too and 
detailMessage is not final.

R?mi


>
>> On Aug 11, 2010, at 3:09 PM, Mandy Chung wrote:
>>
>>> Fix for 6973831: NPE when printing stack trace of OOME
>>>
>>> Webrev at:
>>>    http://cr.openjdk.java.net/~mchung/6973831/webrev.00/
>>>
>>> The VM preallocates OutOfMemoryError objects to improve OOM 
>>> diagnosability. The constructor is not invoked since the OOME object 
>>> allocation is done at VM initialization time and thus the new 
>>> suppressedExceptions field is null which causes NPE when 
>>> Throwable.printStackTrace() method is called on the VM preallocated 
>>> OOM object.
>>>
>>> The fix is to initialize the suppressedExceptions field to null 
>>> instead of Collections.emptyList().  An alternative could be to 
>>> initialize the suppressedException field in the VM after VM 
>>> initialization is finished.  It doesn't handle the case when any new 
>>> field initialized to be non-null is added in the OOM object in the 
>>> future and it would require a VM synchronized change.  The libraries 
>>> fix is simpler and preferred.
>>>
>>> Thanks
>>> Mandy
>



From brian.goetz at oracle.com  Wed Aug 11 21:24:27 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 11 Aug 2010 17:24:27 -0400
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C630DBE.2050606@oracle.com>
References: <4C62F57A.7060409@oracle.com>
	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>
	<4C630DBE.2050606@oracle.com>
Message-ID: <853DBFC2-DD6B-43AD-A95B-AA3573CA407C@oracle.com>

Looks good now.  Serialization logic is a little confusing but seems OK.

On Aug 11, 2010, at 4:53 PM, Mandy Chung wrote:

> On 08/11/10 12:35, Brian Goetz wrote:
>> This code has thread-safety issues.  There is no happens-before between the writes to suppressedExceptions (and its referenced state) and the places where it is iterated (e.g., line 576).
>> 
>> You could plug this hole by replacing the idiom at line 576 (and similar) with
>>   for (Throwable se : getSuppressedExceptions()).
>> 
> 
> Good point.  I fixed getSuppressedExceptions() be a synchronized method but missed the unsynchronized reads.
> 
>> This would be needed for all unsynchronized reads of suppressedException.  You could get away without it at the null check if you really were trying to squeeze some performance out and you didn't mind occasionally missing writes from other threads.
>> 
>> 
> 
> The updated webrev is at:
>   http://cr.openjdk.java.net/~mchung/6973831/webrev.01/
> 
> I leave the unsynchronized read in the readObject() method as the Throwable object is still being deserialized and the suppressedExceptions is going to be replaced with a new list.
> 
> Thanks
> Mandy
> 
>> On Aug 11, 2010, at 3:09 PM, Mandy Chung wrote:
>> 
>>> Fix for 6973831: NPE when printing stack trace of OOME
>>> 
>>> Webrev at:
>>>   http://cr.openjdk.java.net/~mchung/6973831/webrev.00/
>>> 
>>> The VM preallocates OutOfMemoryError objects to improve OOM diagnosability. The constructor is not invoked since the OOME object allocation is done at VM initialization time and thus the new suppressedExceptions field is null which causes NPE when Throwable.printStackTrace() method is called on the VM preallocated OOM object.
>>> 
>>> The fix is to initialize the suppressedExceptions field to null instead of Collections.emptyList().  An alternative could be to initialize the suppressedException field in the VM after VM initialization is finished.  It doesn't handle the case when any new field initialized to be non-null is added in the OOM object in the future and it would require a VM synchronized change.  The libraries fix is simpler and preferred.
>>> 
>>> Thanks
>>> Mandy
> 



From mandy.chung at oracle.com  Wed Aug 11 21:43:14 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Aug 2010 14:43:14 -0700
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C631032.50407@univ-mlv.fr>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>
	<4C631032.50407@univ-mlv.fr>
Message-ID: <4C631972.7000708@oracle.com>

  On 08/11/10 14:03, R?mi Forax wrote:
> Brian, Mandy,
> It seems this is not the sole thread-safety issue,
> access to fields 'cause' or 'stackTrace' aren't thread safe too and 
> detailMessage is not final.
>

I agree that the getCause and setStackTrace method need to be 
synchronized.  On the other hand, the initCause and setStackTrace 
methods are used to override the values initialized in the constructor 
and so access to these fields are likely safe in practice.  I can fix it 
as part of this fix.

The "detailMessage" is not final because the VM in fact preallocates 
Throwable object (OOME and ArithmeticException) and then sets the 
'detailMessage' field directly (as the constructor is not invoked).

Mandy


From mandy.chung at oracle.com  Wed Aug 11 21:57:48 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Aug 2010 14:57:48 -0700
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C631972.7000708@oracle.com>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>	<4C631032.50407@univ-mlv.fr>
	<4C631972.7000708@oracle.com>
Message-ID: <4C631CDC.6040106@oracle.com>

  On 08/11/10 14:43, Mandy Chung wrote:
>  On 08/11/10 14:03, R?mi Forax wrote:
>> Brian, Mandy,
>> It seems this is not the sole thread-safety issue,
>> access to fields 'cause' or 'stackTrace' aren't thread safe too and 
>> detailMessage is not final.
>>
>
> I agree that the getCause and setStackTrace method need to be 
> synchronized.  On the other hand, the initCause and setStackTrace 
> methods are used to override the values initialized in the constructor 
> and so access to these fields are likely safe in practice.  I can fix 
> it as part of this fix.
>

Fixed the getCause and setStackTrace methods:
    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/

Mandy

> The "detailMessage" is not final because the VM in fact preallocates 
> Throwable object (OOME and ArithmeticException) and then sets the 
> 'detailMessage' field directly (as the constructor is not invoked).
>
> Mandy



From dl at cs.oswego.edu  Thu Aug 12 00:24:42 2010
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 11 Aug 2010 20:24:42 -0400
Subject: jsr166y/openjdk resync
Message-ID: <4C633F4A.8020009@cs.oswego.edu>


A few months ago, we simplified some of the APIs to the ForkJoin
classes (mainly, removing some methods so as to allow better
internal automation). The "jsr1yy6" versions of these
API changes have been in use since then, and we're confident
that these changes (and corresponding internal implementation
improvements) should go into the openjdk7 versions.
In case you are curious, some discussions about them
can be found in concurrency-interest list archives, including
http://cs.oswego.edu/pipermail/concurrency-interest/2010-June/007243.html

So we (mainly Martin Buchholz and I) would like to do this.
Since they involve API changes, I suspect there might be some
additional process requirements beyond us just doing the
mercurial commits. If so, can someone let us know what they
are? We already arranged to have corresponding JCK/TCK tests
updated.

-Doug



From David.Holmes at oracle.com  Thu Aug 12 01:26:26 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Thu, 12 Aug 2010 11:26:26 +1000
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C631CDC.6040106@oracle.com>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>	<4C631032.50407@univ-mlv.fr>	<4C631972.7000708@oracle.com>
	<4C631CDC.6040106@oracle.com>
Message-ID: <4C634DC2.7010408@oracle.com>

I'm a bit behind on this functionality as I have no ideas what a 
suppressed exception is. :) That aside I'm curious as to the expected 
multi-thread usage for an exception that requires these things to be 
thread-safe ? Given an exception occurs in a given thread, passing it to 
another thread should require some form of safe-publication.

David

Mandy Chung said the following on 08/12/10 07:57:
>  On 08/11/10 14:43, Mandy Chung wrote:
>>  On 08/11/10 14:03, R?mi Forax wrote:
>>> Brian, Mandy,
>>> It seems this is not the sole thread-safety issue,
>>> access to fields 'cause' or 'stackTrace' aren't thread safe too and 
>>> detailMessage is not final.
>>>
>>
>> I agree that the getCause and setStackTrace method need to be 
>> synchronized.  On the other hand, the initCause and setStackTrace 
>> methods are used to override the values initialized in the constructor 
>> and so access to these fields are likely safe in practice.  I can fix 
>> it as part of this fix.
>>
> 
> Fixed the getCause and setStackTrace methods:
>    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/
> 
> Mandy
> 
>> The "detailMessage" is not final because the VM in fact preallocates 
>> Throwable object (OOME and ArithmeticException) and then sets the 
>> 'detailMessage' field directly (as the constructor is not invoked).
>>
>> Mandy
> 


From chris.hegarty at oracle.com  Thu Aug 12 11:52:25 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Aug 2010 12:52:25 +0100
Subject: jsr166y/openjdk resync
In-Reply-To: <4C633F4A.8020009@cs.oswego.edu>
References: <4C633F4A.8020009@cs.oswego.edu>
Message-ID: <4C63E079.1040904@oracle.com>

No problem Doug, I worked with Martin on the original jsr166y 
integration into JDK7 and can certainly help with these updates.

-Chris.

Doug Lea wrote:
> 
> A few months ago, we simplified some of the APIs to the ForkJoin
> classes (mainly, removing some methods so as to allow better
> internal automation). The "jsr1yy6" versions of these
> API changes have been in use since then, and we're confident
> that these changes (and corresponding internal implementation
> improvements) should go into the openjdk7 versions.
> In case you are curious, some discussions about them
> can be found in concurrency-interest list archives, including
> http://cs.oswego.edu/pipermail/concurrency-interest/2010-June/007243.html
> 
> So we (mainly Martin Buchholz and I) would like to do this.
> Since they involve API changes, I suspect there might be some
> additional process requirements beyond us just doing the
> mercurial commits. If so, can someone let us know what they
> are? We already arranged to have corresponding JCK/TCK tests
> updated.
> 
> -Doug
> 


From David.Holmes at oracle.com  Thu Aug 12 12:58:06 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Thu, 12 Aug 2010 22:58:06 +1000
Subject: jsr166y/openjdk resync
In-Reply-To: <4C633F4A.8020009@cs.oswego.edu>
References: <4C633F4A.8020009@cs.oswego.edu>
Message-ID: <4C63EFDE.2090700@oracle.com>

Hi Doug,

I could be mistaken but at this stage I don't think new API changes have 
any additional overhead. Coordinating the code changes and test changes 
is the biggest issue.

David

Doug Lea said the following on 08/12/10 10:24:
> 
> A few months ago, we simplified some of the APIs to the ForkJoin
> classes (mainly, removing some methods so as to allow better
> internal automation). The "jsr1yy6" versions of these
> API changes have been in use since then, and we're confident
> that these changes (and corresponding internal implementation
> improvements) should go into the openjdk7 versions.
> In case you are curious, some discussions about them
> can be found in concurrency-interest list archives, including
> http://cs.oswego.edu/pipermail/concurrency-interest/2010-June/007243.html
> 
> So we (mainly Martin Buchholz and I) would like to do this.
> Since they involve API changes, I suspect there might be some
> additional process requirements beyond us just doing the
> mercurial commits. If so, can someone let us know what they
> are? We already arranged to have corresponding JCK/TCK tests
> updated.
> 
> -Doug
> 


From mandy.chung at oracle.com  Thu Aug 12 18:29:03 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Aug 2010 11:29:03 -0700
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C634DC2.7010408@oracle.com>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>	<4C631032.50407@univ-mlv.fr>	<4C631972.7000708@oracle.com>
	<4C631CDC.6040106@oracle.com> <4C634DC2.7010408@oracle.com>
Message-ID: <4C643D6F.7060700@oracle.com>

  On 08/11/10 18:26, David Holmes wrote:
> I'm a bit behind on this functionality as I have no ideas what a 
> suppressed exception is. :) 

FWIW.  The suppressed exceptions are added for automatic resource 
management (6911258).
    
http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html

> That aside I'm curious as to the expected multi-thread usage for an 
> exception that requires these things to be thread-safe ? Given an 
> exception occurs in a given thread, passing it to another thread 
> should require some form of safe-publication.
>

Agree.  May I count you as a reviewer?
    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/

Thanks
Mandy

> David
>
> Mandy Chung said the following on 08/12/10 07:57:
>>  On 08/11/10 14:43, Mandy Chung wrote:
>>>  On 08/11/10 14:03, R?mi Forax wrote:
>>>> Brian, Mandy,
>>>> It seems this is not the sole thread-safety issue,
>>>> access to fields 'cause' or 'stackTrace' aren't thread safe too and 
>>>> detailMessage is not final.
>>>>
>>>
>>> I agree that the getCause and setStackTrace method need to be 
>>> synchronized.  On the other hand, the initCause and setStackTrace 
>>> methods are used to override the values initialized in the 
>>> constructor and so access to these fields are likely safe in 
>>> practice.  I can fix it as part of this fix.
>>>
>>
>> Fixed the getCause and setStackTrace methods:
>>    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/
>>
>> Mandy
>>
>>> The "detailMessage" is not final because the VM in fact preallocates 
>>> Throwable object (OOME and ArithmeticException) and then sets the 
>>> 'detailMessage' field directly (as the constructor is not invoked).
>>>
>>> Mandy
>>



From forax at univ-mlv.fr  Thu Aug 12 19:00:29 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 12 Aug 2010 21:00:29 +0200
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C643D6F.7060700@oracle.com>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>	<4C631032.50407@univ-mlv.fr>	<4C631972.7000708@oracle.com>	<4C631CDC.6040106@oracle.com>
	<4C634DC2.7010408@oracle.com> <4C643D6F.7060700@oracle.com>
Message-ID: <4C6444CD.3010201@univ-mlv.fr>

Le 12/08/2010 20:29, Mandy Chung a ?crit :
>  On 08/11/10 18:26, David Holmes wrote:
>> I'm a bit behind on this functionality as I have no ideas what a 
>> suppressed exception is. :) 
>
> FWIW.  The suppressed exceptions are added for automatic resource 
> management (6911258).
>    
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html
>
>> That aside I'm curious as to the expected multi-thread usage for an 
>> exception that requires these things to be thread-safe ? Given an 
>> exception occurs in a given thread, passing it to another thread 
>> should require some form of safe-publication.
>>
>
> Agree.  May I count you as a reviewer?
>    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/
>
> Thanks
> Mandy

Changes are fine for me.

> The "detailMessage" is not final because the VM in fact preallocates 
> Throwable object (OOME and ArithmeticException) and then sets the 
> 'detailMessage' field directly (as the constructor is not invoked). 

I am pretty sure the VM can set this field even if it is declared final.
I think I don't see the problem.

R?mi



From alan.bateman at oracle.com  Thu Aug 12 18:56:13 2010
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 12 Aug 2010 18:56:13 +0000
Subject: hg: jdk7/tl/jdk: 6971825: (so) improve scatter/gather implementation
Message-ID: <20100812185626.EB50A470FC@hg.openjdk.java.net>

Changeset: 11ee8b471f9c
Author:    alanb
Date:      2010-08-12 19:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/11ee8b471f9c

6971825: (so) improve scatter/gather implementation
Reviewed-by: chegar, sherman

! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/IOVecWrapper.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/Util.java



From David.Holmes at oracle.com  Thu Aug 12 21:00:18 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 13 Aug 2010 07:00:18 +1000
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C643D6F.7060700@oracle.com>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>	<4C631032.50407@univ-mlv.fr>	<4C631972.7000708@oracle.com>
	<4C631CDC.6040106@oracle.com> <4C634DC2.7010408@oracle.com>
	<4C643D6F.7060700@oracle.com>
Message-ID: <4C6460E2.9020304@oracle.com>

Mandy Chung said the following on 08/13/10 04:29:
>  On 08/11/10 18:26, David Holmes wrote:
>> I'm a bit behind on this functionality as I have no ideas what a 
>> suppressed exception is. :) 
> 
> FWIW.  The suppressed exceptions are added for automatic resource 
> management (6911258).
>    
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html

Can't say I'm enthralled with the suppressed-exception part of this.

>> That aside I'm curious as to the expected multi-thread usage for an 
>> exception that requires these things to be thread-safe ? Given an 
>> exception occurs in a given thread, passing it to another thread 
>> should require some form of safe-publication.
>>
> 
> Agree.  May I count you as a reviewer?
>    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/

Reviewed. :)

David

> Thanks
> Mandy
> 
>> David
>>
>> Mandy Chung said the following on 08/12/10 07:57:
>>>  On 08/11/10 14:43, Mandy Chung wrote:
>>>>  On 08/11/10 14:03, R?mi Forax wrote:
>>>>> Brian, Mandy,
>>>>> It seems this is not the sole thread-safety issue,
>>>>> access to fields 'cause' or 'stackTrace' aren't thread safe too and 
>>>>> detailMessage is not final.
>>>>>
>>>>
>>>> I agree that the getCause and setStackTrace method need to be 
>>>> synchronized.  On the other hand, the initCause and setStackTrace 
>>>> methods are used to override the values initialized in the 
>>>> constructor and so access to these fields are likely safe in 
>>>> practice.  I can fix it as part of this fix.
>>>>
>>>
>>> Fixed the getCause and setStackTrace methods:
>>>    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/
>>>
>>> Mandy
>>>
>>>> The "detailMessage" is not final because the VM in fact preallocates 
>>>> Throwable object (OOME and ArithmeticException) and then sets the 
>>>> 'detailMessage' field directly (as the constructor is not invoked).
>>>>
>>>> Mandy
>>>
> 


From brian.goetz at oracle.com  Thu Aug 12 21:31:05 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 12 Aug 2010 17:31:05 -0400
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C6460E2.9020304@oracle.com>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>	<4C631032.50407@univ-mlv.fr>	<4C631972.7000708@oracle.com>
	<4C631CDC.6040106@oracle.com> <4C634DC2.7010408@oracle.com>
	<4C643D6F.7060700@oracle.com> <4C6460E2.9020304@oracle.com>
Message-ID: <69BBBCDF-F8C0-4965-8943-EEB1E786EA7D@oracle.com>

So, this aspect of COIN is still somewhat new, and so I think it is worth looking at carefully.  There is a specification for this feature that was discussed on coin-dev.  You might want to take a look and comment -- its not too late.

On Aug 12, 2010, at 5:00 PM, David Holmes wrote:

> Mandy Chung said the following on 08/13/10 04:29:
>> On 08/11/10 18:26, David Holmes wrote:
>>> I'm a bit behind on this functionality as I have no ideas what a suppressed exception is. :) 
>> FWIW.  The suppressed exceptions are added for automatic resource management (6911258).
>>   http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html
> 
> Can't say I'm enthralled with the suppressed-exception part of this.
> 
>>> That aside I'm curious as to the expected multi-thread usage for an exception that requires these things to be thread-safe ? Given an exception occurs in a given thread, passing it to another thread should require some form of safe-publication.
>>> 
>> Agree.  May I count you as a reviewer?
>>   http://cr.openjdk.java.net/~mchung/6973831/webrev.02/
> 
> Reviewed. :)
> 
> David
> 
>> Thanks
>> Mandy
>>> David
>>> 
>>> Mandy Chung said the following on 08/12/10 07:57:
>>>> On 08/11/10 14:43, Mandy Chung wrote:
>>>>> On 08/11/10 14:03, R?mi Forax wrote:
>>>>>> Brian, Mandy,
>>>>>> It seems this is not the sole thread-safety issue,
>>>>>> access to fields 'cause' or 'stackTrace' aren't thread safe too and detailMessage is not final.
>>>>>> 
>>>>> 
>>>>> I agree that the getCause and setStackTrace method need to be synchronized.  On the other hand, the initCause and setStackTrace methods are used to override the values initialized in the constructor and so access to these fields are likely safe in practice.  I can fix it as part of this fix.
>>>>> 
>>>> 
>>>> Fixed the getCause and setStackTrace methods:
>>>>   http://cr.openjdk.java.net/~mchung/6973831/webrev.02/
>>>> 
>>>> Mandy
>>>> 
>>>>> The "detailMessage" is not final because the VM in fact preallocates Throwable object (OOME and ArithmeticException) and then sets the 'detailMessage' field directly (as the constructor is not invoked).
>>>>> 
>>>>> Mandy
>>>> 



From mandy.chung at oracle.com  Thu Aug 12 23:22:52 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Aug 2010 16:22:52 -0700
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C6444CD.3010201@univ-mlv.fr>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>	<4C631032.50407@univ-mlv.fr>	<4C631972.7000708@oracle.com>	<4C631CDC.6040106@oracle.com>	<4C634DC2.7010408@oracle.com>
	<4C643D6F.7060700@oracle.com> <4C6444CD.3010201@univ-mlv.fr>
Message-ID: <4C64824C.10803@oracle.com>

  David, Brian, Remi,

Thanks for the review.

On 08/12/10 12:00, R?mi Forax wrote:

>> The "detailMessage" is not final because the VM in fact preallocates 
>> Throwable object (OOME and ArithmeticException) and then sets the 
>> 'detailMessage' field directly (as the constructor is not invoked). 
>
> I am pretty sure the VM can set this field even if it is declared final.
> I think I don't see the problem.
>

I will file a CR to address this and separate from this bug fix.  I 
believe that the VM has no problem setting this field even if it's 
declared final.  I may be overly cautious but I think we need the VM 
team to evaluate this.

Thanks
Mandy


From mandy.chung at oracle.com  Thu Aug 12 23:47:41 2010
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 12 Aug 2010 23:47:41 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100812234800.12AEA47112@hg.openjdk.java.net>

Changeset: 389bc53d0945
Author:    mchung
Date:      2010-08-12 16:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/389bc53d0945

6973831: NPE when printing stack trace of OOME
Summary: Initialize suppressedExceptions field to null
Reviewed-by: briangoetz, dholmes, forax

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

Changeset: cdd6d518f47e
Author:    mchung
Date:      2010-08-12 16:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cdd6d518f47e

Merge




From David.Holmes at oracle.com  Fri Aug 13 00:24:33 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 13 Aug 2010 10:24:33 +1000
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C64824C.10803@oracle.com>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>	<4C631032.50407@univ-mlv.fr>	<4C631972.7000708@oracle.com>	<4C631CDC.6040106@oracle.com>	<4C634DC2.7010408@oracle.com>	<4C643D6F.7060700@oracle.com>
	<4C6444CD.3010201@univ-mlv.fr> <4C64824C.10803@oracle.com>
Message-ID: <4C6490C1.2080409@oracle.com>

Hi Mandy,

Mandy Chung said the following on 08/13/10 09:22:
> On 08/12/10 12:00, R?mi Forax wrote:
> 
>>> The "detailMessage" is not final because the VM in fact preallocates 
>>> Throwable object (OOME and ArithmeticException) and then sets the 
>>> 'detailMessage' field directly (as the constructor is not invoked). 
>>
>> I am pretty sure the VM can set this field even if it is declared final.
>> I think I don't see the problem.
>>
> 
> I will file a CR to address this and separate from this bug fix.  I 
> believe that the VM has no problem setting this field even if it's 
> declared final.  I may be overly cautious but I think we need the VM 
> team to evaluate this.

The VM doesn't even look at the finality of the field it just does a 
direct store into memory.

The issue with having the VM modify final fields in general is that the 
compiler might reorder/hoist a load of a final field not knowing that it 
might be changed by the VM. However that would only be a problem if the 
object concerned was already accessible at the Java level and that is 
not the case with the preallocated exception objects.

Making the detail message final should be fine - though not essential.

David


From mandy.chung at oracle.com  Fri Aug 13 01:41:09 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Aug 2010 18:41:09 -0700
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <4C6490C1.2080409@oracle.com>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>	<4C631032.50407@univ-mlv.fr>	<4C631972.7000708@oracle.com>	<4C631CDC.6040106@oracle.com>	<4C634DC2.7010408@oracle.com>	<4C643D6F.7060700@oracle.com>
	<4C6444CD.3010201@univ-mlv.fr> <4C64824C.10803@oracle.com>
	<4C6490C1.2080409@oracle.com>
Message-ID: <4C64A2B5.3070604@oracle.com>

David Holmes wrote:
> Hi Mandy,
>
> Mandy Chung said the following on 08/13/10 09:22:
>> On 08/12/10 12:00, R?mi Forax wrote:
>>
>>>> The "detailMessage" is not final because the VM in fact 
>>>> preallocates Throwable object (OOME and ArithmeticException) and 
>>>> then sets the 'detailMessage' field directly (as the constructor is 
>>>> not invoked). 
>>>
>>> I am pretty sure the VM can set this field even if it is declared 
>>> final.
>>> I think I don't see the problem.
>>>
>>
>> I will file a CR to address this and separate from this bug fix.  I 
>> believe that the VM has no problem setting this field even if it's 
>> declared final.  I may be overly cautious but I think we need the VM 
>> team to evaluate this.
>
> The VM doesn't even look at the finality of the field it just does a 
> direct store into memory.
>
> The issue with having the VM modify final fields in general is that 
> the compiler might reorder/hoist a load of a final field not knowing 
> that it might be changed by the VM. However that would only be a 
> problem if the object concerned was already accessible at the Java 
> level and that is not the case with the preallocated exception objects.
>
> Making the detail message final should be fine - though not essential.

Thanks for the confirmation, David.   The preallocated exception objects 
will only be passed to Java level after the detailMessage field is set 
(and not changed again) and so it's a non-issue.

I filed 6976861 and will update the CR.

Thanks
Mandy


From lana.steuck at oracle.com  Fri Aug 13 05:49:18 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Aug 2010 05:49:18 +0000
Subject: hg: jdk7/tl: 2 new changesets
Message-ID: <20100813054918.8EEB047131@hg.openjdk.java.net>

Changeset: f8be576feefc
Author:    cl
Date:      2010-07-29 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/f8be576feefc

Added tag jdk7-b103 for changeset be2aedc4e3b1

! .hgtags

Changeset: 9f96a4269d77
Author:    cl
Date:      2010-08-06 12:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/9f96a4269d77

Added tag jdk7-b104 for changeset f8be576feefc

! .hgtags



From lana.steuck at oracle.com  Fri Aug 13 05:49:23 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Aug 2010 05:49:23 +0000
Subject: hg: jdk7/tl/corba: 2 new changesets
Message-ID: <20100813054924.BCA4A47132@hg.openjdk.java.net>

Changeset: 9607213481d4
Author:    cl
Date:      2010-07-29 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/9607213481d4

Added tag jdk7-b103 for changeset 11e7678c3eb1

! .hgtags

Changeset: 6f21b030092f
Author:    cl
Date:      2010-08-06 12:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/6f21b030092f

Added tag jdk7-b104 for changeset 9607213481d4

! .hgtags



From lana.steuck at oracle.com  Fri Aug 13 05:54:10 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Aug 2010 05:54:10 +0000
Subject: hg: jdk7/tl/jaxp: 2 new changesets
Message-ID: <20100813055410.D6BED47136@hg.openjdk.java.net>

Changeset: d42c4acb6424
Author:    cl
Date:      2010-07-29 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/d42c4acb6424

Added tag jdk7-b103 for changeset b7722e878864

! .hgtags

Changeset: 3233b9a4c12e
Author:    cl
Date:      2010-08-06 12:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/3233b9a4c12e

Added tag jdk7-b104 for changeset d42c4acb6424

! .hgtags



From lana.steuck at oracle.com  Fri Aug 13 05:54:15 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Aug 2010 05:54:15 +0000
Subject: hg: jdk7/tl/jaxws: 2 new changesets
Message-ID: <20100813055415.E635A47137@hg.openjdk.java.net>

Changeset: bbc4cce6c20a
Author:    cl
Date:      2010-07-29 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/bbc4cce6c20a

Added tag jdk7-b103 for changeset 267386d6b923

! .hgtags

Changeset: 39eb4f3031f4
Author:    cl
Date:      2010-08-06 12:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/39eb4f3031f4

Added tag jdk7-b104 for changeset bbc4cce6c20a

! .hgtags



From lana.steuck at oracle.com  Fri Aug 13 05:55:38 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Aug 2010 05:55:38 +0000
Subject: hg: jdk7/tl/jdk: 21 new changesets
Message-ID: <20100813055900.A0CE247139@hg.openjdk.java.net>

Changeset: b839344245a9
Author:    cl
Date:      2010-07-29 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b839344245a9

Added tag jdk7-b103 for changeset 6488b70a23cc

! .hgtags

Changeset: 6950da80c75c
Author:    ohair
Date:      2010-08-02 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6950da80c75c

6973616: Update minimum boot jdk from 1.5 to 1.6
Reviewed-by: igor, jjg

! make/common/shared/Defs-versions.gmk

Changeset: dd48c78218a7
Author:    ohair
Date:      2010-08-02 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd48c78218a7

6971426: jdk/make/docs docs target does not work on windows
Reviewed-by: igor, jjg

! make/docs/Makefile

Changeset: f46ec75b1663
Author:    ohair
Date:      2010-08-03 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f46ec75b1663

6974239: Correct reference to jdk document site in javadoc
Reviewed-by: skannan

! make/docs/Makefile

Changeset: 1a92820132a0
Author:    cl
Date:      2010-08-04 22:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1a92820132a0

Merge


Changeset: d967f8507d9d
Author:    cl
Date:      2010-08-06 12:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d967f8507d9d

Added tag jdk7-b104 for changeset 1a92820132a0

! .hgtags

Changeset: 539528c5d395
Author:    lana
Date:      2010-07-14 09:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/539528c5d395

Merge


Changeset: cf0c23a99823
Author:    lana
Date:      2010-07-29 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cf0c23a99823

Merge

- src/linux/doc/man/ja/kinit.1
- src/linux/doc/man/ja/klist.1
- src/linux/doc/man/ja/ktab.1
- test/java/nio/channels/ServerSocketChannel/AcceptAddress.java
- test/java/nio/charset/coders/Surrogate.java
- test/tools/launcher/Makefile.SolarisRunpath
- test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so
- test/tools/launcher/lib/i386/lib32/liblibrary.so
- test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so
- test/tools/launcher/lib/sparc/lib32/liblibrary.so
- test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so
- test/tools/launcher/lib/sparc/lib64/liblibrary.so

Changeset: c6f443c3d96a
Author:    lana
Date:      2010-08-02 19:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c6f443c3d96a

Merge


Changeset: c38803ce0560
Author:    uta
Date:      2010-07-23 18:59 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c38803ce0560

6969851: VM hangs/crashes in FileDialog test (VS2008/2010 build)
Reviewed-by: prr, art

! src/windows/native/sun/windows/awt.h

Changeset: 9bb8d5c093fc
Author:    lana
Date:      2010-07-29 13:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9bb8d5c093fc

Merge

- src/linux/doc/man/ja/kinit.1
- src/linux/doc/man/ja/klist.1
- src/linux/doc/man/ja/ktab.1
- test/java/nio/channels/ServerSocketChannel/AcceptAddress.java
- test/java/nio/charset/coders/Surrogate.java
- test/tools/launcher/Makefile.SolarisRunpath
- test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so
- test/tools/launcher/lib/i386/lib32/liblibrary.so
- test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so
- test/tools/launcher/lib/sparc/lib32/liblibrary.so
- test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so
- test/tools/launcher/lib/sparc/lib64/liblibrary.so

Changeset: 8a72583dc41d
Author:    lana
Date:      2010-08-02 19:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8a72583dc41d

Merge


Changeset: 65403b9bcb58
Author:    peterz
Date:      2010-07-13 17:26 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/65403b9bcb58

6462562: InternationalFormatter inserts text incorrectly
6578432: Currency format instance does not work with Swing's NumberFormatter
Reviewed-by: rupashka

! src/share/classes/javax/swing/text/DefaultFormatter.java
! src/share/classes/javax/swing/text/InternationalFormatter.java
+ test/javax/swing/JFormattedTextField/Test6462562.java

Changeset: a0d7b76abcd3
Author:    alexp
Date:      2010-07-29 19:34 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a0d7b76abcd3

4743225: Size of JComboBox list is wrong when list is populated via PopupMenuListener
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java
+ test/javax/swing/JComboBox/4743225/bug4743225.java

Changeset: 0e8acbf12695
Author:    lana
Date:      2010-07-29 13:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0e8acbf12695

Merge

- src/linux/doc/man/ja/kinit.1
- src/linux/doc/man/ja/klist.1
- src/linux/doc/man/ja/ktab.1
- test/java/nio/channels/ServerSocketChannel/AcceptAddress.java
- test/java/nio/charset/coders/Surrogate.java
- test/tools/launcher/Makefile.SolarisRunpath
- test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so
- test/tools/launcher/lib/i386/lib32/liblibrary.so
- test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so
- test/tools/launcher/lib/sparc/lib32/liblibrary.so
- test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so
- test/tools/launcher/lib/sparc/lib64/liblibrary.so

Changeset: 951e46d93af0
Author:    malenkov
Date:      2010-07-30 19:21 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/951e46d93af0

6199676: REGRESSION: ColorChooser loses preview when change LandF in Java5
Reviewed-by: alexp, peterz

! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java
+ test/javax/swing/JColorChooser/Test6199676.java

Changeset: f40de306ab66
Author:    malenkov
Date:      2010-07-30 19:40 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f40de306ab66

6972468: Security manager should be used for tests in java/beans/XMLEncoder
Reviewed-by: peterz

! test/java/beans/XMLEncoder/Test4631471.java
! test/java/beans/XMLEncoder/Test4903007.java
! test/java/beans/XMLEncoder/javax_swing_JLayeredPane.java

Changeset: ce1e26600ab7
Author:    lana
Date:      2010-08-02 19:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ce1e26600ab7

Merge


Changeset: 10e7e04d1e96
Author:    lana
Date:      2010-08-02 19:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/10e7e04d1e96

Merge

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

Changeset: 3b0abcb51280
Author:    lana
Date:      2010-08-09 16:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b0abcb51280

Merge

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

Changeset: 041997c49f15
Author:    lana
Date:      2010-08-12 19:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/041997c49f15

Merge




From lana.steuck at oracle.com  Fri Aug 13 05:52:06 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Aug 2010 05:52:06 +0000
Subject: hg: jdk7/tl/hotspot: 20 new changesets
Message-ID: <20100813055241.E622447133@hg.openjdk.java.net>

Changeset: efd4401fab1d
Author:    cl
Date:      2010-07-29 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/efd4401fab1d

Added tag jdk7-b103 for changeset cb4250ef73b2

! .hgtags

Changeset: e7ec8cd4dd8a
Author:    tonyp
Date:      2010-06-28 14:13 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e7ec8cd4dd8a

6962569: assembler_sparc.cpp:1969: assert(false) failed: error
Summary: array_overlap_test() fails when the address range crosses the MSB boundary. Thanks to Tom and Vladimir for their help on this one.
Reviewed-by: kvn, never, iveresov

! src/cpu/sparc/vm/stubGenerator_sparc.cpp

Changeset: 4e5661ba9d98
Author:    tonyp
Date:      2010-06-28 14:13 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4e5661ba9d98

6944166: G1: explicit GCs are not always handled correctly
Summary: G1 was not handling explicit GCs correctly in many ways. It does now. See the CR for the list of improvements contained in this changeset.
Reviewed-by: iveresov, ysr, johnc

! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp
! 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/vm_operations_g1.cpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp
! src/share/vm/gc_implementation/includeDB_gc_g1
! src/share/vm/gc_implementation/shared/vmGCOperations.hpp
! src/share/vm/gc_interface/gcCause.cpp
! src/share/vm/runtime/mutexLocker.cpp

Changeset: 1a1ce2076047
Author:    ysr
Date:      2010-07-16 10:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1a1ce2076047

Merge


Changeset: ad7e433e2730
Author:    ysr
Date:      2010-07-20 16:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ad7e433e2730

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/runtime/vtune.hpp

Changeset: 131ed9a23d48
Author:    ysr
Date:      2010-07-21 09:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/131ed9a23d48

Merge


Changeset: 083fde3b838e
Author:    jrose
Date:      2010-07-15 18:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/083fde3b838e

6964498: JSR 292 invokedynamic sites need local bootstrap methods
Summary: Add JVM_CONSTANT_InvokeDynamic records to constant pool to determine per-instruction BSMs.
Reviewed-by: twisti

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/oops/constantPoolOop.hpp
! src/share/vm/oops/cpCacheOop.cpp
! src/share/vm/oops/cpCacheOop.hpp
! src/share/vm/prims/jvm.h
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/constantTag.cpp
! src/share/vm/utilities/constantTag.hpp

Changeset: 01b172b8cd7c
Author:    never
Date:      2010-07-16 08:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/01b172b8cd7c

Merge


Changeset: e0ba4e04c839
Author:    jrose
Date:      2010-07-16 18:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e0ba4e04c839

6969574: invokedynamic call sites deoptimize instead of executing
Reviewed-by: kvn

! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/oops/cpCacheOop.cpp
! src/share/vm/oops/cpCacheOop.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/prims/methodHandleWalk.cpp

Changeset: 7139e81efd2d
Author:    never
Date:      2010-07-22 15:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7139e81efd2d

6970566: runThese fails with SIGSEGV
Reviewed-by: kvn

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

Changeset: 5063ce716349
Author:    never
Date:      2010-07-23 10:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5063ce716349

Merge


Changeset: a93a9eda13f7
Author:    jcoomes
Date:      2010-07-16 21:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a93a9eda13f7

6962947: shared TaskQueue statistics
Reviewed-by: tonyp, ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/gc_implementation/parNew/parOopClosures.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/psTasks.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/taskqueue.cpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: 5cbac8938c4c
Author:    johnc
Date:      2010-07-19 11:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5cbac8938c4c

6956639: G1: assert(cached_ptr != card_ptr) failed: shouldn't be, concurrentG1Refine.cpp:307
Summary: During concurrent refinment, filter cards in young regions after it has been determined that the region has been allocated from and the young type of the region has been set.
Reviewed-by: iveresov, tonyp, jcoomes

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

Changeset: 4f1fffe08c63
Author:    ysr
Date:      2010-07-21 12:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4f1fffe08c63

Merge


Changeset: 1890dc9151da
Author:    ysr
Date:      2010-07-23 14:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1890dc9151da

Merge


Changeset: cc3fdfeb54b0
Author:    trims
Date:      2010-07-29 23:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cc3fdfeb54b0

Merge


Changeset: fd2645290e89
Author:    trims
Date:      2010-07-30 06:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fd2645290e89

6973381: Bump the HS19 build number to 05
Summary: Update the HS19 build number to 05
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 28abe3f6a5f6
Author:    trims
Date:      2010-08-03 19:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/28abe3f6a5f6

Merge


Changeset: b4acf10eb134
Author:    trims
Date:      2010-08-05 02:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b4acf10eb134

Added tag hs19-b04 for changeset e55900b5c1b8

! .hgtags

Changeset: 6709c14587c2
Author:    cl
Date:      2010-08-06 12:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6709c14587c2

Added tag jdk7-b104 for changeset b4acf10eb134

! .hgtags



From lana.steuck at oracle.com  Fri Aug 13 06:00:17 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Aug 2010 06:00:17 +0000
Subject: hg: jdk7/tl/langtools: 5 new changesets
Message-ID: <20100813060025.AE9BB4713A@hg.openjdk.java.net>

Changeset: fc7219517ec1
Author:    cl
Date:      2010-07-29 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fc7219517ec1

Added tag jdk7-b103 for changeset bd85271c580c

! .hgtags

Changeset: 49489c1d8fae
Author:    cl
Date:      2010-08-06 12:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/49489c1d8fae

Added tag jdk7-b104 for changeset fc7219517ec1

! .hgtags

Changeset: 186feb2042f0
Author:    lana
Date:      2010-08-02 19:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/186feb2042f0

Merge


Changeset: aaecac256d39
Author:    lana
Date:      2010-08-09 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/aaecac256d39

Merge


Changeset: c04ae2714f52
Author:    lana
Date:      2010-08-12 19:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c04ae2714f52

Merge




From chris.hegarty at oracle.com  Fri Aug 13 13:58:29 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 13 Aug 2010 14:58:29 +0100
Subject: Threads should not be Cloneable
Message-ID: <4C654F85.5020905@oracle.com>


The issue of whether Threads should be Cloneable came up during the 
discussion of another problem. I talked to David about this and we 
believe there is no value being able to clone a thread, in fact it can 
cause some strange problems. David sent a mail [1] to the 
concurrency-interest mailing list requesting feedback on this. No 
objections to date.

To that end, I filed CR 6968584: "Thread should not be Cloneable" and am 
proposing to add the following to Thread:

     /**
      * Throws CloneNotSupportedException as a Thread can not be 
meaningfully
      * cloned. Construct a new Thread instead.
      *
      * @throws  CloneNotSupportedException
      *          always
      */
     protected final Object clone() throws CloneNotSupportedException {
         throw new CloneNotSupportedException();
     }

Thanks,
-Chris.

[1] 
http://cs.oswego.edu/pipermail/concurrency-interest/2010-August/007326.html


From brian.goetz at oracle.com  Fri Aug 13 14:01:21 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 13 Aug 2010 10:01:21 -0400
Subject: Threads should not be Cloneable
In-Reply-To: <4C654F85.5020905@oracle.com>
References: <4C654F85.5020905@oracle.com>
Message-ID: <3A57399A-92B2-4D2F-8328-372867BF6A13@oracle.com>

Explicit non-objection :)

On Aug 13, 2010, at 9:58 AM, Chris Hegarty wrote:

> 
> The issue of whether Threads should be Cloneable came up during the discussion of another problem. I talked to David about this and we believe there is no value being able to clone a thread, in fact it can cause some strange problems. David sent a mail [1] to the concurrency-interest mailing list requesting feedback on this. No objections to date.
> 
> To that end, I filed CR 6968584: "Thread should not be Cloneable" and am proposing to add the following to Thread:
> 
>    /**
>     * Throws CloneNotSupportedException as a Thread can not be meaningfully
>     * cloned. Construct a new Thread instead.
>     *
>     * @throws  CloneNotSupportedException
>     *          always
>     */
>    protected final Object clone() throws CloneNotSupportedException {
>        throw new CloneNotSupportedException();
>    }
> 
> Thanks,
> -Chris.
> 
> [1] http://cs.oswego.edu/pipermail/concurrency-interest/2010-August/007326.html



From tom.hawtin at oracle.com  Fri Aug 13 14:12:03 2010
From: tom.hawtin at oracle.com (tom.hawtin at oracle.com)
Date: Fri, 13 Aug 2010 15:12:03 +0100
Subject: Threads should not be Cloneable
In-Reply-To: <4C654F85.5020905@oracle.com>
References: <4C654F85.5020905@oracle.com>
Message-ID: <4C6552B3.7090509@oracle.com>

On 13/08/2010 14:58, Chris Hegarty wrote:

>     protected final Object clone() throws CloneNotSupportedException {
>         throw new CloneNotSupportedException();

The final can (and should, IMO) be removed.

Tom


From chris.hegarty at oracle.com  Fri Aug 13 14:15:53 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 13 Aug 2010 15:15:53 +0100
Subject: Threads should not be Cloneable
In-Reply-To: <4C6552B3.7090509@oracle.com>
References: <4C654F85.5020905@oracle.com> <4C6552B3.7090509@oracle.com>
Message-ID: <4C655399.1070808@oracle.com>

On 13/08/2010 15:12, tom.hawtin at oracle.com wrote:
> On 13/08/2010 14:58, Chris Hegarty wrote:
>
>> protected final Object clone() throws CloneNotSupportedException {
>> throw new CloneNotSupportedException();
>
> The final can (and should, IMO) be removed.

OK, so we'll allow subclasses to crate their own clones but disallow 
access to the default Object.clone implementation. I don't have a 
particular problem with this.

-Chris.

>
> Tom


From forax at univ-mlv.fr  Fri Aug 13 14:30:46 2010
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Fri, 13 Aug 2010 16:30:46 +0200
Subject: Threads should not be Cloneable
In-Reply-To: <4C655399.1070808@oracle.com>
References: <4C654F85.5020905@oracle.com> <4C6552B3.7090509@oracle.com>
	<4C655399.1070808@oracle.com>
Message-ID: <4C655716.3070902@univ-mlv.fr>

Le 13/08/2010 16:15, Chris Hegarty a ?crit :
> On 13/08/2010 15:12, tom.hawtin at oracle.com wrote:
>> On 13/08/2010 14:58, Chris Hegarty wrote:
>>
>>> protected final Object clone() throws CloneNotSupportedException {
>>> throw new CloneNotSupportedException();
>>
>> The final can (and should, IMO) be removed.
>
> OK, so we'll allow subclasses to crate their own clones but disallow 
> access to the default Object.clone implementation. I don't have a 
> particular problem with this.
>
> -Chris.
>
>>
>> Tom

Knowning that the default implementation doesn't work for Thread,
it seems a reasonable choice.

R?mi


From schlosna at gmail.com  Fri Aug 13 16:06:25 2010
From: schlosna at gmail.com (David Schlosnagle)
Date: Fri, 13 Aug 2010 12:06:25 -0400
Subject: Threads should not be Cloneable
In-Reply-To: <4C655399.1070808@oracle.com>
References: <4C654F85.5020905@oracle.com> <4C6552B3.7090509@oracle.com>
	<4C655399.1070808@oracle.com>
Message-ID: <AANLkTikoBBuOuRKu+xTjYATz0Ro919X0627vJabgKfPR@mail.gmail.com>

On Fri, Aug 13, 2010 at 10:15 AM, Chris Hegarty
<chris.hegarty at oracle.com> wrote:
> OK, so we'll allow subclasses to crate their own clones but disallow access
> to the default Object.clone implementation. I don't have a particular
> problem with this.
>
> -Chris.

I may be missing something, but if java.lang.Thread.clone() will now
throw CloneNotSupportedException, how would subtypes properly
implement Cloneable? If the subtype calls super.clone(),
CloneNotSupportedException will be thrown. If the subtype calls its
own constructor, that would seem to violate the clone contract for any
further subtypes. I think it would seem best to either strictly forbid
cloning all j.l.Thread and subtypes by making j.l.Thread.clone() final
and always throw CloneNotSupportedException, or if you are concerned
about violating source compatibility by making j.l.Thread.clone()
final then you could make it throw CloneNotSupportedException for
threadStatus != 0 (i.e. NEW threads).

- Dave


From dl at cs.oswego.edu  Fri Aug 13 16:59:03 2010
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 13 Aug 2010 12:59:03 -0400
Subject: Thread.getState() very slow
In-Reply-To: <4C3FD549.5060007@oracle.com>
References: <4C387723.2070407@cs.oswego.edu>
	<4C39440B.5070501@oracle.com>	<4C39A8E1.4050502@cs.oswego.edu>
	<4C3A43B0.8010200@oracle.com> <4C3FD549.5060007@oracle.com>
Message-ID: <4C6579D7.5090006@cs.oswego.edu>

Sorry for the long delay on this...

On 07/15/10 23:43, Mandy Chung wrote:
> I think making Thread.threadStatus a volatile field and using
> JVMTI_JAVA_LANG_THREAD_STATE_MASK to convert Thread.threadStatus to Thread.State
> enum would be a good solution.
>
>
> It'd be great if Doug can do the experiment and evaluate the performance impact.
> If you want me to prototype the jdk change, let me know and I should be able to
> make some time to do it next week.
>

I did an equivalent experiment (of just directly accessing
threadState via Unsafe.getIntVolatile and comparing it to
cached values) and it was about 14X faster.  So anything
along these lines would be grat. That said, I decided not
to try to rely on getState in the near term. (Among other
reasons, it does not usually reflect IO blockage.) So this
is off the critical path for now. But someday someone is sure
to run into similar performance issues unless implementation
is improved.

-Doug



From martinrb at google.com  Fri Aug 13 17:18:22 2010
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 13 Aug 2010 10:18:22 -0700
Subject: Thread.getState() very slow
In-Reply-To: <4C6579D7.5090006@cs.oswego.edu>
References: <4C387723.2070407@cs.oswego.edu> <4C39440B.5070501@oracle.com>
	<4C39A8E1.4050502@cs.oswego.edu> <4C3A43B0.8010200@oracle.com>
	<4C3FD549.5060007@oracle.com> <4C6579D7.5090006@cs.oswego.edu>
Message-ID: <AANLkTinAMfJRwY+q=2dnu+Y+52JCN3pUYD8j-9A-Y6Qz@mail.gmail.com>

As a related project, we could fix the JDK so that threads blocked in IO
operations would be much more likely to also report a thread state of
BLOCKED.

Martin

On Fri, Aug 13, 2010 at 09:59, Doug Lea <dl at cs.oswego.edu> wrote:

> Sorry for the long delay on this...
>
>
> On 07/15/10 23:43, Mandy Chung wrote:
>
>> I think making Thread.threadStatus a volatile field and using
>> JVMTI_JAVA_LANG_THREAD_STATE_MASK to convert Thread.threadStatus to
>> Thread.State
>> enum would be a good solution.
>>
>>
>> It'd be great if Doug can do the experiment and evaluate the performance
>> impact.
>> If you want me to prototype the jdk change, let me know and I should be
>> able to
>> make some time to do it next week.
>>
>>
> I did an equivalent experiment (of just directly accessing
> threadState via Unsafe.getIntVolatile and comparing it to
> cached values) and it was about 14X faster.  So anything
> along these lines would be grat. That said, I decided not
> to try to rely on getState in the near term. (Among other
> reasons, it does not usually reflect IO blockage.) So this
> is off the critical path for now. But someday someone is sure
> to run into similar performance issues unless implementation
> is improved.
>
> -Doug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100813/1920cda4/attachment.html>

From mandy.chung at oracle.com  Fri Aug 13 17:30:08 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 13 Aug 2010 10:30:08 -0700
Subject: Thread.getState() very slow
In-Reply-To: <4C6579D7.5090006@cs.oswego.edu>
References: <4C387723.2070407@cs.oswego.edu>
	<4C39440B.5070501@oracle.com>	<4C39A8E1.4050502@cs.oswego.edu>
	<4C3A43B0.8010200@oracle.com> <4C3FD549.5060007@oracle.com>
	<4C6579D7.5090006@cs.oswego.edu>
Message-ID: <4C658120.9080206@oracle.com>

Hi Doug,

Doug Lea wrote:
> Sorry for the long delay on this...
>
> On 07/15/10 23:43, Mandy Chung wrote:
>> I think making Thread.threadStatus a volatile field and using
>> JVMTI_JAVA_LANG_THREAD_STATE_MASK to convert Thread.threadStatus to 
>> Thread.State
>> enum would be a good solution.
>>
>>
>> It'd be great if Doug can do the experiment and evaluate the 
>> performance impact.
>> If you want me to prototype the jdk change, let me know and I should 
>> be able to
>> make some time to do it next week.
>>
>
> I did an equivalent experiment (of just directly accessing
> threadState via Unsafe.getIntVolatile and comparing it to
> cached values) and it was about 14X faster.  So anything
> along these lines would be grat. That said, I decided not
> to try to rely on getState in the near term. (Among other
> reasons, it does not usually reflect IO blockage.) So this
> is off the critical path for now. But someday someone is sure
> to run into similar performance issues unless implementation
> is improved.
>

Thanks for doing the experiment and the performance number which is 
great.  I file 2 CRs:

6977034: Thread.getState() very slow
6977039: Extend Thread.State.BLOCKED to reflect blocking on I/O state

Mandy


From jeremymanson at google.com  Fri Aug 13 17:54:39 2010
From: jeremymanson at google.com (Jeremy Manson)
Date: Fri, 13 Aug 2010 10:54:39 -0700
Subject: Thread.getState() very slow
In-Reply-To: <AANLkTinAMfJRwY+q=2dnu+Y+52JCN3pUYD8j-9A-Y6Qz@mail.gmail.com>
References: <4C387723.2070407@cs.oswego.edu> <4C39440B.5070501@oracle.com>
	<4C39A8E1.4050502@cs.oswego.edu> <4C3A43B0.8010200@oracle.com>
	<4C3FD549.5060007@oracle.com> <4C6579D7.5090006@cs.oswego.edu>
	<AANLkTinAMfJRwY+q=2dnu+Y+52JCN3pUYD8j-9A-Y6Qz@mail.gmail.com>
Message-ID: <AANLkTi=VjPT2CcnbrjoNP5JrOOs-BKGKhf=efL3MV0dj@mail.gmail.com>

Second, FWIW.  Our users are constantly baffled as to why all of their
blocked-on-epoll threads are listed as RUNNABLE.

Jeremy

On Fri, Aug 13, 2010 at 10:18 AM, Martin Buchholz <martinrb at google.com> wrote:
> As a related project, we could fix the JDK so that threads blocked in IO
> operations would be much more likely to also report a thread state of
> BLOCKED.
>
> Martin
>
> On Fri, Aug 13, 2010 at 09:59, Doug Lea <dl at cs.oswego.edu> wrote:
>>
>> Sorry for the long delay on this...
>>
>> On 07/15/10 23:43, Mandy Chung wrote:
>>>
>>> I think making Thread.threadStatus a volatile field and using
>>> JVMTI_JAVA_LANG_THREAD_STATE_MASK to convert Thread.threadStatus to
>>> Thread.State
>>> enum would be a good solution.
>>>
>>>
>>> It'd be great if Doug can do the experiment and evaluate the performance
>>> impact.
>>> If you want me to prototype the jdk change, let me know and I should be
>>> able to
>>> make some time to do it next week.
>>>
>>
>> I did an equivalent experiment (of just directly accessing
>> threadState via Unsafe.getIntVolatile and comparing it to
>> cached values) and it was about 14X faster. ?So anything
>> along these lines would be grat. That said, I decided not
>> to try to rely on getState in the near term. (Among other
>> reasons, it does not usually reflect IO blockage.) So this
>> is off the critical path for now. But someday someone is sure
>> to run into similar performance issues unless implementation
>> is improved.
>>
>> -Doug
>>
>
>


From ahughes at redhat.com  Fri Aug 13 21:27:25 2010
From: ahughes at redhat.com (ahughes at redhat.com)
Date: Fri, 13 Aug 2010 21:27:25 +0000
Subject: hg: jdk7/tl/jdk: 6976186: Integrate Shark
Message-ID: <20100813212737.E9C8A4716A@hg.openjdk.java.net>

Changeset: 0cdd73548292
Author:    gbenson
Date:      2010-08-13 22:26 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0cdd73548292

6976186: Integrate Shark
Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure.
Reviewed-by: ohair

! make/jdk_generic_profile.sh



From David.Holmes at oracle.com  Fri Aug 13 23:21:54 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Sat, 14 Aug 2010 09:21:54 +1000
Subject: Threads should not be Cloneable
In-Reply-To: <4C6552B3.7090509@oracle.com>
References: <4C654F85.5020905@oracle.com> <4C6552B3.7090509@oracle.com>
Message-ID: <4C65D392.9000204@oracle.com>

tom.hawtin at oracle.com said the following on 08/14/10 00:12:
> On 13/08/2010 14:58, Chris Hegarty wrote:
> 
>>     protected final Object clone() throws CloneNotSupportedException {
>>         throw new CloneNotSupportedException();
> 
> The final can (and should, IMO) be removed.

Why? What purpose would it serve?

You can not clone the Thread. The "clone" of the subclass could only be 
done via construction - so just use a constructor in the first place. As 
David Schlosnagle points out any subclass of that "Cloneable" would have 
to use a similar construction-based clone because super.clone() can not 
return the correct type. That's a bug waiting to happen.

Why given even the smallest illusion that a Thread subclass can be cloned?

David


From David.Holmes at oracle.com  Fri Aug 13 23:33:06 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Sat, 14 Aug 2010 09:33:06 +1000
Subject: Thread.getState() very slow
In-Reply-To: <AANLkTi=VjPT2CcnbrjoNP5JrOOs-BKGKhf=efL3MV0dj@mail.gmail.com>
References: <4C387723.2070407@cs.oswego.edu>
	<4C39440B.5070501@oracle.com>	<4C39A8E1.4050502@cs.oswego.edu>
	<4C3A43B0.8010200@oracle.com>	<4C3FD549.5060007@oracle.com>
	<4C6579D7.5090006@cs.oswego.edu>	<AANLkTinAMfJRwY+q=2dnu+Y+52JCN3pUYD8j-9A-Y6Qz@mail.gmail.com>
	<AANLkTi=VjPT2CcnbrjoNP5JrOOs-BKGKhf=efL3MV0dj@mail.gmail.com>
Message-ID: <4C65D632.1010208@oracle.com>

The problem is, when it comes to I/O, many operations are potentially 
blocking, but we don't know that a-priori. At best I think we could have 
a state that indicates it is executing an IO operation, but we can't 
know if it is actually blocking.

David

Jeremy Manson said the following on 08/14/10 03:54:
> Second, FWIW.  Our users are constantly baffled as to why all of their
> blocked-on-epoll threads are listed as RUNNABLE.
> 
> Jeremy
> 
> On Fri, Aug 13, 2010 at 10:18 AM, Martin Buchholz <martinrb at google.com> wrote:
>> As a related project, we could fix the JDK so that threads blocked in IO
>> operations would be much more likely to also report a thread state of
>> BLOCKED.
>>
>> Martin
>>
>> On Fri, Aug 13, 2010 at 09:59, Doug Lea <dl at cs.oswego.edu> wrote:
>>> Sorry for the long delay on this...
>>>
>>> On 07/15/10 23:43, Mandy Chung wrote:
>>>> I think making Thread.threadStatus a volatile field and using
>>>> JVMTI_JAVA_LANG_THREAD_STATE_MASK to convert Thread.threadStatus to
>>>> Thread.State
>>>> enum would be a good solution.
>>>>
>>>>
>>>> It'd be great if Doug can do the experiment and evaluate the performance
>>>> impact.
>>>> If you want me to prototype the jdk change, let me know and I should be
>>>> able to
>>>> make some time to do it next week.
>>>>
>>> I did an equivalent experiment (of just directly accessing
>>> threadState via Unsafe.getIntVolatile and comparing it to
>>> cached values) and it was about 14X faster.  So anything
>>> along these lines would be grat. That said, I decided not
>>> to try to rely on getState in the near term. (Among other
>>> reasons, it does not usually reflect IO blockage.) So this
>>> is off the critical path for now. But someday someone is sure
>>> to run into similar performance issues unless implementation
>>> is improved.
>>>
>>> -Doug
>>>
>>


From schlosna at gmail.com  Sat Aug 14 00:24:37 2010
From: schlosna at gmail.com (David Schlosnagle)
Date: Fri, 13 Aug 2010 20:24:37 -0400
Subject: Threads should not be Cloneable
In-Reply-To: <4C65D392.9000204@oracle.com>
References: <4C654F85.5020905@oracle.com> <4C6552B3.7090509@oracle.com>
	<4C65D392.9000204@oracle.com>
Message-ID: <AANLkTi=qUCOyAfpcJRkWNids+ghPBn622yBGx1+a784O@mail.gmail.com>

On Fri, Aug 13, 2010 at 7:21 PM, David Holmes <David.Holmes at oracle.com> wrote:
> tom.hawtin at oracle.com said the following on 08/14/10 00:12:
>>
>> On 13/08/2010 14:58, Chris Hegarty wrote:
>>
>>> ? ?protected final Object clone() throws CloneNotSupportedException {
>>> ? ? ? ?throw new CloneNotSupportedException();
>>
>> The final can (and should, IMO) be removed.
>
> Why? What purpose would it serve?
>
> You can not clone the Thread. The "clone" of the subclass could only be done
> via construction - so just use a constructor in the first place. As David
> Schlosnagle points out any subclass of that "Cloneable" would have to use a
> similar construction-based clone because super.clone() can not return the
> correct type. That's a bug waiting to happen.
>
> Why given even the smallest illusion that a Thread subclass can be cloned?
>
> David
>

In addition to making Thread.clone() final and throw
CloneNotSupportedException, it would be nice to add @Deprecated so
callers will show up as a compiler warning and in IDEs, as well as
join the ranks of all the other deprecated Thread methods.

- Dave


From crazybob at crazybob.org  Sat Aug 14 16:03:59 2010
From: crazybob at crazybob.org (Bob Lee)
Date: Sat, 14 Aug 2010 16:03:59 +0000
Subject: Thread.getState() very slow
In-Reply-To: <4C387723.2070407@cs.oswego.edu>
References: <4C387723.2070407@cs.oswego.edu>
Message-ID: <AANLkTi=RjsffT+OsmPqrc4DKEPovAXLGpMxOqngX23J+@mail.gmail.com>

Doug,

I ran into similar problems not too long ago. Dalvik uses a volatile field
for the thread state.

I wrote a sampling profiler for Dalvik. See
SamplingProfiler.c<http://android.git.kernel.org/?p=platform/libcore.git;a=blob;f=dalvik/src/main/java/dalvik/system/SamplingProfiler.java;h=1d88dd17001886c274db909477d077c6247af128;hb=HEAD>and
dalvik_system_SamplingProfiler.c<http://android.git.kernel.org/?p=platform/dalvik.git;a=blob;f=vm/native/dalvik_system_SamplingProfiler.c;h=5642bde15fe29d3b036d0460cecfe0414baa802a;hb=HEAD>
.

It records the thread state with each sample. The Java thread state wasn't
particularly helpful, so when a thread is in native code, it reads the
thread state from the system. See
SystemThread.c<http://android.git.kernel.org/?p=platform/dalvik.git;a=blob;f=vm/native/SystemThread.c;h=bd2be03e71331e1d0b5d799b04dc7a50fb5fa4b3;hb=HEAD>.
It reads /proc/self/task/[TID]/stat.

Linux really should provide a more efficient API for this.

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

From fw at deneb.enyo.de  Sun Aug 15 11:50:51 2010
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 15 Aug 2010 13:50:51 +0200
Subject: Threads should not be Cloneable
In-Reply-To: <AANLkTikoBBuOuRKu+xTjYATz0Ro919X0627vJabgKfPR@mail.gmail.com>
	(David Schlosnagle's message of "Fri, 13 Aug 2010 12:06:25 -0400")
References: <4C654F85.5020905@oracle.com> <4C6552B3.7090509@oracle.com>
	<4C655399.1070808@oracle.com>
	<AANLkTikoBBuOuRKu+xTjYATz0Ro919X0627vJabgKfPR@mail.gmail.com>
Message-ID: <87tymwp010.fsf@mid.deneb.enyo.de>

* David Schlosnagle:

> I may be missing something, but if java.lang.Thread.clone() will now
> throw CloneNotSupportedException, how would subtypes properly
> implement Cloneable? If the subtype calls super.clone(),
> CloneNotSupportedException will be thrown. If the subtype calls its
> own constructor, that would seem to violate the clone contract for any
> further subtypes.

The clone contract is extremely lose, so this isn't an issue.


From fw at deneb.enyo.de  Sun Aug 15 11:51:20 2010
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 15 Aug 2010 13:51:20 +0200
Subject: Threads should not be Cloneable
In-Reply-To: <4C65D392.9000204@oracle.com> (David Holmes's message of "Sat, 14
	Aug 2010 09:21:54 +1000")
References: <4C654F85.5020905@oracle.com> <4C6552B3.7090509@oracle.com>
	<4C65D392.9000204@oracle.com>
Message-ID: <87pqxkp007.fsf@mid.deneb.enyo.de>

* David Holmes:

> tom.hawtin at oracle.com said the following on 08/14/10 00:12:
>> On 13/08/2010 14:58, Chris Hegarty wrote:
>>
>>>     protected final Object clone() throws CloneNotSupportedException {
>>>         throw new CloneNotSupportedException();
>>
>> The final can (and should, IMO) be removed.
>
> Why? What purpose would it serve?

Increased backwards compatibility.


From fw at deneb.enyo.de  Sun Aug 15 11:51:55 2010
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 15 Aug 2010 13:51:55 +0200
Subject: Threads should not be Cloneable
In-Reply-To: <4C654F85.5020905@oracle.com> (Chris Hegarty's message of "Fri,
	13 Aug 2010 14:58:29 +0100")
References: <4C654F85.5020905@oracle.com>
Message-ID: <87ocd4ozz8.fsf@mid.deneb.enyo.de>

* Chris Hegarty:

> The issue of whether Threads should be Cloneable came up during the
> discussion of another problem. I talked to David about this and we
> believe there is no value being able to clone a thread, in fact it can
> cause some strange problems. David sent a mail [1] to the
> concurrency-interest mailing list requesting feedback on this. No
> objections to date.

Thanks for making this issue public, so that we can fix it.

This has been reported as a potential security issue to Oracle back in
February, together with a rediscovery of what which was subsequently
assigned CVE-2010-0088, and the observation that ColorModel needs a
similar patch:

diff -r ac23e40d3880 src/share/classes/java/awt/image/ColorModel.java
--- a/src/share/classes/java/awt/image/ColorModel.java	Fri Aug 13 10:36:08 2010 -0400
+++ b/src/share/classes/java/awt/image/ColorModel.java	Sat Aug 14 14:23:15 2010 +0200
@@ -1956,4 +1956,8 @@
         return lg16Toog16LUT;
     }
 
+    @Override
+    protected Object clone() throws CloneNotSupportedException {
+        throw new CloneNotSupportedException();
+    }
 }


Classes storing native pointers must never be cloneable.  I hope
having identified all such cases in the JDK, but I can post my scripts
so that others can try to find more instances.

Contrary to my expectations in February, it turns out that the general
issue was already described here, more than a decade ago:

<http://www.javaworld.com/javaworld/jw-12-1998/jw-12-securityrules.html?page=3>

(See rule 8.)  It's just that these recommendations haven't been
applied to the JDK.

Coincidentally, I've been working this weekend on a fix for the CORBA
issue I reported at about the same time (which is otherwise
unrelated).  It's somewhat less straightforward to fix, but I hope to
have a patch soon.


From David.Holmes at oracle.com  Sun Aug 15 22:22:13 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 16 Aug 2010 08:22:13 +1000
Subject: Threads should not be Cloneable
In-Reply-To: <87pqxkp007.fsf@mid.deneb.enyo.de>
References: <4C654F85.5020905@oracle.com>
	<4C6552B3.7090509@oracle.com>	<4C65D392.9000204@oracle.com>
	<87pqxkp007.fsf@mid.deneb.enyo.de>
Message-ID: <4C686895.6090502@oracle.com>

Hi Florian,

Florian Weimer said the following on 08/15/10 21:51:
> * David Holmes:
>> tom.hawtin at oracle.com said the following on 08/14/10 00:12:
>>> On 13/08/2010 14:58, Chris Hegarty wrote:
>>>
>>>>     protected final Object clone() throws CloneNotSupportedException {
>>>>         throw new CloneNotSupportedException();
>>> The final can (and should, IMO) be removed.
>> Why? What purpose would it serve?
> 
> Increased backwards compatibility.

The only thing this would increase compatibility with is if there exists 
already a subclass of Thread that overrides clone() to provide 
construction-based cloning**. Are you aware of such a use-case? The 
postings to the concurrency-interest mailing list and to here are to 
solicit feedback regarding any genuine use-cases for this functionality. 
So far there have been (as we expected) zero responses regarding actual 
use.

The 'final' makes it clear that the programmer should just forget about 
clone() when it comes to Thread and any of its subclasses. If we remove 
the final then we have to provide additional documentation explaining 
the limitations that any override of clone() would encounter.

** Any usage involving super.clone() is already affected by this change 
regardless of 'final'.

Cheers,
David Holmes


From David.Holmes at oracle.com  Sun Aug 15 22:46:01 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 16 Aug 2010 08:46:01 +1000
Subject: Threads should not be Cloneable
In-Reply-To: <87ocd4ozz8.fsf@mid.deneb.enyo.de>
References: <4C654F85.5020905@oracle.com> <87ocd4ozz8.fsf@mid.deneb.enyo.de>
Message-ID: <4C686E29.2040706@oracle.com>

Florian Weimer said the following on 08/15/10 21:51:
> Classes storing native pointers must never be cloneable.  I hope
> having identified all such cases in the JDK, but I can post my scripts
> so that others can try to find more instances.

I would not say that "Classes storing native pointers must never be 
cloneable" - the same cloning considerations apply to a native pointer 
as they do a Java reference: does it make sense for two instances to 
share the same pointer/reference? If the answer is no then you need to 
define a custom clone() method if you want to be able to correctly clone 
a class.

The ability of a subclass to introduce cloning in a way that can use a 
broken superclass clone() implementation is also not in itself 
necessarily a security issue. You can only clone subclass instances, not 
arbitrary superclass instances - so it really comes down to the details 
of the class concerned.

David Holmes


From chris.hegarty at oracle.com  Mon Aug 16 09:03:37 2010
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 16 Aug 2010 10:03:37 +0100
Subject: Threads should not be Cloneable
In-Reply-To: <4C686895.6090502@oracle.com>
References: <4C654F85.5020905@oracle.com>	<4C6552B3.7090509@oracle.com>	<4C65D392.9000204@oracle.com>	<87pqxkp007.fsf@mid.deneb.enyo.de>
	<4C686895.6090502@oracle.com>
Message-ID: <4C68FEE9.7090706@oracle.com>

Thanks everyone for your very valuable feedback.

 From what I'm reading there doesn't seem to be a problem with defining 
Thread.clone to throw CloneNotSupportedException. OK, that's done. Now 
should it be final?

It appears that there is very little value in making clone non-final. 
Yes, it will increase compatibility, but not in any overly useful way. 
And it seems agreed, previous reason excluded, that the right thing to 
do is to remove any doubt about cloning. In light of that I would like 
to proceed with the change as originally proposed.

Thanks,
-Chris.

On 15/08/2010 23:22, David Holmes wrote:
> Hi Florian,
>
> Florian Weimer said the following on 08/15/10 21:51:
>> * David Holmes:
>>> tom.hawtin at oracle.com said the following on 08/14/10 00:12:
>>>> On 13/08/2010 14:58, Chris Hegarty wrote:
>>>>
>>>>> protected final Object clone() throws CloneNotSupportedException {
>>>>> throw new CloneNotSupportedException();
>>>> The final can (and should, IMO) be removed.
>>> Why? What purpose would it serve?
>>
>> Increased backwards compatibility.
>
> The only thing this would increase compatibility with is if there exists
> already a subclass of Thread that overrides clone() to provide
> construction-based cloning**. Are you aware of such a use-case? The
> postings to the concurrency-interest mailing list and to here are to
> solicit feedback regarding any genuine use-cases for this functionality.
> So far there have been (as we expected) zero responses regarding actual
> use.
>
> The 'final' makes it clear that the programmer should just forget about
> clone() when it comes to Thread and any of its subclasses. If we remove
> the final then we have to provide additional documentation explaining
> the limitations that any override of clone() would encounter.
>
> ** Any usage involving super.clone() is already affected by this change
> regardless of 'final'.
>
> Cheers,
> David Holmes


From brian.goetz at oracle.com  Mon Aug 16 13:46:24 2010
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 16 Aug 2010 09:46:24 -0400
Subject: Threads should not be Cloneable
In-Reply-To: <4C68FEE9.7090706@oracle.com>
References: <4C654F85.5020905@oracle.com>	<4C6552B3.7090509@oracle.com>	<4C65D392.9000204@oracle.com>	<87pqxkp007.fsf@mid.deneb.enyo.de>	<4C686895.6090502@oracle.com>
	<4C68FEE9.7090706@oracle.com>
Message-ID: <4C694130.1040102@oracle.com>

Compatibility is not an end unto itself; IMO compatibility with broken 
programs is not something we should spend our effort maintaining.  I'm +1 on 
this change, with final.

On 8/16/2010 5:03 AM, Chris Hegarty wrote:
> Thanks everyone for your very valuable feedback.
>
>  From what I'm reading there doesn't seem to be a problem with defining
> Thread.clone to throw CloneNotSupportedException. OK, that's done. Now
> should it be final?
>
> It appears that there is very little value in making clone non-final.
> Yes, it will increase compatibility, but not in any overly useful way.
> And it seems agreed, previous reason excluded, that the right thing to
> do is to remove any doubt about cloning. In light of that I would like
> to proceed with the change as originally proposed.
>
> Thanks,
> -Chris.
>
> On 15/08/2010 23:22, David Holmes wrote:
>> Hi Florian,
>>
>> Florian Weimer said the following on 08/15/10 21:51:
>>> * David Holmes:
>>>> tom.hawtin at oracle.com said the following on 08/14/10 00:12:
>>>>> On 13/08/2010 14:58, Chris Hegarty wrote:
>>>>>
>>>>>> protected final Object clone() throws CloneNotSupportedException {
>>>>>> throw new CloneNotSupportedException();
>>>>> The final can (and should, IMO) be removed.
>>>> Why? What purpose would it serve?
>>>
>>> Increased backwards compatibility.
>>
>> The only thing this would increase compatibility with is if there exists
>> already a subclass of Thread that overrides clone() to provide
>> construction-based cloning**. Are you aware of such a use-case? The
>> postings to the concurrency-interest mailing list and to here are to
>> solicit feedback regarding any genuine use-cases for this functionality.
>> So far there have been (as we expected) zero responses regarding actual
>> use.
>>
>> The 'final' makes it clear that the programmer should just forget about
>> clone() when it comes to Thread and any of its subclasses. If we remove
>> the final then we have to provide additional documentation explaining
>> the limitations that any override of clone() would encounter.
>>
>> ** Any usage involving super.clone() is already affected by this change
>> regardless of 'final'.
>>
>> Cheers,
>> David Holmes


From maurizio.cimadamore at oracle.com  Mon Aug 16 14:06:26 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 16 Aug 2010 14:06:26 +0000
Subject: hg: jdk7/tl/langtools: 2 new changesets
Message-ID: <20100816140629.E3B0647206@hg.openjdk.java.net>

Changeset: 27bae58329d5
Author:    mcimadamore
Date:      2010-08-16 14:56 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/27bae58329d5

6976649: javac does not enforce required annotation elements in arrays
Summary: type annotation should take advantage of recursive annotation checking
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/annotations/6881115/T6881115.java
! test/tools/javac/annotations/6881115/T6881115.out
! test/tools/javac/annotations/pos/TrailingComma.java

Changeset: dc550520ed6f
Author:    mcimadamore
Date:      2010-08-16 14:58 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dc550520ed6f

6369605: Unconstrained type variables fails to include bounds
Summary: unconstrained type-variables with recursive bounds are not inferred properly
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/diags/examples/InvalidInferredTypes.java
+ test/tools/javac/generics/inference/6369605/T6369605a.java
+ test/tools/javac/generics/inference/6369605/T6369605b.java
! test/tools/javac/generics/inference/6638712/T6638712a.out



From joe.darcy at oracle.com  Mon Aug 16 20:05:19 2010
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 16 Aug 2010 13:05:19 -0700
Subject: Threads should not be Cloneable
In-Reply-To: <4C68FEE9.7090706@oracle.com>
References: <4C654F85.5020905@oracle.com>	<4C6552B3.7090509@oracle.com>	<4C65D392.9000204@oracle.com>	<87pqxkp007.fsf@mid.deneb.enyo.de>	<4C686895.6090502@oracle.com>
	<4C68FEE9.7090706@oracle.com>
Message-ID: <4C6999FF.7060509@oracle.com>

Chris Hegarty wrote:
> Thanks everyone for your very valuable feedback.
>
> From what I'm reading there doesn't seem to be a problem with defining 
> Thread.clone to throw CloneNotSupportedException. OK, that's done. Now 
> should it be final?
>
> It appears that there is very little value in making clone non-final. 
> Yes, it will increase compatibility, but not in any overly useful way. 
> And it seems agreed, previous reason excluded, that the right thing to 
> do is to remove any doubt about cloning. In light of that I would like 
> to proceed with the change as originally proposed.
The general evolution policy of the JDK [1] has long been:

>    1. Don't break binary compatibility (as defined in the Java 
> Language Specification).
>    2. Avoid introducing source incompatibilities.
>    3. Manage behavioral compatibility changes.

Per JLSv3 section 13.4.17 "final Methods," [2]

> Changing an instance method that is not final to be final may break 
> compatibility with existing binaries that depend on the ability to 
> override the method.

Therefore, adding final to Thread's clone method would be a binary 
incompatible change since any (weird, broken) subclasses which override 
the clone method would fail to link, which is the definition of binary 
compatibility.  While there is merit in considering this change, the 
default position would be to reject the change as going against the 
general evolution policy.

-Joe

[1] 
http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy
[2] 
http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.4.17


>
> Thanks,
> -Chris.
>
> On 15/08/2010 23:22, David Holmes wrote:
>> Hi Florian,
>>
>> Florian Weimer said the following on 08/15/10 21:51:
>>> * David Holmes:
>>>> tom.hawtin at oracle.com said the following on 08/14/10 00:12:
>>>>> On 13/08/2010 14:58, Chris Hegarty wrote:
>>>>>
>>>>>> protected final Object clone() throws CloneNotSupportedException {
>>>>>> throw new CloneNotSupportedException();
>>>>> The final can (and should, IMO) be removed.
>>>> Why? What purpose would it serve?
>>>
>>> Increased backwards compatibility.
>>
>> The only thing this would increase compatibility with is if there exists
>> already a subclass of Thread that overrides clone() to provide
>> construction-based cloning**. Are you aware of such a use-case? The
>> postings to the concurrency-interest mailing list and to here are to
>> solicit feedback regarding any genuine use-cases for this functionality.
>> So far there have been (as we expected) zero responses regarding actual
>> use.
>>
>> The 'final' makes it clear that the programmer should just forget about
>> clone() when it comes to Thread and any of its subclasses. If we remove
>> the final then we have to provide additional documentation explaining
>> the limitations that any override of clone() would encounter.
>>
>> ** Any usage involving super.clone() is already affected by this change
>> regardless of 'final'.
>>
>> Cheers,
>> David Holmes



From jonathan.gibbons at oracle.com  Mon Aug 16 21:59:42 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 16 Aug 2010 21:59:42 +0000
Subject: hg: jdk7/tl/langtools: 6976833: options included twice in Example
	SimpleCompiler
Message-ID: <20100816215944.29C474721B@hg.openjdk.java.net>

Changeset: a31c511db424
Author:    jjg
Date:      2010-08-16 14:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a31c511db424

6976833: options included twice in Example SimpleCompiler
Reviewed-by: darcy

! test/tools/javac/diags/Example.java



From mandy.chung at oracle.com  Mon Aug 16 22:36:36 2010
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Mon, 16 Aug 2010 22:36:36 +0000
Subject: hg: jdk7/tl/jdk: 6921234: TEST_BUG:
	java/lang/ClassLoader/deadlock/TestCrossDelegate.sh needs to be
	modified for Cygwin
Message-ID: <20100816223646.22CDC4721E@hg.openjdk.java.net>

Changeset: 8329ebeabc10
Author:    mchung
Date:      2010-08-16 15:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8329ebeabc10

6921234: TEST_BUG: java/lang/ClassLoader/deadlock/TestCrossDelegate.sh needs to be modified for Cygwin
Summary: Add check for CYGWIN
Reviewed-by: ohair

! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh



From David.Holmes at oracle.com  Mon Aug 16 23:49:35 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 17 Aug 2010 09:49:35 +1000
Subject: Threads should not be Cloneable
In-Reply-To: <4C6999FF.7060509@oracle.com>
References: <4C654F85.5020905@oracle.com>	<4C6552B3.7090509@oracle.com>	<4C65D392.9000204@oracle.com>	<87pqxkp007.fsf@mid.deneb.enyo.de>	<4C686895.6090502@oracle.com>	<4C68FEE9.7090706@oracle.com>
	<4C6999FF.7060509@oracle.com>
Message-ID: <4C69CE8F.6050601@oracle.com>

Joe Darcy said the following on 08/17/10 06:05:
> The general evolution policy of the JDK [1] has long been:
> 
>>    1. Don't break binary compatibility (as defined in the Java 
>> Language Specification).
>>    2. Avoid introducing source incompatibilities.
>>    3. Manage behavioral compatibility changes.
> 
> Per JLSv3 section 13.4.17 "final Methods," [2]
> 
>> Changing an instance method that is not final to be final may break 
>> compatibility with existing binaries that depend on the ability to 
>> override the method.
> 
> Therefore, adding final to Thread's clone method would be a binary 
> incompatible change since any (weird, broken) subclasses which override 
> the clone method would fail to link, which is the definition of binary 
> compatibility.  While there is merit in considering this change, the 
> default position would be to reject the change as going against the 
> general evolution policy.

Fortunately, as Brian stated, compatibility is not an end unto itself 
here and we often do have documented incompatibilities across major 
releases. In this case there is far more harm, in my opinion, leaving 
the possibility of people trying to clone threads than there is in 
breaking a hypothetical program that is unlikely to be functioning 
correctly anyway. Thread should never have been cloneable in any way - 
the fact that this has flown under the radar for so long is a strong 
indicator that nobody actually does this in practice (else they would 
have complained that it didn't work).

David

> -Joe
> 
> [1] 
> http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy 
> 
> [2] 
> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.4.17 
> 
> 
> 
>>
>> Thanks,
>> -Chris.
>>
>> On 15/08/2010 23:22, David Holmes wrote:
>>> Hi Florian,
>>>
>>> Florian Weimer said the following on 08/15/10 21:51:
>>>> * David Holmes:
>>>>> tom.hawtin at oracle.com said the following on 08/14/10 00:12:
>>>>>> On 13/08/2010 14:58, Chris Hegarty wrote:
>>>>>>
>>>>>>> protected final Object clone() throws CloneNotSupportedException {
>>>>>>> throw new CloneNotSupportedException();
>>>>>> The final can (and should, IMO) be removed.
>>>>> Why? What purpose would it serve?
>>>>
>>>> Increased backwards compatibility.
>>>
>>> The only thing this would increase compatibility with is if there exists
>>> already a subclass of Thread that overrides clone() to provide
>>> construction-based cloning**. Are you aware of such a use-case? The
>>> postings to the concurrency-interest mailing list and to here are to
>>> solicit feedback regarding any genuine use-cases for this functionality.
>>> So far there have been (as we expected) zero responses regarding actual
>>> use.
>>>
>>> The 'final' makes it clear that the programmer should just forget about
>>> clone() when it comes to Thread and any of its subclasses. If we remove
>>> the final then we have to provide additional documentation explaining
>>> the limitations that any override of clone() would encounter.
>>>
>>> ** Any usage involving super.clone() is already affected by this change
>>> regardless of 'final'.
>>>
>>> Cheers,
>>> David Holmes
> 


From jeroen at sumatra.nl  Tue Aug 17 04:11:58 2010
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Tue, 17 Aug 2010 04:11:58 +0000
Subject: Threads should not be Cloneable
In-Reply-To: <4C69CE8F.6050601@oracle.com>
References: <4C654F85.5020905@oracle.com>	<4C6552B3.7090509@oracle.com>
	<4C65D392.9000204@oracle.com>	<87pqxkp007.fsf@mid.deneb.enyo.de>
	<4C686895.6090502@oracle.com>	<4C68FEE9.7090706@oracle.com>
	<4C6999FF.7060509@oracle.com> <4C69CE8F.6050601@oracle.com>
Message-ID: <D395C7FC996C944EBD345AB36164F4B23726C6A4@woyla.sumatrasoftware.com>

David Holmes wrote:
> Fortunately, as Brian stated, compatibility is not an end unto itself
> here and we often do have documented incompatibilities across major
> releases. In this case there is far more harm, in my opinion, leaving
> the possibility of people trying to clone threads than there is in
> breaking a hypothetical program that is unlikely to be functioning
> correctly anyway. Thread should never have been cloneable in any way -
> the fact that this has flown under the radar for so long is a strong
> indicator that nobody actually does this in practice (else they would
> have complained that it didn't work).

I really don't understand your position. It clearly doesn't make sense to call Object.clone() on a Thread, but you can have a perfectly safe clone() on a Thread subclass:

public final MyCloneableThread extends Thread {
  public Object clone() {
    return new MyCloneableThread();
  }
}

On the other hand, there is no reason to make clone() in Thread final other than some vague notion that you want to prevent people from writing new code like the above, but given that Java is an "old" and stable platform that argument doesn't carry much weight either.

BTW, from a security standpoint, overriding clone doesn't help. An attacker can simply create a Thread subclass that doesn't have the ACC_SUPER flag set and that class will be able to call Object.clone() just fine.

Regards,
Jeroen



From David.Holmes at oracle.com  Tue Aug 17 04:38:33 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 17 Aug 2010 14:38:33 +1000
Subject: Threads should not be Cloneable
In-Reply-To: <D395C7FC996C944EBD345AB36164F4B23726C6A4@woyla.sumatrasoftware.com>
References: <4C654F85.5020905@oracle.com>	<4C6552B3.7090509@oracle.com>	<4C65D392.9000204@oracle.com>	<87pqxkp007.fsf@mid.deneb.enyo.de>	<4C686895.6090502@oracle.com>	<4C68FEE9.7090706@oracle.com>	<4C6999FF.7060509@oracle.com>
	<4C69CE8F.6050601@oracle.com>
	<D395C7FC996C944EBD345AB36164F4B23726C6A4@woyla.sumatrasoftware.com>
Message-ID: <4C6A1249.4030603@oracle.com>

Jeroen Frijters said the following on 08/17/10 14:11:
> David Holmes wrote:
>> Fortunately, as Brian stated, compatibility is not an end unto itself
>> here and we often do have documented incompatibilities across major
>> releases. In this case there is far more harm, in my opinion, leaving
>> the possibility of people trying to clone threads than there is in
>> breaking a hypothetical program that is unlikely to be functioning
>> correctly anyway. Thread should never have been cloneable in any way -
>> the fact that this has flown under the radar for so long is a strong
>> indicator that nobody actually does this in practice (else they would
>> have complained that it didn't work).
> 
> I really don't understand your position. It clearly doesn't make sense to call Object.clone() on a Thread, but you can have a perfectly safe clone() on a Thread subclass:
> 
> public final MyCloneableThread extends Thread {
>   public Object clone() {
>     return new MyCloneableThread();
>   }
> }

I assume you really meant something like "new MyCloneableThread(this)" 
to actually get a copy. You can do that, but:

a) the above gives you nothing that the constructor alone could not achieve
b) the above is only valid in a final class (as used), or if documented 
explicitly so that subclasses know that they can not use super.clone()

If we prevent a Thread subclass from calling super.clone() but still 
allow the subclass to override clone() then we will need to document 
that they can only use a construction-based clone technique, and that 
all further subclasses will also be constrained to that technique.

I don't see the point in going to such lengths when our message is a 
very simple "Thread is not cloneable - get over it, move on". Let's 
close the door completely, not leave it ajar. I/we only want to set 
right what should not have been done wrong in the first place.

> On the other hand, there is no reason to make clone() in Thread final other than some vague notion that you want to prevent people from writing new code like the above, but given that Java is an "old" and stable platform that argument doesn't carry much weight either.
> 
> BTW, from a security standpoint, overriding clone doesn't help. An attacker can simply create a Thread subclass that doesn't have the ACC_SUPER flag set and that class will be able to call Object.clone() just fine.

I'm not quite sure exactly what you mean, but if that is the case then 
someone should file a bug report.

Cheers,
David

> Regards,
> Jeroen
> 


From joe.darcy at oracle.com  Tue Aug 17 06:41:05 2010
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 16 Aug 2010 23:41:05 -0700
Subject: Code review request: 6973831 NPE when printing stack trace of OOME
In-Reply-To: <69BBBCDF-F8C0-4965-8943-EEB1E786EA7D@oracle.com>
References: <4C62F57A.7060409@oracle.com>	<A9F164F1-BCEB-444C-9F39-935D12665063@oracle.com>	<4C630DBE.2050606@oracle.com>	<4C631032.50407@univ-mlv.fr>	<4C631972.7000708@oracle.com>	<4C631CDC.6040106@oracle.com>
	<4C634DC2.7010408@oracle.com>	<4C643D6F.7060700@oracle.com>
	<4C6460E2.9020304@oracle.com>
	<69BBBCDF-F8C0-4965-8943-EEB1E786EA7D@oracle.com>
Message-ID: <4C6A2F01.6030207@oracle.com>

Brian Goetz wrote:
> So, this aspect of COIN is still somewhat new, and so I think it is worth looking at carefully.  There is a specification for this feature that was discussed on coin-dev.  You might want to take a look and comment -- its not too late.
>
>   

In particular:

"Project Coin: Updated ARM Spec"
http://blogs.sun.com/darcy/entry/project_coin_updated_arm_spec

"Project Coin: Uniform Suppression in try-with-resources"
http://blogs.sun.com/darcy/entry/project_coin_uniform_suppression

or

http://mail.openjdk.java.net/pipermail/coin-dev/2010-July/002796.html
http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002812.html

-Joe





From brucechapman at paradise.net.nz  Tue Aug 17 09:17:47 2010
From: brucechapman at paradise.net.nz (Bruce Chapman)
Date: Tue, 17 Aug 2010 21:17:47 +1200
Subject: Threads should not be Cloneable
In-Reply-To: <4C6A1249.4030603@oracle.com>
References: <4C654F85.5020905@oracle.com> <4C6552B3.7090509@oracle.com>
	<4C65D392.9000204@oracle.com> <87pqxkp007.fsf@mid.deneb.enyo.de>
	<4C686895.6090502@oracle.com> <4C68FEE9.7090706@oracle.com>
	<4C6999FF.7060509@oracle.com> <4C69CE8F.6050601@oracle.com>
	<D395C7FC996C944EBD345AB36164F4B23726C6A4@woyla.sumatrasoftware.com>
	<4C6A1249.4030603@oracle.com>
Message-ID: <4C6A53BB.8010503@paradise.net.nz>

In the early days of my climb up the java learning curve, well before
much body of commonly understood best practice evolved, there are many
things which in hindsight are regrettable. Here's two

1./ Our highly threaded app had many classes that extended Thread
instead of the (now) wiser "implements Runnable"

2./ I thought clone() and Cloneable was the right way to get a 'copy
constructor' (it was in the JDK, it must be best practice - right?)

Therefore there is a reasonable chance that in that (once familiar yet
minuscule) body of code from a previous millennium, there is a class
that extends Thread and is cloned using a clone()  method.

You might not find it in more recent code, but these were once commonish
idioms, till Josh corrected us with Effective Java. Some of that code
may still be running. Don't break it.

Bruce


David Holmes wrote:
> Jeroen Frijters said the following on 08/17/10 14:11:
>> David Holmes wrote:
>>> Fortunately, as Brian stated, compatibility is not an end unto itself
>>> here and we often do have documented incompatibilities across major
>>> releases. In this case there is far more harm, in my opinion, leaving
>>> the possibility of people trying to clone threads than there is in
>>> breaking a hypothetical program that is unlikely to be functioning
>>> correctly anyway. Thread should never have been cloneable in any way -
>>> the fact that this has flown under the radar for so long is a strong
>>> indicator that nobody actually does this in practice (else they would
>>> have complained that it didn't work).
>>
>> I really don't understand your position. It clearly doesn't make 
>> sense to call Object.clone() on a Thread, but you can have a 
>> perfectly safe clone() on a Thread subclass:
>>
>> public final MyCloneableThread extends Thread {
>>   public Object clone() {
>>     return new MyCloneableThread();
>>   }
>> }
>
> I assume you really meant something like "new MyCloneableThread(this)" 
> to actually get a copy. You can do that, but:
>
> a) the above gives you nothing that the constructor alone could not 
> achieve
> b) the above is only valid in a final class (as used), or if 
> documented explicitly so that subclasses know that they can not use 
> super.clone()
>
> If we prevent a Thread subclass from calling super.clone() but still 
> allow the subclass to override clone() then we will need to document 
> that they can only use a construction-based clone technique, and that 
> all further subclasses will also be constrained to that technique.
>
> I don't see the point in going to such lengths when our message is a 
> very simple "Thread is not cloneable - get over it, move on". Let's 
> close the door completely, not leave it ajar. I/we only want to set 
> right what should not have been done wrong in the first place.
>
>> On the other hand, there is no reason to make clone() in Thread final 
>> other than some vague notion that you want to prevent people from 
>> writing new code like the above, but given that Java is an "old" and 
>> stable platform that argument doesn't carry much weight either.
>>
>> BTW, from a security standpoint, overriding clone doesn't help. An 
>> attacker can simply create a Thread subclass that doesn't have the 
>> ACC_SUPER flag set and that class will be able to call Object.clone() 
>> just fine.
>
> I'm not quite sure exactly what you mean, but if that is the case then 
> someone should file a bug report.
>
> Cheers,
> David
>
>> Regards,
>> Jeroen
>>
>




From David.Holmes at oracle.com  Tue Aug 17 10:07:06 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 17 Aug 2010 20:07:06 +1000
Subject: Threads should not be Cloneable
In-Reply-To: <4C6A53BB.8010503@paradise.net.nz>
References: <4C654F85.5020905@oracle.com>
	<4C6552B3.7090509@oracle.com>	<4C65D392.9000204@oracle.com>
	<87pqxkp007.fsf@mid.deneb.enyo.de>	<4C686895.6090502@oracle.com>
	<4C68FEE9.7090706@oracle.com>	<4C6999FF.7060509@oracle.com>
	<4C69CE8F.6050601@oracle.com>	<D395C7FC996C944EBD345AB36164F4B23726C6A4@woyla.sumatrasoftware.com>	<4C6A1249.4030603@oracle.com>
	<4C6A53BB.8010503@paradise.net.nz>
Message-ID: <4C6A5F4A.6040203@oracle.com>

Bruce Chapman said the following on 08/17/10 19:17:
> In the early days of my climb up the java learning curve, well before
> much body of commonly understood best practice evolved, there are many
> things which in hindsight are regrettable. Here's two
> 
> 1./ Our highly threaded app had many classes that extended Thread
> instead of the (now) wiser "implements Runnable"

Well Doug Lea and I were touting this since 1996! If you want to define 
some work define a Runnable, if you want to define a "worker" then 
extend Thread. :)

> 2./ I thought clone() and Cloneable was the right way to get a 'copy
> constructor' (it was in the JDK, it must be best practice - right?)

Yes that one is best practice right along-side destructors, oops I mean 
finalizers :)

> Therefore there is a reasonable chance that in that (once familiar yet
> minuscule) body of code from a previous millennium, there is a class
> that extends Thread and is cloned using a clone()  method.
> 
> You might not find it in more recent code, but these were once commonish
> idioms, till Josh corrected us with Effective Java. Some of that code
> may still be running. Don't break it.

Well I contend it's already broken if it is cloning a thread but that 
aside ...

... You seem to be advocating for not making this change at all, as 
opposed to arguing for or against clone() being final? But we either 
have to disallow cloning or give it meaningful semantics - and the 
latter isn't going to happen.

David

> 
> Bruce
> 
> 
> David Holmes wrote:
>> Jeroen Frijters said the following on 08/17/10 14:11:
>>> David Holmes wrote:
>>>> Fortunately, as Brian stated, compatibility is not an end unto itself
>>>> here and we often do have documented incompatibilities across major
>>>> releases. In this case there is far more harm, in my opinion, leaving
>>>> the possibility of people trying to clone threads than there is in
>>>> breaking a hypothetical program that is unlikely to be functioning
>>>> correctly anyway. Thread should never have been cloneable in any way -
>>>> the fact that this has flown under the radar for so long is a strong
>>>> indicator that nobody actually does this in practice (else they would
>>>> have complained that it didn't work).
>>>
>>> I really don't understand your position. It clearly doesn't make 
>>> sense to call Object.clone() on a Thread, but you can have a 
>>> perfectly safe clone() on a Thread subclass:
>>>
>>> public final MyCloneableThread extends Thread {
>>>   public Object clone() {
>>>     return new MyCloneableThread();
>>>   }
>>> }
>>
>> I assume you really meant something like "new MyCloneableThread(this)" 
>> to actually get a copy. You can do that, but:
>>
>> a) the above gives you nothing that the constructor alone could not 
>> achieve
>> b) the above is only valid in a final class (as used), or if 
>> documented explicitly so that subclasses know that they can not use 
>> super.clone()
>>
>> If we prevent a Thread subclass from calling super.clone() but still 
>> allow the subclass to override clone() then we will need to document 
>> that they can only use a construction-based clone technique, and that 
>> all further subclasses will also be constrained to that technique.
>>
>> I don't see the point in going to such lengths when our message is a 
>> very simple "Thread is not cloneable - get over it, move on". Let's 
>> close the door completely, not leave it ajar. I/we only want to set 
>> right what should not have been done wrong in the first place.
>>
>>> On the other hand, there is no reason to make clone() in Thread final 
>>> other than some vague notion that you want to prevent people from 
>>> writing new code like the above, but given that Java is an "old" and 
>>> stable platform that argument doesn't carry much weight either.
>>>
>>> BTW, from a security standpoint, overriding clone doesn't help. An 
>>> attacker can simply create a Thread subclass that doesn't have the 
>>> ACC_SUPER flag set and that class will be able to call Object.clone() 
>>> just fine.
>>
>> I'm not quite sure exactly what you mean, but if that is the case then 
>> someone should file a bug report.
>>
>> Cheers,
>> David
>>
>>> Regards,
>>> Jeroen
>>>
>>
> 
> 


From lists at laerad.com  Tue Aug 17 10:31:41 2010
From: lists at laerad.com (Benedict Elliott Smith)
Date: Tue, 17 Aug 2010 11:31:41 +0100
Subject: Threads should not be Cloneable
In-Reply-To: <4C6A5F4A.6040203@oracle.com>
References: <4C654F85.5020905@oracle.com> <4C6552B3.7090509@oracle.com>
	<4C65D392.9000204@oracle.com> <87pqxkp007.fsf@mid.deneb.enyo.de>
	<4C686895.6090502@oracle.com> <4C68FEE9.7090706@oracle.com>
	<4C6999FF.7060509@oracle.com> <4C69CE8F.6050601@oracle.com>
	<D395C7FC996C944EBD345AB36164F4B23726C6A4@woyla.sumatrasoftware.com>
	<4C6A1249.4030603@oracle.com> <4C6A53BB.8010503@paradise.net.nz>
	<4C6A5F4A.6040203@oracle.com>
Message-ID: <AANLkTimJNu+bVJJsYSaOLrOk8MiEVSeuRecnb8DoV1AW@mail.gmail.com>

I think he is arguing that probably many people who do not subscribe to this
mailing list will have overridden Thread.clone() with an implementation that
does not call super.clone(), simply because the "standard" name for methods
that copy an object was "clone". And that you will be breaking all of this
perfectly valid code simply because you don't like it. Crusades against ugly
code (that break existing applications and libraries) don't do the language
much service when perhaps even a majority of applications in various
industries are written "badly". Even the smartest make bad decisions when
learning, and there are plenty of people who aren't the smartest to carry on
when those have figured out not to. Plenty of such projects are then
"maintained" (i.e. left alone as much as possible) by people who have never
or rarely seen the code base, and inflicting this kind of problem on them is
unkind at best.

I think people on this and similar mailing lists might sometimes forget that
the majority of users *don't subscribe to it*, and that these people need to
be catered to just as much as those that do. And that the people who *don't
*subscribe *just may *be the people who are more likely to have made these
kinds of errors, and not understand why their previously functional code now
doesn't work with a new release of Java.



On 17 August 2010 11:07, David Holmes <David.Holmes at oracle.com> wrote:

> Bruce Chapman said the following on 08/17/10 19:17:
>
>  In the early days of my climb up the java learning curve, well before
>> much body of commonly understood best practice evolved, there are many
>> things which in hindsight are regrettable. Here's two
>>
>> 1./ Our highly threaded app had many classes that extended Thread
>> instead of the (now) wiser "implements Runnable"
>>
>
> Well Doug Lea and I were touting this since 1996! If you want to define
> some work define a Runnable, if you want to define a "worker" then extend
> Thread. :)
>
>
>  2./ I thought clone() and Cloneable was the right way to get a 'copy
>> constructor' (it was in the JDK, it must be best practice - right?)
>>
>
> Yes that one is best practice right along-side destructors, oops I mean
> finalizers :)
>
>
>  Therefore there is a reasonable chance that in that (once familiar yet
>> minuscule) body of code from a previous millennium, there is a class
>> that extends Thread and is cloned using a clone()  method.
>>
>> You might not find it in more recent code, but these were once commonish
>> idioms, till Josh corrected us with Effective Java. Some of that code
>> may still be running. Don't break it.
>>
>
> Well I contend it's already broken if it is cloning a thread but that aside
> ...
>
> ... You seem to be advocating for not making this change at all, as opposed
> to arguing for or against clone() being final? But we either have to
> disallow cloning or give it meaningful semantics - and the latter isn't
> going to happen.
>
> David
>
>
>
>> Bruce
>>
>>
>> David Holmes wrote:
>>
>>> Jeroen Frijters said the following on 08/17/10 14:11:
>>>
>>>> David Holmes wrote:
>>>>
>>>>> Fortunately, as Brian stated, compatibility is not an end unto itself
>>>>> here and we often do have documented incompatibilities across major
>>>>> releases. In this case there is far more harm, in my opinion, leaving
>>>>> the possibility of people trying to clone threads than there is in
>>>>> breaking a hypothetical program that is unlikely to be functioning
>>>>> correctly anyway. Thread should never have been cloneable in any way -
>>>>> the fact that this has flown under the radar for so long is a strong
>>>>> indicator that nobody actually does this in practice (else they would
>>>>> have complained that it didn't work).
>>>>>
>>>>
>>>> I really don't understand your position. It clearly doesn't make sense
>>>> to call Object.clone() on a Thread, but you can have a perfectly safe
>>>> clone() on a Thread subclass:
>>>>
>>>> public final MyCloneableThread extends Thread {
>>>>  public Object clone() {
>>>>    return new MyCloneableThread();
>>>>  }
>>>> }
>>>>
>>>
>>> I assume you really meant something like "new MyCloneableThread(this)" to
>>> actually get a copy. You can do that, but:
>>>
>>> a) the above gives you nothing that the constructor alone could not
>>> achieve
>>> b) the above is only valid in a final class (as used), or if documented
>>> explicitly so that subclasses know that they can not use super.clone()
>>>
>>> If we prevent a Thread subclass from calling super.clone() but still
>>> allow the subclass to override clone() then we will need to document that
>>> they can only use a construction-based clone technique, and that all further
>>> subclasses will also be constrained to that technique.
>>>
>>> I don't see the point in going to such lengths when our message is a very
>>> simple "Thread is not cloneable - get over it, move on". Let's close the
>>> door completely, not leave it ajar. I/we only want to set right what should
>>> not have been done wrong in the first place.
>>>
>>>  On the other hand, there is no reason to make clone() in Thread final
>>>> other than some vague notion that you want to prevent people from writing
>>>> new code like the above, but given that Java is an "old" and stable platform
>>>> that argument doesn't carry much weight either.
>>>>
>>>> BTW, from a security standpoint, overriding clone doesn't help. An
>>>> attacker can simply create a Thread subclass that doesn't have the ACC_SUPER
>>>> flag set and that class will be able to call Object.clone() just fine.
>>>>
>>>
>>> I'm not quite sure exactly what you mean, but if that is the case then
>>> someone should file a bug report.
>>>
>>> Cheers,
>>> David
>>>
>>>  Regards,
>>>> Jeroen
>>>>
>>>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100817/fa836c54/attachment.html>

From David.Holmes at oracle.com  Tue Aug 17 10:42:31 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 17 Aug 2010 20:42:31 +1000
Subject: Threads should not be Cloneable
In-Reply-To: <AANLkTimJNu+bVJJsYSaOLrOk8MiEVSeuRecnb8DoV1AW@mail.gmail.com>
References: <4C654F85.5020905@oracle.com>	<4C6552B3.7090509@oracle.com>	<4C65D392.9000204@oracle.com>	<87pqxkp007.fsf@mid.deneb.enyo.de>	<4C686895.6090502@oracle.com>	<4C68FEE9.7090706@oracle.com>	<4C6999FF.7060509@oracle.com>	<4C69CE8F.6050601@oracle.com>	<D395C7FC996C944EBD345AB36164F4B23726C6A4@woyla.sumatrasoftware.com>	<4C6A1249.4030603@oracle.com>	<4C6A53BB.8010503@paradise.net.nz>	<4C6A5F4A.6040203@oracle.com>
	<AANLkTimJNu+bVJJsYSaOLrOk8MiEVSeuRecnb8DoV1AW@mail.gmail.com>
Message-ID: <4C6A6797.5010804@oracle.com>

Fine I give up - no final.

David

Benedict Elliott Smith said the following on 08/17/10 20:31:
> I think he is arguing that probably many people who do not subscribe to 
> this mailing list will have overridden Thread.clone() with an 
> implementation that does not call super.clone(), simply because the 
> "standard" name for methods that copy an object was "clone". And that 
> you will be breaking all of this perfectly valid code simply because you 
> don't like it. Crusades against ugly code (that break existing 
> applications and libraries) don't do the language much service when 
> perhaps even a majority of applications in various industries are 
> written "badly". Even the smartest make bad decisions when learning, and 
> there are plenty of people who aren't the smartest to carry on when 
> those have figured out not to. Plenty of such projects are then 
> "maintained" (i.e. left alone as much as possible) by people who have 
> never or rarely seen the code base, and inflicting this kind of problem 
> on them is unkind at best.
> 
> I think people on this and similar mailing lists might sometimes forget 
> that the majority of users /don't subscribe to it/, and that these 
> people need to be catered to just as much as those that do. And that the 
> people who /don't /subscribe /just may /be the people who are more 
> likely to have made these kinds of errors, and not understand why their 
> previously functional code now doesn't work with a new release of Java.
> 
> 
> 
> On 17 August 2010 11:07, David Holmes <David.Holmes at oracle.com 
> <mailto:David.Holmes at oracle.com>> wrote:
> 
>     Bruce Chapman said the following on 08/17/10 19:17:
> 
>         In the early days of my climb up the java learning curve, well
>         before
>         much body of commonly understood best practice evolved, there
>         are many
>         things which in hindsight are regrettable. Here's two
> 
>         1./ Our highly threaded app had many classes that extended Thread
>         instead of the (now) wiser "implements Runnable"
> 
> 
>     Well Doug Lea and I were touting this since 1996! If you want to
>     define some work define a Runnable, if you want to define a "worker"
>     then extend Thread. :)
> 
> 
>         2./ I thought clone() and Cloneable was the right way to get a 'copy
>         constructor' (it was in the JDK, it must be best practice - right?)
> 
> 
>     Yes that one is best practice right along-side destructors, oops I
>     mean finalizers :)
> 
> 
>         Therefore there is a reasonable chance that in that (once
>         familiar yet
>         minuscule) body of code from a previous millennium, there is a class
>         that extends Thread and is cloned using a clone()  method.
> 
>         You might not find it in more recent code, but these were once
>         commonish
>         idioms, till Josh corrected us with Effective Java. Some of that
>         code
>         may still be running. Don't break it.
> 
> 
>     Well I contend it's already broken if it is cloning a thread but
>     that aside ...
> 
>     ... You seem to be advocating for not making this change at all, as
>     opposed to arguing for or against clone() being final? But we either
>     have to disallow cloning or give it meaningful semantics - and the
>     latter isn't going to happen.
> 
>     David
> 
> 
> 
>         Bruce
> 
> 
>         David Holmes wrote:
> 
>             Jeroen Frijters said the following on 08/17/10 14:11:
> 
>                 David Holmes wrote:
> 
>                     Fortunately, as Brian stated, compatibility is not
>                     an end unto itself
>                     here and we often do have documented
>                     incompatibilities across major
>                     releases. In this case there is far more harm, in my
>                     opinion, leaving
>                     the possibility of people trying to clone threads
>                     than there is in
>                     breaking a hypothetical program that is unlikely to
>                     be functioning
>                     correctly anyway. Thread should never have been
>                     cloneable in any way -
>                     the fact that this has flown under the radar for so
>                     long is a strong
>                     indicator that nobody actually does this in practice
>                     (else they would
>                     have complained that it didn't work).
> 
> 
>                 I really don't understand your position. It clearly
>                 doesn't make sense to call Object.clone() on a Thread,
>                 but you can have a perfectly safe clone() on a Thread
>                 subclass:
> 
>                 public final MyCloneableThread extends Thread {
>                  public Object clone() {
>                    return new MyCloneableThread();
>                  }
>                 }
> 
> 
>             I assume you really meant something like "new
>             MyCloneableThread(this)" to actually get a copy. You can do
>             that, but:
> 
>             a) the above gives you nothing that the constructor alone
>             could not achieve
>             b) the above is only valid in a final class (as used), or if
>             documented explicitly so that subclasses know that they can
>             not use super.clone()
> 
>             If we prevent a Thread subclass from calling super.clone()
>             but still allow the subclass to override clone() then we
>             will need to document that they can only use a
>             construction-based clone technique, and that all further
>             subclasses will also be constrained to that technique.
> 
>             I don't see the point in going to such lengths when our
>             message is a very simple "Thread is not cloneable - get over
>             it, move on". Let's close the door completely, not leave it
>             ajar. I/we only want to set right what should not have been
>             done wrong in the first place.
> 
>                 On the other hand, there is no reason to make clone() in
>                 Thread final other than some vague notion that you want
>                 to prevent people from writing new code like the above,
>                 but given that Java is an "old" and stable platform that
>                 argument doesn't carry much weight either.
> 
>                 BTW, from a security standpoint, overriding clone
>                 doesn't help. An attacker can simply create a Thread
>                 subclass that doesn't have the ACC_SUPER flag set and
>                 that class will be able to call Object.clone() just fine.
> 
> 
>             I'm not quite sure exactly what you mean, but if that is the
>             case then someone should file a bug report.
> 
>             Cheers,
>             David
> 
>                 Regards,
>                 Jeroen
> 
> 
> 
> 
> 


From michael.x.mcmahon at oracle.com  Tue Aug 17 14:16:41 2010
From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com)
Date: Tue, 17 Aug 2010 14:16:41 +0000
Subject: hg: jdk7/tl/jdk: 6339649: URI.create should include a detail message
	when throwing IllegalArgumentException
Message-ID: <20100817141706.2738447248@hg.openjdk.java.net>

Changeset: 42eaa082a4e6
Author:    michaelm
Date:      2010-08-17 14:49 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/42eaa082a4e6

6339649: URI.create should include a detail message when throwing IllegalArgumentException
Summary: create enclosing exception with message of enclosed
Reviewed-by: alanb, chegar

! src/share/classes/java/net/URI.java
! test/java/net/URI/Test.java



From Ulf.Zibis at gmx.de  Tue Aug 17 16:11:22 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 17 Aug 2010 18:11:22 +0200
Subject: possible bug in java.util.DeflaterOutputStream
In-Reply-To: <4C30C0BC.4020206@gmx.de>
References: <4C30C0BC.4020206@gmx.de>
Message-ID: <4C6AB4AA.6040007@gmx.de>

No feedback since long.
Nobody knows about this particular error message and it's possible cause ?

-Ulf


Am 04.07.2010 19:11, schrieb Ulf Zibis:
> Hi,
>
> writing data to a zip file returns following 2 error lines:
> bit length overflow
> code 0 bits 6->7
> I use:
>     DataOutputStream dos = new DataOutputStream(new 
> DeflaterOutputStream(new FileOutputStream(outFilePathName)));
>
> Is there any idea, where this comes from?
>
> The class to run:
> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/JDK-7/j_l_Character_names/src_sherman2/build/tools/generatecharacter/CharacterNamesGenerator6.java?rev=1106&view=markup 
>
> (From NetBeans run configuration gen_sherman2_6)
> My project:
> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/JDK-7/j_l_Character_names/?rev=1106 
>
>
> If I write to normal file, no error occurs:
>      DataOutputStream dos = new DataOutputStream(new 
> FileOutputStream(outFilePathName));
>
> -Ulf
>
>
>
>
>



From xueming.shen at oracle.com  Tue Aug 17 17:08:49 2010
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 17 Aug 2010 10:08:49 -0700
Subject: possible bug in java.util.DeflaterOutputStream
In-Reply-To: <4C6AB4AA.6040007@gmx.de>
References: <4C30C0BC.4020206@gmx.de> <4C6AB4AA.6040007@gmx.de>
Message-ID: <4C6AC221.3080200@oracle.com>

  It's from the native zlib during tree building.


On 8/17/2010 09:11, Ulf Zibis wrote:
> No feedback since long.
> Nobody knows about this particular error message and it's possible 
> cause ?
>
> -Ulf
>
>
> Am 04.07.2010 19:11, schrieb Ulf Zibis:
>> Hi,
>>
>> writing data to a zip file returns following 2 error lines:
>> bit length overflow
>> code 0 bits 6->7
>> I use:
>>     DataOutputStream dos = new DataOutputStream(new 
>> DeflaterOutputStream(new FileOutputStream(outFilePathName)));
>>
>> Is there any idea, where this comes from?
>>
>> The class to run:
>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/JDK-7/j_l_Character_names/src_sherman2/build/tools/generatecharacter/CharacterNamesGenerator6.java?rev=1106&view=markup 
>>
>> (From NetBeans run configuration gen_sherman2_6)
>> My project:
>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/JDK-7/j_l_Character_names/?rev=1106 
>>
>>
>> If I write to normal file, no error occurs:
>>      DataOutputStream dos = new DataOutputStream(new 
>> FileOutputStream(outFilePathName));
>>
>> -Ulf
>>
>>
>>
>>
>>
>



From xueming.shen at oracle.com  Tue Aug 17 23:07:31 2010
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Tue, 17 Aug 2010 23:07:31 +0000
Subject: hg: jdk7/tl/jdk: 6969651: TEST_BUG: tools/jar/JarEntryTime.java
	failed on JDK7 when run on NFS
Message-ID: <20100817230740.B70464725D@hg.openjdk.java.net>

Changeset: bfc3855a9341
Author:    sherman
Date:      2010-08-17 16:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bfc3855a9341

6969651: TEST_BUG: tools/jar/JarEntryTime.java failed on JDK7 when run on NFS
Summary: changed to use more appropriate nfs file time
Reviewed-by: martin

! test/tools/jar/JarEntryTime.java



From kelly.ohair at oracle.com  Thu Aug 19 01:46:37 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Thu, 19 Aug 2010 01:46:37 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100819014656.681F8472A0@hg.openjdk.java.net>

Changeset: 01dec49e95c4
Author:    ohair
Date:      2010-08-18 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/01dec49e95c4

6974005: Use of cygpath in Makefile logic needs to silence error messages
Reviewed-by: mchung

! make/common/shared/Defs-windows.gmk

Changeset: 42bfa43f2ae1
Author:    ohair
Date:      2010-08-18 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/42bfa43f2ae1

6932743: Makefiles not parsing version strings with - from uname -r
Reviewed-by: mchung

! make/common/shared/Defs.gmk



From weijun.wang at sun.com  Thu Aug 19 03:27:10 2010
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Thu, 19 Aug 2010 03:27:10 +0000
Subject: hg: jdk7/tl/jdk: 6976536: Solaris JREs do not have the
	krb5.kdc.bad.policy configured by default.
Message-ID: <20100819032719.85816472A4@hg.openjdk.java.net>

Changeset: 4abd65f04638
Author:    weijun
Date:      2010-08-19 11:26 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4abd65f04638

6976536: Solaris JREs do not have the krb5.kdc.bad.policy configured by default.
Reviewed-by: valeriep

! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
+ test/sun/security/krb5/BadKdcDefaultValue.java



From weijun.wang at sun.com  Thu Aug 19 04:25:11 2010
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Thu, 19 Aug 2010 04:25:11 +0000
Subject: hg: jdk7/tl/jdk: 6921610: 1.6 update 17 and 18 throw
	java.lang.IndexOutOfBoundsException
Message-ID: <20100819042521.C27C4472A7@hg.openjdk.java.net>

Changeset: 95bb147c7c33
Author:    weijun
Date:      2010-08-19 12:24 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/95bb147c7c33

6921610: 1.6 update 17 and 18 throw java.lang.IndexOutOfBoundsException
Reviewed-by: vinnie, xuelei

! src/share/classes/com/sun/jndi/ldap/Connection.java



From maurizio.cimadamore at oracle.com  Thu Aug 19 11:04:46 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 19 Aug 2010 11:04:46 +0000
Subject: hg: jdk7/tl/langtools: 3 new changesets
Message-ID: <20100819110452.C4D74472B7@hg.openjdk.java.net>

Changeset: c655e0280bdc
Author:    mcimadamore
Date:      2010-08-19 11:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c655e0280bdc

6886247: regression: javac crashes with an assertion error in Attr.java
Summary: capture conversion does not work on nested types
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_1.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_2.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_2.out

Changeset: d6fe0ea070aa
Author:    mcimadamore
Date:      2010-08-19 11:52 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d6fe0ea070aa

6885255: Improve usability of raw warnings
Summary: raw warnings should be disabled in (i) instanceof expressions and (ii) when java.lang.Class is not parameterized
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/warnings/6747671/T6747671.java
! test/tools/javac/warnings/6747671/T6747671.out
+ test/tools/javac/warnings/6885255/T6885255.java
+ test/tools/javac/warnings/6885255/T6885255.out

Changeset: a75770c0d7f6
Author:    mcimadamore
Date:      2010-08-19 11:54 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a75770c0d7f6

6977800: Regression: invalid resolution of supertype for local class
Summary: resolution of superclass/superinterfaces in extends/implements clause skips local classes
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/T6977800.java
! test/tools/javac/generics/typevars/5060485/Compatibility.java
+ test/tools/javac/generics/typevars/5060485/Compatibility.out
+ test/tools/javac/generics/typevars/5060485/Compatibility02.java
+ test/tools/javac/generics/typevars/5060485/Compatibility02.out



From forax at univ-mlv.fr  Thu Aug 19 15:21:05 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 19 Aug 2010 17:21:05 +0200
Subject: hg: jdk7/tl/langtools: 3 new changesets
In-Reply-To: <20100819110452.C4D74472B7@hg.openjdk.java.net>
References: <20100819110452.C4D74472B7@hg.openjdk.java.net>
Message-ID: <4C6D4BE1.1000203@univ-mlv.fr>


> Changeset: d6fe0ea070aa
> Author:    mcimadamore
> Date:      2010-08-19 11:52 +0100
> URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d6fe0ea070aa
>
> 6885255: Improve usability of raw warnings
> Summary: raw warnings should be disabled in (i) instanceof expressions and (ii) when java.lang.Class is not parameterized
> Reviewed-by: jjg
>
> ! src/share/classes/com/sun/tools/javac/comp/Attr.java
> ! src/share/classes/com/sun/tools/javac/comp/Check.java
> ! test/tools/javac/warnings/6747671/T6747671.java
> ! test/tools/javac/warnings/6747671/T6747671.out
> + test/tools/javac/warnings/6885255/T6885255.java
> + test/tools/javac/warnings/6885255/T6885255.out
>    

We discuss [1] about Class<rawtype> and instanceof rawtype but not cast 
(rawtype).
I was able to convince myself that a cast with a raw type doesn't harm.

I just want to be sure that it's ok for everybody (Martin?).

R?mi
[1] http://blogs.sun.com/mcimadamore/entry/diagnosing_raw_types



From maurizio.cimadamore at oracle.com  Thu Aug 19 15:30:55 2010
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 19 Aug 2010 16:30:55 +0100
Subject: [Fwd: Re: hg: jdk7/tl/langtools: 3 new changesets]
In-Reply-To: <4C6D4C58.2000703@oracle.com>
References: <4C6D4C58.2000703@oracle.com>
Message-ID: <4C6D4E2F.1010709@oracle.com>

Hi Remi,
I'd be tempted to say that a cast to a raw type is likely to reveal a 
suspicious behavior in the source code; as such I'd be for keeping the 
warnings in raw cast. Note, I just wanted to remove those cases in which 
the warning was unavoidable (as in Object.getClass()) or pointless (in 
instanceof, because it would have force people to go from List to 
List<?> with no apparent benefit).

Maurizio
>
> -------- Original Message --------
> Subject: 	Re: hg: jdk7/tl/langtools: 3 new changesets
> Date: 	Thu, 19 Aug 2010 17:21:05 +0200
> From: 	R?mi Forax <forax at univ-mlv.fr>
> To: 	core-libs-dev at openjdk.java.net
> References: 	<20100819110452.C4D74472B7 at hg.openjdk.java.net>
>
>
>
> >  Changeset: d6fe0ea070aa
> >  Author:    mcimadamore
> >  Date:      2010-08-19 11:52 +0100
> >  URL:http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d6fe0ea070aa
> >
> >  6885255: Improve usability of raw warnings
> >  Summary: raw warnings should be disabled in (i) instanceof expressions and (ii) when java.lang.Class is not parameterized
> >  Reviewed-by: jjg
> >
> >  ! src/share/classes/com/sun/tools/javac/comp/Attr.java
> >  ! src/share/classes/com/sun/tools/javac/comp/Check.java
> >  ! test/tools/javac/warnings/6747671/T6747671.java
> >  ! test/tools/javac/warnings/6747671/T6747671.out
> >  + test/tools/javac/warnings/6885255/T6885255.java
> >  + test/tools/javac/warnings/6885255/T6885255.out
> >
>
> We discuss [1] about Class<rawtype>  and instanceof rawtype but not cast
> (rawtype).
> I was able to convince myself that a cast with a raw type doesn't harm.
>
> I just want to be sure that it's ok for everybody (Martin?).
>
> R?mi
> [1]http://blogs.sun.com/mcimadamore/entry/diagnosing_raw_types
>
>    

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

From martinrb at google.com  Thu Aug 19 17:11:54 2010
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 19 Aug 2010 10:11:54 -0700
Subject: hg: jdk7/tl/langtools: 3 new changesets
In-Reply-To: <4C6D4BE1.1000203@univ-mlv.fr>
References: <20100819110452.C4D74472B7@hg.openjdk.java.net>
	<4C6D4BE1.1000203@univ-mlv.fr>
Message-ID: <AANLkTikT89N===n5KU-nUVU8Hv=y8skT0p62=g=J=58r@mail.gmail.com>

On Thu, Aug 19, 2010 at 08:21, R?mi Forax <forax at univ-mlv.fr> wrote:

>
>  Changeset: d6fe0ea070aa
>> Author:    mcimadamore
>> Date:      2010-08-19 11:52 +0100
>> URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d6fe0ea070aa
>>
>> 6885255: Improve usability of raw warnings
>> Summary: raw warnings should be disabled in (i) instanceof expressions and
>> (ii) when java.lang.Class is not parameterized
>> Reviewed-by: jjg
>>
>> ! src/share/classes/com/sun/tools/javac/comp/Attr.java
>> ! src/share/classes/com/sun/tools/javac/comp/Check.java
>> ! test/tools/javac/warnings/6747671/T6747671.java
>> ! test/tools/javac/warnings/6747671/T6747671.out
>> + test/tools/javac/warnings/6885255/T6885255.java
>> + test/tools/javac/warnings/6885255/T6885255.out
>>
>>
>
> We discuss [1] about Class<rawtype> and instanceof rawtype but not cast
> (rawtype).
> I was able to convince myself that a cast with a raw type doesn't harm.
>
> I just want to be sure that it's ok for everybody (Martin?).
>
>



> R?mi
> [1] http://blogs.sun.com/mcimadamore/entry/diagnosing_raw_types
>
>
Remi, Thanks for reminding me of that blog entry.

Maurizio, thanks for fixing this.

I may try to clean up warnings in j.u.c. someday, and see what happens.

One more thought... if we accept your statement that

"""The second argument of an instanceof should be a reifiable (see JLS 4.7)
reference type"""

then in today's world if they wrote

if (x instanceof List<?>) { ..... ((List<String>) x) }

then that would fail in some future world when reification allowed us to
distinguish between List<?> and List<String> at runtime.  In other words,
pushing people to switch from

instanceof List

to

instanceof List<?>

may be doing them a disservice.

Martin (not a compiler guy)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100819/6cbb6ea8/attachment.html>

From Ulf.Zibis at gmx.de  Thu Aug 19 20:05:05 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 19 Aug 2010 22:05:05 +0200
Subject: possible bug in java.util.DeflaterOutputStream
In-Reply-To: <4C6AC221.3080200@oracle.com>
References: <4C30C0BC.4020206@gmx.de> <4C6AB4AA.6040007@gmx.de>
	<4C6AC221.3080200@oracle.com>
Message-ID: <4C6D8E71.3050008@gmx.de>

Ok, thanks, should I file a bug, or is it expected behaviour in some 
circumstances?
BTW, I used build fastdebug-b84 that time.

-Ulf


Am 17.08.2010 19:08, schrieb Xueming Shen:
>  It's from the native zlib during tree building.
>
>
> On 8/17/2010 09:11, Ulf Zibis wrote:
>> No feedback since long.
>> Nobody knows about this particular error message and it's possible 
>> cause ?
>>
>> -Ulf
>>
>>
>> Am 04.07.2010 19:11, schrieb Ulf Zibis:
>>> Hi,
>>>
>>> writing data to a zip file returns following 2 error lines:
>>> bit length overflow
>>> code 0 bits 6->7
>>> I use:
>>>     DataOutputStream dos = new DataOutputStream(new 
>>> DeflaterOutputStream(new FileOutputStream(outFilePathName)));
>>>
>>> Is there any idea, where this comes from?
>>>
>>> The class to run:
>>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/JDK-7/j_l_Character_names/src_sherman2/build/tools/generatecharacter/CharacterNamesGenerator6.java?rev=1106&view=markup 
>>>
>>> (From NetBeans run configuration gen_sherman2_6)
>>> My project:
>>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/JDK-7/j_l_Character_names/?rev=1106 
>>>
>>>
>>> If I write to normal file, no error occurs:
>>>      DataOutputStream dos = new DataOutputStream(new 
>>> FileOutputStream(outFilePathName));
>>>
>>> -Ulf
>>>
>>>
>>>
>>>
>>>
>>
>
>
>



From kumar.x.srinivasan at oracle.com  Fri Aug 20 15:51:43 2010
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Fri, 20 Aug 2010 15:51:43 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20100820155217.D5DAB4730D@hg.openjdk.java.net>

Changeset: 1ce9c1690080
Author:    ksrini
Date:      2010-08-19 14:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1ce9c1690080

6888127: java.util.jar.Pack200.Packer Memory Leak
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/Driver.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/Package.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
+ src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java
! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/Utils.java

Changeset: 16e43f336262
Author:    ksrini
Date:      2010-08-20 08:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16e43f336262

6966737: (pack200) the pack200 regression tests need to be more robust.
Reviewed-by: jrose, ohair

+ test/tools/pack200/CommandLineTests.java
- test/tools/pack200/Pack200Simple.sh
! test/tools/pack200/Pack200Test.java
! test/tools/pack200/PackageVersionTest.java
! test/tools/pack200/SegmentLimit.java
+ test/tools/pack200/Utils.java
+ test/tools/pack200/pack200-verifier/data/README
+ test/tools/pack200/pack200-verifier/data/golden.jar
+ test/tools/pack200/pack200-verifier/make/build.xml
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/ClassCompare.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Globals.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/JarFileCompare.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Main.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/VerifyTreeSet.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/CommandLineParser.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/TokenList.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/XMLKit.java

Changeset: db1b7c10de61
Author:    ksrini
Date:      2010-08-20 08:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/db1b7c10de61

Merge




From chris.hegarty at oracle.com  Mon Aug 23 13:36:04 2010
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 23 Aug 2010 13:36:04 +0000
Subject: hg: jdk7/tl/jdk: 6968584: Thread should not be Cloneable
Message-ID: <20100823133621.6DB78473B0@hg.openjdk.java.net>

Changeset: fd28003bc1d6
Author:    chegar
Date:      2010-08-23 14:35 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd28003bc1d6

6968584: Thread should not be Cloneable
Reviewed-by: dholmes

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



From chris.hegarty at oracle.com  Mon Aug 23 15:28:58 2010
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 23 Aug 2010 15:28:58 +0000
Subject: hg: jdk7/tl/jdk: 6965924: java.net.HttpCookie using static
	SimpleDateFormat which is not thread safe
Message-ID: <20100823152907.B3C4D473B5@hg.openjdk.java.net>

Changeset: 03218163f4d5
Author:    chegar
Date:      2010-08-23 16:27 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03218163f4d5

6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe
Reviewed-by: michaelm

! src/share/classes/java/net/HttpCookie.java



From maurizio.cimadamore at oracle.com  Mon Aug 23 16:01:09 2010
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 23 Aug 2010 16:01:09 +0000
Subject: hg: jdk7/tl/langtools: 2 new changesets
Message-ID: <20100823160112.D7979473B7@hg.openjdk.java.net>

Changeset: 995bcdb9a41d
Author:    mcimadamore
Date:      2010-08-23 16:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/995bcdb9a41d

6932571: Compiling Generics causing Inconvertible types
Summary: Types.rewriteQuantifiers() does not work well with recursive type-variable bounds
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/6270087/T6270087.java
+ test/tools/javac/cast/6270087/T6270087neg.java
+ test/tools/javac/cast/6270087/T6270087neg.out
+ test/tools/javac/cast/6507317/T6507317.java
+ test/tools/javac/cast/6569057/T6569057.java
+ test/tools/javac/cast/6932571/T6932571a.java
+ test/tools/javac/cast/6932571/T6932571b.java
+ test/tools/javac/cast/6932571/T6932571neg.java
+ test/tools/javac/cast/6932571/T6932571neg.out

Changeset: 594b3c2ef585
Author:    mcimadamore
Date:      2010-08-23 17:00 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/594b3c2ef585

6978574: return statement in try block with multi-catch causes ClassFormatError
Summary: Wrong nested loops in Gen.java causes javac to generate bad bytecode
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/multicatch/T6978574.java



From alan.bateman at oracle.com  Mon Aug 23 16:38:39 2010
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 23 Aug 2010 16:38:39 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100823163858.03F76473BA@hg.openjdk.java.net>

Changeset: 47ab0dcec3e8
Author:    alanb
Date:      2010-08-23 17:11 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/47ab0dcec3e8

6978511: (file) Path.toRealPath should fail if not resolving links and file does not exist
Reviewed-by: forax, chegar

! src/solaris/classes/sun/nio/fs/UnixPath.java
! test/java/nio/file/Path/Misc.java

Changeset: f4a2b4e7a831
Author:    alanb
Date:      2010-08-23 17:35 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f4a2b4e7a831

6431344: (fc) FileChannel.transferTo() doesn't work if address space runs out
Reviewed-by: forax, chegar

! src/share/classes/sun/nio/ch/FileChannelImpl.java



From jonathan.gibbons at oracle.com  Mon Aug 23 18:57:57 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 23 Aug 2010 18:57:57 +0000
Subject: hg: jdk7/tl/langtools: 6975005: improve
	JavacProcessingEnvironment.Round abstraction
Message-ID: <20100823185759.33223473C0@hg.openjdk.java.net>

Changeset: 6b95dd682538
Author:    jjg
Date:      2010-08-23 11:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6b95dd682538

6975005: improve JavacProcessingEnvironment.Round abstraction
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! test/tools/javac/T6358024.java
! test/tools/javac/T6403466.out
! test/tools/javac/processing/filer/TestLastRound.out



From kumar.x.srinivasan at oracle.com  Mon Aug 23 19:44:11 2010
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Mon, 23 Aug 2010 19:44:11 +0000
Subject: hg: jdk7/tl/jdk: 6531345: Memory leak in unpack200
Message-ID: <20100823194420.90502473C2@hg.openjdk.java.net>

Changeset: 6317f7e2c4fd
Author:    ksrini
Date:      2010-08-23 08:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6317f7e2c4fd

6531345: Memory leak in unpack200
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
+ test/tools/pack200/UnpackerMemoryTest.java
! test/tools/pack200/Utils.java



From chris.hegarty at oracle.com  Mon Aug 23 21:00:32 2010
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 23 Aug 2010 21:00:32 +0000
Subject: hg: jdk7/tl/jdk: 6977851: NPE from FileURLConnection.connect
Message-ID: <20100823210042.D30B2473C8@hg.openjdk.java.net>

Changeset: cb67f0263bd4
Author:    chegar
Date:      2010-08-23 21:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb67f0263bd4

6977851: NPE from FileURLConnection.connect
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/file/FileURLConnection.java
+ test/sun/net/www/protocol/file/DirPermissionDenied.java
+ test/sun/net/www/protocol/file/DirPermissionDenied.sh



From jonathan.gibbons at oracle.com  Mon Aug 23 22:13:31 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 23 Aug 2010 22:13:31 +0000
Subject: hg: jdk7/tl/langtools: 6976747: JCDiagnostic: replace "boolean
	mandatory" with new "Set<JCDiagnostic.Flag>"
Message-ID: <20100823221333.A95CE473CB@hg.openjdk.java.net>

Changeset: a626d8c1de6e
Author:    jjg
Date:      2010-08-23 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a626d8c1de6e

6976747: JCDiagnostic: replace "boolean mandatory" with new "Set<JCDiagnostic.Flag>"
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java



From kumar.x.srinivasan at oracle.com  Tue Aug 24 00:21:38 2010
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Tue, 24 Aug 2010 00:21:38 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100824002158.9C155473D2@hg.openjdk.java.net>

Changeset: 2585368bfc7c
Author:    ksrini
Date:      2010-08-23 10:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2585368bfc7c

6969063: (pack200) The default value of Pack200.Packer.SEGMENT_LIMIT property is empty string instead of -1
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
+ test/tools/pack200/Pack200Props.java
- test/tools/pack200/SegmentLimit.java

Changeset: 732f59013e78
Author:    ksrini
Date:      2010-08-23 10:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/732f59013e78

6966740: (pack200) need to add the timezone regression test
Reviewed-by: jrose

+ test/tools/pack200/TimeStamp.java
! test/tools/pack200/Utils.java



From ahughes at redhat.com  Tue Aug 24 12:29:08 2010
From: ahughes at redhat.com (ahughes at redhat.com)
Date: Tue, 24 Aug 2010 12:29:08 +0000
Subject: hg: jdk7/tl: 6976186: Integrate Shark
Message-ID: <20100824122908.2F04A473ED@hg.openjdk.java.net>

Changeset: 1fbed32d2ddd
Author:    gbenson
Date:      2010-08-24 13:27 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/1fbed32d2ddd

6976186: Integrate Shark
Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure.
Reviewed-by: ohair

! make/hotspot-rules.gmk



From jonathan.gibbons at oracle.com  Tue Aug 24 18:31:02 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 24 Aug 2010 18:31:02 +0000
Subject: hg: jdk7/tl/langtools: 6935638: -implicit:none prevents compilation
	with annotation processing
Message-ID: <20100824183104.4CEC8473FD@hg.openjdk.java.net>

Changeset: e9d09e97d669
Author:    jjg
Date:      2010-08-24 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e9d09e97d669

6935638: -implicit:none prevents compilation with annotation processing
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/processing/options/TestImplicitNone.java



From jonathan.gibbons at oracle.com  Tue Aug 24 22:09:37 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 24 Aug 2010 22:09:37 +0000
Subject: hg: jdk7/tl/langtools: 6929404: Filer.getResource(SOURCE_PATH,
	...) does not work when -sourcepath contains >1 entry
Message-ID: <20100824220939.CA0CE47405@hg.openjdk.java.net>

Changeset: f3323b1c65ee
Author:    jjg
Date:      2010-08-24 15:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f3323b1c65ee

6929404: Filer.getResource(SOURCE_PATH, ...) does not work when -sourcepath contains >1 entry
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java
+ test/tools/javac/processing/filer/TestGetResource2.java



From jonathan.gibbons at oracle.com  Wed Aug 25 18:24:31 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 25 Aug 2010 18:24:31 +0000
Subject: hg: jdk7/tl/langtools: 6979564: ":" for path separator in
	dist/bin/javac does not work on Windows
Message-ID: <20100825182439.D167E47433@hg.openjdk.java.net>

Changeset: 6ef801fa38b7
Author:    jjg
Date:      2010-08-25 11:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6ef801fa38b7

6979564: ":" for path separator in dist/bin/javac does not work on Windows
Reviewed-by: jjh

! make/build.xml
! src/share/bin/launcher.sh-template



From jonathan.gibbons at oracle.com  Wed Aug 25 18:40:42 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 25 Aug 2010 18:40:42 +0000
Subject: hg: jdk7/tl/langtools: 6960424: new option -Xpkginfo for better
	control of when package-info.class is generated
Message-ID: <20100825184044.1AF2847435@hg.openjdk.java.net>

Changeset: 70ebdef189c9
Author:    jjg
Date:      2010-08-25 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/70ebdef189c9

6960424: new option -Xpkginfo for better control of when package-info.class is generated
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Attribute.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/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/main/OptionName.java
! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java
! src/share/classes/com/sun/tools/javac/resources/javac.properties
+ test/tools/javac/TestPkgInfo.java



From pawel.veselov at gmail.com  Wed Aug 25 21:47:20 2010
From: pawel.veselov at gmail.com (Pawel Veselov)
Date: Wed, 25 Aug 2010 14:47:20 -0700
Subject: Base 64
Message-ID: <AANLkTik9ti2K8g6A0P0ku-FWTZQhk7xey0s5KJQFSa-b@mail.gmail.com>

Greetings.

After yet another googling for "java base64 implementation",
I figured I gotta say something here as well.
Well, all right, the argument can be made that JDK
shouldn't be supporting all of them obscure data transformation
standards, there is a qillion of them out there, after all. But
base64 being used well too wide for cryptography, IMHO,
the JCA framework should include a cipher for it.

P.S. Am I imagining things, or there has been way less traffic
on this list lately?

Thanks,
-- Pawel.


From naoto.sato at oracle.com  Wed Aug 25 22:35:33 2010
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 25 Aug 2010 22:35:33 +0000
Subject: hg: jdk7/tl/langtools: 6875847: Java Locale Enhancement
Message-ID: <20100825223535.1EC594743F@hg.openjdk.java.net>

Changeset: ecff24121064
Author:    naoto
Date:      2010-08-25 15:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ecff24121064

6875847: Java Locale Enhancement
Summary: Fix for javac to allow "sun.util.locale" package accessible.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/resources/legacy.properties



From joe.darcy at oracle.com  Wed Aug 25 22:36:04 2010
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 25 Aug 2010 22:36:04 +0000
Subject: hg: jdk7/tl/jdk: 6980019: Finish rename of ARM -> try-with-resources
	in jdk repository
Message-ID: <20100825223613.A1FB447440@hg.openjdk.java.net>

Changeset: 93c49f01a4c2
Author:    darcy
Date:      2010-08-25 15:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93c49f01a4c2

6980019: Finish rename of ARM -> try-with-resources in jdk repository
Reviewed-by: jjg

! src/share/classes/java/lang/AutoCloseable.java
! src/share/classes/java/lang/Throwable.java



From Ulf.Zibis at gmx.de  Wed Aug 25 23:43:39 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 26 Aug 2010 01:43:39 +0200
Subject: Pending Character-related work - UncodeBlock2
In-Reply-To: <AANLkTin0ySEdCVz-o1+L2Lfr5aUwarS6wBN5YuOWrPzE@mail.gmail.com>
References: <1ccfd1c11003291547k1bde83d7n9e8ed3cf367aa4a0@mail.gmail.com>	<AANLkTikjzj4VUwK6phR57SL-SpCJRlEwPfABJ-mijF0x@mail.gmail.com>	<4C21962F.8030509@oracle.com>	<AANLkTilr_3TAx6YdhKkVjQ16SUw492Xj86beVKK_fNsi@mail.gmail.com>	<4C21D0C4.8090206@oracle.com>	<AANLkTikORwwPDmF02P0CUcbAn84sB_2dht0zyg-wU9sd@mail.gmail.com>	<4C293101.4040207@oracle.com>	<AANLkTinBnoYAgW59eyLiakVE_kGRgoHomS3jQ3VRlbOU@mail.gmail.com>	<4C29F347.1030801@oracle.com>
	<AANLkTin0ySEdCVz-o1+L2Lfr5aUwarS6wBN5YuOWrPzE@mail.gmail.com>
Message-ID: <4C75AAAB.6020400@gmx.de>

Short thoughts:

1. think about using PreHashedMap
2. think about using CharSequence build by StringBuilder as HashMap key. 
This would save the char[] copies while instantiating the immutable 
strings. More sophisticated you could use a simple byte[] containing the 
ISO-8859 coded chars. Latter would speed up the the comparison, as only 
half of raw bytes must be compared.

-Ulf

P.S.: I'm in vacation since Tuesday.


Am 26.08.2010 00:12, schrieb Martin Buchholz:
> Ping - I haven't heard any news from you lately.
> Is there anything holding up this change?
>
> (I'm finally getting some time to work on jdk7 again...)
>
> Martin
>
> On Tue, Jun 29, 2010 at 06:21, Masayoshi Okutsu 
> <masayoshi.okutsu at oracle.com <mailto:masayoshi.okutsu at oracle.com>> wrote:
>
>     All the changes look good.
>
>     Now, I'll take care of CCC for the forName change.
>
>     Thanks,
>     Masayoshi
>
>     On 6/29/2010 8:54 AM, Martin Buchholz wrote:
>
>         On Mon, Jun 28, 2010 at 16:32, Masayoshi Okutsu
>         <masayoshi.okutsu at oracle.com
>         <mailto:masayoshi.okutsu at oracle.com>>  wrote:
>
>             Hi Martin,
>
>             On 6/29/2010 6:18 AM, Martin Buchholz wrote:
>
>                 Hi Masayoshi,
>
>                 OK, I implemented your suggestion as a follow-on change
>
>                 http://cr.openjdk.java.net/~martin/webrevs/openjdk7/UnicodeBlock2/
>                 <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/UnicodeBlock2/>
>
>
>             I've just skimmed the webrev. The changes look good. I
>             will review them in
>             details later today. A question is, do we need CCC
>             approval on the forName
>             change? Strictly speaking, it's a behavioral change.
>
>         Yes, I am changing the javadoc.  On the other hand, this
>         brings the
>         code and spec
>         into compliance with the Unicode standard, which was already
>         documented,
>         so one can regard this as a clarification and bug fix!
>
>         I leave it to you to decide whether to submit this to CCC.
>
>         Of course, it is an incompatible change, but the mildest such.
>
>         "''
>         Were you really depending on UnicodeBlock.forName("----basic __
>         latin") throwing?
>         """
>
>
>                 (I plan to commit the already reviewed earlier batch
>                 of changes soon)
>
>                 BTW: is jdk7 going to implement the 5.2.0 version of
>                 the standard?
>                 If so, then we should make some further changes, like
>                 accepting "ASCII"
>                 as an alias for "Basic Latin".
>
>
>             It's very likely Unicode 6.0 which should be released in
>             September. Yuka has
>             done all 5.2.0 changes, but she is waiting for some legal
>             approval. Oracle
>             legal takes much more time to review.
>
>         I see....  Legal response time was already very long during
>         the Sun era.
>
>         Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100826/72104a20/attachment.html>

From jonathan.gibbons at oracle.com  Thu Aug 26 22:17:47 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 26 Aug 2010 22:17:47 +0000
Subject: hg: jdk7/tl/langtools: 6604599: ToolProvider should be less
	compiler-specific
Message-ID: <20100826221748.E1EAC4747A@hg.openjdk.java.net>

Changeset: cfd047f3cf60
Author:    jjg
Date:      2010-08-26 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/cfd047f3cf60

6604599: ToolProvider should be less compiler-specific
Reviewed-by: darcy

! src/share/classes/javax/tools/ToolProvider.java
+ test/tools/javac/api/ToolProvider/HelloWorldTest.java
+ test/tools/javac/api/ToolProvider/ToolProviderTest1.java
+ test/tools/javac/api/ToolProvider/ToolProviderTest2.java



From jonathan.gibbons at oracle.com  Thu Aug 26 23:13:57 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 26 Aug 2010 23:13:57 +0000
Subject: hg: jdk7/tl/langtools: 6980017: javap -XDdetail:source behaves badly
	if source not available.
Message-ID: <20100826231402.47CB34747F@hg.openjdk.java.net>

Changeset: ae3acbf63943
Author:    jjg
Date:      2010-08-26 16:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ae3acbf63943

6980017: javap -XDdetail:source behaves badly if source not available.
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javap/CodeWriter.java
! src/share/classes/com/sun/tools/javap/SourceWriter.java
+ test/tools/javap/T6980017.java



From martinrb at google.com  Fri Aug 27 22:30:47 2010
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Aug 2010 15:30:47 -0700
Subject: Possible SecurityException creating processes on Linux
Message-ID: <AANLkTikaH-=G6-LkgTnutm8tbd7wjPvBoLYORbZB9vog@mail.gmail.com>

This is a bug report with fix.

I didn't add enough doPrivileged blocks into my recent
UNIXProcess.java.linux.

Not very likely in practice, but has been observed in the wild.

Here's a fix:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/ProcessDoPrivileged/

Please review.

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

From jonathan.gibbons at oracle.com  Sat Aug 28 00:15:21 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 28 Aug 2010 00:15:21 +0000
Subject: hg: jdk7/tl/langtools: 6980724: test/tools/javac/InterfaceAssert.java
	sometimes fails
Message-ID: <20100828001523.5E57B474CE@hg.openjdk.java.net>

Changeset: 3a9f319be48a
Author:    jjg
Date:      2010-08-27 17:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3a9f319be48a

6980724: test/tools/javac/InterfaceAssert.java sometimes fails
Reviewed-by: darcy

! test/tools/javac/InterfaceAssert.java



From jonathan.gibbons at oracle.com  Sat Aug 28 00:21:05 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 28 Aug 2010 00:21:05 +0000
Subject: hg: jdk7/tl/langtools: 6570730:
	com.sun.source.tree.ModifiersTree.getFlags() should return class type
Message-ID: <20100828002107.6DB23474CF@hg.openjdk.java.net>

Changeset: b4e7a57af8df
Author:    jjg
Date:      2010-08-27 17:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b4e7a57af8df

6570730: com.sun.source.tree.ModifiersTree.getFlags() should return class type
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
- test/tools/javac/T6341023.java
+ test/tools/javac/tree/ClassTreeTest.java
+ test/tools/javac/tree/TreeKindTest.java



From jonathan.gibbons at oracle.com  Sat Aug 28 00:59:21 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 28 Aug 2010 00:59:21 +0000
Subject: hg: jdk7/tl/langtools: 6980707: Reduce use of IOException in
	JavaCompiler
Message-ID: <20100828005922.F1F49474D2@hg.openjdk.java.net>

Changeset: eb7c263aab73
Author:    jjg
Date:      2010-08-27 17:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/eb7c263aab73

6980707: Reduce use of IOException in JavaCompiler
Reviewed-by: darcy

! 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/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/FatalError.java
! test/tools/javac/diags/examples.not-yet.txt



From Alan.Bateman at oracle.com  Sat Aug 28 08:36:03 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 28 Aug 2010 09:36:03 +0100
Subject: Possible SecurityException creating processes on Linux
In-Reply-To: <AANLkTikaH-=G6-LkgTnutm8tbd7wjPvBoLYORbZB9vog@mail.gmail.com>
References: <AANLkTikaH-=G6-LkgTnutm8tbd7wjPvBoLYORbZB9vog@mail.gmail.com>
Message-ID: <4C78CA73.8@oracle.com>

Martin Buchholz wrote:
> This is a bug report with fix.
>
> I didn't add enough doPrivileged blocks into my recent 
> UNIXProcess.java.linux.
>
> Not very likely in practice, but has been observed in the wild.
>
> Here's a fix:
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/ProcessDoPrivileged/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/ProcessDoPrivileged/>
>
> Please review.
>
> Martin
I've created this:
  6980747: (process) Runtime.exec can fail due to SecurityException (lnx)

The fix looks fine.  It might be good to indent the second and third 
lines of the test summary to make it easier to distinguish the test tags 
from the text. On Windows I assume the "env" command will run the Cygwin 
or MKS "env" program rather than the built-in "env" command. It probably 
matter as the test doesn't actually need the child process to do anything.

-Alan.



From martinrb at google.com  Sat Aug 28 19:02:49 2010
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 28 Aug 2010 12:02:49 -0700
Subject: Possible SecurityException creating processes on Linux
In-Reply-To: <4C78CA73.8@oracle.com>
References: <AANLkTikaH-=G6-LkgTnutm8tbd7wjPvBoLYORbZB9vog@mail.gmail.com>
	<4C78CA73.8@oracle.com>
Message-ID: <AANLkTi=2FR1hxKUe4iNCJnUUAkfM-vpQWLtQWAbAMo-Z@mail.gmail.com>

Hi Alan,

Thanks for the review.

On Sat, Aug 28, 2010 at 01:36, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> Martin Buchholz wrote:
>
>>
>> The fix looks fine.  It might be good to indent the second and third lines
> of the test summary


Done.


> to make it easier to distinguish the test tags from the text. On Windows I
> assume the "env" command will run the Cygwin or MKS "env" program rather
> than the built-in "env" command.


I changed this to use the most portable process invocation, namely
<java.home>/bin/java -version

IOException is no longer acceptable; removed the catch.

It probably matter as the test doesn't actually need the child process to do
> anything.
>
>
Right.  But let's keep our standards as high as possible.

In the same spirit, I tightened the FilePermission from
read,write,execute => execute

Committing.

Martin

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

From martinrb at google.com  Sat Aug 28 19:20:29 2010
From: martinrb at google.com (martinrb at google.com)
Date: Sat, 28 Aug 2010 19:20:29 +0000
Subject: hg: jdk7/tl/jdk: 6980747: Runtime.exec can fail due to
	SecurityException (lnx)
Message-ID: <20100828192038.BD37F474F8@hg.openjdk.java.net>

Changeset: 1470dffe6551
Author:    martin
Date:      2010-08-28 12:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1470dffe6551

6980747: Runtime.exec can fail due to SecurityException (lnx)
Summary: Add missing doPrivileged to UNIXProcess.java.linux
Reviewed-by: alanb

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



From weijun.wang at sun.com  Mon Aug 30 07:29:59 2010
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Mon, 30 Aug 2010 07:29:59 +0000
Subject: hg: jdk7/tl/jdk: 6911951: NTLM should be a supported Java SASL
	mechanism
Message-ID: <20100830073009.75A1047541@hg.openjdk.java.net>

Changeset: 9be643e70f42
Author:    weijun
Date:      2010-08-30 14:37 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9be643e70f42

6911951: NTLM should be a supported Java SASL mechanism
Reviewed-by: vinnie, michaelm

+ src/share/classes/com/sun/security/ntlm/Client.java
+ src/share/classes/com/sun/security/ntlm/NTLM.java
+ src/share/classes/com/sun/security/ntlm/NTLMException.java
+ src/share/classes/com/sun/security/ntlm/Server.java
+ src/share/classes/com/sun/security/ntlm/Version.java
! src/share/classes/com/sun/security/sasl/Provider.java
+ src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java
+ src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java
+ src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java
+ test/com/sun/security/sasl/ntlm/NTLMTest.java



From martinrb at google.com  Mon Aug 30 18:38:56 2010
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 30 Aug 2010 11:38:56 -0700
Subject: Process.waitFor() may hang if subprocess has live descendants (lnx)
Message-ID: <AANLkTi=Pzar2W95FZ31WqUSN67Q+OH_0KXKd-TL3oCFV@mail.gmail.com>

This is a bug report with fix.

My code in UNIXProcess.java.linux introduced a hang if the subprocess
terminates, but it has remaining descendants that keep the pipe file
descriptors open.

Here's a fix:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/ProcessHang/<http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/ProcessHang/>

Please review.

Alan, there are remaining (pre-existing) thorny issues with proper handling
of process streams and asynchronous close, that we might want to discuss
someday.



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

From jonathan.gibbons at oracle.com  Tue Aug 31 01:03:57 2010
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 31 Aug 2010 01:03:57 +0000
Subject: hg: jdk7/tl/langtools: 6403465: javac should defer diagnostics until
	it can be determined they are persistent
Message-ID: <20100831010359.3E5A947568@hg.openjdk.java.net>

Changeset: 4124840b35fe
Author:    jjg
Date:      2010-08-30 18:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4124840b35fe

6403465: javac should defer diagnostics until it can be determined they are persistent
Reviewed-by: mcimadamore, darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! test/tools/javac/processing/6430209/b6341534.java
+ test/tools/javac/processing/errors/TestSuppression.java



From David.Holmes at oracle.com  Tue Aug 31 01:21:01 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 31 Aug 2010 11:21:01 +1000
Subject: Process.waitFor() may hang if subprocess has live descendants
	(lnx)
In-Reply-To: <AANLkTi=Pzar2W95FZ31WqUSN67Q+OH_0KXKd-TL3oCFV@mail.gmail.com>
References: <AANLkTi=Pzar2W95FZ31WqUSN67Q+OH_0KXKd-TL3oCFV@mail.gmail.com>
Message-ID: <4C7C58FD.3030008@oracle.com>

Hi Martin,

My only minor concern with this is the potential change in timing. Is it 
possible that a test will assume the streams are closed when waitFor 
returns? If so I guess we need to update the test.

Cheers,
David

Martin Buchholz said the following on 08/31/10 04:38:
> This is a bug report with fix.
> 
> My code in UNIXProcess.java.linux introduced a hang if the subprocess 
> terminates, but it has remaining descendants that keep the pipe file 
> descriptors open.
> 
> Here's a fix:
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/ProcessHang/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/ProcessHang/>
> 
> Please review.
> 
> Alan, there are remaining (pre-existing) thorny issues with proper 
> handling of process streams and asynchronous close, that we might want 
> to discuss someday.
> 
> 
> 
> Martin


From martinrb at google.com  Tue Aug 31 05:38:34 2010
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 30 Aug 2010 22:38:34 -0700
Subject: Process.waitFor() may hang if subprocess has live descendants
	(lnx)
In-Reply-To: <4C7C58FD.3030008@oracle.com>
References: <AANLkTi=Pzar2W95FZ31WqUSN67Q+OH_0KXKd-TL3oCFV@mail.gmail.com>
	<4C7C58FD.3030008@oracle.com>
Message-ID: <AANLkTi=47QOFksWB5e6R1NXGT3wJwG-q5hDbFfP06A=t@mail.gmail.com>

On Mon, Aug 30, 2010 at 18:21, David Holmes <David.Holmes at oracle.com> wrote:

> Hi Martin,
>
> My only minor concern with this is the potential change in timing. Is it
> possible that a test will assume the streams are closed when waitFor
> returns? If so I guess we need to update the test.
>
>
This change reverts to the historical behavior.

One cannot really close any user-visible stream before waitFor returns,
because there may be buffered data remaining to be read, at both the java
and os pipe level.

(this stuff is all surprisingly tricky... further improvements are possible,
but are going to be much more work)

Martin

Cheers,
> David
>
> Martin Buchholz said the following on 08/31/10 04:38:
>
>> This is a bug report with fix.
>>
>> My code in UNIXProcess.java.linux introduced a hang if the subprocess
>> terminates, but it has remaining descendants that keep the pipe file
>> descriptors open.
>>
>> Here's a fix:
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/ProcessHang/<http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/ProcessHang/><
>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/ProcessHang/>
>>
>>
>> Please review.
>>
>> Alan, there are remaining (pre-existing) thorny issues with proper
>> handling of process streams and asynchronous close, that we might want to
>> discuss someday.
>>
>>
>>
>> Martin
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100830/6f700f88/attachment.html>

From Alan.Bateman at oracle.com  Tue Aug 31 08:51:22 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Aug 2010 09:51:22 +0100
Subject: Process.waitFor() may hang if subprocess has live descendants
	(lnx)
In-Reply-To: <AANLkTi=Pzar2W95FZ31WqUSN67Q+OH_0KXKd-TL3oCFV@mail.gmail.com>
References: <AANLkTi=Pzar2W95FZ31WqUSN67Q+OH_0KXKd-TL3oCFV@mail.gmail.com>
Message-ID: <4C7CC28A.8040802@oracle.com>

Martin Buchholz wrote:
> This is a bug report with fix.
>
> My code in UNIXProcess.java.linux introduced a hang if the subprocess 
> terminates, but it has remaining descendants that keep the pipe file 
> descriptors open.
>
> Here's a fix:
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/ProcessHang/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/ProcessHang/>
>
> Please review.
>
> Alan, there are remaining (pre-existing) thorny issues with proper 
> handling of process streams and asynchronous close, that we might want 
> to discuss someday.
>
>
>
> Martin 
I checked 6944584 [1], and as you said, this is just reverting to how it 
used to work. The change looks fine to me. I've created a bug to track 
this and included a thread dump obtained from running the updated test 
without the fix.

  6981138: (process) Process.waitFor() may hang if subprocess has live 
descendants (lnx)

On the test, it might be best to leave out wakeupJeff for now. Even if 
we come up with a solution for the asynchronous close issues then I 
assume this test will need to change anyway because it runs commands 
that are highly platform dependent.

-Alan.

[1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/422531c98ba5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100831/cdadad14/attachment.html>

From mandy.chung at oracle.com  Tue Aug 31 16:19:33 2010
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 31 Aug 2010 16:19:33 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100831161952.0AC864758A@hg.openjdk.java.net>

Changeset: 6586ab5b79f4
Author:    mchung
Date:      2010-08-31 09:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6586ab5b79f4

6981005: TEST BUG: java/lang/ClassLoader/TestCrossDelegate.sh timeout on windows
Summary: Increase timeout value
Reviewed-by: alanb

! test/ProblemList.txt
! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh

Changeset: def50d3ad78e
Author:    mchung
Date:      2010-08-31 09:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/def50d3ad78e

6977548: Broken link in ClassLoader.defineClass javadoc
Reviewed-by: valeriep

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



From martinrb at google.com  Tue Aug 31 18:17:30 2010
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Aug 2010 11:17:30 -0700
Subject: Process.waitFor() may hang if subprocess has live descendants
	(lnx)
In-Reply-To: <4C7CC28A.8040802@oracle.com>
References: <AANLkTi=Pzar2W95FZ31WqUSN67Q+OH_0KXKd-TL3oCFV@mail.gmail.com>
	<4C7CC28A.8040802@oracle.com>
Message-ID: <AANLkTi=+ehCH7qoCVH11o4XaEvUoJuVpT48raW-Z67Mu@mail.gmail.com>

On Tue, Aug 31, 2010 at 01:51, Alan Bateman <Alan.Bateman at oracle.com> wrote:

>
> On the test, it might be best to leave out wakeupJeff for now. Even if we
> come up with a solution for the asynchronous close issues then I assume this
> test will need to change anyway because it runs commands that are highly
> platform dependent.
>

I prefer to leave in wakeupJeff, and not only because of the
toddler-parent-in-joke.  It demonstrates something I have been wondering
about for years, namely occasional non-reproducible Bad file descriptor
errors (because EINTR can happen at any time, and it is unspecified which
thread in a process is chosen to handle the signal).  You're right that more
test work is needed if this difficult problem is ever addressed.

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

From kelly.ohair at oracle.com  Tue Aug 31 22:51:20 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Tue, 31 Aug 2010 22:51:20 +0000
Subject: hg: jdk7/tl/corba: 2 new changesets
Message-ID: <20100831225121.E937F475A2@hg.openjdk.java.net>

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

Added tag jdk7-b105 for changeset 6f21b030092f

! .hgtags

Changeset: 0f60cf26c5b5
Author:    ohair
Date:      2010-08-30 14:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/0f60cf26c5b5

6981043: Clean out all native code makefile logic from corba repository
Reviewed-by: jjg

! make/Makefile
! make/common/Defs-linux.gmk
! make/common/Defs-solaris.gmk
! make/common/Defs-windows.gmk
! make/common/Defs.gmk
- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
! make/common/Rules.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
! make/common/shared/Defs-java.gmk
! make/common/shared/Defs-linux.gmk
! make/common/shared/Defs-solaris.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Platform.gmk
! make/org/omg/idl/Makefile



From kelly.ohair at oracle.com  Tue Aug 31 22:49:35 2010
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Tue, 31 Aug 2010 22:49:35 +0000
Subject: hg: jdk7/tl/jaxws: 6962317: jdk7 jaxws source bundle still needs
	rebranding; ...
Message-ID: <20100831224935.D045B475A0@hg.openjdk.java.net>

Changeset: c6c2f9094bdd
Author:    ohair
Date:      2010-08-30 16:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/c6c2f9094bdd

6962317: jdk7 jaxws source bundle still needs rebranding
6955300: Missing files in the jaf source bundle
Reviewed-by: ramap

! jaxws.properties