From xuelei.fan at oracle.com  Tue Aug  2 09:19:19 2011
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 02 Aug 2011 17:19:19 +0800
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E34155E.5090700@oracle.com>
References: <4E34155E.5090700@oracle.com>
Message-ID: <4E37C117.2030104@oracle.com>

> Please review these JNDI changes.
> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072353
> webrev: http://cr.openjdk.java.net/~mduigou/7072353/0/webrev/

Thanks for your effort to make JNDI free of compile-warning. The work is
hard, I appreciate it.

1. I noticed the copyright date of a few files are unchanged, please
update them before you push the changes.

2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java
   In javax.naming.Context,  Hashtable<?,?> is used for context
environment. In this changes, you use Hashtable<String, java.lang.Object>.
   What do you think if we keep the type of K and V the same as
Hashtable<?,?>?

   I also noticed the similar inconsistency at:
   . com/sun/jndi/dns/DnsContext.java:
       50   Hashtable<Object,Object> environment;
   . com/sun/jndi/ldap/LdapCtx.java
       226  Hashtable<String, java.lang.Object> envprops = null;

3. src/share/classes/com/sun/jndi/dns/DnsContext.java
   What do you think if we have BaseNameClassPairEnumeration to
implement the NamingEnumeration, so that we can share the code of
nextElement()?

  class BaseNameClassPairEnumeration implements NamingEnumeration<T>

*** com/sun/jndi/ldap/Connection.java
 251         } catch (ClassNotFoundException |
 252                  InstantiationException |
 253                  InvocationTargetException |
 254                  IllegalAccessException e) {

I like this new try-catch feature!

4. com/sun/jndi/ldap/LdapCtx.java
1194    return (NamingEnumeration)
1195        new LdapBindingEnumeration(this, answer, name, cont);

   LdapBindingEnumeration is of type NamingEnumeration, it may be not
necessary to convert to NamingEnumeration. Do you mean
NamingEnumeration<Binding>?

       return (NamingEnumeration<Binding>)
           new LdapBindingEnumeration(this, answer, name, cont);

2244  switch (propName) {
   Do you want to indent this block? We usually indent a block even for
switch blocks.

3017 Vector<Object> temp = (Vector)extractURLs(res.errorMessage);
   You may not need the conversion any more, the return value of
extractURLs() has been updated to
   2564     private static Vector<String> extractURLs(String refString)

5. com/sun/jndi/ldap/LdapBindingEnumeration.java
   Why it is necessary to convert the return type twice (line 92)?

   92   return (LdapBindingEnumeration)(NamingEnumeration)
   93           refCtx.listBindings(listArg);

   It's great to use convariant return type. I would suggest add
override tag to make it easy understood.

I am only able to review a quarter of the update today, will continue
tomorrow.

Thanks,
Xuelei


From chris.hegarty at oracle.com  Tue Aug  2 14:08:59 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 02 Aug 2011 14:08:59 +0000
Subject: hg: jdk8/tl/jdk: 6978200: ServerSocket.toString include "port=0" in
	the returned String
Message-ID: <20110802140909.6A2E3478C2@hg.openjdk.java.net>

Changeset: 809e8db0c142
Author:    chegar
Date:      2011-07-29 10:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/809e8db0c142

6978200: ServerSocket.toString include "port=0" in the returned String
Summary: Removal of "port=0" from ServerSocket.toString method
Reviewed-by: alanb, chegar
Contributed-by: kurchi.subhra.hazra at oracle.com

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



From Alan.Bateman at oracle.com  Tue Aug  2 16:11:56 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 02 Aug 2011 17:11:56 +0100
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E37C117.2030104@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
Message-ID: <4E3821CC.9030202@oracle.com>

Xuelei Fan wrote:
> :
> 1. I noticed the copyright date of a few files are unchanged, please
> update them before you push the changes.
>   
This has come up a few times but I don't think it is strictly required. 
Kelly or one of the release engineers run a script over the forest 
periodically to fix up the date range. The nice thing (in my view 
anyway) about not changing the headers is that it avoids clutter in the 
patch and webrev. It also makes it a bit easier to transport patches to 
other releases.

-Alan



From Xuelei.Fan at Oracle.Com  Tue Aug  2 16:53:52 2011
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Wed, 3 Aug 2011 00:53:52 +0800
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E3821CC.9030202@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E3821CC.9030202@oracle.com>
Message-ID: <4128F157-7CB7-43F5-846C-6FFB5A6DEA0A@Oracle.Com>



On Aug 3, 2011, at 12:11 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> Xuelei Fan wrote:
>> :
>> 1. I noticed the copyright date of a few files are unchanged, please
>> update them before you push the changes.
>>  
> This has come up a few times but I don't think it is strictly required. Kelly or one of the release engineers run a script over the forest periodically to fix up the date range.
It's very good. I like the way that update the header in bunch.

Thanks,
Xuelei

> The nice thing (in my view anyway) about not changing the headers is that it avoids clutter in the patch and webrev. It also makes it a bit easier to transport patches to other releases.
> 
> -Alan
> 


From alexandre.boulgakov at oracle.com  Tue Aug  2 18:44:09 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Tue, 02 Aug 2011 11:44:09 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E37C117.2030104@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
Message-ID: <4E384579.1080209@oracle.com>

Thanks for reviewing! See my responses inline.

I'll wait on sending another webrev until I've received the rest of your 
comments.

-Sasha

On 8/2/2011 2:19 AM, Xuelei Fan wrote:
>> Please review these JNDI changes.
>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072353
>> webrev: http://cr.openjdk.java.net/~mduigou/7072353/0/webrev/
> Thanks for your effort to make JNDI free of compile-warning. The work is
> hard, I appreciate it.
>
> 1. I noticed the copyright date of a few files are unchanged, please
> update them before you push the changes.
I've done that in my local copy but didn't include it in the webrev so 
as to not pollute it.
>
> 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java
>     In javax.naming.Context,  Hashtable<?,?>  is used for context
> environment. In this changes, you use Hashtable<String, java.lang.Object>.
>     What do you think if we keep the type of K and V the same as
> Hashtable<?,?>?
>
>     I also noticed the similar inconsistency at:
>     . com/sun/jndi/dns/DnsContext.java:
>         50   Hashtable<Object,Object>  environment;
>     . com/sun/jndi/ldap/LdapCtx.java
>         226  Hashtable<String, java.lang.Object>  envprops = null;
The environment passed to the constructor is still Hashtable<?,?>, so 
there shouldn't be any source incompatibility because of this. However, 
the environment is accessed within the class under the assumption that 
(String, Object) pairs or (Object, Object) pairs can be added. This 
means that the environment must be of type Hashtable<String, Object> or 
Hashtable<Object, Object> at the time Hashtable.put is called. We can 
either cast it at every call site or once in the constructor. If I 
understand type erasure correctly, these casts will not affect the 
bytecode produced since the compiler is smart enough to notice we are 
casting a Hashtable to a Hashtable, so the only difference is in terms 
of readability and the number of @SuppressWarnings("unchecked") 
annotations thta need to be included.
>
> 3. src/share/classes/com/sun/jndi/dns/DnsContext.java
>     What do you think if we have BaseNameClassPairEnumeration to
> implement the NamingEnumeration, so that we can share the code of
> nextElement()?

I'll change it to
abstract class BaseNameClassPairEnumeration<T> implements 
NamingEnumeration<T>

>
>    class BaseNameClassPairEnumeration implements NamingEnumeration<T>
>
> *** com/sun/jndi/ldap/Connection.java
>   251         } catch (ClassNotFoundException |
>   252                  InstantiationException |
>   253                  InvocationTargetException |
>   254                  IllegalAccessException e) {
>
> I like this new try-catch feature!
>
> 4. com/sun/jndi/ldap/LdapCtx.java
> 1194    return (NamingEnumeration)
> 1195        new LdapBindingEnumeration(this, answer, name, cont);
>
>     LdapBindingEnumeration is of type NamingEnumeration, it may be not
> necessary to convert to NamingEnumeration. Do you mean
> NamingEnumeration<Binding>?
>
>         return (NamingEnumeration<Binding>)
>             new LdapBindingEnumeration(this, answer, name, cont);
LdapBindingEnumeration extends LdapNamingEnumeration, which implements 
NamingEnumeration<NameClassPair>. This means we can cast it to 
NamingEnumeration<Binding> directly, but must go through a raw 
intermediate like NamingEnumeration or Object. I can change it to a 
double cast with (NamingEnumeration<Binding>)(NamingEnumeration), if you 
think that would improve readability, or LdapBindingEnumeration and 
LdapNamingEnumeration could be refactored to implement different 
NamingEnumeration<T> interfaces (like I did with 
NameClassPairEnumeration and BindingEnumeration in 
src/share/classes/com/sun/jndi/dns/DnsContext.java).
>
> 2244  switch (propName) {
>     Do you want to indent this block? We usually indent a block even for
> switch blocks.
Oops, didn't notice that.
>
> 3017 Vector<Object>  temp = (Vector)extractURLs(res.errorMessage);
>     You may not need the conversion any more, the return value of
> extractURLs() has been updated to
>     2564     private static Vector<String>  extractURLs(String refString)
The cast is needed to go from Vector<String> to Vector<Object>.
>
> 5. com/sun/jndi/ldap/LdapBindingEnumeration.java
>     Why it is necessary to convert the return type twice (line 92)?
>
>     92   return (LdapBindingEnumeration)(NamingEnumeration)
>     93           refCtx.listBindings(listArg);
Again, it's due to a generic type mismatch: refCtx.listBindings(listArg) 
returns a NamingEnumeration<Binding> but LdapBindingEnumeration 
implements NamingEnumeration<NameClassPair>. It'd be great if we could 
have variant generic interface type parameters, so 
NamingEnumeration<Binding> could extend NamingEnumeration<NameClassPair>.
>
>     It's great to use convariant return type. I would suggest add
> override tag to make it easy understood.
>
> I am only able to review a quarter of the update today, will continue
> tomorrow.
>
> Thanks,
> Xuelei


From alexandre.boulgakov at oracle.com  Tue Aug  2 18:47:08 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Tue, 02 Aug 2011 11:47:08 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E37C117.2030104@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
Message-ID: <4E38462C.7010900@oracle.com>

Thanks for reviewing! Please see my responses inline.

I'll wait on sending another webrev until I've received the rest of your 
comments.

-Sasha

On 8/2/2011 2:19 AM, Xuelei Fan wrote:
>> Please review these JNDI changes.
>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072353
>> webrev: http://cr.openjdk.java.net/~mduigou/7072353/0/webrev/
> Thanks for your effort to make JNDI free of compile-warning. The work is
> hard, I appreciate it.
>
> 1. I noticed the copyright date of a few files are unchanged, please
> update them before you push the changes.
I've done that in my local copy but didn't include it in the webrev so 
as to not pollute it.
>
> 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java
>     In javax.naming.Context,  Hashtable<?,?>  is used for context
> environment. In this changes, you use Hashtable<String, java.lang.Object>.
>     What do you think if we keep the type of K and V the same as
> Hashtable<?,?>?
>
>     I also noticed the similar inconsistency at:
>     . com/sun/jndi/dns/DnsContext.java:
>         50   Hashtable<Object,Object>  environment;
>     . com/sun/jndi/ldap/LdapCtx.java
>         226  Hashtable<String, java.lang.Object>  envprops = null;
The environment passed to the constructor is still Hashtable<?,?>, so 
there shouldn't be any source incompatibility because of this. However, 
the environment is accessed within the class under the assumption that 
(String, Object) pairs or (Object, Object) pairs can be added. This 
means that the environment must be of type Hashtable<String, Object> or 
Hashtable<Object, Object> at the time Hashtable.put is called. We can 
either cast it at every call site or once in the constructor. If I 
understand type erasure correctly, these casts will not affect the 
bytecode produced since the compiler is smart enough to notice we are 
casting a Hashtable to a Hashtable, so the only difference is in terms 
of readability and the number of @SuppressWarnings("unchecked") 
annotations that need to be included.
>
> 3. src/share/classes/com/sun/jndi/dns/DnsContext.java
>     What do you think if we have BaseNameClassPairEnumeration to
> implement the NamingEnumeration, so that we can share the code of
> nextElement()?

I'll change it to
abstract class BaseNameClassPairEnumeration<T> implements 
NamingEnumeration<T>

>
>    class BaseNameClassPairEnumeration implements NamingEnumeration<T>
>
> *** com/sun/jndi/ldap/Connection.java
>   251         } catch (ClassNotFoundException |
>   252                  InstantiationException |
>   253                  InvocationTargetException |
>   254                  IllegalAccessException e) {
>
> I like this new try-catch feature!
>
> 4. com/sun/jndi/ldap/LdapCtx.java
> 1194    return (NamingEnumeration)
> 1195        new LdapBindingEnumeration(this, answer, name, cont);
>
>     LdapBindingEnumeration is of type NamingEnumeration, it may be not
> necessary to convert to NamingEnumeration. Do you mean
> NamingEnumeration<Binding>?
>
>         return (NamingEnumeration<Binding>)
>             new LdapBindingEnumeration(this, answer, name, cont);
LdapBindingEnumeration extends LdapNamingEnumeration, which implements 
NamingEnumeration<NameClassPair>. This means we cannot cast it to 
NamingEnumeration<Binding> directly, but must go through a raw 
intermediate like NamingEnumeration or Object. I can change it to a 
double cast with (NamingEnumeration<Binding>)(NamingEnumeration), if you 
think that would improve readability, or LdapBindingEnumeration and 
LdapNamingEnumeration could be refactored to implement different 
NamingEnumeration<T> interfaces (like I did with 
NameClassPairEnumeration and BindingEnumeration in 
src/share/classes/com/sun/jndi/dns/DnsContext.java).
>
> 2244  switch (propName) {
>     Do you want to indent this block? We usually indent a block even for
> switch blocks.
Oops, didn't notice that.
>
> 3017 Vector<Object>  temp = (Vector)extractURLs(res.errorMessage);
>     You may not need the conversion any more, the return value of
> extractURLs() has been updated to
>     2564     private static Vector<String>  extractURLs(String refString)
The cast is needed to go from Vector<String> to Vector<Object>.
>
> 5. com/sun/jndi/ldap/LdapBindingEnumeration.java
>     Why it is necessary to convert the return type twice (line 92)?
>
>     92   return (LdapBindingEnumeration)(NamingEnumeration)
>     93           refCtx.listBindings(listArg);
Again, it's due to a generic type mismatch: refCtx.listBindings(listArg) 
returns a NamingEnumeration<Binding> but LdapBindingEnumeration 
implements NamingEnumeration<NameClassPair>. It'd be great if we could 
have variant generic interface type parameters, so 
NamingEnumeration<Binding> could extend NamingEnumeration<NameClassPair>.
>
>     It's great to use convariant return type. I would suggest add
> override tag to make it easy understood.
>
> I am only able to review a quarter of the update today, will continue
> tomorrow.
>
> Thanks,
> Xuelei


From mike.duigou at oracle.com  Tue Aug  2 19:44:28 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 2 Aug 2011 12:44:28 -0700
Subject: 7073296: Review : Bug in Executable.equalParamTypes() results in
	incorrect comparison for differing number of params
Message-ID: <972EFBC9-2387-4BCF-8715-1F9096C8F14C@oracle.com>

Hello All;

A fairly simple bug to review which snuck through testing.

http://cr.openjdk.java.net/~mduigou/7073296/0/webrev/

The changes to Class are incidental but so trivial that opted to include them. I can remove if anyone feels strongly (or even weakly) that they should be excluded.

Mike

From joe.darcy at oracle.com  Tue Aug  2 22:27:40 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 02 Aug 2011 15:27:40 -0700
Subject: 7073296: Review : Bug in Executable.equalParamTypes() results
	in incorrect comparison for differing number of params
In-Reply-To: <972EFBC9-2387-4BCF-8715-1F9096C8F14C@oracle.com>
References: <972EFBC9-2387-4BCF-8715-1F9096C8F14C@oracle.com>
Message-ID: <4E3879DC.8010507@oracle.com>

Hi Mike.

Thanks for developing the fix for this.  Generally looks good to go 
back; a few minor nits.  Personally, I would leave the "// Doesn't use 
Boolean.getBoolean to avoid class init." note in java.lang.Class unless 
you know the comment is not relevant any more.  Given the default 
semantics of jtreg, you could omit the @compile and @run lines in the test.

Cheers,

-Joe

On 8/2/2011 12:44 PM, Mike Duigou wrote:
> Hello All;
>
> A fairly simple bug to review which snuck through testing.
>
> http://cr.openjdk.java.net/~mduigou/7073296/0/webrev/
>
> The changes to Class are incidental but so trivial that opted to include them. I can remove if anyone feels strongly (or even weakly) that they should be excluded.
>
> Mike


From mike.duigou at oracle.com  Tue Aug  2 22:32:26 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 2 Aug 2011 15:32:26 -0700
Subject: 7073296: Review : Bug in Executable.equalParamTypes() results in
	incorrect comparison for differing number of params
In-Reply-To: <4E3879DC.8010507@oracle.com>
References: <972EFBC9-2387-4BCF-8715-1F9096C8F14C@oracle.com>
	<4E3879DC.8010507@oracle.com>
Message-ID: <078CFCA6-2C47-4D69-A807-7A9EDEFE6038@oracle.com>


On Aug 2 2011, at 15:27 , joe.darcy at oracle.com wrote:

> Hi Mike.
> 
> Thanks for developing the fix for this.  Generally looks good to go back; a few minor nits.  Personally, I would leave the "// Doesn't use Boolean.getBoolean to avoid class init." note in java.lang.Class unless you know the comment is not relevant any more.

I actually added the note. I checked with java -verbose:class on the load order and Class is loaded quite a bit before Boolean. It's a note to future maintainers who, like I was, are tempted to convert to Boolean.getBoolean().

>  Given the default semantics of jtreg, you could omit the @compile and @run lines in the test.

Will do.

> Cheers,
> 
> -Joe
> 
> On 8/2/2011 12:44 PM, Mike Duigou wrote:
>> Hello All;
>> 
>> A fairly simple bug to review which snuck through testing.
>> 
>> http://cr.openjdk.java.net/~mduigou/7073296/0/webrev/
>> 
>> The changes to Class are incidental but so trivial that opted to include them. I can remove if anyone feels strongly (or even weakly) that they should be excluded.
>> 
>> Mike



From joe.darcy at oracle.com  Tue Aug  2 22:53:03 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 02 Aug 2011 15:53:03 -0700
Subject: 7073296: Review : Bug in Executable.equalParamTypes() results
	in incorrect comparison for differing number of params
In-Reply-To: <078CFCA6-2C47-4D69-A807-7A9EDEFE6038@oracle.com>
References: <972EFBC9-2387-4BCF-8715-1F9096C8F14C@oracle.com>
	<4E3879DC.8010507@oracle.com>
	<078CFCA6-2C47-4D69-A807-7A9EDEFE6038@oracle.com>
Message-ID: <4E387FCF.5090709@oracle.com>

On 8/2/2011 3:32 PM, Mike Duigou wrote:
> On Aug 2 2011, at 15:27 , joe.darcy at oracle.com wrote:
>
>   
>> Hi Mike.
>>
>> Thanks for developing the fix for this.  Generally looks good to go back; a few minor nits.  Personally, I would leave the "// Doesn't use Boolean.getBoolean to avoid class init." note in java.lang.Class unless you know the comment is not relevant any more.
>>     
>
> I actually added the note. I checked with java -verbose:class on the load order and Class is loaded quite a bit before Boolean. It's a note to future maintainers who, like I was, are tempted to convert to Boolean.getBoolean().
>   

Read the patch wrong; doh! 

-Joe




From xuelei.fan at oracle.com  Wed Aug  3 04:13:13 2011
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 03 Aug 2011 12:13:13 +0800
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E384579.1080209@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com>
Message-ID: <4E38CAD9.8050705@oracle.com>

 com/sun/jndi/toolkit/dir/SearchFilter.java
 451         for (NamingEnumeration<?> ve = attr.getAll();
 452              ve.hasMore();
 453                ) {

The update is OK. But the coding style looks uncomfortable. Would you
mind change it to use for-each style?

. javax/naming/directory/BasicAttribute.java
It's an old coding style issue, would you mind indent the lines in
inner-class ValuesEnumImpl?


On 8/3/2011 2:44 AM, Alexandre Boulgakov wrote:
> Thanks for reviewing! See my responses inline.
> 
> I'll wait on sending another webrev until I've received the rest of your
> comments.
> 
> -Sasha
> 
> On 8/2/2011 2:19 AM, Xuelei Fan wrote:
>>> Please review these JNDI changes.
>>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072353
>>> webrev: http://cr.openjdk.java.net/~mduigou/7072353/0/webrev/
>> Thanks for your effort to make JNDI free of compile-warning. The work is
>> hard, I appreciate it.
>>
>> 1. I noticed the copyright date of a few files are unchanged, please
>> update them before you push the changes.
> I've done that in my local copy but didn't include it in the webrev so
> as to not pollute it.
We (security team) used to update all copyright date range manually. But
Alan told me that the release engineers will run a script over the
forest periodically to fix up the date range. I like this way, I think
we don't have to update the date range in every fix manually any more.
It depends on you.

>>
>> 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java
>>     In javax.naming.Context,  Hashtable<?,?>  is used for context
>> environment. In this changes, you use Hashtable<String,
>> java.lang.Object>.
>>     What do you think if we keep the type of K and V the same as
>> Hashtable<?,?>?
>>
>>     I also noticed the similar inconsistency at:
>>     . com/sun/jndi/dns/DnsContext.java:
>>         50   Hashtable<Object,Object>  environment;
>>     . com/sun/jndi/ldap/LdapCtx.java
>>         226  Hashtable<String, java.lang.Object>  envprops = null;
> The environment passed to the constructor is still Hashtable<?,?>, so
> there shouldn't be any source incompatibility because of this. However,
> the environment is accessed within the class under the assumption that
> (String, Object) pairs or (Object, Object) pairs can be added. This
> means that the environment must be of type Hashtable<String, Object> or
> Hashtable<Object, Object> at the time Hashtable.put is called. We can
> either cast it at every call site or once in the constructor. If I
> understand type erasure correctly, these casts will not affect the
> bytecode produced since the compiler is smart enough to notice we are
> casting a Hashtable to a Hashtable, so the only difference is in terms
> of readability and the number of @SuppressWarnings("unchecked")
> annotations thta need to be included.
Sounds reasonable.

>>
>> 3. src/share/classes/com/sun/jndi/dns/DnsContext.java
>>     What do you think if we have BaseNameClassPairEnumeration to
>> implement the NamingEnumeration, so that we can share the code of
>> nextElement()?
> 
> I'll change it to
> abstract class BaseNameClassPairEnumeration<T> implements
> NamingEnumeration<T>
> 
You may also want to change BaseFlatNames in
com/sun/jndi/toolkit/dir/HierMemDirCtx.java with the similar style.

>>
>>    class BaseNameClassPairEnumeration implements NamingEnumeration<T>
>>
>> *** com/sun/jndi/ldap/Connection.java
>>   251         } catch (ClassNotFoundException |
>>   252                  InstantiationException |
>>   253                  InvocationTargetException |
>>   254                  IllegalAccessException e) {
>>
>> I like this new try-catch feature!
>>
>> 4. com/sun/jndi/ldap/LdapCtx.java
>> 1194    return (NamingEnumeration)
>> 1195        new LdapBindingEnumeration(this, answer, name, cont);
>>
>>     LdapBindingEnumeration is of type NamingEnumeration, it may be not
>> necessary to convert to NamingEnumeration. Do you mean
>> NamingEnumeration<Binding>?
>>
>>         return (NamingEnumeration<Binding>)
>>             new LdapBindingEnumeration(this, answer, name, cont);
> LdapBindingEnumeration extends LdapNamingEnumeration, which implements
> NamingEnumeration<NameClassPair>. This means we can cast it to
> NamingEnumeration<Binding> directly, but must go through a raw
> intermediate like NamingEnumeration or Object. I can change it to a
> double cast with (NamingEnumeration<Binding>)(NamingEnumeration), if you
> think that would improve readability, or LdapBindingEnumeration and
> LdapNamingEnumeration could be refactored to implement different
> NamingEnumeration<T> interfaces (like I did with
> NameClassPairEnumeration and BindingEnumeration in
> src/share/classes/com/sun/jndi/dns/DnsContext.java).

LdapBindingEnumeration --extends--> LdapNamingEnumeration --implements
--> NamingEnumeration<NameClassPair>.

>From the above hierarchy, LdapBindingEnumeration is an instance of
NamingEnumeration<NameClassPair>. Now you cast it to
NamingEnumeration<Binding>. It might work, but it looks unreasonable and
risky in the first glance.

The LdapNamingEnumeration and LdapBindingEnumeration is designed when
using non-generic programming style. If we switch to use generic
features, the inherit structure may not sound reasonable any more.

You made a good update in DnsContext and HierMemDirCtx by introducing a
intermediate class, BaseNameClassPairEnumeration/BaseFlatNames. Does it
sound a solution to LdapBindingEnumeration and LdapNamingEnumeration?

>>
>> 2244  switch (propName) {
>>     Do you want to indent this block? We usually indent a block even for
>> switch blocks.
> Oops, didn't notice that.
>>
>> 3017 Vector<Object>  temp = (Vector)extractURLs(res.errorMessage);
>>     You may not need the conversion any more, the return value of
>> extractURLs() has been updated to
>>     2564     private static Vector<String>  extractURLs(String refString)
> The cast is needed to go from Vector<String> to Vector<Object>.
>>
>> 5. com/sun/jndi/ldap/LdapBindingEnumeration.java
>>     Why it is necessary to convert the return type twice (line 92)?
>>
8>>     92   return (LdapBindingEnumeration)(NamingEnumeration)
>>     93           refCtx.listBindings(listArg);
> Again, it's due to a generic type mismatch: refCtx.listBindings(listArg)
> returns a NamingEnumeration<Binding> but LdapBindingEnumeration
> implements NamingEnumeration<NameClassPair>. It'd be great if we could
> have variant generic interface type parameters, so
> NamingEnumeration<Binding> could extend NamingEnumeration<NameClassPair>.

See above.

Otherwise, looks fine to me.

Thanks,
Xuelei

>>
>>     It's great to use convariant return type. I would suggest add
>> override tag to make it easy understood.
>>
>> I am only able to review a quarter of the update today, will continue
>> tomorrow.
>>
>> Thanks,
>> Xuelei


From sebastian.sickelmann at gmx.de  Wed Aug  3 05:31:18 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 03 Aug 2011 07:31:18 +0200
Subject: 7073296: Review : Bug in Executable.equalParamTypes() results
	in	incorrect comparison for differing number of params
In-Reply-To: <972EFBC9-2387-4BCF-8715-1F9096C8F14C@oracle.com>
References: <972EFBC9-2387-4BCF-8715-1F9096C8F14C@oracle.com>
Message-ID: <4E38DD26.3020006@gmx.de>

Am 02.08.2011 21:44, schrieb Mike Duigou:
> Hello All;
>
> A fairly simple bug to review which snuck through testing.
>
> http://cr.openjdk.java.net/~mduigou/7073296/0/webrev/
>
> The changes to Class are incidental but so trivial that opted to include them. I can remove if anyone feels strongly (or even weakly) that they should be excluded.
>
> Mike
Looks good to me


From ahughes at redhat.com  Wed Aug  3 05:44:23 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Wed, 3 Aug 2011 06:44:23 +0100
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E3821CC.9030202@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E3821CC.9030202@oracle.com>
Message-ID: <20110803054423.GD31431@rivendell.middle-earth.co.uk>

On 17:11 Tue 02 Aug     , Alan Bateman wrote:
> Xuelei Fan wrote:
> > :
> > 1. I noticed the copyright date of a few files are unchanged, please
> > update them before you push the changes.
> >   
> This has come up a few times but I don't think it is strictly required. 
> Kelly or one of the release engineers run a script over the forest 
> periodically to fix up the date range. The nice thing (in my view 
> anyway) about not changing the headers is that it avoids clutter in the 
> patch and webrev. It also makes it a bit easier to transport patches to 
> other releases.
> 

I was thinking the same thing.  Copyright header changes mixed into other
patches are a nightmare as regards backporting.

> -Alan
> 

-- 
Andrew :)

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

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From David.Holmes at oracle.com  Wed Aug  3 07:42:21 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 03 Aug 2011 17:42:21 +1000
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E384579.1080209@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com>
Message-ID: <4E38FBDD.8070202@oracle.com>

Alexandre Boulgakov said the following on 08/03/11 04:44:
> On 8/2/2011 2:19 AM, Xuelei Fan wrote:
>> 3017 Vector<Object>  temp = (Vector)extractURLs(res.errorMessage);
>>     You may not need the conversion any more, the return value of
>> extractURLs() has been updated to
>>     2564     private static Vector<String>  extractURLs(String refString)
> The cast is needed to go from Vector<String> to Vector<Object>.

Raw types should be avoided (here and elsewhere there are casts to raw 
Vector). I'm surprised (generics continue to surprise me) that despite 
all our advances in type-inference etc that the compiler can not tell 
that a Vector<T> is-a Vector<Object>. :(

Not knowing how LdapResult.referrals is used overall I'm unsure what 
might be a better fix but perhaps referrals could be declared as 
Vector<?> and an unchecked cast to Vector<Object> added only/if where 
needed?

Cheers,
David Holmes



From Alan.Bateman at oracle.com  Wed Aug  3 09:00:56 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 03 Aug 2011 10:00:56 +0100
Subject: 7073296: Review : Bug in Executable.equalParamTypes() results
	in incorrect comparison for differing number of params
In-Reply-To: <972EFBC9-2387-4BCF-8715-1F9096C8F14C@oracle.com>
References: <972EFBC9-2387-4BCF-8715-1F9096C8F14C@oracle.com>
Message-ID: <4E390E48.7090901@oracle.com>

Mike Duigou wrote:
> Hello All;
>
> A fairly simple bug to review which snuck through testing.
>
> http://cr.openjdk.java.net/~mduigou/7073296/0/webrev/
>
> The changes to Class are incidental but so trivial that opted to include them. I can remove if anyone feels strongly (or even weakly) that they should be excluded.
>
> Mike
While the bug did sneak into the jdk8/tl/jdk repository it didn't get 
any further so no damage done. Thanks for tracking it down. The fix 
looks good to me too.

-Alan





From neil.richards at ngmr.net  Wed Aug  3 13:57:54 2011
From: neil.richards at ngmr.net (Neil Richards)
Date: Wed, 03 Aug 2011 14:57:54 +0100
Subject: Request for review: Make MethodHandleProxies.getSingleMethod()
	agnostic of ordering of methods returned from Class.getMethods()
In-Reply-To: <4E26C726.7050409@oracle.com>
References: <1311159119.1024.56.camel@chalkhill> <4E26C726.7050409@oracle.com>
Message-ID: <1312379874.25189.63.camel@chalkhill>

On Wed, 2011-07-20 at 22:16 +1000, David Holmes wrote: 
> However, unless I'm missing something subtle, why do we need to check 
> for the method being abstract? Aren't all interface methods always 
> implicitly abstract?

Hi David,
Thanks for looking at my suggestion.

Firstly, let me correct myself: where I originally talked about
'isSingleMethod', I actually meant 'getSingleMethod' (which returns
'null' if the given interface does not represent a single method).

I believe you're right that all interface methods are currently always
abstract.

Therefore, please find below an updated suggested fix, which removes the
duplicated check.

Can I interest a core-libs committer in helping me to get this change
committed?

Thanks,
Neil

-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


# HG changeset patch
# User Neil Richards <neil.richards at ngmr.net>, <neil_richards at uk.ibm.com>
# Date 1311156497 -3600
# Branch ojdk-131
# Node ID e5e3c6df9f8b37e936c9cb00982c1cb92751f87e
# Parent  8bbea505b060fc7c97d9c241f8531a2a758cbe20
Summary: Make getSingleMethod() agnostic of ordering of methods returned from Class.getMethods()
Contributed-by: <neil.richards at ngmr.net>

diff --git a/src/share/classes/java/lang/invoke/MethodHandleProxies.java b/src/share/classes/java/lang/invoke/MethodHandleProxies.java
--- a/src/share/classes/java/lang/invoke/MethodHandleProxies.java
+++ b/src/share/classes/java/lang/invoke/MethodHandleProxies.java
@@ -246,8 +246,9 @@
         Method sm = null;
         for (Method m : intfc.getMethods()) {
             int mod = m.getModifiers();
-            if (Modifier.isAbstract(mod)) {
-                if (sm != null && !isObjectMethod(sm))
+            if (!isObjectMethod(m)) {
+                // NB: All interface methods are inherently abstract
+                if (sm != null)
                     return null;  // too many abstract methods
                 sm = m;
             }





From neil.richards at ngmr.net  Wed Aug  3 14:32:09 2011
From: neil.richards at ngmr.net (Neil Richards)
Date: Wed, 03 Aug 2011 15:32:09 +0100
Subject: Request for review: #include ANSI headers for functions referred
	to in jli_util.h
Message-ID: <1312381929.14748.15.camel@chalkhill>

Hi,
I've noticed that jdk/src/share/bin/jli_util.h does not currently
include the ANSI headers for the functions that it #defines aliases for,
which is not good practice.

Please find below a suggested change which adds the necessary #include
statements to correct this.

Please consider this change for committal.

Thanks,
Neil

-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


# HG changeset patch
# User Neil Richards <neil.richards at ngmr.net>, <neil_richards at uk.ibm.com>
# Date 1311681383 -3600
# Branch ojdk-145
# Node ID 395dc4307fa501bf0d18afc87928247bd80c9d78
# Parent  07a12583d4ea8d9d9de865aa9ab7dea2ca6b043e
Summary: Include ANSI headers for functions referred to in jli_util.h
Contributed-by: <neil.richards at ngmr.net>

diff -r 07a12583d4ea -r 395dc4307fa5 src/share/bin/jli_util.h
--- a/src/share/bin/jli_util.h	Mon Jul 25 14:35:13 2011 -0700
+++ b/src/share/bin/jli_util.h	Tue Jul 26 12:56:23 2011 +0100
@@ -27,6 +27,8 @@
 #define _JLI_UTIL_H
 
 #include <stdlib.h>
+#include <string.h>
+#include <stdio.h>
 #include <jni.h>
 
 void *JLI_MemAlloc(size_t size);
@@ -58,6 +60,7 @@
 #define JLI_Snprintf                    _snprintf
 #else
 #include <unistd.h>
+#include <strings.h>
 #define JLI_StrCaseCmp(p1, p2)          strcasecmp((p1), (p2))
 #define JLI_StrNCaseCmp(p1, p2, p3)     strncasecmp((p1), (p2), (p3))
 #define JLI_Snprintf                    snprintf




From joe.darcy at oracle.com  Wed Aug  3 16:24:22 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 03 Aug 2011 09:24:22 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E38FBDD.8070202@oracle.com>
References: <4E34155E.5090700@oracle.com>
	<4E37C117.2030104@oracle.com>	<4E384579.1080209@oracle.com>
	<4E38FBDD.8070202@oracle.com>
Message-ID: <4E397636.5070302@oracle.com>

On 8/3/2011 12:42 AM, David Holmes wrote:
> Alexandre Boulgakov said the following on 08/03/11 04:44:
>> On 8/2/2011 2:19 AM, Xuelei Fan wrote:
>>> 3017 Vector<Object>  temp = (Vector)extractURLs(res.errorMessage);
>>>     You may not need the conversion any more, the return value of
>>> extractURLs() has been updated to
>>>     2564     private static Vector<String>  extractURLs(String 
>>> refString)
>> The cast is needed to go from Vector<String> to Vector<Object>.
>
> Raw types should be avoided (here and elsewhere there are casts to raw 
> Vector). I'm surprised (generics continue to surprise me) that despite 
> all our advances in type-inference etc that the compiler can not tell 
> that a Vector<T> is-a Vector<Object>. :(

That is because in general a Vector<T> is not a Vector<Object> because 
of the way subtyping works.  As with arrays, it all looks fine until you 
want to change the container; consider

Vector<String> vs = new Vector<>();
...
Vector<Object> vo = vs; // Assume this was okay to alias an object 
vector and a string vector

vo.add(new Integer(1));  // Add an Integer to a list of strings, boom!

Using wildcards makes the subtyping work along the type argument axis.

-Joe



From ahughes at redhat.com  Wed Aug  3 17:51:39 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Wed, 3 Aug 2011 18:51:39 +0100
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E397636.5070302@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38FBDD.8070202@oracle.com>
	<4E397636.5070302@oracle.com>
Message-ID: <20110803175139.GR31431@rivendell.middle-earth.co.uk>

On 09:24 Wed 03 Aug     , Joe Darcy wrote:
> On 8/3/2011 12:42 AM, David Holmes wrote:
> > Alexandre Boulgakov said the following on 08/03/11 04:44:
> >> On 8/2/2011 2:19 AM, Xuelei Fan wrote:
> >>> 3017 Vector<Object>  temp = (Vector)extractURLs(res.errorMessage);
> >>>     You may not need the conversion any more, the return value of
> >>> extractURLs() has been updated to
> >>>     2564     private static Vector<String>  extractURLs(String 
> >>> refString)
> >> The cast is needed to go from Vector<String> to Vector<Object>.
> >
> > Raw types should be avoided (here and elsewhere there are casts to raw 
> > Vector). I'm surprised (generics continue to surprise me) that despite 
> > all our advances in type-inference etc that the compiler can not tell 
> > that a Vector<T> is-a Vector<Object>. :(
> 
> That is because in general a Vector<T> is not a Vector<Object> because 
> of the way subtyping works.  As with arrays, it all looks fine until you 
> want to change the container; consider
> 
> Vector<String> vs = new Vector<>();
> ...
> Vector<Object> vo = vs; // Assume this was okay to alias an object 
> vector and a string vector
> 
> vo.add(new Integer(1));  // Add an Integer to a list of strings, boom!
> 
> Using wildcards makes the subtyping work along the type argument axis.
> 

Exactly.  What I wondered on reading this is why it needs to be cast to a
Vector<Object> anyway.  That would only reduce type safety as you say.

> -Joe
> 

-- 
Andrew :)

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

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From alexandre.boulgakov at oracle.com  Wed Aug  3 18:03:29 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Wed, 03 Aug 2011 11:03:29 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E38CAD9.8050705@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com>
Message-ID: <4E398D71.9030302@oracle.com>

Please see my responses inline.

Thanks!
-Sasha

On 8/2/2011 9:13 PM, Xuelei Fan wrote:
> . com/sun/jndi/toolkit/dir/SearchFilter.java
>   451         for (NamingEnumeration<?>  ve = attr.getAll();
>   452              ve.hasMore();
>   453                ) {
>
> The update is OK. But the coding style looks uncomfortable. Would you
> mind change it to use for-each style?
For-each only works with Iterables. There doesn't seem to be a way to 
get an Iterable out of an Attribute instance, so the only way to use a 
for-each here would be to wrap the Enumeration in an ArrayList using 
Collections.list(). While this might look neater, the contents of the 
Enumeration would have to be copied over, using time and increasing the 
memory footprint. Changing Attribute to implement Iterable would require 
a spec change, and would be beyond the scope of this fix.

>
> . javax/naming/directory/BasicAttribute.java
> It's an old coding style issue, would you mind indent the lines in
> inner-class ValuesEnumImpl?
Got it.
> We (security team) used to update all copyright date range manually. But
> Alan told me that the release engineers will run a script over the
> forest periodically to fix up the date range. I like this way, I think
> we don't have to update the date range in every fix manually any more.
> It depends on you.
I'll keep that in mind, but I've already updated the copyright dates in 
my local copy. Would it be fine to include them in the next version of 
the webrev? Since these are just warning fixes, they probably will not 
be backported.
>
>>> 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java
>>>      In javax.naming.Context,  Hashtable<?,?>   is used for context
>>> environment. In this changes, you use Hashtable<String,
>>> java.lang.Object>.
>>>      What do you think if we keep the type of K and V the same as
>>> Hashtable<?,?>?
>>>
>>>      I also noticed the similar inconsistency at:
>>>      . com/sun/jndi/dns/DnsContext.java:
>>>          50   Hashtable<Object,Object>   environment;
>>>      . com/sun/jndi/ldap/LdapCtx.java
>>>          226  Hashtable<String, java.lang.Object>   envprops = null;
>> The environment passed to the constructor is still Hashtable<?,?>, so
>> there shouldn't be any source incompatibility because of this. However,
>> the environment is accessed within the class under the assumption that
>> (String, Object) pairs or (Object, Object) pairs can be added. This
>> means that the environment must be of type Hashtable<String, Object>  or
>> Hashtable<Object, Object>  at the time Hashtable.put is called. We can
>> either cast it at every call site or once in the constructor. If I
>> understand type erasure correctly, these casts will not affect the
>> bytecode produced since the compiler is smart enough to notice we are
>> casting a Hashtable to a Hashtable, so the only difference is in terms
>> of readability and the number of @SuppressWarnings("unchecked")
>> annotations thta need to be included.
> Sounds reasonable.
>
>>> 3. src/share/classes/com/sun/jndi/dns/DnsContext.java
>>>      What do you think if we have BaseNameClassPairEnumeration to
>>> implement the NamingEnumeration, so that we can share the code of
>>> nextElement()?
>> I'll change it to
>> abstract class BaseNameClassPairEnumeration<T>  implements
>> NamingEnumeration<T>
>>
> You may also want to change BaseFlatNames in
> com/sun/jndi/toolkit/dir/HierMemDirCtx.java with the similar style.
Got it. Would it make sense to make everything except for the next() 
methods final, or will the compiler infer that?
> LdapBindingEnumeration --extends-->  LdapNamingEnumeration --implements
> -->  NamingEnumeration<NameClassPair>.
>
>  From the above hierarchy, LdapBindingEnumeration is an instance of
> NamingEnumeration<NameClassPair>. Now you cast it to
> NamingEnumeration<Binding>. It might work, but it looks unreasonable and
> risky in the first glance.
>
> The LdapNamingEnumeration and LdapBindingEnumeration is designed when
> using non-generic programming style. If we switch to use generic
> features, the inherit structure may not sound reasonable any more.
>
> You made a good update in DnsContext and HierMemDirCtx by introducing a
> intermediate class, BaseNameClassPairEnumeration/BaseFlatNames. Does it
> sound a solution to LdapBindingEnumeration and LdapNamingEnumeration?
Yes, I can do that. And also for LdapSearchEnumeration which extends 
LdapNamingEnumeration as well.
>
>>> 2244  switch (propName) {
>>>      Do you want to indent this block? We usually indent a block even for
>>> switch blocks.
>> Oops, didn't notice that.
>>> 3017 Vector<Object>   temp = (Vector)extractURLs(res.errorMessage);
>>>      You may not need the conversion any more, the return value of
>>> extractURLs() has been updated to
>>>      2564     private static Vector<String>   extractURLs(String refString)
>> The cast is needed to go from Vector<String>  to Vector<Object>.
>>> 5. com/sun/jndi/ldap/LdapBindingEnumeration.java
>>>      Why it is necessary to convert the return type twice (line 92)?
>>>
> 8>>      92   return (LdapBindingEnumeration)(NamingEnumeration)
>>>      93           refCtx.listBindings(listArg);
>> Again, it's due to a generic type mismatch: refCtx.listBindings(listArg)
>> returns a NamingEnumeration<Binding>  but LdapBindingEnumeration
>> implements NamingEnumeration<NameClassPair>. It'd be great if we could
>> have variant generic interface type parameters, so
>> NamingEnumeration<Binding>  could extend NamingEnumeration<NameClassPair>.
> See above.
>
> Otherwise, looks fine to me.
>
> Thanks,
> Xuelei
>
>>>      It's great to use convariant return type. I would suggest add
>>> override tag to make it easy understood.
>>>
>>> I am only able to review a quarter of the update today, will continue
>>> tomorrow.
>>>
>>> Thanks,
>>> Xuelei


From alexandre.boulgakov at oracle.com  Wed Aug  3 18:06:11 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Wed, 03 Aug 2011 11:06:11 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <20110803175139.GR31431@rivendell.middle-earth.co.uk>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38FBDD.8070202@oracle.com>
	<4E397636.5070302@oracle.com>
	<20110803175139.GR31431@rivendell.middle-earth.co.uk>
Message-ID: <4E398E13.5020208@oracle.com>

On 8/3/2011 10:51 AM, Dr Andrew John Hughes wrote:
> On 09:24 Wed 03 Aug     , Joe Darcy wrote:
>> On 8/3/2011 12:42 AM, David Holmes wrote:
>>> Alexandre Boulgakov said the following on 08/03/11 04:44:
>>>> On 8/2/2011 2:19 AM, Xuelei Fan wrote:
>>>>> 3017 Vector<Object>   temp = (Vector)extractURLs(res.errorMessage);
>>>>>      You may not need the conversion any more, the return value of
>>>>> extractURLs() has been updated to
>>>>>      2564     private static Vector<String>   extractURLs(String
>>>>> refString)
>>>> The cast is needed to go from Vector<String>  to Vector<Object>.
>>> Raw types should be avoided (here and elsewhere there are casts to raw
>>> Vector). I'm surprised (generics continue to surprise me) that despite
>>> all our advances in type-inference etc that the compiler can not tell
>>> that a Vector<T>  is-a Vector<Object>. :(
>> That is because in general a Vector<T>  is not a Vector<Object>  because
>> of the way subtyping works.  As with arrays, it all looks fine until you
>> want to change the container; consider
>>
>> Vector<String>  vs = new Vector<>();
>> ...
>> Vector<Object>  vo = vs; // Assume this was okay to alias an object
>> vector and a string vector
>>
>> vo.add(new Integer(1));  // Add an Integer to a list of strings, boom!
>>
>> Using wildcards makes the subtyping work along the type argument axis.
>>
> Exactly.  What I wondered on reading this is why it needs to be cast to a
> Vector<Object>  anyway.  That would only reduce type safety as you say.
The current code uses it to store Strings and Vector<String>s. The most 
specific common base type is Object, so I don't think we can do any 
better than that.
>
>> -Joe
>>


From neil.richards at ngmr.net  Wed Aug  3 21:09:36 2011
From: neil.richards at ngmr.net (Neil Richards)
Date: Wed, 03 Aug 2011 22:09:36 +0100
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E398D71.9030302@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com>
	<4E398D71.9030302@oracle.com>
Message-ID: <1312405776.14748.25.camel@chalkhill>

On Wed, 2011-08-03 at 11:03 -0700, Alexandre Boulgakov wrote:
> Please see my responses inline.
> 
> Thanks!
> -Sasha
> 
> On 8/2/2011 9:13 PM, Xuelei Fan wrote:
> > . com/sun/jndi/toolkit/dir/SearchFilter.java
> >   451         for (NamingEnumeration<?>  ve = attr.getAll();
> >   452              ve.hasMore();
> >   453                ) {
> >
> > The update is OK. But the coding style looks uncomfortable. Would you
> > mind change it to use for-each style?
> For-each only works with Iterables. There doesn't seem to be a way to 
> get an Iterable out of an Attribute instance, so the only way to use a 
> for-each here would be to wrap the Enumeration in an ArrayList using 
> Collections.list(). While this might look neater, the contents of the 
> Enumeration would have to be copied over, using time and increasing the 
> memory footprint. Changing Attribute to implement Iterable would require 
> a spec change, and would be beyond the scope of this fix.

Would it  be useful to have a utility object to convert an Enumeration
so it can be used in for-each constructs? - something like:
----
        import java.util.Enumeration;
        import java.util.Iterator;
        
        /**
         * Utility class to transform an Enumeration object such that it can be used in
         * the for-each construct.
         */
        public class IterableEnumerationHolder<E> implements Iterable<E>, Iterator<E> {
            private final Enumeration<E> e;
        
            public IterableEnumerationHolder(final Enumeration<E> e) {
                this.e = e;
            }
        
            @Override
            public Iterator<E> iterator() {
                return this;
            }
        
            @Override
            public boolean hasNext() {
                return e.hasMoreElements();
            }
        
            @Override
            public E next() {
                return e.nextElement();
            }
        
            @Override
            public void remove() {
                throw new UnsupportedOperationException();
            }
        }
----

If it would, perhaps it might be considered for Java 8?

Regards,
Neil

-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From alexandre.boulgakov at oracle.com  Wed Aug  3 21:14:22 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Wed, 03 Aug 2011 14:14:22 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <1312405776.14748.25.camel@chalkhill>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com>
	<4E398D71.9030302@oracle.com> <1312405776.14748.25.camel@chalkhill>
Message-ID: <4E39BA2E.9050405@oracle.com>

Users of Iterable expect to call Iterable.iterator() multiple times, 
receiving a fresh iterator pointing to the beginning of the Iterable 
each time. This would not be possible to do with an Enumeration wrapper 
since Enumerations are read-once.

I don't know if this is a strong enough reason not to include such a 
utility class, but it could certainly be confusing.

-Sasha

On 8/3/2011 2:09 PM, Neil Richards wrote:
> On Wed, 2011-08-03 at 11:03 -0700, Alexandre Boulgakov wrote:
>> Please see my responses inline.
>>
>> Thanks!
>> -Sasha
>>
>> On 8/2/2011 9:13 PM, Xuelei Fan wrote:
>>> . com/sun/jndi/toolkit/dir/SearchFilter.java
>>>    451         for (NamingEnumeration<?>   ve = attr.getAll();
>>>    452              ve.hasMore();
>>>    453                ) {
>>>
>>> The update is OK. But the coding style looks uncomfortable. Would you
>>> mind change it to use for-each style?
>> For-each only works with Iterables. There doesn't seem to be a way to
>> get an Iterable out of an Attribute instance, so the only way to use a
>> for-each here would be to wrap the Enumeration in an ArrayList using
>> Collections.list(). While this might look neater, the contents of the
>> Enumeration would have to be copied over, using time and increasing the
>> memory footprint. Changing Attribute to implement Iterable would require
>> a spec change, and would be beyond the scope of this fix.
> Would it  be useful to have a utility object to convert an Enumeration
> so it can be used in for-each constructs? - something like:
> ----
>          import java.util.Enumeration;
>          import java.util.Iterator;
>
>          /**
>           * Utility class to transform an Enumeration object such that it can be used in
>           * the for-each construct.
>           */
>          public class IterableEnumerationHolder<E>  implements Iterable<E>, Iterator<E>  {
>              private final Enumeration<E>  e;
>
>              public IterableEnumerationHolder(final Enumeration<E>  e) {
>                  this.e = e;
>              }
>
>              @Override
>              public Iterator<E>  iterator() {
>                  return this;
>              }
>
>              @Override
>              public boolean hasNext() {
>                  return e.hasMoreElements();
>              }
>
>              @Override
>              public E next() {
>                  return e.nextElement();
>              }
>
>              @Override
>              public void remove() {
>                  throw new UnsupportedOperationException();
>              }
>          }
> ----
>
> If it would, perhaps it might be considered for Java 8?
>
> Regards,
> Neil
>


From xuelei.fan at oracle.com  Wed Aug  3 23:15:03 2011
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 04 Aug 2011 07:15:03 +0800
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E398D71.9030302@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com>
	<4E398D71.9030302@oracle.com>
Message-ID: <4E39D677.8090107@oracle.com>

On 8/4/2011 2:03 AM, Alexandre Boulgakov wrote:
> Please see my responses inline.
> 
> Thanks!
> -Sasha
> 
> On 8/2/2011 9:13 PM, Xuelei Fan wrote:
>> . com/sun/jndi/toolkit/dir/SearchFilter.java
>>   451         for (NamingEnumeration<?>  ve = attr.getAll();
>>   452              ve.hasMore();
>>   453                ) {
>>
>> The update is OK. But the coding style looks uncomfortable. Would you
>> mind change it to use for-each style?
> For-each only works with Iterables. There doesn't seem to be a way to
> get an Iterable out of an Attribute instance, so the only way to use a
> for-each here would be to wrap the Enumeration in an ArrayList using
> Collections.list(). While this might look neater, the contents of the
> Enumeration would have to be copied over, using time and increasing the
> memory footprint. Changing Attribute to implement Iterable would require
> a spec change, and would be beyond the scope of this fix.
> 
My fault, I thought Enumeration is able to work with for-each. OK,
forgot it, or if you don't mind, please append line 453 at the end of
line 452.

>>
>> . javax/naming/directory/BasicAttribute.java
>> It's an old coding style issue, would you mind indent the lines in
>> inner-class ValuesEnumImpl?
> Got it.
>> We (security team) used to update all copyright date range manually. But
>> Alan told me that the release engineers will run a script over the
>> forest periodically to fix up the date range. I like this way, I think
>> we don't have to update the date range in every fix manually any more.
>> It depends on you.
> I'll keep that in mind, but I've already updated the copyright dates in
> my local copy. Would it be fine to include them in the next version of
> the webrev? 
Sure, it's OK.

> Since these are just warning fixes, they probably will not
> be backported.
>>
>>>> 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java
>>>>      In javax.naming.Context,  Hashtable<?,?>   is used for context
>>>> environment. In this changes, you use Hashtable<String,
>>>> java.lang.Object>.
>>>>      What do you think if we keep the type of K and V the same as
>>>> Hashtable<?,?>?
>>>>
>>>>      I also noticed the similar inconsistency at:
>>>>      . com/sun/jndi/dns/DnsContext.java:
>>>>          50   Hashtable<Object,Object>   environment;
>>>>      . com/sun/jndi/ldap/LdapCtx.java
>>>>          226  Hashtable<String, java.lang.Object>   envprops = null;
>>> The environment passed to the constructor is still Hashtable<?,?>, so
>>> there shouldn't be any source incompatibility because of this. However,
>>> the environment is accessed within the class under the assumption that
>>> (String, Object) pairs or (Object, Object) pairs can be added. This
>>> means that the environment must be of type Hashtable<String, Object>  or
>>> Hashtable<Object, Object>  at the time Hashtable.put is called. We can
>>> either cast it at every call site or once in the constructor. If I
>>> understand type erasure correctly, these casts will not affect the
>>> bytecode produced since the compiler is smart enough to notice we are
>>> casting a Hashtable to a Hashtable, so the only difference is in terms
>>> of readability and the number of @SuppressWarnings("unchecked")
>>> annotations thta need to be included.
>> Sounds reasonable.
>>
>>>> 3. src/share/classes/com/sun/jndi/dns/DnsContext.java
>>>>      What do you think if we have BaseNameClassPairEnumeration to
>>>> implement the NamingEnumeration, so that we can share the code of
>>>> nextElement()?
>>> I'll change it to
>>> abstract class BaseNameClassPairEnumeration<T>  implements
>>> NamingEnumeration<T>
>>>
>> You may also want to change BaseFlatNames in
>> com/sun/jndi/toolkit/dir/HierMemDirCtx.java with the similar style.
> Got it. Would it make sense to make everything except for the next()
> methods final, or will the compiler infer that?
I think it's a good idea.

>> LdapBindingEnumeration --extends-->  LdapNamingEnumeration --implements
>> -->  NamingEnumeration<NameClassPair>.
>>
>>  From the above hierarchy, LdapBindingEnumeration is an instance of
>> NamingEnumeration<NameClassPair>. Now you cast it to
>> NamingEnumeration<Binding>. It might work, but it looks unreasonable and
>> risky in the first glance.
>>
>> The LdapNamingEnumeration and LdapBindingEnumeration is designed when
>> using non-generic programming style. If we switch to use generic
>> features, the inherit structure may not sound reasonable any more.
>>
>> You made a good update in DnsContext and HierMemDirCtx by introducing a
>> intermediate class, BaseNameClassPairEnumeration/BaseFlatNames. Does it
>> sound a solution to LdapBindingEnumeration and LdapNamingEnumeration?
> Yes, I can do that. And also for LdapSearchEnumeration which extends
> LdapNamingEnumeration as well.
Thanks.

Thanks,
Xuelei
>>
>>>> 2244  switch (propName) {
>>>>      Do you want to indent this block? We usually indent a block
>>>> even for
>>>> switch blocks.
>>> Oops, didn't notice that.
>>>> 3017 Vector<Object>   temp = (Vector)extractURLs(res.errorMessage);
>>>>      You may not need the conversion any more, the return value of
>>>> extractURLs() has been updated to
>>>>      2564     private static Vector<String>   extractURLs(String
>>>> refString)
>>> The cast is needed to go from Vector<String>  to Vector<Object>.
>>>> 5. com/sun/jndi/ldap/LdapBindingEnumeration.java
>>>>      Why it is necessary to convert the return type twice (line 92)?
>>>>
>> 8>>      92   return (LdapBindingEnumeration)(NamingEnumeration)
>>>>      93           refCtx.listBindings(listArg);
>>> Again, it's due to a generic type mismatch: refCtx.listBindings(listArg)
>>> returns a NamingEnumeration<Binding>  but LdapBindingEnumeration
>>> implements NamingEnumeration<NameClassPair>. It'd be great if we could
>>> have variant generic interface type parameters, so
>>> NamingEnumeration<Binding>  could extend
>>> NamingEnumeration<NameClassPair>.
>> See above.
>>
>> Otherwise, looks fine to me.
>>
>> Thanks,
>> Xuelei
>>
>>>>      It's great to use convariant return type. I would suggest add
>>>> override tag to make it easy understood.
>>>>
>>>> I am only able to review a quarter of the update today, will continue
>>>> tomorrow.
>>>>
>>>> Thanks,
>>>> Xuelei



From David.Holmes at oracle.com  Thu Aug  4 01:58:25 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Thu, 04 Aug 2011 11:58:25 +1000
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E397636.5070302@oracle.com>
References: <4E34155E.5090700@oracle.com>	<4E37C117.2030104@oracle.com>	<4E384579.1080209@oracle.com>	<4E38FBDD.8070202@oracle.com>
	<4E397636.5070302@oracle.com>
Message-ID: <4E39FCC1.6020308@oracle.com>

Joe Darcy said the following on 08/04/11 02:24:
> On 8/3/2011 12:42 AM, David Holmes wrote:
>> Alexandre Boulgakov said the following on 08/03/11 04:44:
>>> On 8/2/2011 2:19 AM, Xuelei Fan wrote:
>>>> 3017 Vector<Object>  temp = (Vector)extractURLs(res.errorMessage);
>>>>     You may not need the conversion any more, the return value of
>>>> extractURLs() has been updated to
>>>>     2564     private static Vector<String>  extractURLs(String 
>>>> refString)
>>> The cast is needed to go from Vector<String> to Vector<Object>.
>>
>> Raw types should be avoided (here and elsewhere there are casts to raw 
>> Vector). I'm surprised (generics continue to surprise me) that despite 
>> all our advances in type-inference etc that the compiler can not tell 
>> that a Vector<T> is-a Vector<Object>. :(
> 
> That is because in general a Vector<T> is not a Vector<Object> because 
> of the way subtyping works.  As with arrays, it all looks fine until you 
> want to change the container; consider
> 
> Vector<String> vs = new Vector<>();
> ...
> Vector<Object> vo = vs; // Assume this was okay to alias an object 
> vector and a string vector
> 
> vo.add(new Integer(1));  // Add an Integer to a list of strings, boom!

I see what you are saying but with arrays the boom would be an 
ArrayStoreException would it not? So the problem here is that there is 
no runtime checking for generics that could do the same. So we have to 
disallow this.

> Using wildcards makes the subtyping work along the type argument axis.

So what is the right fix here? To declare the underlying Vector as a 
Vector<?> and cast it to something concrete when needed? It seems very 
wrong to me to be inserting raw type casts all through this code.

Cheers,
David

> -Joe
> 


From joe.darcy at oracle.com  Thu Aug  4 02:33:44 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 03 Aug 2011 19:33:44 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E39FCC1.6020308@oracle.com>
References: <4E34155E.5090700@oracle.com>	<4E37C117.2030104@oracle.com>	<4E384579.1080209@oracle.com>	<4E38FBDD.8070202@oracle.com>
	<4E397636.5070302@oracle.com> <4E39FCC1.6020308@oracle.com>
Message-ID: <4E3A0508.6030908@oracle.com>

David Holmes wrote:
> Joe Darcy said the following on 08/04/11 02:24:
>> On 8/3/2011 12:42 AM, David Holmes wrote:
>>> Alexandre Boulgakov said the following on 08/03/11 04:44:
>>>> On 8/2/2011 2:19 AM, Xuelei Fan wrote:
>>>>> 3017 Vector<Object>  temp = (Vector)extractURLs(res.errorMessage);
>>>>>     You may not need the conversion any more, the return value of
>>>>> extractURLs() has been updated to
>>>>>     2564     private static Vector<String>  extractURLs(String 
>>>>> refString)
>>>> The cast is needed to go from Vector<String> to Vector<Object>.
>>>
>>> Raw types should be avoided (here and elsewhere there are casts to 
>>> raw Vector). I'm surprised (generics continue to surprise me) that 
>>> despite all our advances in type-inference etc that the compiler can 
>>> not tell that a Vector<T> is-a Vector<Object>. :(
>>
>> That is because in general a Vector<T> is not a Vector<Object> 
>> because of the way subtyping works.  As with arrays, it all looks 
>> fine until you want to change the container; consider
>>
>> Vector<String> vs = new Vector<>();
>> ...
>> Vector<Object> vo = vs; // Assume this was okay to alias an object 
>> vector and a string vector
>>
>> vo.add(new Integer(1));  // Add an Integer to a list of strings, boom!
>
> I see what you are saying but with arrays the boom would be an 
> ArrayStoreException would it not? So the problem here is that there is 
> no runtime checking for generics that could do the same. So we have to 
> disallow this.

Exactly; since arrays are reified so the VM has the information needed 
to check for an errant store and when appropriate throw the 
ArrayStoreException.  Since generics are implemented via erasure, the 
analogous information is not available at runtime for collections.  Note 
that the behavior of arrays is statically unsafe and requires the 
runtime check.

>
>> Using wildcards makes the subtyping work along the type argument axis.
>
> So what is the right fix here? To declare the underlying Vector as a 
> Vector<?> and cast it to something concrete when needed? It seems very 
> wrong to me to be inserting raw type casts all through this code.

It isn't entirely clear to be from a quick inspection of the code what 
the actual type usage is.  A writable general Vector should be a 
Vector<Object> and Vector just meant for reading should be a Vector<?> 
(or the equivalent Vector<? extends Object>).

If the type usage is "a sequence of X's and Y's" where X and Y don't 
have some useful supertype, I would recommend using a somewhat different 
set of data structures, like a list of type-safe heterogeneous 
containers or a list of a new package-level XorY class.

-Joe


From joe.darcy at oracle.com  Thu Aug  4 02:39:07 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 03 Aug 2011 19:39:07 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E38462C.7010900@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E38462C.7010900@oracle.com>
Message-ID: <4E3A064B.5070605@oracle.com>

PS Looking in src/share/classes/com/sun/jndi/dns/DnsContext.java, for 
this code

1085     public Binding nextElement() {
1086         try {
1087             return next();
1088         } catch (NamingException e) {
1089             throw (new java.util.NoSuchElementException(
1090                     "javax.naming.NamingException was thrown: " +
1091                     e.getMessage()));
1092         }
1093     }

I recommend considering replacing 1089 - 1091 with something like

java.util.NoSuchElementException nsee = new 
java.util.NoSuchElementException();
nsee.initCause(e);
throw nsee;

-Joe

Alexandre Boulgakov wrote:
> Thanks for reviewing! Please see my responses inline.
>
> I'll wait on sending another webrev until I've received the rest of 
> your comments.
>
> -Sasha
>
> On 8/2/2011 2:19 AM, Xuelei Fan wrote:
>>> Please review these JNDI changes.
>>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072353
>>> webrev: http://cr.openjdk.java.net/~mduigou/7072353/0/webrev/
>> Thanks for your effort to make JNDI free of compile-warning. The work is
>> hard, I appreciate it.
>>
>> 1. I noticed the copyright date of a few files are unchanged, please
>> update them before you push the changes.
> I've done that in my local copy but didn't include it in the webrev so 
> as to not pollute it.
>>
>> 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java
>>     In javax.naming.Context,  Hashtable<?,?>  is used for context
>> environment. In this changes, you use Hashtable<String, 
>> java.lang.Object>.
>>     What do you think if we keep the type of K and V the same as
>> Hashtable<?,?>?
>>
>>     I also noticed the similar inconsistency at:
>>     . com/sun/jndi/dns/DnsContext.java:
>>         50   Hashtable<Object,Object>  environment;
>>     . com/sun/jndi/ldap/LdapCtx.java
>>         226  Hashtable<String, java.lang.Object>  envprops = null;
> The environment passed to the constructor is still Hashtable<?,?>, so 
> there shouldn't be any source incompatibility because of this. 
> However, the environment is accessed within the class under the 
> assumption that (String, Object) pairs or (Object, Object) pairs can 
> be added. This means that the environment must be of type 
> Hashtable<String, Object> or Hashtable<Object, Object> at the time 
> Hashtable.put is called. We can either cast it at every call site or 
> once in the constructor. If I understand type erasure correctly, these 
> casts will not affect the bytecode produced since the compiler is 
> smart enough to notice we are casting a Hashtable to a Hashtable, so 
> the only difference is in terms of readability and the number of 
> @SuppressWarnings("unchecked") annotations that need to be included.
>>
>> 3. src/share/classes/com/sun/jndi/dns/DnsContext.java
>>     What do you think if we have BaseNameClassPairEnumeration to
>> implement the NamingEnumeration, so that we can share the code of
>> nextElement()?
>
> I'll change it to
> abstract class BaseNameClassPairEnumeration<T> implements 
> NamingEnumeration<T>
>
>>
>>    class BaseNameClassPairEnumeration implements NamingEnumeration<T>
>>
>> *** com/sun/jndi/ldap/Connection.java
>>   251         } catch (ClassNotFoundException |
>>   252                  InstantiationException |
>>   253                  InvocationTargetException |
>>   254                  IllegalAccessException e) {
>>
>> I like this new try-catch feature!
>>
>> 4. com/sun/jndi/ldap/LdapCtx.java
>> 1194    return (NamingEnumeration)
>> 1195        new LdapBindingEnumeration(this, answer, name, cont);
>>
>>     LdapBindingEnumeration is of type NamingEnumeration, it may be not
>> necessary to convert to NamingEnumeration. Do you mean
>> NamingEnumeration<Binding>?
>>
>>         return (NamingEnumeration<Binding>)
>>             new LdapBindingEnumeration(this, answer, name, cont);
> LdapBindingEnumeration extends LdapNamingEnumeration, which implements 
> NamingEnumeration<NameClassPair>. This means we cannot cast it to 
> NamingEnumeration<Binding> directly, but must go through a raw 
> intermediate like NamingEnumeration or Object. I can change it to a 
> double cast with (NamingEnumeration<Binding>)(NamingEnumeration), if 
> you think that would improve readability, or LdapBindingEnumeration 
> and LdapNamingEnumeration could be refactored to implement different 
> NamingEnumeration<T> interfaces (like I did with 
> NameClassPairEnumeration and BindingEnumeration in 
> src/share/classes/com/sun/jndi/dns/DnsContext.java).
>>
>> 2244  switch (propName) {
>>     Do you want to indent this block? We usually indent a block even for
>> switch blocks.
> Oops, didn't notice that.
>>
>> 3017 Vector<Object>  temp = (Vector)extractURLs(res.errorMessage);
>>     You may not need the conversion any more, the return value of
>> extractURLs() has been updated to
>>     2564     private static Vector<String>  extractURLs(String 
>> refString)
> The cast is needed to go from Vector<String> to Vector<Object>.
>>
>> 5. com/sun/jndi/ldap/LdapBindingEnumeration.java
>>     Why it is necessary to convert the return type twice (line 92)?
>>
>>     92   return (LdapBindingEnumeration)(NamingEnumeration)
>>     93           refCtx.listBindings(listArg);
> Again, it's due to a generic type mismatch: 
> refCtx.listBindings(listArg) returns a NamingEnumeration<Binding> but 
> LdapBindingEnumeration implements NamingEnumeration<NameClassPair>. 
> It'd be great if we could have variant generic interface type 
> parameters, so NamingEnumeration<Binding> could extend 
> NamingEnumeration<NameClassPair>.
>>
>>     It's great to use convariant return type. I would suggest add
>> override tag to make it easy understood.
>>
>> I am only able to review a quarter of the update today, will continue
>> tomorrow.
>>
>> Thanks,
>> Xuelei



From David.Holmes at oracle.com  Thu Aug  4 03:42:02 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Thu, 04 Aug 2011 13:42:02 +1000
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E3A0508.6030908@oracle.com>
References: <4E34155E.5090700@oracle.com>	<4E37C117.2030104@oracle.com>	<4E384579.1080209@oracle.com>	<4E38FBDD.8070202@oracle.com>
	<4E397636.5070302@oracle.com> <4E39FCC1.6020308@oracle.com>
	<4E3A0508.6030908@oracle.com>
Message-ID: <4E3A150A.9070503@oracle.com>

Joe Darcy said the following on 08/04/11 12:33:
> David Holmes wrote:
>>> Using wildcards makes the subtyping work along the type argument axis.
>>
>> So what is the right fix here? To declare the underlying Vector as a 
>> Vector<?> and cast it to something concrete when needed? It seems very 
>> wrong to me to be inserting raw type casts all through this code.
> 
> It isn't entirely clear to be from a quick inspection of the code what 
> the actual type usage is.  A writable general Vector should be a 
> Vector<Object> and Vector just meant for reading should be a Vector<?> 
> (or the equivalent Vector<? extends Object>).
> 
> If the type usage is "a sequence of X's and Y's" where X and Y don't 
> have some useful supertype, I would recommend using a somewhat different 
> set of data structures, like a list of type-safe heterogeneous 
> containers or a list of a new package-level XorY class.

Buried in one of Sasha's emails it says:

"The current code uses it to store Strings and Vector<String>s."

Hence it is declared Vector<Object>.

This is looking to me like code that should not have been generified.

David

> -Joe


From joe.darcy at oracle.com  Thu Aug  4 05:44:41 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 03 Aug 2011 22:44:41 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E3A150A.9070503@oracle.com>
References: <4E34155E.5090700@oracle.com>	<4E37C117.2030104@oracle.com>	<4E384579.1080209@oracle.com>	<4E38FBDD.8070202@oracle.com>
	<4E397636.5070302@oracle.com> <4E39FCC1.6020308@oracle.com>
	<4E3A0508.6030908@oracle.com> <4E3A150A.9070503@oracle.com>
Message-ID: <4E3A31C9.8060304@oracle.com>

David Holmes wrote:
> Joe Darcy said the following on 08/04/11 12:33:
>> David Holmes wrote:
>>>> Using wildcards makes the subtyping work along the type argument axis.
>>>
>>> So what is the right fix here? To declare the underlying Vector as a 
>>> Vector<?> and cast it to something concrete when needed? It seems 
>>> very wrong to me to be inserting raw type casts all through this code.
>>
>> It isn't entirely clear to be from a quick inspection of the code 
>> what the actual type usage is.  A writable general Vector should be a 
>> Vector<Object> and Vector just meant for reading should be a 
>> Vector<?> (or the equivalent Vector<? extends Object>).
>>
>> If the type usage is "a sequence of X's and Y's" where X and Y don't 
>> have some useful supertype, I would recommend using a somewhat 
>> different set of data structures, like a list of type-safe 
>> heterogeneous containers or a list of a new package-level XorY class.
>
> Buried in one of Sasha's emails it says:
>
> "The current code uses it to store Strings and Vector<String>s."
>
> Hence it is declared Vector<Object>.
>
> This is looking to me like code that should not have been generified.
>

Hmm.  If String or Vector<String> are the two kinds of stored values, I 
would recommend Vector<Vector<String>> where a lone string was wrapped 
in a vector.  (Actually, I would recommend a List<List<String>>, but 
that may be beyond the scope of this cleanup.

-Joe



From carsongross at gmail.com  Thu Aug  4 06:09:57 2011
From: carsongross at gmail.com (Carson Gross)
Date: Wed, 3 Aug 2011 23:09:57 -0700
Subject: Second try... Readable Collections Interfaces.
Message-ID: <CAO92UoErKwzj4EM7dotmrV=GLEbOUti4cO_7WQi-efnFJPNvKg@mail.gmail.com>

(This bounced or got hung up the first time I sent it.)

Hi Guys,

I work on Gosu, a JDK-based language, and I was talking w/ Charles Nutter
and Ola Bini today (ed: now last week) at OSCON, and a general idea that
I've been kicking around for a long time came up.  They both didn't think it
was crazy, so I figured I'd bounce it off this mailing list.  Apologies if
this has been discussed before.

Here's the problem I have: I'd like to return my mutable collections to
consumers as an immutable collection.

Now, I know I can wrap my collections in immutable versions, but that isn't
really what I want: I'm less concerned that the implementation is actually
immutable, but I'd like the consumer of my collections to *know* statically
that they aren't supposed to mutate the collection I'm handing them.  Tt a
practical level, the wrapping approach necessitates me either wrapping the
mutable collection I've got in my class every time I return it or to
maintain a second reference to the wrapped class, both of which are ugly.

So, what I think I want is an interface like, for example, ReadableList,
which has only the readable methods on List and none of the mutators.  And,
presumably, that would extend a ReadableCollection, which would have only
the readable methods on Collection, and so on.  (One point that Josh Bloch
made was that Iterable breaks this, but I *think* you could introduce a
ReadableIterator interface without the remove() method and use covariance
return types in the mutable collections to make it all work out.)  I could
then return my mutable Lists as this interface, and send a strong signal to
the caller that they shouldn't mutate them.  (If they downcast... hey, we
are all adults here, right?)

Some sample code:

class MyClass {
  List<String> someNames = ...

  public ReadableList<String> getSomeNames() {
    return someNames;
  }
}

So callers of MyClass#getSomeNames() will know that I don't intend for them
to mutate the list.  And, of course, it would be nice if these interfaces
worked properly with the for() statement, etc.

As a side note, I like the name ReadableList vs. the more obvious
ImmutableList, since java.util.List would extend this interface and it isn't
an ImmutableList.

Anyway, this is obviously a very rough idea, but I'd like to hear what
people think and what problems might come up when implementing it.

Thanks,
Carson


From weijun.wang at oracle.com  Thu Aug  4 10:19:29 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Thu, 04 Aug 2011 10:19:29 +0000
Subject: hg: jdk8/tl/jdk: 7061379: [Kerberos] Cross-realm authentication fails,
	due to nameType problem
Message-ID: <20110804101955.C941C4792B@hg.openjdk.java.net>

Changeset: e68db408d08c
Author:    weijun
Date:      2011-08-04 18:18 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e68db408d08c

7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/PrincipalName.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/auto/PrincipalNameEquals.java



From Alan.Bateman at oracle.com  Thu Aug  4 15:50:38 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 04 Aug 2011 16:50:38 +0100
Subject: Code Review Request : 7011591 JDWP socket transport should restart
	interrupted system calls (EINTR)
In-Reply-To: <4E3A8A4F.60609@oracle.com>
References: <4E3A8A4F.60609@oracle.com>
Message-ID: <4E3ABFCE.3070408@oracle.com>

David Buck wrote:
> Hi!
>
> I would like to request that my fix for 7011591 be reviewed for push 
> into JDK8 (and JDK7u if possible).
>
> CR: 7011591 JDWP socket transport should restart interrupted system 
> calls (EINTR)
> :
>
> Webrev: http://cr.openjdk.java.net/~dbuck/7011591/webrev.00/
I've added serviceability-dev to the CC list as that is where the 
debugger code is.

I looked at the webrev and it mostly looks okay to me. One issue is that 
dbgsysPoll probably should adjust the timeout when interrupted. A minor 
nit is that you've changed the copyright date on the file from 1998 to 1997.

-Alan.


From cgdecker at gmail.com  Thu Aug  4 16:17:16 2011
From: cgdecker at gmail.com (Colin Decker)
Date: Thu, 4 Aug 2011 12:17:16 -0400
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E39BA2E.9050405@oracle.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com>
	<4E398D71.9030302@oracle.com> <1312405776.14748.25.camel@chalkhill>
	<4E39BA2E.9050405@oracle.com>
Message-ID: <CAPmOpX5VGB_7+dLQf22s5n7vw6mmVw8Gq9_87V29hAzigJJLeg@mail.gmail.com>

One better way to handle this in Java 8 would be to have a utility method
that takes a Supplier<Enumeration<E>> SAM argument (with a no-arg method
that returns an Enumeration<E>) and returns an Iterable<E> that gets a new
Enumeration from the supplier each time iterator() is called. It could then
be used with method references:

Iterable<E> iterable = Util.enumerationIterable(#object.getEnumeration);

-- 
Colin


On Wed, Aug 3, 2011 at 5:14 PM, Alexandre Boulgakov <
alexandre.boulgakov at oracle.com> wrote:

> Users of Iterable expect to call Iterable.iterator() multiple times,
> receiving a fresh iterator pointing to the beginning of the Iterable each
> time. This would not be possible to do with an Enumeration wrapper since
> Enumerations are read-once.
>
> I don't know if this is a strong enough reason not to include such a
> utility class, but it could certainly be confusing.
>
> -Sasha
>
>
> On 8/3/2011 2:09 PM, Neil Richards wrote:
>
>> On Wed, 2011-08-03 at 11:03 -0700, Alexandre Boulgakov wrote:
>>
>>> Please see my responses inline.
>>>
>>> Thanks!
>>> -Sasha
>>>
>>> On 8/2/2011 9:13 PM, Xuelei Fan wrote:
>>>
>>>> . com/sun/jndi/toolkit/dir/**SearchFilter.java
>>>>   451         for (NamingEnumeration<?>   ve = attr.getAll();
>>>>   452              ve.hasMore();
>>>>   453                ) {
>>>>
>>>> The update is OK. But the coding style looks uncomfortable. Would you
>>>> mind change it to use for-each style?
>>>>
>>> For-each only works with Iterables. There doesn't seem to be a way to
>>> get an Iterable out of an Attribute instance, so the only way to use a
>>> for-each here would be to wrap the Enumeration in an ArrayList using
>>> Collections.list(). While this might look neater, the contents of the
>>> Enumeration would have to be copied over, using time and increasing the
>>> memory footprint. Changing Attribute to implement Iterable would require
>>> a spec change, and would be beyond the scope of this fix.
>>>
>> Would it  be useful to have a utility object to convert an Enumeration
>> so it can be used in for-each constructs? - something like:
>> ----
>>         import java.util.Enumeration;
>>         import java.util.Iterator;
>>
>>         /**
>>          * Utility class to transform an Enumeration object such that it
>> can be used in
>>          * the for-each construct.
>>          */
>>         public class IterableEnumerationHolder<E>  implements Iterable<E>,
>> Iterator<E>  {
>>             private final Enumeration<E>  e;
>>
>>             public IterableEnumerationHolder(**final Enumeration<E>  e) {
>>                 this.e = e;
>>             }
>>
>>             @Override
>>             public Iterator<E>  iterator() {
>>                 return this;
>>             }
>>
>>             @Override
>>             public boolean hasNext() {
>>                 return e.hasMoreElements();
>>             }
>>
>>             @Override
>>             public E next() {
>>                 return e.nextElement();
>>             }
>>
>>             @Override
>>             public void remove() {
>>                 throw new UnsupportedOperationException(**);
>>             }
>>         }
>> ----
>>
>> If it would, perhaps it might be considered for Java 8?
>>
>> Regards,
>> Neil
>>
>>


From mike.duigou at oracle.com  Thu Aug  4 16:17:50 2011
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 04 Aug 2011 16:17:50 +0000
Subject: hg: jdk8/tl/jdk: 7073296: Executable.equalParamTypes() incorrectly
	returns true when the number of params differs.
Message-ID: <20110804161801.09D1A47938@hg.openjdk.java.net>

Changeset: 565555e89034
Author:    mduigou
Date:      2011-08-04 08:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/565555e89034

7073296: Executable.equalParamTypes() incorrectly returns true when the number of params differs.
Reviewed-by: alanb, darcy

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/reflect/Executable.java
+ test/java/lang/reflect/Constructor/Equals.java



From daniel.daugherty at oracle.com  Thu Aug  4 16:19:10 2011
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 04 Aug 2011 10:19:10 -0600
Subject: Code Review Request : 7011591 JDWP socket transport should restart
	interrupted system calls (EINTR)
In-Reply-To: <4E3ABFCE.3070408@oracle.com>
References: <4E3A8A4F.60609@oracle.com> <4E3ABFCE.3070408@oracle.com>
Message-ID: <4E3AC67E.7080208@oracle.com>

On 8/4/11 9:50 AM, Alan Bateman wrote:
> David Buck wrote:
>> Hi!
>>
>> I would like to request that my fix for 7011591 be reviewed for push 
>> into JDK8 (and JDK7u if possible).
>>
>> CR: 7011591 JDWP socket transport should restart interrupted system 
>> calls (EINTR)
>> :
>>
>> Webrev: http://cr.openjdk.java.net/~dbuck/7011591/webrev.00/
> I've added serviceability-dev to the CC list as that is where the 
> debugger code is.

Alan, thanks for adding in serviceability-dev...

Thumbs up from me since this matches my earlier reviews.


> I looked at the webrev and it mostly looks okay to me. One issue is 
> that dbgsysPoll probably should adjust the timeout when interrupted.

Adjust it how? (Just curious)


> A minor nit is that you've changed the copyright date on the file from 
> 1998 to 1997.

Don't know how I missed that with the earlier reviews, but the
Teamware history shows that the earliest date for this file
is indeed in 1998 and not 1997:

$ sccs prs -r1.1 src/solaris/transport/socket/socket_md.c
src/solaris/transport/socket/SCCS/s.socket_md.c:

D 1.1 98/11/21 21:20:56 gordonh 1 0     00149/00000/00000
MRs:
COMMENTS:

Dan



From forax at univ-mlv.fr  Thu Aug  4 16:34:15 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Thu, 04 Aug 2011 18:34:15 +0200
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <CAPmOpX5VGB_7+dLQf22s5n7vw6mmVw8Gq9_87V29hAzigJJLeg@mail.gmail.com>
References: <4E34155E.5090700@oracle.com>
	<4E37C117.2030104@oracle.com>	<4E384579.1080209@oracle.com>
	<4E38CAD9.8050705@oracle.com>	<4E398D71.9030302@oracle.com>
	<1312405776.14748.25.camel@chalkhill>	<4E39BA2E.9050405@oracle.com>
	<CAPmOpX5VGB_7+dLQf22s5n7vw6mmVw8Gq9_87V29hAzigJJLeg@mail.gmail.com>
Message-ID: <4E3ACA07.4060203@univ-mlv.fr>

On 08/04/2011 06:17 PM, Colin Decker wrote:
> One better way to handle this in Java 8 would be to have a utility method
> that takes a Supplier<Enumeration<E>>  SAM argument (with a no-arg method
> that returns an Enumeration<E>) and returns an Iterable<E>  that gets a new
> Enumeration from the supplier each time iterator() is called. It could then
> be used with method references:
>
> Iterable<E>  iterable = Util.enumerationIterable(#object.getEnumeration);
>

you means Collections.list().

R?mi



From cgdecker at gmail.com  Thu Aug  4 16:52:13 2011
From: cgdecker at gmail.com (Colin Decker)
Date: Thu, 4 Aug 2011 12:52:13 -0400
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E3ACA07.4060203@univ-mlv.fr>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com>
	<4E398D71.9030302@oracle.com> <1312405776.14748.25.camel@chalkhill>
	<4E39BA2E.9050405@oracle.com>
	<CAPmOpX5VGB_7+dLQf22s5n7vw6mmVw8Gq9_87V29hAzigJJLeg@mail.gmail.com>
	<4E3ACA07.4060203@univ-mlv.fr>
Message-ID: <CAPmOpX6Z5izjbKgL1f6ak_NV65UsnxDqCLn1YZAMTKTrGPf5FA@mail.gmail.com>

No, that copies the Enumeration. I'm talking about something that creates
lazy Iterators backed by Enumerations.

-- 
Colin


On Thu, Aug 4, 2011 at 12:34 PM, R?mi Forax <forax at univ-mlv.fr> wrote:

> On 08/04/2011 06:17 PM, Colin Decker wrote:
>
>> One better way to handle this in Java 8 would be to have a utility method
>> that takes a Supplier<Enumeration<E>>  SAM argument (with a no-arg method
>> that returns an Enumeration<E>) and returns an Iterable<E>  that gets a
>> new
>> Enumeration from the supplier each time iterator() is called. It could
>> then
>> be used with method references:
>>
>> Iterable<E>  iterable = Util.enumerationIterable(#**
>> object.getEnumeration);
>>
>>
> you means Collections.list().
>
> R?mi
>
>


From forax at univ-mlv.fr  Thu Aug  4 17:03:12 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Thu, 04 Aug 2011 19:03:12 +0200
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <CAPmOpX6Z5izjbKgL1f6ak_NV65UsnxDqCLn1YZAMTKTrGPf5FA@mail.gmail.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com>
	<4E398D71.9030302@oracle.com> <1312405776.14748.25.camel@chalkhill>
	<4E39BA2E.9050405@oracle.com>
	<CAPmOpX5VGB_7+dLQf22s5n7vw6mmVw8Gq9_87V29hAzigJJLeg@mail.gmail.com>
	<4E3ACA07.4060203@univ-mlv.fr>
	<CAPmOpX6Z5izjbKgL1f6ak_NV65UsnxDqCLn1YZAMTKTrGPf5FA@mail.gmail.com>
Message-ID: <4E3AD0D0.6090007@univ-mlv.fr>

On 08/04/2011 06:52 PM, Colin Decker wrote:
> No, that copies the Enumeration. I'm talking about something that 
> creates lazy Iterators backed by Enumerations.
>
> -- 
> Colin

Ok,
why not adding a method iterator(Enumeration) that takes an Enumeration and
returns an Iterator and then do a method reference on the method iterator.

Iterable<String> iterable = #Collections.iterator(enumeration).iterator;

R?mi

>
>
> On Thu, Aug 4, 2011 at 12:34 PM, R?mi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     On 08/04/2011 06:17 PM, Colin Decker wrote:
>
>         One better way to handle this in Java 8 would be to have a
>         utility method
>         that takes a Supplier<Enumeration<E>>  SAM argument (with a
>         no-arg method
>         that returns an Enumeration<E>) and returns an Iterable<E>
>          that gets a new
>         Enumeration from the supplier each time iterator() is called.
>         It could then
>         be used with method references:
>
>         Iterable<E>  iterable =
>         Util.enumerationIterable(#object.getEnumeration);
>
>
>     you means Collections.list().
>
>     R?mi
>
>



From cgdecker at gmail.com  Thu Aug  4 17:39:51 2011
From: cgdecker at gmail.com (Colin Decker)
Date: Thu, 4 Aug 2011 13:39:51 -0400
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E3AD0D0.6090007@univ-mlv.fr>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com>
	<4E398D71.9030302@oracle.com> <1312405776.14748.25.camel@chalkhill>
	<4E39BA2E.9050405@oracle.com>
	<CAPmOpX5VGB_7+dLQf22s5n7vw6mmVw8Gq9_87V29hAzigJJLeg@mail.gmail.com>
	<4E3ACA07.4060203@univ-mlv.fr>
	<CAPmOpX6Z5izjbKgL1f6ak_NV65UsnxDqCLn1YZAMTKTrGPf5FA@mail.gmail.com>
	<4E3AD0D0.6090007@univ-mlv.fr>
Message-ID: <CAPmOpX7StGgfn-+Ad6sjNd81hFfnEUZDt1xd=W2xtc4AHNLWgA@mail.gmail.com>

Well, Iterator doesn't have an iterator() method. It also looks like you'd
have to have a reference to a single Enumeration already there? I was
suggesting using a method reference to an Enumeration-returning method so
that a fresh Enumeration could be retrieved to back each Iterator created by
the resulting Iterable. There may be a better way than I suggested... I just
wanted to point out that there's no good reason to create a single-use
Iterable for Enumerations when method references could make it easy to
create a proper Iterable.

-- 
Colin


On Thu, Aug 4, 2011 at 1:03 PM, R?mi Forax <forax at univ-mlv.fr> wrote:

> **
> On 08/04/2011 06:52 PM, Colin Decker wrote:
>
> No, that copies the Enumeration. I'm talking about something that creates
> lazy Iterators backed by Enumerations.
>
> --
> Colin
>
>
> Ok,
> why not adding a method iterator(Enumeration) that takes an Enumeration and
> returns an Iterator and then do a method reference on the method iterator.
>
> Iterable<String> iterable = #Collections.iterator(enumeration).iterator;
>
> R?mi
>
>
>
>
> On Thu, Aug 4, 2011 at 12:34 PM, R?mi Forax <forax at univ-mlv.fr> wrote:
>
>> On 08/04/2011 06:17 PM, Colin Decker wrote:
>>
>>> One better way to handle this in Java 8 would be to have a utility method
>>> that takes a Supplier<Enumeration<E>>  SAM argument (with a no-arg method
>>> that returns an Enumeration<E>) and returns an Iterable<E>  that gets a
>>> new
>>> Enumeration from the supplier each time iterator() is called. It could
>>> then
>>> be used with method references:
>>>
>>> Iterable<E>  iterable = Util.enumerationIterable(#object.getEnumeration);
>>>
>>>
>>  you means Collections.list().
>>
>> R?mi
>>
>>
>
>


From forax at univ-mlv.fr  Thu Aug  4 18:07:54 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Thu, 04 Aug 2011 20:07:54 +0200
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <CAPmOpX7StGgfn-+Ad6sjNd81hFfnEUZDt1xd=W2xtc4AHNLWgA@mail.gmail.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com>
	<4E398D71.9030302@oracle.com> <1312405776.14748.25.camel@chalkhill>
	<4E39BA2E.9050405@oracle.com>
	<CAPmOpX5VGB_7+dLQf22s5n7vw6mmVw8Gq9_87V29hAzigJJLeg@mail.gmail.com>
	<4E3ACA07.4060203@univ-mlv.fr>
	<CAPmOpX6Z5izjbKgL1f6ak_NV65UsnxDqCLn1YZAMTKTrGPf5FA@mail.gmail.com>
	<4E3AD0D0.6090007@univ-mlv.fr>
	<CAPmOpX7StGgfn-+Ad6sjNd81hFfnEUZDt1xd=W2xtc4AHNLWgA@mail.gmail.com>
Message-ID: <4E3ADFFA.4010207@univ-mlv.fr>

On 08/04/2011 07:39 PM, Colin Decker wrote:
> Well, Iterator doesn't have an iterator() method. It also looks like 
> you'd have to have a reference to a single Enumeration already there? 
> I was suggesting using a method reference to an Enumeration-returning 
> method so that a fresh Enumeration could be retrieved to back each 
> Iterator created by the resulting Iterable. There may be a better way 
> than I suggested... I just wanted to point out that there's no good 
> reason to create a single-use Iterable for Enumerations when method 
> references could make it easy to create a proper Iterable.
>
> -- 
> Colin

doh, sorry, right.

R?mi

>
>
> On Thu, Aug 4, 2011 at 1:03 PM, R?mi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     On 08/04/2011 06:52 PM, Colin Decker wrote:
>>     No, that copies the Enumeration. I'm talking about something that
>>     creates lazy Iterators backed by Enumerations.
>>
>>     -- 
>>     Colin
>
>     Ok,
>     why not adding a method iterator(Enumeration) that takes an
>     Enumeration and
>     returns an Iterator and then do a method reference on the method
>     iterator.
>
>     Iterable<String> iterable =
>     #Collections.iterator(enumeration).iterator;
>
>     R?mi
>
>
>>
>>
>>     On Thu, Aug 4, 2011 at 12:34 PM, R?mi Forax <forax at univ-mlv.fr
>>     <mailto:forax at univ-mlv.fr>> wrote:
>>
>>         On 08/04/2011 06:17 PM, Colin Decker wrote:
>>
>>             One better way to handle this in Java 8 would be to have
>>             a utility method
>>             that takes a Supplier<Enumeration<E>>  SAM argument (with
>>             a no-arg method
>>             that returns an Enumeration<E>) and returns an
>>             Iterable<E>  that gets a new
>>             Enumeration from the supplier each time iterator() is
>>             called. It could then
>>             be used with method references:
>>
>>             Iterable<E>  iterable =
>>             Util.enumerationIterable(#object.getEnumeration);
>>
>>
>>         you means Collections.list().
>>
>>         R?mi
>>
>>
>
>



From joe.darcy at oracle.com  Thu Aug  4 18:17:07 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 04 Aug 2011 18:17:07 +0000
Subject: hg: jdk8/tl/langtools: 7071246: Enclosing string literal in
	parenthesis in switch-case crashes javac
Message-ID: <20110804181712.289234793D@hg.openjdk.java.net>

Changeset: 64b9b7ae3366
Author:    darcy
Date:      2011-08-04 11:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64b9b7ae3366

7071246: Enclosing string literal in parenthesis in switch-case crashes javac
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
! test/tools/javac/StringsInSwitch/StringSwitches.java



From joe.darcy at oracle.com  Thu Aug  4 18:56:18 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 04 Aug 2011 11:56:18 -0700
Subject: JDK 8 code review request for 7075098: Remove unused fdlibm files
Message-ID: <4E3AEB52.9070300@oracle.com>

Hello.

Please review these straightforward changes for

    7075098: Remove unused fdlibm files
    http://cr.openjdk.java.net/~darcy/7075098.0/

The JDK math libraries in java.lang.{Math, StrictMath} do not expose all 
the functionality implemented in the embedded copy of FDLIBM (freely 
distributable math library).  Since we do not plan do expose the 
remaining functionality (erf, gamma, lgama, j0, j1, jn, acosh, asinh, 
etc.) and these functions are not needed by the Java core libs directly 
or by transitivity, this changeset removes the unneeded files from the 
build.

On my Linux build, with this change the size of the compiled fdlibm 
library file went down from 234,372 to 165,750 and all the math library 
regression tests pass.

Thanks,

-Joe


From Alan.Bateman at oracle.com  Thu Aug  4 19:34:00 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 04 Aug 2011 20:34:00 +0100
Subject: JDK 8 code review request for 7075098: Remove unused fdlibm files
In-Reply-To: <4E3AEB52.9070300@oracle.com>
References: <4E3AEB52.9070300@oracle.com>
Message-ID: <4E3AF428.20803@oracle.com>

Joe Darcy wrote:
> Hello.
>
> Please review these straightforward changes for
>
>    7075098: Remove unused fdlibm files
>    http://cr.openjdk.java.net/~darcy/7075098.0/
>
> The JDK math libraries in java.lang.{Math, StrictMath} do not expose 
> all the functionality implemented in the embedded copy of FDLIBM 
> (freely distributable math library).  Since we do not plan do expose 
> the remaining functionality (erf, gamma, lgama, j0, j1, jn, acosh, 
> asinh, etc.) and these functions are not needed by the Java core libs 
> directly or by transitivity, this changeset removes the unneeded files 
> from the build.
>
> On my Linux build, with this change the size of the compiled fdlibm 
> library file went down from 234,372 to 165,750 and all the math 
> library regression tests pass.
>
> Thanks,
>
> -Joe
This looks good to me. I assume you've checked that it builds on other 
platforms too.

-Alan.


From mike.duigou at oracle.com  Thu Aug  4 19:50:59 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 4 Aug 2011 12:50:59 -0700
Subject: JDK 8 code review request for 7075098: Remove unused fdlibm files
In-Reply-To: <4E3AEB52.9070300@oracle.com>
References: <4E3AEB52.9070300@oracle.com>
Message-ID: <0A214C25-0DB6-4B5C-AA9C-3142CB9CFA78@oracle.com>

Looks good to me. 

I did wonder if we have a policy for tracking fdlibm updates. The fdlibm people don't seem to ascribe dates to their releases or think to include version numbers in their headers. Are we using 5.3, the apparent latest version? Their release page mentions an outstanding incorrect code generation bug due to non-standards compliant code. Is our usage vulnerable to this bug? Do we have a test to catch this bug should it be encountered?

Mike

On Aug 4 2011, at 11:56 , Joe Darcy wrote:

> Hello.
> 
> Please review these straightforward changes for
> 
>   7075098: Remove unused fdlibm files
>   http://cr.openjdk.java.net/~darcy/7075098.0/
> 
> The JDK math libraries in java.lang.{Math, StrictMath} do not expose all the functionality implemented in the embedded copy of FDLIBM (freely distributable math library).  Since we do not plan do expose the remaining functionality (erf, gamma, lgama, j0, j1, jn, acosh, asinh, etc.) and these functions are not needed by the Java core libs directly or by transitivity, this changeset removes the unneeded files from the build.
> 
> On my Linux build, with this change the size of the compiled fdlibm library file went down from 234,372 to 165,750 and all the math library regression tests pass.
> 
> Thanks,
> 
> -Joe



From joe.darcy at oracle.com  Thu Aug  4 20:09:45 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 04 Aug 2011 13:09:45 -0700
Subject: JDK 8 code review request for 7075098: Remove unused fdlibm files
In-Reply-To: <0A214C25-0DB6-4B5C-AA9C-3142CB9CFA78@oracle.com>
References: <4E3AEB52.9070300@oracle.com>
	<0A214C25-0DB6-4B5C-AA9C-3142CB9CFA78@oracle.com>
Message-ID: <4E3AFC89.5060902@oracle.com>

Hi Mike.

Mike Duigou wrote:
> Looks good to me. 
>
> I did wonder if we have a policy for tracking fdlibm updates. 

To a first approximation (and even a second approximation), fdlibm 
doesn't have updates any more any hasn't for many years.  The changes in 
in 5.3 were to fix a few bugs I and others had discovered circa 2004. [1]

> The fdlibm people don't seem to ascribe dates to their releases or think to include version numbers in their headers. Are we using 5.3, the apparent latest version? 

Yes, as specified in java.lang.StrictMath, we are using 5.3 which is the 
latest version.  The upstream master copy of FDLIBM is no longer being 
actively maintained so I don't expect any versions after 5.3 any time soon.

> Their release page mentions an outstanding incorrect code generation bug due to non-standards compliant code. Is our usage vulnerable to this bug? Do we have a test to catch this bug should it be encountered?
>   

The JDK makefiles specially compile the FDLIBM sources under lower 
optimization levels to try to avoid such problems.  Over the years, we 
have had our share of C compiler bugs tripping up FDLIBM, which have 
been caught by our testing.  One of my long-term goals is to finish the 
small matter of programming [2] to port FDLIBM from C to Java, which 
would immunize the JDK from this class of problem.

Thanks for the review,

-Joe

[1] http://blogs.oracle.com/darcy/entry/finding_a_bug_in_fdlibm

[2] A piece of the SMOP:
6908131: Pure Java implementations of StrictMath.floor(double) & 
StrictMath.ceil(double)
http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ad1e30930c6c

> Mike
>
> On Aug 4 2011, at 11:56 , Joe Darcy wrote:
>
>   
>> Hello.
>>
>> Please review these straightforward changes for
>>
>>   7075098: Remove unused fdlibm files
>>   http://cr.openjdk.java.net/~darcy/7075098.0/
>>
>> The JDK math libraries in java.lang.{Math, StrictMath} do not expose all the functionality implemented in the embedded copy of FDLIBM (freely distributable math library).  Since we do not plan do expose the remaining functionality (erf, gamma, lgama, j0, j1, jn, acosh, asinh, etc.) and these functions are not needed by the Java core libs directly or by transitivity, this changeset removes the unneeded files from the build.
>>
>> On my Linux build, with this change the size of the compiled fdlibm library file went down from 234,372 to 165,750 and all the math library regression tests pass.
>>
>> Thanks,
>>
>> -Joe
>>     
>
>   



From alexandre.boulgakov at oracle.com  Thu Aug  4 21:00:11 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Thu, 04 Aug 2011 14:00:11 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E3A31C9.8060304@oracle.com>
References: <4E34155E.5090700@oracle.com>	<4E37C117.2030104@oracle.com>	<4E384579.1080209@oracle.com>	<4E38FBDD.8070202@oracle.com>
	<4E397636.5070302@oracle.com> <4E39FCC1.6020308@oracle.com>
	<4E3A0508.6030908@oracle.com> <4E3A150A.9070503@oracle.com>
	<4E3A31C9.8060304@oracle.com>
Message-ID: <4E3B085B.60803@oracle.com>


On 8/3/2011 10:44 PM, Joe Darcy wrote:
> David Holmes wrote:
>> Joe Darcy said the following on 08/04/11 12:33:
>>> David Holmes wrote:
>>>>> Using wildcards makes the subtyping work along the type argument 
>>>>> axis.
>>>>
>>>> So what is the right fix here? To declare the underlying Vector as 
>>>> a Vector<?> and cast it to something concrete when needed? It seems 
>>>> very wrong to me to be inserting raw type casts all through this code.
>>>
>>> It isn't entirely clear to be from a quick inspection of the code 
>>> what the actual type usage is.  A writable general Vector should be 
>>> a Vector<Object> and Vector just meant for reading should be a 
>>> Vector<?> (or the equivalent Vector<? extends Object>).
>>>
>>> If the type usage is "a sequence of X's and Y's" where X and Y don't 
>>> have some useful supertype, I would recommend using a somewhat 
>>> different set of data structures, like a list of type-safe 
>>> heterogeneous containers or a list of a new package-level XorY class.
>>
>> Buried in one of Sasha's emails it says:
>>
>> "The current code uses it to store Strings and Vector<String>s."
>>
>> Hence it is declared Vector<Object>.
>>
>> This is looking to me like code that should not have been generified.
>>
>
> Hmm.  If String or Vector<String> are the two kinds of stored values, 
> I would recommend Vector<Vector<String>> where a lone string was 
> wrapped in a vector.  (Actually, I would recommend a 
> List<List<String>>, but that may be beyond the scope of this cleanup.

I can do Vector<Vector<String>>.

List<List<String>> is probably beyond the scope of removing compiler 
warnings; getting rid of Vectors and Hashtables in general could take a 
whole summer by itself, and would probably be best to do as a whole, 
since it's not always clear at first glance if other classes depend on a 
particular object being a Vector.

-Sasha
>
> -Joe
>


From ahughes at redhat.com  Fri Aug  5 01:46:10 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Fri, 5 Aug 2011 02:46:10 +0100
Subject: JDK 8 code review request for 7075098: Remove unused fdlibm files
In-Reply-To: <4E3AFC89.5060902@oracle.com>
References: <4E3AEB52.9070300@oracle.com>
	<0A214C25-0DB6-4B5C-AA9C-3142CB9CFA78@oracle.com>
	<4E3AFC89.5060902@oracle.com>
Message-ID: <20110805014610.GX31431@rivendell.middle-earth.co.uk>

On 13:09 Thu 04 Aug     , Joe Darcy wrote:
> 
> The JDK makefiles specially compile the FDLIBM sources under lower 
> optimization levels to try to avoid such problems.  Over the years, we 
> have had our share of C compiler bugs tripping up FDLIBM, which have 
> been caught by our testing.  One of my long-term goals is to finish the 
> small matter of programming [2] to port FDLIBM from C to Java, which 
> would immunize the JDK from this class of problem.
> 

FWIW, GNU Classpath used Java versions of the StrictMath methods, though
it's now out of sync with the ones added in 1.6.

> Thanks for the review,
> 
> -Joe
> 
> [1] http://blogs.oracle.com/darcy/entry/finding_a_bug_in_fdlibm
> 
> [2] A piece of the SMOP:
> 6908131: Pure Java implementations of StrictMath.floor(double) & 
> StrictMath.ceil(double)
> http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ad1e30930c6c
> 

-- 
Andrew :)

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

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From aph at redhat.com  Fri Aug  5 09:41:50 2011
From: aph at redhat.com (Andrew Haley)
Date: Fri, 05 Aug 2011 10:41:50 +0100
Subject: JDK 8 code review request for 7075098: Remove unused fdlibm files
In-Reply-To: <4E3AFC89.5060902@oracle.com>
References: <4E3AEB52.9070300@oracle.com>	<0A214C25-0DB6-4B5C-AA9C-3142CB9CFA78@oracle.com>
	<4E3AFC89.5060902@oracle.com>
Message-ID: <4E3BBADE.5040007@redhat.com>

On 08/04/2011 09:09 PM, Joe Darcy wrote:

> Mike Duigou wrote:
>> Looks good to me. 
>>
>> I did wonder if we have a policy for tracking fdlibm updates. 
> 
> To a first approximation (and even a second approximation), fdlibm 
> doesn't have updates any more any hasn't for many years.  The changes in 
> in 5.3 were to fix a few bugs I and others had discovered circa 2004. [1]

That's right.  We used fdlibm in libgcj too, and it is very solid and reliable
code.  The only problems we ever had were some non-portable assumptions that
were fairly easy to fix.  Maybe fdlibm will never now be updated.

Andrew.


From sebastian.sickelmann at gmx.de  Fri Aug  5 11:18:35 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 05 Aug 2011 13:18:35 +0200
Subject: =?US-ASCII?Q?Re=3A_=5BFwd=3A_Code_review_request=3A_7072353_JNDI_libr?=
	=?US-ASCII?Q?aries_do_not_build=09with_javac_-Xlint=3Aall_-Werror=5D?=
In-Reply-To: <CAPmOpX5VGB_7+dLQf22s5n7vw6mmVw8Gq9_87V29hAzigJJLeg@mail.gmail.com>
References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com>
	<4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com>
	<4E398D71.9030302@oracle.com> <1312405776.14748.25.camel@chalkhill>
	<4E39BA2E.9050405@oracle.com>
	<CAPmOpX5VGB_7+dLQf22s5n7vw6mmVw8Gq9_87V29hAzigJJLeg@mail.gmail.com>
Message-ID: <ca79f0e6-f90a-4a9f-bfbe-d1b4382c1eaa@email.android.com>

I like that idea. Should we open another discussion thread?


Colin Decker <cgdecker at gmail.com> schrieb:

>One better way to handle this in Java 8 would be to have a utility method
>that takes a Supplier<Enumeration<E>> SAM argument (with a no-arg method
>that returns an Enumeration<E>) and returns an Iterable<E> that gets a new
>Enumeration from the supplier each time iterator() is called. It could then
>be used with method references:
>
>Iterable<E> iterable = Util.enumerationIterable(#object.getEnumeration);
>
>-- 
>Colin
>
>
>On Wed, Aug 3, 2011 at 5:14 PM, Alexandre Boulgakov <
>alexandre.boulgakov at oracle.com> wrote:
>
>> Users of Iterable expect to call Iterable.iterator() multiple times,
>> receiving a fresh iterator pointing to the beginning of the Iterable each
>> time. This would not be possible to do with an Enumeration wrapper since
>> Enumerations are read-once.
>>
>> I don't know if this is a strong enough reason not to include such a
>> utility class, but it could certainly be confusing.
>>
>> -Sasha
>>
>>
>> On 8/3/2011 2:09 PM, Neil Richards wrote:
>>
>>> On Wed, 2011-08-03 at 11:03 -0700, Alexandre Boulgakov wrote:
>>>
>>>> Please see my responses inline.
>>>>
>>>> Thanks!
>>>> -Sasha
>>>>
>>>> On 8/2/2011 9:13 PM, Xuelei Fan wrote:
>>>>
>>>>> . com/sun/jndi/toolkit/dir/**SearchFilter.java
>>>>>   451         for (NamingEnumeration<?>   ve = attr.getAll();
>>>>>   452              ve.hasMore();
>>>>>   453                ) {
>>>>>
>>>>> The update is OK. But the coding style looks uncomfortable. Would you
>>>>> mind change it to use for-each style?
>>>>>
>>>> For-each only works with Iterables. There doesn't seem to be a way to
>>>> get an Iterable out of an Attribute instance, so the only way to use a
>>>> for-each here would be to wrap the Enumeration in an ArrayList using
>>>> Collections.list(). While this might look neater, the contents of the
>>>> Enumeration would have to be copied over, using time and increasing the
>>>> memory footprint. Changing Attribute to implement Iterable would require
>>>> a spec change, and would be beyond the scope of this fix.
>>>>
>>> Would it  be useful to have a utility object to convert an Enumeration
>>> so it can be used in for-each constructs? - something like:
>>> ----
>>>         import java.util.Enumeration;
>>>         import java.util.Iterator;
>>>
>>>         /**
>>>          * Utility class to transform an Enumeration object such that it
>>> can be used in
>>>          * the for-each construct.
>>>          */
>>>         public class IterableEnumerationHolder<E>  implements Iterable<E>,
>>> Iterator<E>  {
>>>             private final Enumeration<E>  e;
>>>
>>>             public IterableEnumerationHolder(**final Enumeration<E>  e) {
>>>                 this.e = e;
>>>             }
>>>
>>>             @Override
>>>             public Iterator<E>  iterator() {
>>>                 return this;
>>>             }
>>>
>>>             @Override
>>>             public boolean hasNext() {
>>>                 return e.hasMoreElements();
>>>             }
>>>
>>>             @Override
>>>             public E next() {
>>>                 return e.nextElement();
>>>             }
>>>
>>>             @Override
>>>             public void remove() {
>>>                 throw new UnsupportedOperationException(**);
>>>             }
>>>         }
>>> ----
>>>
>>> If it would, perhaps it might be considered for Java 8?
>>>
>>> Regards,
>>> Neil
>>>
>>>

-- 
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.


From weijun.wang at oracle.com  Fri Aug  5 14:19:35 2011
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 05 Aug 2011 22:19:35 +0800
Subject: Help: ContextClassLoader in jtreg tests
Message-ID: <4E3BFBF7.2050909@oracle.com>

I have two files: A.java and B.java

/*
  * @test
  * @build A B
  * @run main A
  */
public class A {
     public static void main(String[] args) throws Exception {
         Class.forName("B", true, 
Thread.currentThread().getContextClassLoader());
     }
}

public class B {
}

Now jtreg A.java shows:

    java.lang.ClassNotFoundException: B

How can I get B visible in A's ContextClassLoader?

Don't tell me to change to Class.forName("B"), that line is copied from 
JDK that is called by a real test.

Or, the JDK code itself is problematic and it should fallback to another 
ClassLoader?

Thanks
Max


From christos at zoulas.com  Fri Aug  5 14:52:56 2011
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 5 Aug 2011 10:52:56 -0400
Subject: JDK 8 code review request for 7075098: Remove unused fdlibm files
In-Reply-To: <4E3BBADE.5040007@redhat.com> from Andrew Haley (Aug  5, 10:41am)
Message-ID: <20110805145256.A60AA97118@rebar.astron.com>

On Aug 5, 10:41am, aph at redhat.com (Andrew Haley) wrote:
-- Subject: Re: JDK 8 code review request for 7075098: Remove unused fdlibm f

| On 08/04/2011 09:09 PM, Joe Darcy wrote:
| 
| > Mike Duigou wrote:
| >> Looks good to me. 
| >>
| >> I did wonder if we have a policy for tracking fdlibm updates. 
| > 
| > To a first approximation (and even a second approximation), fdlibm 
| > doesn't have updates any more any hasn't for many years.  The changes in 
| > in 5.3 were to fix a few bugs I and others had discovered circa 2004. [1]
| 
| That's right.  We used fdlibm in libgcj too, and it is very solid and reliable
| code.  The only problems we ever had were some non-portable assumptions that
| were fairly easy to fix.  Maybe fdlibm will never now be updated.

We are using fdlibm too on NetBSD (FreeBSD uses it too) and we had to fix a
couple of bugs and add long double support. Perhaps we should all send our
changes back and get a new release, or if they don't want to maintain it,
we should maintain it centrally?

christos


From alexandre.boulgakov at oracle.com  Fri Aug  5 18:11:34 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Fri, 05 Aug 2011 11:11:34 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E3B085B.60803@oracle.com>
References: <4E34155E.5090700@oracle.com>	<4E37C117.2030104@oracle.com>	<4E384579.1080209@oracle.com>	<4E38FBDD.8070202@oracle.com>
	<4E397636.5070302@oracle.com> <4E39FCC1.6020308@oracle.com>
	<4E3A0508.6030908@oracle.com> <4E3A150A.9070503@oracle.com>
	<4E3A31C9.8060304@oracle.com> <4E3B085B.60803@oracle.com>
Message-ID: <4E3C3256.5080700@oracle.com>

Here's the second version:
http://cr.openjdk.java.net/~mduigou/7072353/2/webrev/ 
<http://cr.openjdk.java.net/%7Emduigou/7072353/2/webrev/>

  * Changed LdapResult.referrals to be a Vector<Vector<String>>;
  * Refactored
      o com/sun/jndi/dns/DnsContext.java: BaseNameClassPairEnumeration<T>;
      o com/sun/jndi/toolkit/dir/HierMemDirCtx.java: BaseFlatNames<T>;
      o com/sun/jndi/ldap/*.java: refactored LdapNamingEnumeration into
        AbstractLdapNamingEnumeration, LdapNameClassPairEnumeration;
        changed LdapBindingEnumeration and LdapSearchEnumeration
        accordingly, as well as a few of their consumers;
  * Made a few additional small changes that were discussed.

Thanks to everyone who reviewed the last version!

Thanks,
Sasha

On 8/4/2011 2:00 PM, Alexandre Boulgakov wrote:
>
> On 8/3/2011 10:44 PM, Joe Darcy wrote:
>> David Holmes wrote:
>>> Joe Darcy said the following on 08/04/11 12:33:
>>>> David Holmes wrote:
>>>>>> Using wildcards makes the subtyping work along the type argument 
>>>>>> axis.
>>>>>
>>>>> So what is the right fix here? To declare the underlying Vector as 
>>>>> a Vector<?> and cast it to something concrete when needed? It 
>>>>> seems very wrong to me to be inserting raw type casts all through 
>>>>> this code.
>>>>
>>>> It isn't entirely clear to be from a quick inspection of the code 
>>>> what the actual type usage is.  A writable general Vector should be 
>>>> a Vector<Object> and Vector just meant for reading should be a 
>>>> Vector<?> (or the equivalent Vector<? extends Object>).
>>>>
>>>> If the type usage is "a sequence of X's and Y's" where X and Y 
>>>> don't have some useful supertype, I would recommend using a 
>>>> somewhat different set of data structures, like a list of type-safe 
>>>> heterogeneous containers or a list of a new package-level XorY class.
>>>
>>> Buried in one of Sasha's emails it says:
>>>
>>> "The current code uses it to store Strings and Vector<String>s."
>>>
>>> Hence it is declared Vector<Object>.
>>>
>>> This is looking to me like code that should not have been generified.
>>>
>>
>> Hmm.  If String or Vector<String> are the two kinds of stored values, 
>> I would recommend Vector<Vector<String>> where a lone string was 
>> wrapped in a vector.  (Actually, I would recommend a 
>> List<List<String>>, but that may be beyond the scope of this cleanup.
>
> I can do Vector<Vector<String>>.
>
> List<List<String>> is probably beyond the scope of removing compiler 
> warnings; getting rid of Vectors and Hashtables in general could take 
> a whole summer by itself, and would probably be best to do as a whole, 
> since it's not always clear at first glance if other classes depend on 
> a particular object being a Vector.
>
> -Sasha
>>
>> -Joe
>>


From jonathan.gibbons at oracle.com  Fri Aug  5 22:58:29 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 05 Aug 2011 22:58:29 +0000
Subject: hg: jdk8/tl/langtools: 7074189: some javac tests fail with latest
	jtreg 4.1 b03
Message-ID: <20110805225832.1F8B547984@hg.openjdk.java.net>

Changeset: c0d5f93af048
Author:    jjg
Date:      2011-08-05 15:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c0d5f93af048

7074189: some javac tests fail with latest jtreg 4.1 b03
Reviewed-by: darcy

+ test/tools/javac/lib/CompileFail.java
! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java
! test/tools/javac/processing/errors/TestReturnCode.java
! test/tools/javac/warnings/Serial.java



From kumar.x.srinivasan at oracle.com  Sat Aug  6 21:18:55 2011
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Sat, 06 Aug 2011 21:18:55 +0000
Subject: hg: jdk8/tl/langtools: 7064544: (javadoc) miscellaneous fixes
	requested by netbeans
Message-ID: <20110806211858.32160479B5@hg.openjdk.java.net>

Changeset: e9f118c2bd3c
Author:    ksrini
Date:      2011-08-05 19:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e9f118c2bd3c

7064544: (javadoc) miscellaneous fixes requested by netbeans
Summary: Contributed by netbeans team, modified to suit by the langtools team.
Reviewed-by: jjg, bpatel

! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/Comment.java
! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java
! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java
! test/com/sun/javadoc/testLinkTaglet/pkg/C.java



From joe.darcy at oracle.com  Sat Aug  6 21:37:19 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Sat, 06 Aug 2011 21:37:19 +0000
Subject: hg: jdk8/tl/jdk: 7075098: Remove unused fdlibm files
Message-ID: <20110806213742.31439479B6@hg.openjdk.java.net>

Changeset: b9fffbe98230
Author:    darcy
Date:      2011-08-06 14:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b9fffbe98230

7075098: Remove unused fdlibm files
Reviewed-by: alanb, mduigou

! make/java/fdlibm/FILES_c.gmk
! src/share/native/java/lang/fdlibm/include/fdlibm.h
! src/share/native/java/lang/fdlibm/include/jfdlibm.h
- src/share/native/java/lang/fdlibm/src/e_acosh.c
- src/share/native/java/lang/fdlibm/src/e_gamma.c
- src/share/native/java/lang/fdlibm/src/e_gamma_r.c
- src/share/native/java/lang/fdlibm/src/e_j0.c
- src/share/native/java/lang/fdlibm/src/e_j1.c
- src/share/native/java/lang/fdlibm/src/e_jn.c
- src/share/native/java/lang/fdlibm/src/e_lgamma.c
- src/share/native/java/lang/fdlibm/src/e_lgamma_r.c
- src/share/native/java/lang/fdlibm/src/s_asinh.c
- src/share/native/java/lang/fdlibm/src/s_erf.c
- src/share/native/java/lang/fdlibm/src/w_acosh.c
- src/share/native/java/lang/fdlibm/src/w_gamma.c
- src/share/native/java/lang/fdlibm/src/w_gamma_r.c
- src/share/native/java/lang/fdlibm/src/w_j0.c
- src/share/native/java/lang/fdlibm/src/w_j1.c
- src/share/native/java/lang/fdlibm/src/w_jn.c
- src/share/native/java/lang/fdlibm/src/w_lgamma.c
- src/share/native/java/lang/fdlibm/src/w_lgamma_r.c



From lana.steuck at oracle.com  Mon Aug  8 00:20:34 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 08 Aug 2011 00:20:34 +0000
Subject: hg: jdk8/tl/jdk: 27 new changesets
Message-ID: <20110808002500.E045C479F3@hg.openjdk.java.net>

Changeset: 6444b0a364d7
Author:    jrose
Date:      2011-06-14 22:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6444b0a364d7

7054590: (JSR-292) MethodHandleProxies.asInterfaceInstance() accepts private/protected nested interfaces
Summary: fix non-compliant logic in MethodHandleProxies, fix invalid private classes in MethodHandlesTest
Reviewed-by: twisti, never

! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! test/java/lang/invoke/MethodHandlesTest.java

Changeset: 5f3cd0cbad56
Author:    jrose
Date:      2011-07-13 01:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f3cd0cbad56

Merge

- src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java

Changeset: bfc5ec581c48
Author:    jrose
Date:      2011-07-16 15:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfc5ec581c48

7058630: JSR 292 method handle proxy violates contract for Object methods
Reviewed-by: never, twisti

! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! test/java/lang/invoke/MethodHandlesTest.java

Changeset: 668edf27e9c7
Author:    jrose
Date:      2011-07-16 15:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/668edf27e9c7

7058651: JSR 292 unit tests need a refresh
Summary: Enhancements to unit tests.
Reviewed-by: never, twisti

! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodHandlesTest.java
! test/java/lang/invoke/RicochetTest.java
+ test/java/lang/invoke/ThrowExceptionsTest.java

Changeset: b42029cd1744
Author:    jrose
Date:      2011-07-16 15:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b42029cd1744

6983728: JSR 292 remove argument count limitations
Summary: Remove workarounds and limitations from before 6939861.
Reviewed-by: never

! src/share/classes/java/lang/invoke/AdapterMethodHandle.java
- src/share/classes/java/lang/invoke/FilterGeneric.java
- src/share/classes/java/lang/invoke/FilterOneArgument.java
- src/share/classes/java/lang/invoke/FromGeneric.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/lang/invoke/MethodTypeForm.java
- src/share/classes/java/lang/invoke/SpreadGeneric.java
- src/share/classes/java/lang/invoke/ToGeneric.java

Changeset: 74598b748a57
Author:    lana
Date:      2011-07-01 12:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74598b748a57

Merge


Changeset: 0a00216a858c
Author:    lana
Date:      2011-07-07 19:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a00216a858c

Merge

- src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java

Changeset: 77d5cc943286
Author:    prr
Date:      2011-07-19 14:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77d5cc943286

7068471: NPE in sun.font.FontConfigManager.getFontConfigFont() when libfontconfig.so is not installed
Reviewed-by: jgodinez, prr
Contributed-by: spoole at linux.vnet.ibm.com

! src/solaris/classes/sun/font/FontConfigManager.java

Changeset: ae05aa9ede7b
Author:    bae
Date:      2011-07-20 16:18 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae05aa9ede7b

7044285: 64 bit VM crashes in Java_sun_java2d_loops_MaskFill_MaskFill
Reviewed-by: jgodinez, prr

! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h

Changeset: 40d0dea5d0fc
Author:    neugens
Date:      2011-07-26 21:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40d0dea5d0fc

7070155: A small refactoring patch for the abstract RenderingEngine.
Summary: Simplify code by using ReflectiveOperationException instead of 3 ignored catch blocks
Reviewed-by: prr

! src/share/classes/sun/java2d/pipe/RenderingEngine.java

Changeset: 0795f0dacfec
Author:    bagiras
Date:      2011-07-11 15:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0795f0dacfec

7050935: closed/java/awt/Choice/WheelEventsConsumed/WheelEventsConsumed.html fails on win32
Reviewed-by: art, dcherepanov

! src/windows/native/sun/windows/awt_Choice.cpp
! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Toolkit.cpp
+ test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java

Changeset: acea32663757
Author:    peytoia
Date:      2011-07-12 08:00 +0900
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acea32663757

7042148: closed/java/awt/font/TextLayout/CheckLayoutLTR.java failed
Reviewed-by: okutsu

! src/share/classes/sun/text/bidi/BidiBase.java
+ test/java/text/Bidi/Bug7042148.java

Changeset: 75ee78eb7322
Author:    peytoia
Date:      2011-07-12 08:46 +0900
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75ee78eb7322

7051769: java.text.Bidi.toString() output is wrong
Reviewed-by: okutsu

! src/share/classes/sun/text/bidi/BidiBase.java
+ test/java/text/Bidi/Bug7051769.java

Changeset: 6bc0e1709d97
Author:    lana
Date:      2011-07-11 16:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6bc0e1709d97

Merge


Changeset: cce5659427bb
Author:    rupashka
Date:      2011-07-12 11:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cce5659427bb

7019963: The goto parent directory button doesn't operate in JFileChooser
Reviewed-by: alexp

! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java

Changeset: 5c22624d193e
Author:    rupashka
Date:      2011-07-15 14:43 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c22624d193e

4909150: WindowsTreeUI can cause NullPointerException occasionally
Reviewed-by: alexp

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java

Changeset: 6ee24f03760d
Author:    serb
Date:      2011-07-15 19:18 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ee24f03760d

7043679: Wrong class name is used in Java_sun_awt_windows_WPrinterJob_initIDs
Reviewed-by: dav, art

! src/windows/native/sun/windows/awt_PrintJob.cpp

Changeset: c90a43ebf8fd
Author:    serb
Date:      2011-07-15 19:19 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c90a43ebf8fd

7043815: AWT-XAWT - AWT-EventQueue-0 deadlock.
Reviewed-by: art, dcherepanov

! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java

Changeset: 252f71b26b23
Author:    serb
Date:      2011-07-15 19:23 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/252f71b26b23

6596915: JCK-runtime-6a/tests/api/java_awt/Component/index.html tesPaintAll fails
Reviewed-by: art, dcherepanov, anthony

! src/solaris/classes/sun/awt/X11/XButtonPeer.java
! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java
! src/solaris/classes/sun/awt/X11/XChoicePeer.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XLabelPeer.java
! src/solaris/classes/sun/awt/X11/XListPeer.java
! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java
! src/solaris/classes/sun/awt/X11/XMenuWindow.java
! src/solaris/classes/sun/awt/X11/XPanelPeer.java
! src/solaris/classes/sun/awt/X11/XRepaintArea.java
! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java
! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java
! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java
! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java
! src/solaris/classes/sun/awt/X11/XWarningWindow.java
! src/solaris/classes/sun/awt/X11/XWindow.java
+ test/java/awt/Component/PaintAll/PaintAll.java

Changeset: 3ed58dbad819
Author:    serb
Date:      2011-07-15 19:24 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ed58dbad819

6642728: Use reflection to access ScrollPane's private method from within sun.awt package
Reviewed-by: art, anthony

! src/share/classes/java/awt/ScrollPaneAdjustable.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java
! src/windows/classes/sun/awt/windows/WScrollPanePeer.java
! src/windows/native/sun/windows/awt_ScrollPane.cpp

Changeset: 9c642ae9a543
Author:    serb
Date:      2011-07-15 19:25 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c642ae9a543

4717864: setFont() does not update Fonts of Menus already on screen
Reviewed-by: art, bagiras

! src/windows/classes/sun/awt/windows/WMenuItemPeer.java
! src/windows/native/sun/windows/awt_Menu.cpp
! src/windows/native/sun/windows/awt_Menu.h
! src/windows/native/sun/windows/awt_MenuBar.cpp
! src/windows/native/sun/windows/awt_MenuBar.h
! src/windows/native/sun/windows/awt_MenuItem.cpp
! src/windows/native/sun/windows/awt_MenuItem.h

Changeset: 3ac81907aa7d
Author:    rupashka
Date:      2011-07-18 17:40 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ac81907aa7d

6509273: Password in JPasswordField gets Printed in clear text
Reviewed-by: alexp

! src/share/classes/sun/swing/text/TextComponentPrintable.java

Changeset: c05b36e4749e
Author:    rupashka
Date:      2011-07-18 18:21 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c05b36e4749e

7031941: Use generificated JComboBox and JList in core libraries
Reviewed-by: alexp

! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java
! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java
! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java
! src/share/classes/javax/swing/text/html/FormView.java
! src/share/classes/javax/swing/text/html/HTMLDocument.java
! src/share/classes/javax/swing/text/html/HTMLWriter.java
! src/share/classes/javax/swing/text/html/OptionComboBoxModel.java
! src/share/classes/javax/swing/text/html/OptionListModel.java
! src/share/classes/sun/swing/FilePane.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java

Changeset: 190b11164876
Author:    lana
Date:      2011-07-27 22:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/190b11164876

Merge


Changeset: 996547848b00
Author:    lana
Date:      2011-08-01 17:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/996547848b00

Merge


Changeset: 3f3a59423a7e
Author:    lana
Date:      2011-08-05 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f3a59423a7e

Merge

- src/share/classes/java/lang/invoke/FilterGeneric.java
- src/share/classes/java/lang/invoke/FilterOneArgument.java
- src/share/classes/java/lang/invoke/FromGeneric.java
- src/share/classes/java/lang/invoke/SpreadGeneric.java
- src/share/classes/java/lang/invoke/ToGeneric.java

Changeset: a5f825ef8587
Author:    lana
Date:      2011-08-07 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5f825ef8587

Merge

- src/share/native/java/lang/fdlibm/src/e_acosh.c
- src/share/native/java/lang/fdlibm/src/e_gamma.c
- src/share/native/java/lang/fdlibm/src/e_gamma_r.c
- src/share/native/java/lang/fdlibm/src/e_j0.c
- src/share/native/java/lang/fdlibm/src/e_j1.c
- src/share/native/java/lang/fdlibm/src/e_jn.c
- src/share/native/java/lang/fdlibm/src/e_lgamma.c
- src/share/native/java/lang/fdlibm/src/e_lgamma_r.c
- src/share/native/java/lang/fdlibm/src/s_asinh.c
- src/share/native/java/lang/fdlibm/src/s_erf.c
- src/share/native/java/lang/fdlibm/src/w_acosh.c
- src/share/native/java/lang/fdlibm/src/w_gamma.c
- src/share/native/java/lang/fdlibm/src/w_gamma_r.c
- src/share/native/java/lang/fdlibm/src/w_j0.c
- src/share/native/java/lang/fdlibm/src/w_j1.c
- src/share/native/java/lang/fdlibm/src/w_jn.c
- src/share/native/java/lang/fdlibm/src/w_lgamma.c
- src/share/native/java/lang/fdlibm/src/w_lgamma_r.c



From lana.steuck at oracle.com  Mon Aug  8 00:19:35 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 08 Aug 2011 00:19:35 +0000
Subject: hg: jdk8/tl/hotspot: 82 new changesets
Message-ID: <20110808002207.D3432479F1@hg.openjdk.java.net>

Changeset: 2b27ef5c2173
Author:    kvn
Date:      2011-05-20 12:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b27ef5c2173

7046096: SEGV IN C2 WITH 6U25
Summary: Missing fail flag set in strings concatenation code.
Reviewed-by: never

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

Changeset: cfbca4d74a61
Author:    jcoomes
Date:      2011-05-20 22:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cfbca4d74a61

Merge


Changeset: 789d04408ca3
Author:    kvn
Date:      2011-05-21 11:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/789d04408ca3

7045693: java/util/EnumSet/EnumSetBash.java still failing intermittently
Summary: New limit for unrolled loop should be set only for zero trip guard and loop iteration test.
Reviewed-by: never

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

Changeset: b55f5bd7ec66
Author:    kvn
Date:      2011-05-21 13:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b55f5bd7ec66

7045506: assert(!can_reshape || !new_phi) failed: for igvn new phi should be hooked
Summary: Replace the assert in PhiNode::Ideal with check to avoid transformation of new phi.
Reviewed-by: never

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

Changeset: 7523488edce5
Author:    kvn
Date:      2011-05-24 12:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7523488edce5

7047300: VM crashes with assert(_base == InstPtr) failed: Not an object pointer
Summary: The code incorrectly used is_instptr() instead of is_oopptr() to get const_oop.
Reviewed-by: never

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

Changeset: ccf072cdba91
Author:    iveresov
Date:      2011-05-24 15:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ccf072cdba91

7046893: LP64 problem with double_quadword in c1_LIRAssembler_x86.cpp
Summary: Fixed invalid casts in address computation
Reviewed-by: kvn, never
Contributed-by: thomas.salter at unisys.com

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

Changeset: 28a9fe9534ea
Author:    kvn
Date:      2011-05-24 20:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28a9fe9534ea

7048030: is_scavengable changes causing compiler to embed more constants
Summary: ciObject::can_be_constant() and should_be_constant() should use is_perm() instead of !is_scavengable()
Reviewed-by: never, jrose

! src/share/vm/ci/ciObject.cpp
! src/share/vm/ci/ciObject.hpp

Changeset: 7db2b9499c36
Author:    never
Date:      2011-05-25 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7db2b9499c36

7046732: JSR 292 assert(result == cpce->f1()) failed: expected result for assembly code
Reviewed-by: kvn, iveresov, jrose

! src/share/vm/interpreter/interpreterRuntime.cpp

Changeset: c7c81f18c834
Author:    kvn
Date:      2011-05-25 21:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c7c81f18c834

7048332: Cadd_cmpLTMask doesn't handle 64-bit tmp register properly
Summary: Use ins_encode %{ %} form to encode cadd_cmpLTMask() instruction and remove unused code.
Reviewed-by: never

! src/cpu/x86/vm/x86_64.ad
+ test/compiler/7048332/Test7048332.java

Changeset: 28263a73ebfb
Author:    iveresov
Date:      2011-05-26 13:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28263a73ebfb

7047491: C1: registers saved incorrectly when calling checkcast_arraycopy stub
Summary: Save and restore the argument registers around the call to checkcast_arraycopy
Reviewed-by: never, roland

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

Changeset: 5ac411b3b8fc
Author:    never
Date:      2011-05-26 14:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ac411b3b8fc

7047961: JSR 292 MethodHandleWalk swap args doesn't handle T_LONG and T_DOUBLE properly
Reviewed-by: kvn, jrose

! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/prims/methodHandles.cpp

Changeset: c76c13577460
Author:    never
Date:      2011-05-26 16:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c76c13577460

Merge


Changeset: b2cb497dec28
Author:    kvn
Date:      2011-05-27 12:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2cb497dec28

7047069: Array can dynamically change size when assigned to an object field
Summary: Fix initialization of a newly-allocated array with arraycopy
Reviewed-by: never

! src/share/vm/opto/library_call.cpp
+ test/compiler/7047069/Test7047069.java

Changeset: 33e2b8f1d466
Author:    kvn
Date:      2011-05-31 10:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/33e2b8f1d466

6956668: misbehavior of XOR operator (^) with int
Summary: optimize cmp_ne(xor(X,1),0) to cmp_eq(X,0) only for boolean values X.
Reviewed-by: never

! src/share/vm/opto/subnode.cpp
+ test/compiler/6956668/Test6956668.java

Changeset: 60b8287df30e
Author:    jrose
Date:      2011-06-01 23:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/60b8287df30e

7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError
Summary: Delegate invokedynamic linkage errors to MethodHandleNatives.raiseException.
Reviewed-by: never

! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp

Changeset: a93146d0e4be
Author:    jrose
Date:      2011-06-01 23:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a93146d0e4be

7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM
Summary: change the default setting of the flag AllowInvokeGeneric to false
Reviewed-by: never

! src/share/vm/runtime/globals.hpp

Changeset: 537a4053b0f9
Author:    ysr
Date:      2011-05-23 16:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/537a4053b0f9

7042740: CMS: assert(n> q) failed: Looping at: ... blockOffsetTable.cpp:557
Summary: Do a one-step look-ahead, when sweeping free or garbage blocks, to avoid overstepping sweep limit, which may become a non-block-boundary because of a heap expansion delta coalescing with a previously co-terminal free block.
Reviewed-by: brutisso, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/blockOffsetTable.cpp

Changeset: f153114134c8
Author:    jcoomes
Date:      2011-06-07 13:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f153114134c8

Merge


Changeset: d3b9f2be46ab
Author:    coleenp
Date:      2011-05-21 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d3b9f2be46ab

7033141: assert(has_cp_cache(i)) failed: oob
Summary: Unrewrite bytecodes for OOM error allocating the constant pool cache.
Reviewed-by: dcubed, acorn, never

! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/methodHandleWalk.cpp

Changeset: 9dd6c4ba364f
Author:    coleenp
Date:      2011-06-02 14:17 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9dd6c4ba364f

7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63
Summary: Removed extra change from another bug fix that caused this regression
Reviewed-by: phh, dcubed, kvn, kamg, never

! src/share/vm/oops/methodOop.cpp

Changeset: 96c891ebe56a
Author:    coleenp
Date:      2011-06-02 21:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/96c891ebe56a

Merge

! src/share/vm/prims/methodHandleWalk.cpp

Changeset: ae1d716e395c
Author:    dsamersoff
Date:      2011-06-09 01:33 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae1d716e395c

Merge


Changeset: f918d6096e23
Author:    never
Date:      2011-06-02 13:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f918d6096e23

7050554: JSR 292 - need optimization for selectAlternative
Reviewed-by: kvn, jrose

! src/share/vm/ci/ciCallProfile.hpp
! src/share/vm/ci/ciMethodHandle.cpp
! src/share/vm/ci/ciMethodHandle.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/doCall.cpp

Changeset: cba7b5c2d53f
Author:    never
Date:      2011-06-03 22:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cba7b5c2d53f

7045514: SPARC assembly code for JSR 292 ricochet frames
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
+ src/cpu/sparc/vm/methodHandles_sparc.hpp
! src/cpu/sparc/vm/registerMap_sparc.hpp
! src/cpu/sparc/vm/runtime_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/stubRoutines_sparc.hpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.hpp
! src/cpu/x86/vm/runtime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: 642c68c75db9
Author:    kvn
Date:      2011-06-04 10:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/642c68c75db9

7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity
Summary: Mark all associated (same box and obj) lock and unlock nodes for elimination if some of them marked already.
Reviewed-by: iveresov, never

! src/share/vm/opto/escape.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/macro.hpp

Changeset: 5cf771a79037
Author:    jrose
Date:      2011-06-08 17:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5cf771a79037

7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp
Reviewed-by: never, twisti

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/share/vm/code/pcDesc.cpp

Changeset: c8f2186acf6d
Author:    twisti
Date:      2011-06-14 12:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8f2186acf6d

7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops
Reviewed-by: iveresov, never

! src/share/vm/c1/c1_LIRGenerator.cpp

Changeset: f8c9417e3571
Author:    never
Date:      2011-06-14 14:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f8c9417e3571

7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters
Reviewed-by: twisti, kvn, jrose

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/stubCodeGenerator.cpp
! src/share/vm/runtime/stubCodeGenerator.hpp

Changeset: e2ce15aa3daf
Author:    never
Date:      2011-06-14 15:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2ce15aa3daf

Merge


Changeset: cfcf2ba8f3eb
Author:    never
Date:      2011-06-15 10:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cfcf2ba8f3eb

Merge

! src/share/vm/prims/methodHandleWalk.cpp

Changeset: e2af886d540b
Author:    trims
Date:      2011-07-01 13:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2af886d540b

7061691: Fork HS21 to HS22 - renumber Minor and build numbers of JVM
Summary: Update the Minor and Build numbers for HS22 fork
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1e3493ac2d11
Author:    ysr
Date:      2011-05-27 10:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e3493ac2d11

7048342: CMS: eob == _limit || fc->isFree() failed: Only a free chunk should allow us to cross over the limit
Summary: The freeness bit was being cleared in debug code when it shouldn't have been. Also removed unused FreeChunk methods linkAfterNonNull and clearPrev.
Reviewed-by: brutisso

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp

Changeset: 5c0a3c1858b1
Author:    ysr
Date:      2011-06-02 10:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c0a3c1858b1

7048782: CMS: assert(last_chunk_index_to_check<= last_chunk_index) failed: parCardTableModRefBS.cpp:359
Summary: The LNC array is sized before the start of a scavenge, while the heap may expand during a scavenge. With CMS, the last block of an arbitrary suffice of the LNC array may expand due to coalition with the expansion delta. We now take care not to attempt access past the end of the LNC array. LNC array code will be cleaned up and suitably encapsulated as part of the forthcoming performance RFE 7043675.
Reviewed-by: brutisso

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

Changeset: e66f38dd58a9
Author:    ysr
Date:      2011-06-08 08:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e66f38dd58a9

Merge


Changeset: 053d84a76d3d
Author:    tonyp
Date:      2011-06-08 15:31 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/053d84a76d3d

7032531: G1: enhance GC logging to include more accurate eden / survivor size transitions
Summary: This changeset extends the logging information generated by +PrintGCDetails to also print out separate size transitions for the eden, survivors, and old regions.
Reviewed-by: ysr, brutisso

! 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

Changeset: ae5b2f1dcf12
Author:    tonyp
Date:      2011-06-08 21:48 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae5b2f1dcf12

7045662: G1: OopsInHeapRegionClosure::set_region() should not be virtual
Summary: make the method non-virtual, remove five unused closures, and fix a couple of copyright typos.
Reviewed-by: stefank, johnc, poonam

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1OopClosures.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp
! src/share/vm/gc_implementation/g1/heapRegionSet.hpp
! src/share/vm/gc_implementation/g1/heapRegionSets.hpp

Changeset: c3f1170908be
Author:    tonyp
Date:      2011-06-10 13:16 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3f1170908be

7045330: G1: Simplify/fix the HeapRegionSeq class
7042285: G1: native memory leak during humongous object allocation
6804436: G1: heap region indices should be size_t
Summary: A series of fixes and improvements to the HeapRegionSeq class: a) replace the _regions growable array with a standard C array, b) avoid de-allocating / re-allocating HeapRegion instances when the heap shrinks / grows (fix for 7042285), c) introduce fast method to map address to HeapRegion via a "biased" array pointer, d) embed the _hrs object in G1CollectedHeap, instead of pointing to it via an indirection, e) assume that all the regions added to the HeapRegionSeq instance are contiguous, f) replace int's with size_t's for indexes (and expand that to HeapRegion as part of 6804436), g) remove unnecessary / unused methods, h) rename a couple of fields (_alloc_search_start and _seq_bottom), i) fix iterate_from() not to always start from index 0 irrespective of the region passed to it, j) add a verification method to check the HeapRegionSeq assumptions, k) always call the wrappers for _hrs.iterate(), _hrs_length(), and _hrs.at() from G1CollectedHeap, not those methods di
 rectly, and l) unify the code that expands the sequence (by either re-using or creating a new HeapRegion) and make it robust wrt to a HeapRegion allocation failing.
Reviewed-by: stefank, johnc, brutisso

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp

Changeset: 2a241e764894
Author:    minqi
Date:      2011-06-10 15:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2a241e764894

6941923: RFE: Handling large log files produced by long running Java Applications
Summary: supply optinal flags to realize gc log rotation
Reviewed-by: ysr, jwilhelm

! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp
! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/atomic.cpp
! src/share/vm/runtime/atomic.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/ostream.hpp
+ test/gc/6941923/test6941923.sh

Changeset: 42df21744b50
Author:    minqi
Date:      2011-06-10 15:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42df21744b50

Merge


Changeset: ef2d1b8f2dd4
Author:    ysr
Date:      2011-06-13 09:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef2d1b8f2dd4

7051430: CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit
Summary: It turns out that there is no need to explicitly stop CMS since the JVM is taken down at a terminal safepoint during which CMS threads are (terminally) inactive. This  will need to be revised if and when we evolve in the future to a point where we allow JVM reincarnation in the same process, but those changes will be much more sweeping than just terminating CMS threads. The unused ::stop() methods will be removed in a separate CR. Also include in this CR is the fix for a small typo in the spelling of UseGCLogFileRotation in a message in arguments.cpp, brought to our attention by Rainer Jung and reviewed by minqi.
Reviewed-by: johnc, jwilhelm

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

Changeset: 74cd10898bea
Author:    brutisso
Date:      2011-06-13 13:48 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/74cd10898bea

6918185: Remove unused code for lost card-marking optimization in BacktraceBuilder
Summary: Removed dead code
Reviewed-by: ysr, coleenp, dholmes

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

Changeset: 842b840e67db
Author:    tonyp
Date:      2011-06-14 10:33 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/842b840e67db

7046558: G1: concurrent marking optimizations
Summary: Some optimizations to improve the concurrent marking phase: specialize the main oop closure, make sure a few methods in the fast path are properly inlined, a few more bits and pieces, and some cosmetic fixes.
Reviewed-by: stefank, johnc

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
+ src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp
! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp
! src/share/vm/utilities/bitMap.hpp

Changeset: 6747fd0512e0
Author:    johnc
Date:      2011-06-14 11:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6747fd0512e0

7004681: G1: Extend marking verification to Full GCs
Summary: Perform a heap verification after the first phase of G1's full GC using objects' mark words to determine liveness. The third parameter of the heap verification routines, which was used in G1 to determine which marking bitmap to use in liveness calculations, has been changed from a boolean to an enum with values defined for using the mark word, and the 'prev' and 'next' bitmaps.
Reviewed-by: tonyp, ysr

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp

Changeset: 5130fa1b24f1
Author:    johnc
Date:      2011-06-15 10:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5130fa1b24f1

7045751: G1: +ExplicitGCInvokesConcurrent causes excessive single region evacuation pauses
Summary: When ExplicitGCInvokesConcurrent is enabled, do not perform an evacuation pause if a marking cycle is already in progress and block the requesting thread until the marking cycle completes.
Reviewed-by: tonyp, ysr

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

Changeset: c9ca3f51cf41
Author:    tonyp
Date:      2011-06-16 15:51 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9ca3f51cf41

6994322: Remove the is_tlab and is_noref / is_large_noref parameters from the CollectedHeap
Summary: Remove two unused parameters from the mem_allocate() method and update its uses accordingly.
Reviewed-by: stefank, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp
! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp
! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp
! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp
! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/gc_interface/collectedHeap.inline.hpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/oops/typeArrayKlass.cpp

Changeset: f75137faa7fe
Author:    ysr
Date:      2011-06-20 09:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f75137faa7fe

6916968: CMS: freeList.cpp:304 assert(_allocation_stats.prevSweep() + ..., "Conservation Principle")
Summary: Fix assert and adjust demand volume computation by adding missing factor.
Reviewed-by: jmasa, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp
! src/share/vm/gc_implementation/shared/allocationStats.hpp

Changeset: 23d434c6290d
Author:    tonyp
Date:      2011-06-20 22:03 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23d434c6290d

7055073: G1: code cleanup in the concurrentMark.* files
Summary: Only cosmetic changes to make the concurrentMark.* more consistent, code-style-wise, with the rest of the codebase.
Reviewed-by: johnc, ysr

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp

Changeset: e8b0b0392037
Author:    tonyp
Date:      2011-06-21 15:23 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8b0b0392037

7046182: G1: remove unnecessary iterations over the collection set
Summary: Remove two unnecessary iterations over the collection set which are supposed to prepare the RSet's of the CSet regions for parallel iterations (we'll make sure this is done incrementally). I'll piggyback on this CR the removal of the G1_REM_SET_LOGGING code.
Reviewed-by: brutisso, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
! src/share/vm/gc_implementation/g1/heapRegionSets.cpp
! src/share/vm/gc_implementation/g1/heapRegionSets.hpp

Changeset: 5f6f2615433a
Author:    tonyp
Date:      2011-06-24 12:38 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f6f2615433a

7049999: G1: Make the G1PrintHeapRegions output consistent and complete
Summary: Extend and make more consistent the output from the G1PrintHeapRegions flag.
Reviewed-by: johnc, jmasa

! src/share/vm/gc_implementation/g1/concurrentMark.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/g1HRPrinter.cpp
+ src/share/vm/gc_implementation/g1/g1HRPrinter.hpp

Changeset: 04760e41b01e
Author:    brutisso
Date:      2011-06-28 14:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04760e41b01e

7016112: CMS: crash during promotion testing
Summary: Also reviewed by mikael.gerdin at oracle.com; stdlib:qsort() does byte-by-byte swapping on Windows. This leads to pointer shearing. Fix is to implement a quicksort that does full pointer updates.
Reviewed-by: never, coleenp, ysr

! src/share/vm/oops/methodOop.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/globals.hpp
+ src/share/vm/utilities/quickSort.cpp
+ src/share/vm/utilities/quickSort.hpp

Changeset: 4bf3cbef0b3e
Author:    jcoomes
Date:      2011-07-06 08:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4bf3cbef0b3e

Merge

! src/share/vm/oops/methodOop.cpp
! src/share/vm/runtime/globals.hpp

Changeset: d83ac25d0304
Author:    never
Date:      2011-06-16 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d83ac25d0304

7055355: JSR 292: crash while throwing WrongMethodTypeException
Reviewed-by: jrose, twisti, bdelsart

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/interpreter/templateInterpreterGenerator.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp

Changeset: aacaff365100
Author:    kvn
Date:      2011-06-20 16:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aacaff365100

7052494: Eclipse test fails on JDK 7 b142
Summary: Keep 'ne' test in Counted loop when we can't guarantee during compilation that init < limit.
Reviewed-by: never

! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.cpp
+ test/compiler/7052494/Test7052494.java

Changeset: de6a837d75cf
Author:    never
Date:      2011-06-21 09:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de6a837d75cf

7056380: VM crashes with SIGSEGV in compiled code
Summary: code was using andq reg, imm instead of addq addr, imm
Reviewed-by: kvn, jrose, twisti

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/x86_64.ad

Changeset: aabf25fa3f05
Author:    never
Date:      2011-06-22 14:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aabf25fa3f05

7057587: JSR 292 - crash with jruby in test/test_respond_to.rb
Summary: don't skip receiver when GC'ing compiled invokedynamic callsites
Reviewed-by: twisti, kvn, jrose

! src/share/vm/code/nmethod.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/parse.hpp

Changeset: ddd894528dbc
Author:    jrose
Date:      2011-06-23 17:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ddd894528dbc

7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path
Reviewed-by: never

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciField.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethodHandle.cpp
! src/share/vm/ci/ciObjArrayKlass.cpp
! src/share/vm/ci/ciSignature.cpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/interpreter/linkResolver.cpp
! 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/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp

Changeset: 498c6cf70f7e
Author:    kvn
Date:      2011-06-28 14:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/498c6cf70f7e

7058036: FieldsAllocationStyle=2 does not work in 32-bit VM
Summary: parseClassFile() incorrectly uses nonstatic_oop_map_size() method instead of nonstatic_oop_map_count().
Reviewed-by: never
Contributed-by: Krystal Mok <rednaxelafx at gmail.com>

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

Changeset: 6ae7a1561b53
Author:    kvn
Date:      2011-06-28 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6ae7a1561b53

6990015: Incorrect Icache line size is used for 64 bit x86
Summary: correct Icache::line_size for x64 and add verification code into vm_version_x86.
Reviewed-by: never, phh

! src/cpu/x86/vm/icache_x86.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp

Changeset: e3cbc9ddd434
Author:    kvn
Date:      2011-06-28 15:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3cbc9ddd434

7044738: Loop unroll optimization causes incorrect result
Summary: take into account memory dependencies when clonning nodes in clone_up_backedge_goo().
Reviewed-by: never

! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
+ test/compiler/7044738/Test7044738.java
+ test/compiler/7046096/Test7046096.java

Changeset: 7889bbcc7f88
Author:    kvn
Date:      2011-06-28 15:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7889bbcc7f88

7047954: VM crashes with assert(is_Mem()) failed
Summary: cast constant array ptrs to bottom
Reviewed-by: never

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

Changeset: 6f6e91603a45
Author:    iveresov
Date:      2011-07-01 10:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f6e91603a45

7058689: Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods
Summary: Take into account current state of profiling before believing that existing higher level versions are valid
Reviewed-by: kvn, never

! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp

Changeset: 2c359f27615c
Author:    iveresov
Date:      2011-07-01 10:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c359f27615c

7057120: Tiered: Allow C1 to inline methods with loops
Summary: Recompile the enclosing methods without inlining of the method that has OSRed to level 4 or recompile the enclosing method at level 4.
Reviewed-by: kvn, never

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/advancedThresholdPolicy.hpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp
! src/share/vm/runtime/simpleThresholdPolicy.hpp

Changeset: 15559220ce79
Author:    never
Date:      2011-07-05 16:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15559220ce79

6478991: C1 NullCheckEliminator yields incorrect exceptions
Reviewed-by: twisti, iveresov

! src/share/vm/c1/c1_Optimizer.cpp
+ test/compiler/6478991/NullCheckTest.java

Changeset: fe240d87c6ec
Author:    never
Date:      2011-07-06 09:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe240d87c6ec

7061101: adlc should complain about mixing block and expression forms of ins_encode
Reviewed-by: kvn

! src/share/vm/adlc/adlparse.cpp

Changeset: 3e23978ea0c3
Author:    never
Date:      2011-07-06 18:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3e23978ea0c3

7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes
Summary: do explicit lookup emulating old LD_LIBRARY_PATH search
Reviewed-by: kvn, jrose

! src/share/tools/hsdis/README
! src/share/vm/compiler/disassembler.cpp

Changeset: b16582d6c7db
Author:    kvn
Date:      2011-07-07 10:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b16582d6c7db

Merge

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/oops/methodOop.cpp

Changeset: 7d9e451f5416
Author:    jcoomes
Date:      2011-07-06 12:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d9e451f5416

7061187: need some includes for arm/ppc
Reviewed-by: dholmes, never, jwilhelm, kvn

! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/runtime/atomic.cpp

Changeset: eb94b7226b7a
Author:    jcoomes
Date:      2011-07-06 12:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eb94b7226b7a

7061192: option handling adjustments for oracle and embedded builds
Reviewed-by: dholmes, never, jwilhelm, kvn

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 65dba8692db7
Author:    jcoomes
Date:      2011-07-06 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65dba8692db7

7061197: ThreadLocalStorage sp map table should be optional
Reviewed-by: dholmes, never, jwilhelm, kvn

! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp
! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp
! src/os_cpu/linux_x86/vm/threadLS_linux_x86.hpp

Changeset: 48048b59a551
Author:    jcoomes
Date:      2011-07-06 12:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48048b59a551

7061204: clean the chunk table synchronously in embedded builds
Reviewed-by: dholmes, never, jwilhelm, kvn

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp

Changeset: bf6481e5f96d
Author:    jcoomes
Date:      2011-07-06 13:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf6481e5f96d

7061225: os::print_cpu_info() should support os-specific data
Reviewed-by: dholmes, never, jwilhelm, kvn

! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp

Changeset: 8a4fc2990229
Author:    jcoomes
Date:      2011-07-07 15:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a4fc2990229

7053189: remove some unnecessary platform-dependent includes
Reviewed-by: dholmes, never, jwilhelm, kvn

! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: b0b8491925fe
Author:    jcoomes
Date:      2011-07-11 14:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b0b8491925fe

7061212: use o/s low memory notification in embedded builds
Reviewed-by: dholmes, never, jwilhelm, kvn

! src/os/linux/vm/os_linux.cpp

Changeset: 0defeba52583
Author:    jcoomes
Date:      2011-07-12 16:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0defeba52583

Merge


Changeset: faa472957b38
Author:    kvn
Date:      2011-07-08 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/faa472957b38

7059034: Use movxtod/movdtox on T4
Summary: Use new VIS3 mov instructions on T4 for move data between general and float registers.
Reviewed-by: never, twisti

! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 263247c478c5
Author:    iveresov
Date:      2011-07-08 15:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/263247c478c5

7058510: multinewarray with 6 dimensions uncommon traps in server compiler
Summary: Pass arguments to runtime via java array for arrays with > 5 dimensions
Reviewed-by: never, kvn, jrose, pbk

! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp

Changeset: 1f4f4ae84625
Author:    kvn
Date:      2011-07-13 10:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f4f4ae84625

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 3fbb609d9e96
Author:    kvn
Date:      2011-07-14 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3fbb609d9e96

7067288: compiler regression test Test7052494 timeouts with client VM
Summary: Test is modified to reduce number of iterations in test5() and test6().
Reviewed-by: never, iveresov

! test/compiler/7052494/Test7052494.java

Changeset: 341a57af9b0a
Author:    never
Date:      2011-07-15 15:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/341a57af9b0a

6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods
Summary: check for single stepping when dispatching invokes from method handles
Reviewed-by: coleenp, twisti, kvn, dsamersoff

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.hpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.hpp
+ test/compiler/6990212/Test6990212.java

Changeset: 968305b802ee
Author:    trims
Date:      2011-07-23 01:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/968305b802ee

Merge


Changeset: 8e5d4aa73a8c
Author:    trims
Date:      2011-07-22 23:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8e5d4aa73a8c

7069176: Update the JDK version numbers in Hotspot for JDK 8
Summary: Change JDK_MINOR_VER and JDK_PREVIOUS_VERSION to reflect JDK8 values
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 0cc8a70952c3
Author:    trims
Date:      2011-07-22 23:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0cc8a70952c3

7070061: Adjust Hotspot make/jprt.properties for new JDK8 settings
Summary: Fix so the JPRT can build with -release jdk8 now
Reviewed-by: ohair

! make/jprt.properties



From David.Holmes at oracle.com  Mon Aug  8 02:46:26 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 08 Aug 2011 12:46:26 +1000
Subject: Help: ContextClassLoader in jtreg tests
In-Reply-To: <4E3BFBF7.2050909@oracle.com>
References: <4E3BFBF7.2050909@oracle.com>
Message-ID: <4E3F4E02.5070308@oracle.com>

Hi Max,

Weijun Wang said the following on 08/06/11 00:19:
> I have two files: A.java and B.java
> 
> /*
>  * @test
>  * @build A B
>  * @run main A
>  */
> public class A {
>     public static void main(String[] args) throws Exception {
>         Class.forName("B", true, 
> Thread.currentThread().getContextClassLoader());
>     }
> }
> 
> public class B {
> }
> 
> Now jtreg A.java shows:
> 
>    java.lang.ClassNotFoundException: B
> 
> How can I get B visible in A's ContextClassLoader?

It isn't A's context class loader it is the current threads. If the 
above isn't working then either:

a) A is not being loaded by the application (aka system) classloader 
(jtreg is using a custom loader); or
b) jtreg has explicitly changed the current thread's context classloader

You would need to investigate what A.class.getClassLoader() reports, and 
what Thread.currentThread().getContextClassLoader() reports.

> Don't tell me to change to Class.forName("B"), that line is copied from 
> JDK that is called by a real test.
> 
> Or, the JDK code itself is problematic and it should fallback to another 
> ClassLoader?

It's unclear why the code/test needs to use the context classloader here 
(or why/how it knows the context loader is the correct loader).

Cheers,
David

> Thanks
> Max


From weijun.wang at oracle.com  Mon Aug  8 03:34:41 2011
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 08 Aug 2011 11:34:41 +0800
Subject: Help: ContextClassLoader in jtreg tests
In-Reply-To: <4E3F4E02.5070308@oracle.com>
References: <4E3BFBF7.2050909@oracle.com> <4E3F4E02.5070308@oracle.com>
Message-ID: <4E3F5951.2010503@oracle.com>



On 08/08/2011 10:46 AM, David Holmes wrote:
> Hi Max,
>
> Weijun Wang said the following on 08/06/11 00:19:
>> I have two files: A.java and B.java
>>
>> /*
>> * @test
>> * @build A B
>> * @run main A
>> */
>> public class A {
>> public static void main(String[] args) throws Exception {
>> Class.forName("B", true, Thread.currentThread().getContextClassLoader());
>> }
>> }
>>
>> public class B {
>> }
>>
>> Now jtreg A.java shows:
>>
>> java.lang.ClassNotFoundException: B
>>
>> How can I get B visible in A's ContextClassLoader?
>
> It isn't A's context class loader it is the current threads. If the
> above isn't working then either:
>
> a) A is not being loaded by the application (aka system) classloader
> (jtreg is using a custom loader); or
> b) jtreg has explicitly changed the current thread's context classloader
>
> You would need to investigate what A.class.getClassLoader() reports, and
> what Thread.currentThread().getContextClassLoader() reports.

A.class.getClassLoader(): A URLClassLoader looking at 
JTwork/classes/test_location and $TESTSRC.

Thread.currentThread().getContextClassLoader(): A 
sun.misc.Launcher$AppClassLoader looking at jtreg.jar. It is also the 
parent class loader of A.class.getClassLoader().

BTW, I've added

             Thread.currentThread().setContextClassLoader(
                     A.class.getClassLoader());

to the test to make it pass.

>
>> Don't tell me to change to Class.forName("B"), that line is copied
>> from JDK that is called by a real test.
>>
>> Or, the JDK code itself is problematic and it should fallback to
>> another ClassLoader?
>
> It's unclear why the code/test needs to use the context classloader here
> (or why/how it knows the context loader is the correct loader).

I'm not sure.

Thanks
Max

>
> Cheers,
> David
>
>> Thanks
>> Max


From David.Holmes at oracle.com  Mon Aug  8 03:42:46 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 08 Aug 2011 13:42:46 +1000
Subject: Help: ContextClassLoader in jtreg tests
In-Reply-To: <4E3F5951.2010503@oracle.com>
References: <4E3BFBF7.2050909@oracle.com> <4E3F4E02.5070308@oracle.com>
	<4E3F5951.2010503@oracle.com>
Message-ID: <4E3F5B36.30904@oracle.com>

Weijun Wang said the following on 08/08/11 13:34:
> On 08/08/2011 10:46 AM, David Holmes wrote:
>> Weijun Wang said the following on 08/06/11 00:19:
>>> I have two files: A.java and B.java
>>>
>>> /*
>>> * @test
>>> * @build A B
>>> * @run main A
>>> */
>>> public class A {
>>> public static void main(String[] args) throws Exception {
>>> Class.forName("B", true, 
>>> Thread.currentThread().getContextClassLoader());
>>> }
>>> }
>>>
>>> public class B {
>>> }
>>>
>>> Now jtreg A.java shows:
>>>
>>> java.lang.ClassNotFoundException: B
>>>
>>> How can I get B visible in A's ContextClassLoader?
>>
>> It isn't A's context class loader it is the current threads. If the
>> above isn't working then either:
>>
>> a) A is not being loaded by the application (aka system) classloader
>> (jtreg is using a custom loader); or
>> b) jtreg has explicitly changed the current thread's context classloader
>>
>> You would need to investigate what A.class.getClassLoader() reports, and
>> what Thread.currentThread().getContextClassLoader() reports.
> 
> A.class.getClassLoader(): A URLClassLoader looking at 
> JTwork/classes/test_location and $TESTSRC.
> 
> Thread.currentThread().getContextClassLoader(): A 
> sun.misc.Launcher$AppClassLoader looking at jtreg.jar. It is also the 
> parent class loader of A.class.getClassLoader().
> 
> BTW, I've added
> 
>             Thread.currentThread().setContextClassLoader(
>                     A.class.getClassLoader());
> 
> to the test to make it pass.

Right. The default context loader for a thread is that of the creating 
thread, and the default for the main thread is the app loader. So if you 
then use a custom loader, as here, to load A, then the context loader 
won't be able to find B. You have to update the context loader as well.

Of course in this simple example it is somewhat pointless to set the 
context loader to fix the problem as you can just use the requisite 
class loader in the first place.

>>
>>> Don't tell me to change to Class.forName("B"), that line is copied
>>> from JDK that is called by a real test.
>>>
>>> Or, the JDK code itself is problematic and it should fallback to
>>> another ClassLoader?
>>
>> It's unclear why the code/test needs to use the context classloader here
>> (or why/how it knows the context loader is the correct loader).
> 
> I'm not sure.

It's probably more important to determine the answer to this question. 
The context class loader is really only meant to be used by SPI 
frameworks so that the core service code (loaded by the extensions 
loader) can find the actual service implementation class (without 
requiring it to be on the boot or extensions classpath).

Cheers,
David

> Thanks
> Max
> 
>>
>> Cheers,
>> David
>>
>>> Thanks
>>> Max


From joe.darcy at oracle.com  Mon Aug  8 05:24:35 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 07 Aug 2011 22:24:35 -0700
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
Message-ID: <4E3F7313.1020103@oracle.com>

Hello.

Please review this small fix, developed after I went through my open bug 
list; patch below, webrev at:

    6380161 (reflect) Exception from newInstance() not chained to cause.
    http://cr.openjdk.java.net/~darcy/6380161.0/

Several call to initCause are added to plumb up caused-by exception 
chains to exception types without constructors taking a cause.  In 
addition, multi-catch is added in on location.

I looked for similar issues in Constructor, Method, and Executable, but 
there weren't any.

Thanks,

-Joe

--- old/src/share/classes/java/lang/Class.java    2011-08-07 
22:21:58.000000000 -0700
+++ new/src/share/classes/java/lang/Class.java    2011-08-07 
22:21:58.000000000 -0700
@@ -349,7 +349,8 @@
                         });
                 cachedConstructor = c;
             } catch (NoSuchMethodException e) {
-                throw new InstantiationException(getName());
+                throw (InstantiationException)
+                    new InstantiationException(getName()).initCause(e);
             }
         }
         Constructor<T> tmpConstructor = cachedConstructor;
@@ -973,7 +974,8 @@
                 descriptor      = (String)   enclosingInfo[2];
                 assert((name != null && descriptor != null) || name == 
descriptor);
             } catch (ClassCastException cce) {
-                throw new InternalError("Invalid type in enclosing 
method information");
+                throw (InternalError)
+                    new InternalError("Invalid type in enclosing method 
information").initCause(cce);
             }
         }
 
@@ -1239,7 +1241,8 @@
         try {
             return getName().substring(enclosingClass.getName().length());
         } catch (IndexOutOfBoundsException ex) {
-            throw new InternalError("Malformed class name");
+            throw (InternalError)
+                new InternalError("Malformed class name").initCause(ex);
         }
     }
 
@@ -2954,9 +2957,8 @@
             }
             // These can happen when users concoct enum-like classes
             // that don't comply with the enum spec.
-            catch (InvocationTargetException ex) { return null; }
-            catch (NoSuchMethodException ex) { return null; }
-            catch (IllegalAccessException ex) { return null; }
+            catch (InvocationTargetException | NoSuchMethodException |
+                   IllegalAccessException ex) { return null; }
         }
         return enumConstants;
     }



From David.Holmes at oracle.com  Mon Aug  8 05:58:25 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 08 Aug 2011 15:58:25 +1000
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <4E3F7313.1020103@oracle.com>
References: <4E3F7313.1020103@oracle.com>
Message-ID: <4E3F7B01.8040608@oracle.com>

Looks good to me Joe.

David

Joe Darcy said the following on 08/08/11 15:24:
> Hello.
> 
> Please review this small fix, developed after I went through my open bug 
> list; patch below, webrev at:
> 
>    6380161 (reflect) Exception from newInstance() not chained to cause.
>    http://cr.openjdk.java.net/~darcy/6380161.0/
> 
> Several call to initCause are added to plumb up caused-by exception 
> chains to exception types without constructors taking a cause.  In 
> addition, multi-catch is added in on location.
> 
> I looked for similar issues in Constructor, Method, and Executable, but 
> there weren't any.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/share/classes/java/lang/Class.java    2011-08-07 
> 22:21:58.000000000 -0700
> +++ new/src/share/classes/java/lang/Class.java    2011-08-07 
> 22:21:58.000000000 -0700
> @@ -349,7 +349,8 @@
>                         });
>                 cachedConstructor = c;
>             } catch (NoSuchMethodException e) {
> -                throw new InstantiationException(getName());
> +                throw (InstantiationException)
> +                    new InstantiationException(getName()).initCause(e);
>             }
>         }
>         Constructor<T> tmpConstructor = cachedConstructor;
> @@ -973,7 +974,8 @@
>                 descriptor      = (String)   enclosingInfo[2];
>                 assert((name != null && descriptor != null) || name == 
> descriptor);
>             } catch (ClassCastException cce) {
> -                throw new InternalError("Invalid type in enclosing 
> method information");
> +                throw (InternalError)
> +                    new InternalError("Invalid type in enclosing method 
> information").initCause(cce);
>             }
>         }
> 
> @@ -1239,7 +1241,8 @@
>         try {
>             return getName().substring(enclosingClass.getName().length());
>         } catch (IndexOutOfBoundsException ex) {
> -            throw new InternalError("Malformed class name");
> +            throw (InternalError)
> +                new InternalError("Malformed class name").initCause(ex);
>         }
>     }
> 
> @@ -2954,9 +2957,8 @@
>             }
>             // These can happen when users concoct enum-like classes
>             // that don't comply with the enum spec.
> -            catch (InvocationTargetException ex) { return null; }
> -            catch (NoSuchMethodException ex) { return null; }
> -            catch (IllegalAccessException ex) { return null; }
> +            catch (InvocationTargetException | NoSuchMethodException |
> +                   IllegalAccessException ex) { return null; }
>         }
>         return enumConstants;
>     }
> 


From mlists at juma.me.uk  Mon Aug  8 07:47:41 2011
From: mlists at juma.me.uk (Ismael Juma)
Date: Mon, 8 Aug 2011 07:47:41 +0000 (UTC)
Subject: JDK 8 code review request for 7075098: Remove unused fdlibm files
References: <4E3AEB52.9070300@oracle.com>
	<0A214C25-0DB6-4B5C-AA9C-3142CB9CFA78@oracle.com>
	<4E3AFC89.5060902@oracle.com>
Message-ID: <loom.20110808T094056-713@post.gmane.org>

Joe Darcy <joe.darcy at ...> writes:
> One of my long-term goals is to finish the 
> small matter of programming [2] to port FDLIBM from C to Java, which 
> would immunize the JDK from this class of problem.

In case people are not aware, FastMath from Apache commons-math is a
pure Java implementation:

http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/c
ommons/math/util/FastMath.java?view=markup

I ran the performance test in their test suite a few months ago and
published the results (note that I didn't write the performance test,
but I fixed some obvious micro-benchmark issues after they were
mentioned in the comments):

http://blog.juma.me.uk/2011/02/23/performance-of-fastmath-from-commons-math/

Best,
Ismael



From Alan.Bateman at oracle.com  Mon Aug  8 08:00:22 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 08 Aug 2011 09:00:22 +0100
Subject: Help: ContextClassLoader in jtreg tests
In-Reply-To: <4E3F4E02.5070308@oracle.com>
References: <4E3BFBF7.2050909@oracle.com> <4E3F4E02.5070308@oracle.com>
Message-ID: <4E3F9796.90703@oracle.com>

David Holmes wrote:
>
> b) jtreg has explicitly changed the current thread's context classloader
I don't jtreg does this but when running tests in -samevm or -agentvm 
mode then jtreg creates a class loader per test. It could be that some 
test is setting the current thread's context class loader and this is 
having a side effect on tests that run subsequentially in the same VM.

-Alan.


From Alan.Bateman at oracle.com  Mon Aug  8 12:17:27 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 08 Aug 2011 13:17:27 +0100
Subject: Request for review: #include ANSI headers for functions referred
	to in jli_util.h
In-Reply-To: <1312381929.14748.15.camel@chalkhill>
References: <1312381929.14748.15.camel@chalkhill>
Message-ID: <4E3FD3D7.1040309@oracle.com>

Neil Richards wrote:
> Hi,
> I've noticed that jdk/src/share/bin/jli_util.h does not currently
> include the ANSI headers for the functions that it #defines aliases for,
> which is not good practice.
>
> Please find below a suggested change which adds the necessary #include
> statements to correct this.
>
> Please consider this change for committal.
>
> Thanks,
> Neil
>
>   
This seems reasonable to me.

-Alan


From alan.bateman at oracle.com  Mon Aug  8 12:43:01 2011
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 08 Aug 2011 12:43:01 +0000
Subject: hg: jdk8/tl/jdk: 7076215: (jli) jdk/src/share/bin/jli_util.h should
	include function prototypes for str functions
Message-ID: <20110808124324.2AF9C47A11@hg.openjdk.java.net>

Changeset: 94934ebbb654
Author:    alanb
Date:      2011-08-08 13:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94934ebbb654

7076215: (jli) jdk/src/share/bin/jli_util.h should include function prototypes for str functions
Reviewed-by: alanb
Contributed-by: neil.richards at ngmr.net

! src/share/bin/jli_util.h



From Lance.Andersen at oracle.com  Mon Aug  8 13:41:31 2011
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Mon, 8 Aug 2011 09:41:31 -0400
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <4E3F7313.1020103@oracle.com>
References: <4E3F7313.1020103@oracle.com>
Message-ID: <1290AE84-AD4B-4066-9BFA-66A3F388E0BF@oracle.com>

Looks fine to me Joe

Best
Lance
On Aug 8, 2011, at 1:24 AM, Joe Darcy wrote:

> Hello.
> 
> Please review this small fix, developed after I went through my open bug list; patch below, webrev at:
> 
>   6380161 (reflect) Exception from newInstance() not chained to cause.
>   http://cr.openjdk.java.net/~darcy/6380161.0/
> 
> Several call to initCause are added to plumb up caused-by exception chains to exception types without constructors taking a cause.  In addition, multi-catch is added in on location.
> 
> I looked for similar issues in Constructor, Method, and Executable, but there weren't any.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/share/classes/java/lang/Class.java    2011-08-07 22:21:58.000000000 -0700
> +++ new/src/share/classes/java/lang/Class.java    2011-08-07 22:21:58.000000000 -0700
> @@ -349,7 +349,8 @@
>                        });
>                cachedConstructor = c;
>            } catch (NoSuchMethodException e) {
> -                throw new InstantiationException(getName());
> +                throw (InstantiationException)
> +                    new InstantiationException(getName()).initCause(e);
>            }
>        }
>        Constructor<T> tmpConstructor = cachedConstructor;
> @@ -973,7 +974,8 @@
>                descriptor      = (String)   enclosingInfo[2];
>                assert((name != null && descriptor != null) || name == descriptor);
>            } catch (ClassCastException cce) {
> -                throw new InternalError("Invalid type in enclosing method information");
> +                throw (InternalError)
> +                    new InternalError("Invalid type in enclosing method information").initCause(cce);
>            }
>        }
> @@ -1239,7 +1241,8 @@
>        try {
>            return getName().substring(enclosingClass.getName().length());
>        } catch (IndexOutOfBoundsException ex) {
> -            throw new InternalError("Malformed class name");
> +            throw (InternalError)
> +                new InternalError("Malformed class name").initCause(ex);
>        }
>    }
> @@ -2954,9 +2957,8 @@
>            }
>            // These can happen when users concoct enum-like classes
>            // that don't comply with the enum spec.
> -            catch (InvocationTargetException ex) { return null; }
> -            catch (NoSuchMethodException ex) { return null; }
> -            catch (IllegalAccessException ex) { return null; }
> +            catch (InvocationTargetException | NoSuchMethodException |
> +                   IllegalAccessException ex) { return null; }
>        }
>        return enumConstants;
>    }
> 


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



From sebastian.sickelmann at gmx.de  Mon Aug  8 14:24:03 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Mon, 08 Aug 2011 16:24:03 +0200
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <4E3F7313.1020103@oracle.com>
References: <4E3F7313.1020103@oracle.com>
Message-ID: <4E3FF183.7020806@gmx.de>

Looks good to me.

But i have one question:

     Why there are two ways to plumb the causes of an exception?
     In many exceptions-classes you can use a constuctor-level argument 
to specify the cause, and in some classes you must use the initCause method.

     Is it: "When you often need a cause at creation-time than we got a 
specializes constructor." ?

     I found 500+ lines jdk/src/share/classes/**/*.java where i found 
line like

            XYZException iae = new XYZException();
             iae.initCause(e);
             throw iae;

     I am searching a minor project for my second Contribution to 
OpenJDK to learn more about the developement / review process.
     Is it worthwhile to look at this issue and maybe refactor some of 
the often used Exceptions to accept a cause at construction-time?

- Sebastian

Am 08.08.2011 07:24, schrieb Joe Darcy:
> Hello.
>
> Please review this small fix, developed after I went through my open 
> bug list; patch below, webrev at:
>
>    6380161 (reflect) Exception from newInstance() not chained to cause.
>    http://cr.openjdk.java.net/~darcy/6380161.0/
>
> Several call to initCause are added to plumb up caused-by exception 
> chains to exception types without constructors taking a cause.  In 
> addition, multi-catch is added in on location.
>
> I looked for similar issues in Constructor, Method, and Executable, 
> but there weren't any.
>
> Thanks,
>
> -Joe
>
> --- old/src/share/classes/java/lang/Class.java    2011-08-07 
> 22:21:58.000000000 -0700
> +++ new/src/share/classes/java/lang/Class.java    2011-08-07 
> 22:21:58.000000000 -0700
> @@ -349,7 +349,8 @@
>                         });
>                 cachedConstructor = c;
>             } catch (NoSuchMethodException e) {
> -                throw new InstantiationException(getName());
> +                throw (InstantiationException)
> +                    new InstantiationException(getName()).initCause(e);
>             }
>         }
>         Constructor<T> tmpConstructor = cachedConstructor;
> @@ -973,7 +974,8 @@
>                 descriptor      = (String)   enclosingInfo[2];
>                 assert((name != null && descriptor != null) || name == 
> descriptor);
>             } catch (ClassCastException cce) {
> -                throw new InternalError("Invalid type in enclosing 
> method information");
> +                throw (InternalError)
> +                    new InternalError("Invalid type in enclosing 
> method information").initCause(cce);
>             }
>         }
>
> @@ -1239,7 +1241,8 @@
>         try {
>             return 
> getName().substring(enclosingClass.getName().length());
>         } catch (IndexOutOfBoundsException ex) {
> -            throw new InternalError("Malformed class name");
> +            throw (InternalError)
> +                new InternalError("Malformed class name").initCause(ex);
>         }
>     }
>
> @@ -2954,9 +2957,8 @@
>             }
>             // These can happen when users concoct enum-like classes
>             // that don't comply with the enum spec.
> -            catch (InvocationTargetException ex) { return null; }
> -            catch (NoSuchMethodException ex) { return null; }
> -            catch (IllegalAccessException ex) { return null; }
> +            catch (InvocationTargetException | NoSuchMethodException |
> +                   IllegalAccessException ex) { return null; }
>         }
>         return enumConstants;
>     }
>



From forax at univ-mlv.fr  Mon Aug  8 14:25:19 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Mon, 08 Aug 2011 16:25:19 +0200
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <1290AE84-AD4B-4066-9BFA-66A3F388E0BF@oracle.com>
References: <4E3F7313.1020103@oracle.com>
	<1290AE84-AD4B-4066-9BFA-66A3F388E0BF@oracle.com>
Message-ID: <4E3FF1CF.7040407@univ-mlv.fr>

Agree, looks good.

R?mi

On 08/08/2011 03:41 PM, Lance Andersen - Oracle wrote:
> Looks fine to me Joe
>
> Best
> Lance
> On Aug 8, 2011, at 1:24 AM, Joe Darcy wrote:
>
>> Hello.
>>
>> Please review this small fix, developed after I went through my open bug list; patch below, webrev at:
>>
>>    6380161 (reflect) Exception from newInstance() not chained to cause.
>>    http://cr.openjdk.java.net/~darcy/6380161.0/
>>
>> Several call to initCause are added to plumb up caused-by exception chains to exception types without constructors taking a cause.  In addition, multi-catch is added in on location.
>>
>> I looked for similar issues in Constructor, Method, and Executable, but there weren't any.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/share/classes/java/lang/Class.java    2011-08-07 22:21:58.000000000 -0700
>> +++ new/src/share/classes/java/lang/Class.java    2011-08-07 22:21:58.000000000 -0700
>> @@ -349,7 +349,8 @@
>>                         });
>>                 cachedConstructor = c;
>>             } catch (NoSuchMethodException e) {
>> -                throw new InstantiationException(getName());
>> +                throw (InstantiationException)
>> +                    new InstantiationException(getName()).initCause(e);
>>             }
>>         }
>>         Constructor<T>  tmpConstructor = cachedConstructor;
>> @@ -973,7 +974,8 @@
>>                 descriptor      = (String)   enclosingInfo[2];
>>                 assert((name != null&&  descriptor != null) || name == descriptor);
>>             } catch (ClassCastException cce) {
>> -                throw new InternalError("Invalid type in enclosing method information");
>> +                throw (InternalError)
>> +                    new InternalError("Invalid type in enclosing method information").initCause(cce);
>>             }
>>         }
>> @@ -1239,7 +1241,8 @@
>>         try {
>>             return getName().substring(enclosingClass.getName().length());
>>         } catch (IndexOutOfBoundsException ex) {
>> -            throw new InternalError("Malformed class name");
>> +            throw (InternalError)
>> +                new InternalError("Malformed class name").initCause(ex);
>>         }
>>     }
>> @@ -2954,9 +2957,8 @@
>>             }
>>             // These can happen when users concoct enum-like classes
>>             // that don't comply with the enum spec.
>> -            catch (InvocationTargetException ex) { return null; }
>> -            catch (NoSuchMethodException ex) { return null; }
>> -            catch (IllegalAccessException ex) { return null; }
>> +            catch (InvocationTargetException | NoSuchMethodException |
>> +                   IllegalAccessException ex) { return null; }
>>         }
>>         return enumConstants;
>>     }
>>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>



From sebastian.sickelmann at gmx.de  Mon Aug  8 14:31:44 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Mon, 08 Aug 2011 16:31:44 +0200
Subject: Iterable support for Enumeration
Message-ID: <4E3FF350.8050603@gmx.de>

Hi,

Maybe my mail [1] got lost in thread-history. But i think that Colin had 
a good idea in [2].
Should we open a new discussion on this, are is meaningless to create 
better support for good old enumerations.

-Sebastian

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007285.html
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007269.html


From sebastian.sickelmann at gmx.de  Mon Aug  8 14:51:16 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Mon, 08 Aug 2011 16:51:16 +0200
Subject: Iterable support for Enumeration
In-Reply-To: <4E3FF350.8050603@gmx.de>
References: <4E3FF350.8050603@gmx.de>
Message-ID: <adc27166-57b0-4c06-bc4d-4c8032b656b7@email.android.com>

Sorry for the typo. I wanted to write.:
 Should we open a new discussion on this, or is meaningless to create 
better support for good old enumerations.


Sebastian Sickelmann <sebastian.sickelmann at gmx.de> schrieb:

>Hi,
>
>Maybe my mail [1] got lost in thread-history. But i think that Colin had 
>a good idea in [2].
>Should we open a new discussion on this, are is meaningless to create 
>better support for good old enumerations.
>
>-Sebastian
>
>[1] 
>http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007285.html
>[2] 
>http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007269.html

-- 
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.


From Alan.Bateman at oracle.com  Mon Aug  8 15:16:31 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 08 Aug 2011 16:16:31 +0100
Subject: Request for review: Make MethodHandleProxies.getSingleMethod()
	agnostic of ordering of methods returned from Class.getMethods()
In-Reply-To: <1312379874.25189.63.camel@chalkhill>
References: <1311159119.1024.56.camel@chalkhill> <4E26C726.7050409@oracle.com>
	<1312379874.25189.63.camel@chalkhill>
Message-ID: <4E3FFDCF.1050402@oracle.com>

Neil Richards wrote:
> :
> .
>
> Can I interest a core-libs committer in helping me to get this change
> committed?
>
>   
It might be better to have this come through mlvm-dev as that is where 
the JSR-292 work has been happening.

-Alan.


From joe.darcy at oracle.com  Mon Aug  8 16:08:58 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 08 Aug 2011 09:08:58 -0700
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <4E3FF1CF.7040407@univ-mlv.fr>
References: <4E3F7313.1020103@oracle.com>	<1290AE84-AD4B-4066-9BFA-66A3F388E0BF@oracle.com>
	<4E3FF1CF.7040407@univ-mlv.fr>
Message-ID: <4E400A1A.3080605@oracle.com>

David, Lance, and R?mi,

Thanks for the prompt reviews,

-Joe

R?mi Forax wrote:
> Agree, looks good.
>
> R?mi
>
> On 08/08/2011 03:41 PM, Lance Andersen - Oracle wrote:
>> Looks fine to me Joe
>>
>> Best
>> Lance
>> On Aug 8, 2011, at 1:24 AM, Joe Darcy wrote:
>>
>>> Hello.
>>>
>>> Please review this small fix, developed after I went through my open 
>>> bug list; patch below, webrev at:
>>>
>>>    6380161 (reflect) Exception from newInstance() not chained to cause.
>>>    http://cr.openjdk.java.net/~darcy/6380161.0/
>>>
>>> Several call to initCause are added to plumb up caused-by exception 
>>> chains to exception types without constructors taking a cause.  In 
>>> addition, multi-catch is added in on location.
>>>
>>> I looked for similar issues in Constructor, Method, and Executable, 
>>> but there weren't any.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> --- old/src/share/classes/java/lang/Class.java    2011-08-07 
>>> 22:21:58.000000000 -0700
>>> +++ new/src/share/classes/java/lang/Class.java    2011-08-07 
>>> 22:21:58.000000000 -0700
>>> @@ -349,7 +349,8 @@
>>>                         });
>>>                 cachedConstructor = c;
>>>             } catch (NoSuchMethodException e) {
>>> -                throw new InstantiationException(getName());
>>> +                throw (InstantiationException)
>>> +                    new 
>>> InstantiationException(getName()).initCause(e);
>>>             }
>>>         }
>>>         Constructor<T>  tmpConstructor = cachedConstructor;
>>> @@ -973,7 +974,8 @@
>>>                 descriptor      = (String)   enclosingInfo[2];
>>>                 assert((name != null&&  descriptor != null) || name 
>>> == descriptor);
>>>             } catch (ClassCastException cce) {
>>> -                throw new InternalError("Invalid type in enclosing 
>>> method information");
>>> +                throw (InternalError)
>>> +                    new InternalError("Invalid type in enclosing 
>>> method information").initCause(cce);
>>>             }
>>>         }
>>> @@ -1239,7 +1241,8 @@
>>>         try {
>>>             return 
>>> getName().substring(enclosingClass.getName().length());
>>>         } catch (IndexOutOfBoundsException ex) {
>>> -            throw new InternalError("Malformed class name");
>>> +            throw (InternalError)
>>> +                new InternalError("Malformed class 
>>> name").initCause(ex);
>>>         }
>>>     }
>>> @@ -2954,9 +2957,8 @@
>>>             }
>>>             // These can happen when users concoct enum-like classes
>>>             // that don't comply with the enum spec.
>>> -            catch (InvocationTargetException ex) { return null; }
>>> -            catch (NoSuchMethodException ex) { return null; }
>>> -            catch (IllegalAccessException ex) { return null; }
>>> +            catch (InvocationTargetException | NoSuchMethodException |
>>> +                   IllegalAccessException ex) { return null; }
>>>         }
>>>         return enumConstants;
>>>     }
>>>
>>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>>
>



From joe.darcy at oracle.com  Mon Aug  8 16:08:11 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Mon, 08 Aug 2011 16:08:11 +0000
Subject: hg: jdk8/tl/jdk: 6380161: (reflect) Exception from newInstance() not
	chained to cause.
Message-ID: <20110808160821.684DE47A19@hg.openjdk.java.net>

Changeset: d4ab25d65adb
Author:    darcy
Date:      2011-08-08 09:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4ab25d65adb

6380161: (reflect) Exception from newInstance() not chained to cause.
Reviewed-by: dholmes, lancea, forax

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



From joe.darcy at oracle.com  Mon Aug  8 17:04:54 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 08 Aug 2011 10:04:54 -0700
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <4E3FF183.7020806@gmx.de>
References: <4E3F7313.1020103@oracle.com> <4E3FF183.7020806@gmx.de>
Message-ID: <4E401736.2090508@oracle.com>

Hello.

On 8/8/2011 7:24 AM, Sebastian Sickelmann wrote:
> Looks good to me.
>
> But i have one question:
>
>     Why there are two ways to plumb the causes of an exception?

The history of this situation is covered in older versions of the 
javadoc of Throwable:
http://download.oracle.com/javase/6/docs/api/java/lang/Throwable.html

>     In many exceptions-classes you can use a constuctor-level argument 
> to specify the cause, and in some classes you must use the initCause 
> method.
>
>     Is it: "When you often need a cause at creation-time than we got a 
> specializes constructor." ?
>
>     I found 500+ lines jdk/src/share/classes/**/*.java where i found 
> line like
>
>            XYZException iae = new XYZException();
>             iae.initCause(e);
>             throw iae;
>
>     I am searching a minor project for my second Contribution to 
> OpenJDK to learn more about the developement / review process.
>     Is it worthwhile to look at this issue and maybe refactor some of 
> the often used Exceptions to accept a cause at construction-time?

I would say such a project would be helpful; for context, this topic 
came up a few months ago on core-libs in the context of another code review:

     
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/007005.html
     
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/007008.html

Cheers,

-Joe

>
> - Sebastian
>
> Am 08.08.2011 07:24, schrieb Joe Darcy:
>> Hello.
>>
>> Please review this small fix, developed after I went through my open 
>> bug list; patch below, webrev at:
>>
>>    6380161 (reflect) Exception from newInstance() not chained to cause.
>>    http://cr.openjdk.java.net/~darcy/6380161.0/
>>
>> Several call to initCause are added to plumb up caused-by exception 
>> chains to exception types without constructors taking a cause.  In 
>> addition, multi-catch is added in on location.
>>
>> I looked for similar issues in Constructor, Method, and Executable, 
>> but there weren't any.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/share/classes/java/lang/Class.java    2011-08-07 
>> 22:21:58.000000000 -0700
>> +++ new/src/share/classes/java/lang/Class.java    2011-08-07 
>> 22:21:58.000000000 -0700
>> @@ -349,7 +349,8 @@
>>                         });
>>                 cachedConstructor = c;
>>             } catch (NoSuchMethodException e) {
>> -                throw new InstantiationException(getName());
>> +                throw (InstantiationException)
>> +                    new InstantiationException(getName()).initCause(e);
>>             }
>>         }
>>         Constructor<T> tmpConstructor = cachedConstructor;
>> @@ -973,7 +974,8 @@
>>                 descriptor      = (String)   enclosingInfo[2];
>>                 assert((name != null && descriptor != null) || name 
>> == descriptor);
>>             } catch (ClassCastException cce) {
>> -                throw new InternalError("Invalid type in enclosing 
>> method information");
>> +                throw (InternalError)
>> +                    new InternalError("Invalid type in enclosing 
>> method information").initCause(cce);
>>             }
>>         }
>>
>> @@ -1239,7 +1241,8 @@
>>         try {
>>             return 
>> getName().substring(enclosingClass.getName().length());
>>         } catch (IndexOutOfBoundsException ex) {
>> -            throw new InternalError("Malformed class name");
>> +            throw (InternalError)
>> +                new InternalError("Malformed class 
>> name").initCause(ex);
>>         }
>>     }
>>
>> @@ -2954,9 +2957,8 @@
>>             }
>>             // These can happen when users concoct enum-like classes
>>             // that don't comply with the enum spec.
>> -            catch (InvocationTargetException ex) { return null; }
>> -            catch (NoSuchMethodException ex) { return null; }
>> -            catch (IllegalAccessException ex) { return null; }
>> +            catch (InvocationTargetException | NoSuchMethodException |
>> +                   IllegalAccessException ex) { return null; }
>>         }
>>         return enumConstants;
>>     }
>>
>



From sebastian.sickelmann at gmx.de  Mon Aug  8 19:18:29 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Mon, 08 Aug 2011 21:18:29 +0200
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <4E401736.2090508@oracle.com>
References: <4E3F7313.1020103@oracle.com> <4E3FF183.7020806@gmx.de>
	<4E401736.2090508@oracle.com>
Message-ID: <4E403685.9020802@gmx.de>

Thanks for encouraging me.

I opened a bug [1] at bugs.openjdk.java.net. Hope that is a right first 
step to getting started.
I wanted to investigate the calls to initCause in jdk-source first to 
pick the most valueable Exceptions first.
I thinks there are many exceptions out of scope of core-libs. How to 
handle these ones. I think i will
start with exceptions from core-libs.
Is there a pattern that says me exceptions belongs to which openjdk-project?

- Sebastian

[1] https://bugs.openjdk.java.net/show_bug.cgi?id=100201

Am 08.08.2011 19:04, schrieb Joe Darcy:
> Hello.
>
> On 8/8/2011 7:24 AM, Sebastian Sickelmann wrote:
>> Looks good to me.
>>
>> But i have one question:
>>
>>     Why there are two ways to plumb the causes of an exception?
>
> The history of this situation is covered in older versions of the 
> javadoc of Throwable:
> http://download.oracle.com/javase/6/docs/api/java/lang/Throwable.html
>
>>     In many exceptions-classes you can use a constuctor-level 
>> argument to specify the cause, and in some classes you must use the 
>> initCause method.
>>
>>     Is it: "When you often need a cause at creation-time than we got 
>> a specializes constructor." ?
>>
>>     I found 500+ lines jdk/src/share/classes/**/*.java where i found 
>> line like
>>
>>            XYZException iae = new XYZException();
>>             iae.initCause(e);
>>             throw iae;
>>
>>     I am searching a minor project for my second Contribution to 
>> OpenJDK to learn more about the developement / review process.
>>     Is it worthwhile to look at this issue and maybe refactor some of 
>> the often used Exceptions to accept a cause at construction-time?
>
> I would say such a project would be helpful; for context, this topic 
> came up a few months ago on core-libs in the context of another code 
> review:
>
>     
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/007005.html
>     
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/007008.html
>
> Cheers,
>
> -Joe
>
>>
>> - Sebastian
>>
>> Am 08.08.2011 07:24, schrieb Joe Darcy:
>>> Hello.
>>>
>>> Please review this small fix, developed after I went through my open 
>>> bug list; patch below, webrev at:
>>>
>>>    6380161 (reflect) Exception from newInstance() not chained to cause.
>>>    http://cr.openjdk.java.net/~darcy/6380161.0/
>>>
>>> Several call to initCause are added to plumb up caused-by exception 
>>> chains to exception types without constructors taking a cause.  In 
>>> addition, multi-catch is added in on location.
>>>
>>> I looked for similar issues in Constructor, Method, and Executable, 
>>> but there weren't any.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> --- old/src/share/classes/java/lang/Class.java    2011-08-07 
>>> 22:21:58.000000000 -0700
>>> +++ new/src/share/classes/java/lang/Class.java    2011-08-07 
>>> 22:21:58.000000000 -0700
>>> @@ -349,7 +349,8 @@
>>>                         });
>>>                 cachedConstructor = c;
>>>             } catch (NoSuchMethodException e) {
>>> -                throw new InstantiationException(getName());
>>> +                throw (InstantiationException)
>>> +                    new 
>>> InstantiationException(getName()).initCause(e);
>>>             }
>>>         }
>>>         Constructor<T> tmpConstructor = cachedConstructor;
>>> @@ -973,7 +974,8 @@
>>>                 descriptor      = (String)   enclosingInfo[2];
>>>                 assert((name != null && descriptor != null) || name 
>>> == descriptor);
>>>             } catch (ClassCastException cce) {
>>> -                throw new InternalError("Invalid type in enclosing 
>>> method information");
>>> +                throw (InternalError)
>>> +                    new InternalError("Invalid type in enclosing 
>>> method information").initCause(cce);
>>>             }
>>>         }
>>>
>>> @@ -1239,7 +1241,8 @@
>>>         try {
>>>             return 
>>> getName().substring(enclosingClass.getName().length());
>>>         } catch (IndexOutOfBoundsException ex) {
>>> -            throw new InternalError("Malformed class name");
>>> +            throw (InternalError)
>>> +                new InternalError("Malformed class 
>>> name").initCause(ex);
>>>         }
>>>     }
>>>
>>> @@ -2954,9 +2957,8 @@
>>>             }
>>>             // These can happen when users concoct enum-like classes
>>>             // that don't comply with the enum spec.
>>> -            catch (InvocationTargetException ex) { return null; }
>>> -            catch (NoSuchMethodException ex) { return null; }
>>> -            catch (IllegalAccessException ex) { return null; }
>>> +            catch (InvocationTargetException | NoSuchMethodException |
>>> +                   IllegalAccessException ex) { return null; }
>>>         }
>>>         return enumConstants;
>>>     }
>>>
>>
>



From Lance.Andersen at oracle.com  Mon Aug  8 20:30:45 2011
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Mon, 8 Aug 2011 16:30:45 -0400
Subject: Found 3 NullPointerExceptions
In-Reply-To: <4E4046E4.4010300@reini.net>
References: <4E29EBFC.2030202@reini.net>
	<B2B04BD5-2489-4C47-AF16-8F18568FE4B0@oracle.com>
	<E9D5266E-90DA-4287-93A8-CAD2ECB28C61@reini.net>
	<1E7C1AB1-90EE-4397-ADBE-FCB4EEB173B9@oracle.com>
	<4E4046E4.4010300@reini.net>
Message-ID: <2710DD13-3E8E-479D-99E9-5CEC95B48277@oracle.com>

Yes it looks OK.  I am in the process of figuring out what I need to do for including your contribution...   I will be putting it back to openjdk8 first

On Aug 8, 2011, at 4:28 PM, Patrick Reinhart wrote:

> Hi Lance,
> 
> I hope you got the time to look in my changes in the meantime:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007194.html
> 
> Regards
> 
> Patrick
> 
>> Hi Patrick,
>> 
>> Still on my list as been in a lot of fire drills.
>> 
>> best
>> lance
>> On Jul 26, 2011, at 1:46 PM, Patrick Reinhart wrote:
>> 
>>> Hi Lance,
>>> 
>>> Did you already had the time looking into my suposed changes?
>>> 
>>> Regards 
>>> 
>>> Patrick
>>> 
>>> Am 22.07.2011 um 23:37 schrieb Lance Andersen - Oracle <Lance.Andersen at oracle.com>:
> 


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



From sebastian.sickelmann at gmx.de  Mon Aug  8 20:57:21 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Mon, 08 Aug 2011 22:57:21 +0200
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <4E403685.9020802@gmx.de>
References: <4E3F7313.1020103@oracle.com>
	<4E3FF183.7020806@gmx.de>	<4E401736.2090508@oracle.com>
	<4E403685.9020802@gmx.de>
Message-ID: <4E404DB1.90406@gmx.de>

I have picked my first Exception in this project.

And unfortunatly i picked InternalError which seems to be used quite 
often. :-)
I tried to change all initCause calls to the new Constructor and found 
many places where there is code like this:

     throw new InternalError(e.toString());
     or
     throw new InternalError(e.getMessage());
     or
     throw new InternalError("Lorem ipsum:"+e);

These ones are candidates for cleanup too, but i want to discuss if 
someone sees a good argument to not to change to
     throw new InternalError(e.getMessage(),e);
     or
     throw new InternalError("Lorem ipsum",e);

Also i don't completely understand why Throwable(Throwable cause) uses 
cause.toString() to fill the message instead of cause.getMessage().
Can someone explain to me why?

Couldn't it be
         if (cause == null) {
             detailMessage = null;
         }else {
             String message = cause.getMessage();
             detailMessage = (message==null ? null : cause.toString());
         }

instead?

- Sebastian


Am 08.08.2011 21:18, schrieb Sebastian Sickelmann:
> Thanks for encouraging me.
>
> I opened a bug [1] at bugs.openjdk.java.net. Hope that is a right 
> first step to getting started.
> I wanted to investigate the calls to initCause in jdk-source first to 
> pick the most valueable Exceptions first.
> I thinks there are many exceptions out of scope of core-libs. How to 
> handle these ones. I think i will
> start with exceptions from core-libs.
> Is there a pattern that says me exceptions belongs to which 
> openjdk-project?
>
> - Sebastian
>
> [1] https://bugs.openjdk.java.net/show_bug.cgi?id=100201
>
> Am 08.08.2011 19:04, schrieb Joe Darcy:
>> Hello.
>>
>> On 8/8/2011 7:24 AM, Sebastian Sickelmann wrote:
>>> Looks good to me.
>>>
>>> But i have one question:
>>>
>>>     Why there are two ways to plumb the causes of an exception?
>>
>> The history of this situation is covered in older versions of the 
>> javadoc of Throwable:
>> http://download.oracle.com/javase/6/docs/api/java/lang/Throwable.html
>>
>>>     In many exceptions-classes you can use a constuctor-level 
>>> argument to specify the cause, and in some classes you must use the 
>>> initCause method.
>>>
>>>     Is it: "When you often need a cause at creation-time than we got 
>>> a specializes constructor." ?
>>>
>>>     I found 500+ lines jdk/src/share/classes/**/*.java where i found 
>>> line like
>>>
>>>            XYZException iae = new XYZException();
>>>             iae.initCause(e);
>>>             throw iae;
>>>
>>>     I am searching a minor project for my second Contribution to 
>>> OpenJDK to learn more about the developement / review process.
>>>     Is it worthwhile to look at this issue and maybe refactor some 
>>> of the often used Exceptions to accept a cause at construction-time?
>>
>> I would say such a project would be helpful; for context, this topic 
>> came up a few months ago on core-libs in the context of another code 
>> review:
>>
>>     
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/007005.html
>>     
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/007008.html
>>
>> Cheers,
>>
>> -Joe
>>
>>>
>>> - Sebastian
>>>
>>> Am 08.08.2011 07:24, schrieb Joe Darcy:
>>>> Hello.
>>>>
>>>> Please review this small fix, developed after I went through my 
>>>> open bug list; patch below, webrev at:
>>>>
>>>>    6380161 (reflect) Exception from newInstance() not chained to 
>>>> cause.
>>>>    http://cr.openjdk.java.net/~darcy/6380161.0/
>>>>
>>>> Several call to initCause are added to plumb up caused-by exception 
>>>> chains to exception types without constructors taking a cause.  In 
>>>> addition, multi-catch is added in on location.
>>>>
>>>> I looked for similar issues in Constructor, Method, and Executable, 
>>>> but there weren't any.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>> --- old/src/share/classes/java/lang/Class.java    2011-08-07 
>>>> 22:21:58.000000000 -0700
>>>> +++ new/src/share/classes/java/lang/Class.java    2011-08-07 
>>>> 22:21:58.000000000 -0700
>>>> @@ -349,7 +349,8 @@
>>>>                         });
>>>>                 cachedConstructor = c;
>>>>             } catch (NoSuchMethodException e) {
>>>> -                throw new InstantiationException(getName());
>>>> +                throw (InstantiationException)
>>>> +                    new 
>>>> InstantiationException(getName()).initCause(e);
>>>>             }
>>>>         }
>>>>         Constructor<T> tmpConstructor = cachedConstructor;
>>>> @@ -973,7 +974,8 @@
>>>>                 descriptor      = (String)   enclosingInfo[2];
>>>>                 assert((name != null && descriptor != null) || name 
>>>> == descriptor);
>>>>             } catch (ClassCastException cce) {
>>>> -                throw new InternalError("Invalid type in enclosing 
>>>> method information");
>>>> +                throw (InternalError)
>>>> +                    new InternalError("Invalid type in enclosing 
>>>> method information").initCause(cce);
>>>>             }
>>>>         }
>>>>
>>>> @@ -1239,7 +1241,8 @@
>>>>         try {
>>>>             return 
>>>> getName().substring(enclosingClass.getName().length());
>>>>         } catch (IndexOutOfBoundsException ex) {
>>>> -            throw new InternalError("Malformed class name");
>>>> +            throw (InternalError)
>>>> +                new InternalError("Malformed class 
>>>> name").initCause(ex);
>>>>         }
>>>>     }
>>>>
>>>> @@ -2954,9 +2957,8 @@
>>>>             }
>>>>             // These can happen when users concoct enum-like classes
>>>>             // that don't comply with the enum spec.
>>>> -            catch (InvocationTargetException ex) { return null; }
>>>> -            catch (NoSuchMethodException ex) { return null; }
>>>> -            catch (IllegalAccessException ex) { return null; }
>>>> +            catch (InvocationTargetException | 
>>>> NoSuchMethodException |
>>>> +                   IllegalAccessException ex) { return null; }
>>>>         }
>>>>         return enumConstants;
>>>>     }
>>>>
>>>
>>
>



From schlosna at gmail.com  Mon Aug  8 21:28:00 2011
From: schlosna at gmail.com (David Schlosnagle)
Date: Mon, 8 Aug 2011 17:28:00 -0400
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <4E404DB1.90406@gmx.de>
References: <4E3F7313.1020103@oracle.com> <4E3FF183.7020806@gmx.de>
	<4E401736.2090508@oracle.com> <4E403685.9020802@gmx.de>
	<4E404DB1.90406@gmx.de>
Message-ID: <CAGVnyzRg=GauJ03VYOODUP7uq6V-_cPbS4oVN5oNzZYpC=f8og@mail.gmail.com>

On Mon, Aug 8, 2011 at 4:57 PM, Sebastian Sickelmann
<sebastian.sickelmann at gmx.de> wrote:
> These ones are candidates for cleanup too, but i want to discuss if someone
> sees a good argument to not to change to
> ? ?throw new InternalError(e.getMessage(),e);
> ? ?or
> ? ?throw new InternalError("Lorem ipsum",e);
>
> Also i don't completely understand why Throwable(Throwable cause) uses
> cause.toString() to fill the message instead of cause.getMessage().
> Can someone explain to me why?

If you look at Throwable.toString(), you'll see that it uses
Throwable.getLocalizedMessage() which allows for localized exception
messages, so I would avoid using getMessage() directly.

I'd also be interested in helping out making the Throwable and
Exception types provide the 4 consistent constructors if there are
committers that would help guide us.

- Dave


From mandy.chung at oracle.com  Mon Aug  8 21:37:55 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 08 Aug 2011 14:37:55 -0700
Subject: Review request: Test bugs to add cygwin support
Message-ID: <4E405733.5040604@oracle.com>

Simple fix on these tests to run on cygwin.

7036518: TEST_BUG: add cygwin support to 
test/java/nio/charset/coders/CheckSJISMappingProp.sh
7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh

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

Thanks
Mandy


From xueming.shen at oracle.com  Mon Aug  8 22:16:21 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 8 Aug 2011 15:16:21 -0700 (PDT)
Subject: Review request: Test bugs to add cygwin support
In-Reply-To: <4E405733.5040604@oracle.com>
References: <4E405733.5040604@oracle.com>
Message-ID: <4E406035.2020503@oracle.com>

Looks good. Thanks for fixing them.

On 08/08/2011 02:37 PM, Mandy Chung wrote:
> Simple fix on these tests to run on cygwin.
>
> 7036518: TEST_BUG: add cygwin support to
> test/java/nio/charset/coders/CheckSJISMappingProp.sh
> 7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh
>
> Webrev at:
>      http://cr.openjdk.java.net/~mchung/7036518/webrev.00/
>
> Thanks
> Mandy



From mandy.chung at oracle.com  Mon Aug  8 23:06:18 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 08 Aug 2011 16:06:18 -0700
Subject: Review request: Test bugs to add cygwin support
In-Reply-To: <4E406035.2020503@oracle.com>
References: <4E405733.5040604@oracle.com> <4E406035.2020503@oracle.com>
Message-ID: <4E406BEA.4010202@oracle.com>

Sherman,

Thanks.  Can you review one more fix:

7012365: TEST_BUG: test/java/nio/charset/spi/basic.sh can be run with Cygwin
Webrev at:
   http://cr.openjdk.java.net/~mchung/7012365/webrev.00/

Mandy

On 8/8/11 3:16 PM, Xueming Shen wrote:
> Looks good. Thanks for fixing them.
>
> On 08/08/2011 02:37 PM, Mandy Chung wrote:
>> Simple fix on these tests to run on cygwin.
>>
>> 7036518: TEST_BUG: add cygwin support to
>> test/java/nio/charset/coders/CheckSJISMappingProp.sh
>> 7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh
>>
>> Webrev at:
>>       http://cr.openjdk.java.net/~mchung/7036518/webrev.00/
>>
>> Thanks
>> Mandy



From joe.darcy at oracle.com  Mon Aug  8 23:22:32 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Mon, 08 Aug 2011 16:22:32 -0700
Subject: Review request: Test bugs to add cygwin support
In-Reply-To: <4E406BEA.4010202@oracle.com>
References: <4E405733.5040604@oracle.com> <4E406035.2020503@oracle.com>
	<4E406BEA.4010202@oracle.com>
Message-ID: <4E406FB8.3000905@oracle.com>

Looks fine.

-Joe

On 8/8/2011 4:06 PM, Mandy Chung wrote:
> Sherman,
>
> Thanks.  Can you review one more fix:
>
> 7012365: TEST_BUG: test/java/nio/charset/spi/basic.sh can be run with 
> Cygwin
> Webrev at:
>   http://cr.openjdk.java.net/~mchung/7012365/webrev.00/
>
> Mandy
>
> On 8/8/11 3:16 PM, Xueming Shen wrote:
>> Looks good. Thanks for fixing them.
>>
>> On 08/08/2011 02:37 PM, Mandy Chung wrote:
>>> Simple fix on these tests to run on cygwin.
>>>
>>> 7036518: TEST_BUG: add cygwin support to
>>> test/java/nio/charset/coders/CheckSJISMappingProp.sh
>>> 7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh
>>>
>>> Webrev at:
>>>       http://cr.openjdk.java.net/~mchung/7036518/webrev.00/
>>>
>>> Thanks
>>> Mandy
>


From mandy.chung at oracle.com  Mon Aug  8 23:28:41 2011
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Mon, 08 Aug 2011 23:28:41 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20110808232918.C481B47A2D@hg.openjdk.java.net>

Changeset: 0f1b4b3bc833
Author:    mchung
Date:      2011-08-08 16:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f1b4b3bc833

7036518: TEST_BUG: add cygwin support to test/java/nio/charset/coders/CheckSJISMappingProp.sh
7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh
Reviewed-by: sherman

! test/demo/zipfs/basic.sh
! test/java/nio/charset/coders/CheckSJISMappingProp.sh

Changeset: 39498fc31d63
Author:    mchung
Date:      2011-08-08 16:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39498fc31d63

7012365: TEST_BUG: test/java/nio/charset/spi/basic.sh can be run with Cygwin
Reviewed-by: darcy

! test/java/nio/charset/spi/basic.sh



From xuelei.fan at oracle.com  Tue Aug  9 01:58:25 2011
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 09 Aug 2011 09:58:25 +0800
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E3C3256.5080700@oracle.com>
References: <4E34155E.5090700@oracle.com>	<4E37C117.2030104@oracle.com>	<4E384579.1080209@oracle.com>	<4E38FBDD.8070202@oracle.com>
	<4E397636.5070302@oracle.com> <4E39FCC1.6020308@oracle.com>
	<4E3A0508.6030908@oracle.com> <4E3A150A.9070503@oracle.com>
	<4E3A31C9.8060304@oracle.com> <4E3B085B.60803@oracle.com>
	<4E3C3256.5080700@oracle.com>
Message-ID: <4E409441.8010406@oracle.com>

On 8/6/2011 2:11 AM, Alexandre Boulgakov wrote:
> Here's the second version:
> http://cr.openjdk.java.net/~mduigou/7072353/2/webrev/
> <http://cr.openjdk.java.net/%7Emduigou/7072353/2/webrev/>
> 
>   * Changed LdapResult.referrals to be a Vector<Vector<String>>;
>   * Refactored
>       o com/sun/jndi/dns/DnsContext.java: BaseNameClassPairEnumeration<T>;
>       o com/sun/jndi/toolkit/dir/HierMemDirCtx.java: BaseFlatNames<T>;
>       o com/sun/jndi/ldap/*.java: refactored LdapNamingEnumeration into
>         AbstractLdapNamingEnumeration, LdapNameClassPairEnumeration;
>         changed LdapBindingEnumeration and LdapSearchEnumeration
>         accordingly, as well as a few of their consumers;
Is it necessary to rename LdapNamingEnumeration to
LdapNameClassPairEnumeration? I think it might not good for sustaining
work, as when backport a fix from JDK 8 to previous releases, we will
have to recognize and rename the class accordingly.

Otherwise, looks fine to me.

>   * Made a few additional small changes that were discussed.
> 
I did not review other updates. There are too many files, if you want me
review all of the changes again, please let me know.

Thanks,
Xuelei

> Thanks to everyone who reviewed the last version!
> 
> Thanks,
> Sasha
> 
> On 8/4/2011 2:00 PM, Alexandre Boulgakov wrote:
>>
>> On 8/3/2011 10:44 PM, Joe Darcy wrote:
>>> David Holmes wrote:
>>>> Joe Darcy said the following on 08/04/11 12:33:
>>>>> David Holmes wrote:
>>>>>>> Using wildcards makes the subtyping work along the type argument
>>>>>>> axis.
>>>>>>
>>>>>> So what is the right fix here? To declare the underlying Vector as
>>>>>> a Vector<?> and cast it to something concrete when needed? It
>>>>>> seems very wrong to me to be inserting raw type casts all through
>>>>>> this code.
>>>>>
>>>>> It isn't entirely clear to be from a quick inspection of the code
>>>>> what the actual type usage is.  A writable general Vector should be
>>>>> a Vector<Object> and Vector just meant for reading should be a
>>>>> Vector<?> (or the equivalent Vector<? extends Object>).
>>>>>
>>>>> If the type usage is "a sequence of X's and Y's" where X and Y
>>>>> don't have some useful supertype, I would recommend using a
>>>>> somewhat different set of data structures, like a list of type-safe
>>>>> heterogeneous containers or a list of a new package-level XorY class.
>>>>
>>>> Buried in one of Sasha's emails it says:
>>>>
>>>> "The current code uses it to store Strings and Vector<String>s."
>>>>
>>>> Hence it is declared Vector<Object>.
>>>>
>>>> This is looking to me like code that should not have been generified.
>>>>
>>>
>>> Hmm.  If String or Vector<String> are the two kinds of stored values,
>>> I would recommend Vector<Vector<String>> where a lone string was
>>> wrapped in a vector.  (Actually, I would recommend a
>>> List<List<String>>, but that may be beyond the scope of this cleanup.
>>
>> I can do Vector<Vector<String>>.
>>
>> List<List<String>> is probably beyond the scope of removing compiler
>> warnings; getting rid of Vectors and Hashtables in general could take
>> a whole summer by itself, and would probably be best to do as a whole,
>> since it's not always clear at first glance if other classes depend on
>> a particular object being a Vector.
>>
>> -Sasha
>>>
>>> -Joe
>>>



From alexandre.boulgakov at oracle.com  Tue Aug  9 02:16:55 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Mon, 8 Aug 2011 19:16:55 -0700 (PDT)
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
Message-ID: <c80e9908-47f1-4f0f-83d9-46ba9f14a207@default>

I can change it back to LdapNamingEnumeration. I just thought it would be more consistent with LdapBindingEnumeration and LdapSearchEnumeration. I did not think of the back-porting issue. Would it be better to change AbstractLdapNamingEnumeration to LdapNamingEnumeration, as far as back-porting, since they share the most code? Or do you mean for back-porting code that uses these enumerations?

I don't think you need to review the other changes; they are specific change that were already discussed and agreed on.

Thanks,
Sasha

----- Original Message -----
From: xuelei.fan at oracle.com
To: alexandre.boulgakov at oracle.com
Cc: joe.darcy at oracle.com, core-libs-dev at openjdk.java.net
Sent: Monday, August 8, 2011 6:58:41 PM GMT -08:00 US/Canada Pacific
Subject: Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]

On 8/6/2011 2:11 AM, Alexandre Boulgakov wrote:
> Here's the second version:
> http://cr.openjdk.java.net/~mduigou/7072353/2/webrev/
> <http://cr.openjdk.java.net/%7Emduigou/7072353/2/webrev/>
> 
>   * Changed LdapResult.referrals to be a Vector<Vector<String>>;
>   * Refactored
>       o com/sun/jndi/dns/DnsContext.java: BaseNameClassPairEnumeration<T>;
>       o com/sun/jndi/toolkit/dir/HierMemDirCtx.java: BaseFlatNames<T>;
>       o com/sun/jndi/ldap/*.java: refactored LdapNamingEnumeration into
>         AbstractLdapNamingEnumeration, LdapNameClassPairEnumeration;
>         changed LdapBindingEnumeration and LdapSearchEnumeration
>         accordingly, as well as a few of their consumers;
Is it necessary to rename LdapNamingEnumeration to
LdapNameClassPairEnumeration? I think it might not good for sustaining
work, as when backport a fix from JDK 8 to previous releases, we will
have to recognize and rename the class accordingly.

Otherwise, looks fine to me.

>   * Made a few additional small changes that were discussed.
> 
I did not review other updates. There are too many files, if you want me
review all of the changes again, please let me know.

Thanks,
Xuelei

> Thanks to everyone who reviewed the last version!
> 
> Thanks,
> Sasha
> 
> On 8/4/2011 2:00 PM, Alexandre Boulgakov wrote:
>>
>> On 8/3/2011 10:44 PM, Joe Darcy wrote:
>>> David Holmes wrote:
>>>> Joe Darcy said the following on 08/04/11 12:33:
>>>>> David Holmes wrote:
>>>>>>> Using wildcards makes the subtyping work along the type argument
>>>>>>> axis.
>>>>>>
>>>>>> So what is the right fix here? To declare the underlying Vector as
>>>>>> a Vector<?> and cast it to something concrete when needed? It
>>>>>> seems very wrong to me to be inserting raw type casts all through
>>>>>> this code.
>>>>>
>>>>> It isn't entirely clear to be from a quick inspection of the code
>>>>> what the actual type usage is.  A writable general Vector should be
>>>>> a Vector<Object> and Vector just meant for reading should be a
>>>>> Vector<?> (or the equivalent Vector<? extends Object>).
>>>>>
>>>>> If the type usage is "a sequence of X's and Y's" where X and Y
>>>>> don't have some useful supertype, I would recommend using a
>>>>> somewhat different set of data structures, like a list of type-safe
>>>>> heterogeneous containers or a list of a new package-level XorY class.
>>>>
>>>> Buried in one of Sasha's emails it says:
>>>>
>>>> "The current code uses it to store Strings and Vector<String>s."
>>>>
>>>> Hence it is declared Vector<Object>.
>>>>
>>>> This is looking to me like code that should not have been generified.
>>>>
>>>
>>> Hmm.  If String or Vector<String> are the two kinds of stored values,
>>> I would recommend Vector<Vector<String>> where a lone string was
>>> wrapped in a vector.  (Actually, I would recommend a
>>> List<List<String>>, but that may be beyond the scope of this cleanup.
>>
>> I can do Vector<Vector<String>>.
>>
>> List<List<String>> is probably beyond the scope of removing compiler
>> warnings; getting rid of Vectors and Hashtables in general could take
>> a whole summer by itself, and would probably be best to do as a whole,
>> since it's not always clear at first glance if other classes depend on
>> a particular object being a Vector.
>>
>> -Sasha
>>>
>>> -Joe
>>>



From Xuelei.Fan at Oracle.Com  Tue Aug  9 02:28:52 2011
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Tue, 9 Aug 2011 10:28:52 +0800
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <c80e9908-47f1-4f0f-83d9-46ba9f14a207@default>
References: <c80e9908-47f1-4f0f-83d9-46ba9f14a207@default>
Message-ID: <EB72E59A-C830-421E-AEF6-EE093FA1CAA0@Oracle.Com>



On Aug 9, 2011, at 10:16 AM, Alexandre Boulgakov <alexandre.boulgakov at oracle.com> wrote:

> I can change it back to LdapNamingEnumeration. I just thought it would be more consistent with LdapBindingEnumeration and LdapSearchEnumeration. I did not think of the back-porting issue. Would it be better to change AbstractLdapNamingEnumeration to LdapNamingEnumeration, as far as back-porting, since they share the most code? Or do you mean for back-porting code that uses these enumerations?
> 
I would prefer to change it back to LNE, and keep the new ALNE class, since the most confusing place is the code using the LNE, I think.

Xuelei



> I don't think you need to review the other changes; they are specific change that were already discussed and agreed on.
> 
> Thanks,
> Sasha
> 
> ----- Original Message -----
> From: xuelei.fan at oracle.com
> To: alexandre.boulgakov at oracle.com
> Cc: joe.darcy at oracle.com, core-libs-dev at openjdk.java.net
> Sent: Monday, August 8, 2011 6:58:41 PM GMT -08:00 US/Canada Pacific
> Subject: Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]
> 
> On 8/6/2011 2:11 AM, Alexandre Boulgakov wrote:
>> Here's the second version:
>> http://cr.openjdk.java.net/~mduigou/7072353/2/webrev/
>> <http://cr.openjdk.java.net/%7Emduigou/7072353/2/webrev/>
>> 
>>  * Changed LdapResult.referrals to be a Vector<Vector<String>>;
>>  * Refactored
>>      o com/sun/jndi/dns/DnsContext.java: BaseNameClassPairEnumeration<T>;
>>      o com/sun/jndi/toolkit/dir/HierMemDirCtx.java: BaseFlatNames<T>;
>>      o com/sun/jndi/ldap/*.java: refactored LdapNamingEnumeration into
>>        AbstractLdapNamingEnumeration, LdapNameClassPairEnumeration;
>>        changed LdapBindingEnumeration and LdapSearchEnumeration
>>        accordingly, as well as a few of their consumers;
> Is it necessary to rename LdapNamingEnumeration to
> LdapNameClassPairEnumeration? I think it might not good for sustaining
> work, as when backport a fix from JDK 8 to previous releases, we will
> have to recognize and rename the class accordingly.
> 
> Otherwise, looks fine to me.
> 
>>  * Made a few additional small changes that were discussed.
>> 
> I did not review other updates. There are too many files, if you want me
> review all of the changes again, please let me know.
> 
> Thanks,
> Xuelei
> 
>> Thanks to everyone who reviewed the last version!
>> 
>> Thanks,
>> Sasha
>> 
>> On 8/4/2011 2:00 PM, Alexandre Boulgakov wrote:
>>> 
>>> On 8/3/2011 10:44 PM, Joe Darcy wrote:
>>>> David Holmes wrote:
>>>>> Joe Darcy said the following on 08/04/11 12:33:
>>>>>> David Holmes wrote:
>>>>>>>> Using wildcards makes the subtyping work along the type argument
>>>>>>>> axis.
>>>>>>> 
>>>>>>> So what is the right fix here? To declare the underlying Vector as
>>>>>>> a Vector<?> and cast it to something concrete when needed? It
>>>>>>> seems very wrong to me to be inserting raw type casts all through
>>>>>>> this code.
>>>>>> 
>>>>>> It isn't entirely clear to be from a quick inspection of the code
>>>>>> what the actual type usage is.  A writable general Vector should be
>>>>>> a Vector<Object> and Vector just meant for reading should be a
>>>>>> Vector<?> (or the equivalent Vector<? extends Object>).
>>>>>> 
>>>>>> If the type usage is "a sequence of X's and Y's" where X and Y
>>>>>> don't have some useful supertype, I would recommend using a
>>>>>> somewhat different set of data structures, like a list of type-safe
>>>>>> heterogeneous containers or a list of a new package-level XorY class.
>>>>> 
>>>>> Buried in one of Sasha's emails it says:
>>>>> 
>>>>> "The current code uses it to store Strings and Vector<String>s."
>>>>> 
>>>>> Hence it is declared Vector<Object>.
>>>>> 
>>>>> This is looking to me like code that should not have been generified.
>>>>> 
>>>> 
>>>> Hmm.  If String or Vector<String> are the two kinds of stored values,
>>>> I would recommend Vector<Vector<String>> where a lone string was
>>>> wrapped in a vector.  (Actually, I would recommend a
>>>> List<List<String>>, but that may be beyond the scope of this cleanup.
>>> 
>>> I can do Vector<Vector<String>>.
>>> 
>>> List<List<String>> is probably beyond the scope of removing compiler
>>> warnings; getting rid of Vectors and Hashtables in general could take
>>> a whole summer by itself, and would probably be best to do as a whole,
>>> since it's not always clear at first glance if other classes depend on
>>> a particular object being a Vector.
>>> 
>>> -Sasha
>>>> 
>>>> -Joe
>>>> 
> 


From alexandre.boulgakov at oracle.com  Tue Aug  9 07:55:38 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Tue, 9 Aug 2011 00:55:38 -0700 (PDT)
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
Message-ID: <56aed32f-39b2-44c5-89a2-3cb58f0eabae@default>

That makes sense. I'll do that with automatic refactoring in Netbeans. Do you want me to send another webrev afterwards?

Thanks,
Sasha

----- Original Message -----
From: Xuelei.Fan at oracle.com
To: alexandre.boulgakov at oracle.com
Cc: joe.darcy at oracle.com, core-libs-dev at openjdk.java.net
Sent: Monday, August 8, 2011 7:30:09 PM GMT -08:00 US/Canada Pacific
Subject: Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]



On Aug 9, 2011, at 10:16 AM, Alexandre Boulgakov <alexandre.boulgakov at oracle.com> wrote:

> I can change it back to LdapNamingEnumeration. I just thought it would be more consistent with LdapBindingEnumeration and LdapSearchEnumeration. I did not think of the back-porting issue. Would it be better to change AbstractLdapNamingEnumeration to LdapNamingEnumeration, as far as back-porting, since they share the most code? Or do you mean for back-porting code that uses these enumerations?
> 
I would prefer to change it back to LNE, and keep the new ALNE class, since the most confusing place is the code using the LNE, I think.

Xuelei



> I don't think you need to review the other changes; they are specific change that were already discussed and agreed on.
> 
> Thanks,
> Sasha
> 
> ----- Original Message -----
> From: xuelei.fan at oracle.com
> To: alexandre.boulgakov at oracle.com
> Cc: joe.darcy at oracle.com, core-libs-dev at openjdk.java.net
> Sent: Monday, August 8, 2011 6:58:41 PM GMT -08:00 US/Canada Pacific
> Subject: Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]
> 
> On 8/6/2011 2:11 AM, Alexandre Boulgakov wrote:
>> Here's the second version:
>> http://cr.openjdk.java.net/~mduigou/7072353/2/webrev/
>> <http://cr.openjdk.java.net/%7Emduigou/7072353/2/webrev/>
>> 
>>  * Changed LdapResult.referrals to be a Vector<Vector<String>>;
>>  * Refactored
>>      o com/sun/jndi/dns/DnsContext.java: BaseNameClassPairEnumeration<T>;
>>      o com/sun/jndi/toolkit/dir/HierMemDirCtx.java: BaseFlatNames<T>;
>>      o com/sun/jndi/ldap/*.java: refactored LdapNamingEnumeration into
>>        AbstractLdapNamingEnumeration, LdapNameClassPairEnumeration;
>>        changed LdapBindingEnumeration and LdapSearchEnumeration
>>        accordingly, as well as a few of their consumers;
> Is it necessary to rename LdapNamingEnumeration to
> LdapNameClassPairEnumeration? I think it might not good for sustaining
> work, as when backport a fix from JDK 8 to previous releases, we will
> have to recognize and rename the class accordingly.
> 
> Otherwise, looks fine to me.
> 
>>  * Made a few additional small changes that were discussed.
>> 
> I did not review other updates. There are too many files, if you want me
> review all of the changes again, please let me know.
> 
> Thanks,
> Xuelei
> 
>> Thanks to everyone who reviewed the last version!
>> 
>> Thanks,
>> Sasha
>> 
>> On 8/4/2011 2:00 PM, Alexandre Boulgakov wrote:
>>> 
>>> On 8/3/2011 10:44 PM, Joe Darcy wrote:
>>>> David Holmes wrote:
>>>>> Joe Darcy said the following on 08/04/11 12:33:
>>>>>> David Holmes wrote:
>>>>>>>> Using wildcards makes the subtyping work along the type argument
>>>>>>>> axis.
>>>>>>> 
>>>>>>> So what is the right fix here? To declare the underlying Vector as
>>>>>>> a Vector<?> and cast it to something concrete when needed? It
>>>>>>> seems very wrong to me to be inserting raw type casts all through
>>>>>>> this code.
>>>>>> 
>>>>>> It isn't entirely clear to be from a quick inspection of the code
>>>>>> what the actual type usage is.  A writable general Vector should be
>>>>>> a Vector<Object> and Vector just meant for reading should be a
>>>>>> Vector<?> (or the equivalent Vector<? extends Object>).
>>>>>> 
>>>>>> If the type usage is "a sequence of X's and Y's" where X and Y
>>>>>> don't have some useful supertype, I would recommend using a
>>>>>> somewhat different set of data structures, like a list of type-safe
>>>>>> heterogeneous containers or a list of a new package-level XorY class.
>>>>> 
>>>>> Buried in one of Sasha's emails it says:
>>>>> 
>>>>> "The current code uses it to store Strings and Vector<String>s."
>>>>> 
>>>>> Hence it is declared Vector<Object>.
>>>>> 
>>>>> This is looking to me like code that should not have been generified.
>>>>> 
>>>> 
>>>> Hmm.  If String or Vector<String> are the two kinds of stored values,
>>>> I would recommend Vector<Vector<String>> where a lone string was
>>>> wrapped in a vector.  (Actually, I would recommend a
>>>> List<List<String>>, but that may be beyond the scope of this cleanup.
>>> 
>>> I can do Vector<Vector<String>>.
>>> 
>>> List<List<String>> is probably beyond the scope of removing compiler
>>> warnings; getting rid of Vectors and Hashtables in general could take
>>> a whole summer by itself, and would probably be best to do as a whole,
>>> since it's not always clear at first glance if other classes depend on
>>> a particular object being a Vector.
>>> 
>>> -Sasha
>>>> 
>>>> -Joe
>>>> 
> 


From xuelei.fan at oracle.com  Tue Aug  9 09:53:13 2011
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 09 Aug 2011 17:53:13 +0800
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <56aed32f-39b2-44c5-89a2-3cb58f0eabae@default>
References: <56aed32f-39b2-44c5-89a2-3cb58f0eabae@default>
Message-ID: <4E410389.8070809@oracle.com>

On 8/9/2011 3:55 PM, Alexandre Boulgakov wrote:
> That makes sense. I'll do that with automatic refactoring in Netbeans. Do you want me to send another webrev afterwards?
> 
Just to confirm, you will change LdapNameClassPairEnumeration back to
LdapNamingEnumeration, and will not change the name
AbstractLdapNamingEnumeration, right? If the answer is right, I will not
need to review the webrev any more.

Generally, I will always generate a webrev with the latest update before
push the changes. Because in the future, some others may refer to the
webrev for other work, such as researching regression failure, backport,
etc.

Thanks for your cleanup the JNDI code.

Xuelei

> Thanks,
> Sasha
> 
> ----- Original Message -----
> From: Xuelei.Fan at oracle.com
> To: alexandre.boulgakov at oracle.com
> Cc: joe.darcy at oracle.com, core-libs-dev at openjdk.java.net
> Sent: Monday, August 8, 2011 7:30:09 PM GMT -08:00 US/Canada Pacific
> Subject: Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]
> 
> 
> 
> On Aug 9, 2011, at 10:16 AM, Alexandre Boulgakov <alexandre.boulgakov at oracle.com> wrote:
> 
>> I can change it back to LdapNamingEnumeration. I just thought it would be more consistent with LdapBindingEnumeration and LdapSearchEnumeration. I did not think of the back-porting issue. Would it be better to change AbstractLdapNamingEnumeration to LdapNamingEnumeration, as far as back-porting, since they share the most code? Or do you mean for back-porting code that uses these enumerations?
>>
> I would prefer to change it back to LNE, and keep the new ALNE class, since the most confusing place is the code using the LNE, I think.
> 
> Xuelei
> 
> 
> 
>> I don't think you need to review the other changes; they are specific change that were already discussed and agreed on.
>>
>> Thanks,
>> Sasha
>>
>> ----- Original Message -----
>> From: xuelei.fan at oracle.com
>> To: alexandre.boulgakov at oracle.com
>> Cc: joe.darcy at oracle.com, core-libs-dev at openjdk.java.net
>> Sent: Monday, August 8, 2011 6:58:41 PM GMT -08:00 US/Canada Pacific
>> Subject: Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]
>>
>> On 8/6/2011 2:11 AM, Alexandre Boulgakov wrote:
>>> Here's the second version:
>>> http://cr.openjdk.java.net/~mduigou/7072353/2/webrev/
>>> <http://cr.openjdk.java.net/%7Emduigou/7072353/2/webrev/>
>>>
>>>  * Changed LdapResult.referrals to be a Vector<Vector<String>>;
>>>  * Refactored
>>>      o com/sun/jndi/dns/DnsContext.java: BaseNameClassPairEnumeration<T>;
>>>      o com/sun/jndi/toolkit/dir/HierMemDirCtx.java: BaseFlatNames<T>;
>>>      o com/sun/jndi/ldap/*.java: refactored LdapNamingEnumeration into
>>>        AbstractLdapNamingEnumeration, LdapNameClassPairEnumeration;
>>>        changed LdapBindingEnumeration and LdapSearchEnumeration
>>>        accordingly, as well as a few of their consumers;
>> Is it necessary to rename LdapNamingEnumeration to
>> LdapNameClassPairEnumeration? I think it might not good for sustaining
>> work, as when backport a fix from JDK 8 to previous releases, we will
>> have to recognize and rename the class accordingly.
>>
>> Otherwise, looks fine to me.
>>
>>>  * Made a few additional small changes that were discussed.
>>>
>> I did not review other updates. There are too many files, if you want me
>> review all of the changes again, please let me know.
>>
>> Thanks,
>> Xuelei
>>
>>> Thanks to everyone who reviewed the last version!
>>>
>>> Thanks,
>>> Sasha
>>>
>>> On 8/4/2011 2:00 PM, Alexandre Boulgakov wrote:
>>>>
>>>> On 8/3/2011 10:44 PM, Joe Darcy wrote:
>>>>> David Holmes wrote:
>>>>>> Joe Darcy said the following on 08/04/11 12:33:
>>>>>>> David Holmes wrote:
>>>>>>>>> Using wildcards makes the subtyping work along the type argument
>>>>>>>>> axis.
>>>>>>>>
>>>>>>>> So what is the right fix here? To declare the underlying Vector as
>>>>>>>> a Vector<?> and cast it to something concrete when needed? It
>>>>>>>> seems very wrong to me to be inserting raw type casts all through
>>>>>>>> this code.
>>>>>>>
>>>>>>> It isn't entirely clear to be from a quick inspection of the code
>>>>>>> what the actual type usage is.  A writable general Vector should be
>>>>>>> a Vector<Object> and Vector just meant for reading should be a
>>>>>>> Vector<?> (or the equivalent Vector<? extends Object>).
>>>>>>>
>>>>>>> If the type usage is "a sequence of X's and Y's" where X and Y
>>>>>>> don't have some useful supertype, I would recommend using a
>>>>>>> somewhat different set of data structures, like a list of type-safe
>>>>>>> heterogeneous containers or a list of a new package-level XorY class.
>>>>>>
>>>>>> Buried in one of Sasha's emails it says:
>>>>>>
>>>>>> "The current code uses it to store Strings and Vector<String>s."
>>>>>>
>>>>>> Hence it is declared Vector<Object>.
>>>>>>
>>>>>> This is looking to me like code that should not have been generified.
>>>>>>
>>>>>
>>>>> Hmm.  If String or Vector<String> are the two kinds of stored values,
>>>>> I would recommend Vector<Vector<String>> where a lone string was
>>>>> wrapped in a vector.  (Actually, I would recommend a
>>>>> List<List<String>>, but that may be beyond the scope of this cleanup.
>>>>
>>>> I can do Vector<Vector<String>>.
>>>>
>>>> List<List<String>> is probably beyond the scope of removing compiler
>>>> warnings; getting rid of Vectors and Hashtables in general could take
>>>> a whole summer by itself, and would probably be best to do as a whole,
>>>> since it's not always clear at first glance if other classes depend on
>>>> a particular object being a Vector.
>>>>
>>>> -Sasha
>>>>>
>>>>> -Joe
>>>>>
>>



From Alan.Bateman at oracle.com  Tue Aug  9 11:43:14 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 09 Aug 2011 12:43:14 +0100
Subject: 7015589: (spec) BufferedWriter.close leaves stream open if close
	of underlying Writer fails
Message-ID: <4E411D52.1080509@oracle.com>


A few months back there was a bug report [1] pointing out that it's 
possible to continue writing to a BufferedWriter after invoking its 
close method and the close fails. A similar issue arises with 
BufferedOutputStream and other classes. At issue is whether a stream (or 
more generally a resource) is considered closed in the event that the 
close method fails. This isn't something that Closeable is clear on. Joe 
tells me that this didn't come up in the Coin discussions on 
try-with-resources either.

I think it's safe to say that it would be desirable that close releases 
the resources for failing cases as otherwise the resources may never be 
released (esp. with try-with-resources usages). Furthermore, when there 
are multiple resources involved, or cases like the bug report where one 
stream wraps another, then it would be desirable to keep the state of 
the resources in sync. To that end, the changes here propose adding an 
advisory note to AutoCloseable to advise implementers to release the 
underlying resources and to mark the resource as closed prior to 
throwing the exception.

For the specific buffering classes discussed at the time, these are 
changed to follow this advise (but their javadoc isn't changed as there 
may be other implementations or these classes extended in many ways). In 
the case of BufferedWriter it is also fixed so that any exception from 
flushing the underlying writer isn't supplanted by the exception from 
close. In the case of FilterOutputStream (BufferedOutputStream extends 
it) then it is fixed so that it doesn't ignore the exception thrown when 
flushing the underlying stream. This is clearly the right thing to do 
but it does mean that close can now throw an IOException for a case 
where it didn't before. For now I don't propose to include a 
compatibility switch but this may be something that has to revisited 
later. There are other classes in java.io that could also be cleaned up 
but I don't propose to do a complete audit at this time.

The webrev with the changes is here:
   http://cr.openjdk.java.net/~alanb/7015589/webrev/

Thanks,
Alan.

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005732.html


From chris.hegarty at oracle.com  Tue Aug  9 13:05:08 2011
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 09 Aug 2011 14:05:08 +0100
Subject: Code Review 7073295: TEST_BUG:
	test/java/lang/instrument/ManifestTest.sh causing havoc (win)
Message-ID: <4E413084.7020105@oracle.com>

Hi,

This test creates temporary directories in the scratch area with spaces 
in their names. It fails on Cygwin because jtreg cannot cleanup after 
it. Easiest to just have the test cleanup (minimally) after itself.

Webrev:
   http://cr.openjdk.java.net/~chegar/7073295/webrev.00/webrev/

Thanks,
-Chris.


From forax at univ-mlv.fr  Tue Aug  9 13:10:26 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 09 Aug 2011 15:10:26 +0200
Subject: 7015589: (spec) BufferedWriter.close leaves stream open if close
	of underlying Writer fails
In-Reply-To: <4E411D52.1080509@oracle.com>
References: <4E411D52.1080509@oracle.com>
Message-ID: <4E4131C2.6000203@univ-mlv.fr>

On 08/09/2011 01:43 PM, Alan Bateman wrote:
>
> A few months back there was a bug report [1] pointing out that it's 
> possible to continue writing to a BufferedWriter after invoking its 
> close method and the close fails. A similar issue arises with 
> BufferedOutputStream and other classes. At issue is whether a stream 
> (or more generally a resource) is considered closed in the event that 
> the close method fails. This isn't something that Closeable is clear 
> on. Joe tells me that this didn't come up in the Coin discussions on 
> try-with-resources either.
>
> I think it's safe to say that it would be desirable that close 
> releases the resources for failing cases as otherwise the resources 
> may never be released (esp. with try-with-resources usages). 
> Furthermore, when there are multiple resources involved, or cases like 
> the bug report where one stream wraps another, then it would be 
> desirable to keep the state of the resources in sync. To that end, the 
> changes here propose adding an advisory note to AutoCloseable to 
> advise implementers to release the underlying resources and to mark 
> the resource as closed prior to throwing the exception.
>
> For the specific buffering classes discussed at the time, these are 
> changed to follow this advise (but their javadoc isn't changed as 
> there may be other implementations or these classes extended in many 
> ways). In the case of BufferedWriter it is also fixed so that any 
> exception from flushing the underlying writer isn't supplanted by the 
> exception from close. In the case of FilterOutputStream 
> (BufferedOutputStream extends it) then it is fixed so that it doesn't 
> ignore the exception thrown when flushing the underlying stream. This 
> is clearly the right thing to do but it does mean that close can now 
> throw an IOException for a case where it didn't before. For now I 
> don't propose to include a compatibility switch but this may be 
> something that has to revisited later. There are other classes in 
> java.io that could also be cleaned up but I don't propose to do a 
> complete audit at this time.
>
> The webrev with the changes is here:
>   http://cr.openjdk.java.net/~alanb/7015589/webrev/
>
> Thanks,
> Alan.
>
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005732.html

Let's close() close :)
Patch looks good.

R?mi


From chris.hegarty at oracle.com  Tue Aug  9 14:29:36 2011
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 09 Aug 2011 15:29:36 +0100
Subject: Fwd: Code Review 7073295:
	TEST_BUG:	test/java/lang/instrument/ManifestTest.sh
	causing havoc (win)
Message-ID: <4E414450.9040006@oracle.com>

Sorry, should have cc'ed serviceability-dev at openjdk.java.net too.

-Chris.

-------- Original Message --------
Subject: Code Review 7073295: TEST_BUG: 
test/java/lang/instrument/ManifestTest.sh causing havoc (win)
Date: Tue, 09 Aug 2011 14:05:08 +0100
From: Chris Hegarty <chris.hegarty at oracle.com>
To: core-libs-dev <core-libs-dev at openjdk.java.net>, 
"alan.bateman at oracle.com" <alan.bateman at oracle.com>

Hi,

This test creates temporary directories in the scratch area with spaces
in their names. It fails on Cygwin because jtreg cannot cleanup after
it. Easiest to just have the test cleanup (minimally) after itself.

Webrev:
   http://cr.openjdk.java.net/~chegar/7073295/webrev.00/webrev/

Thanks,
-Chris.


From chris.hegarty at oracle.com  Tue Aug  9 14:52:41 2011
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 09 Aug 2011 15:52:41 +0100
Subject: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup in
	Cygwin
Message-ID: <4E4149B9.1010909@oracle.com>

Hi Dan, Alan,

This is a trivial change to use /dev/null instead of NUL for Windows 
test with Cygwin.

http://cr.openjdk.java.net/~chegar/7076756/webrev.00/webrev/

Thanks,
-Chris.


From Alan.Bateman at oracle.com  Tue Aug  9 15:07:16 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 09 Aug 2011 16:07:16 +0100
Subject: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup
	in Cygwin
In-Reply-To: <4E4149B9.1010909@oracle.com>
References: <4E4149B9.1010909@oracle.com>
Message-ID: <4E414D24.2010003@oracle.com>

Chris Hegarty wrote:
> Hi Dan, Alan,
>
> This is a trivial change to use /dev/null instead of NUL for Windows 
> test with Cygwin.
>
> http://cr.openjdk.java.net/~chegar/7076756/webrev.00/webrev/
>
> Thanks,
> -Chris.
Looks okay although it might be slightly cleaner to set devnull 
consistently, ie:

case Windows* )
  devnull=NUL
  ;;

Just a suggestion.

-Alan.


From mandy.chung at oracle.com  Tue Aug  9 15:11:04 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 09 Aug 2011 08:11:04 -0700
Subject: Code Review 7073295: TEST_BUG:
	test/java/lang/instrument/ManifestTest.sh causing havoc (win)
In-Reply-To: <4E413084.7020105@oracle.com>
References: <4E413084.7020105@oracle.com>
Message-ID: <4E414E08.8060409@oracle.com>

Looks good.

Mandy

On 8/9/11 6:05 AM, Chris Hegarty wrote:
> Hi,
>
> This test creates temporary directories in the scratch area with 
> spaces in their names. It fails on Cygwin because jtreg cannot cleanup 
> after it. Easiest to just have the test cleanup (minimally) after itself.
>
> Webrev:
>   http://cr.openjdk.java.net/~chegar/7073295/webrev.00/webrev/
>
> Thanks,
> -Chris.



From chris.hegarty at oracle.com  Tue Aug  9 15:40:42 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 09 Aug 2011 15:40:42 +0000
Subject: hg: jdk8/tl/jdk: 7073295: TEST_BUG:
	test/java/lang/instrument/ManifestTest.sh causing havoc (win)
Message-ID: <20110809154108.32B0647A55@hg.openjdk.java.net>

Changeset: 26fe74aa48ef
Author:    chegar
Date:      2011-08-09 16:39 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26fe74aa48ef

7073295: TEST_BUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win)
Reviewed-by: mchung

! test/java/lang/instrument/ManifestTest.sh



From daniel.daugherty at oracle.com  Tue Aug  9 15:52:55 2011
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 09 Aug 2011 09:52:55 -0600
Subject: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup
	in Cygwin
In-Reply-To: <4E4149B9.1010909@oracle.com>
References: <4E4149B9.1010909@oracle.com>
Message-ID: <4E4157D7.9060309@oracle.com>

On 8/9/11 8:52 AM, Chris Hegarty wrote:
> Hi Dan, Alan,
>
> This is a trivial change to use /dev/null instead of NUL for Windows 
> test with Cygwin.
>
> http://cr.openjdk.java.net/~chegar/7076756/webrev.00/webrev/
>
> Thanks,
> -Chris.

I'm good with the change, but the bug report itself is less than clear.

I run these tests all the time on WinXP/Cygwin so I'm guessing
that there is more going on here than meets the eye. I'm going to
guess that the '-samevm' option is the enabler for this failure
mode. The failure mode that you fixed should also affect tests
other than BreakpointWithFullGC.sh so I'm not quite sure why
this issue appears with just that test. Or maybe it does appear
with other tests, but again the bug report isn't clear.

In any case, thumbs up on the change.

Dan



From chris.hegarty at oracle.com  Tue Aug  9 15:56:49 2011
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 09 Aug 2011 16:56:49 +0100
Subject: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup
	in Cygwin
In-Reply-To: <4E4157D7.9060309@oracle.com>
References: <4E4149B9.1010909@oracle.com> <4E4157D7.9060309@oracle.com>
Message-ID: <4E4158C1.8000502@oracle.com>

Sorry Dan, I'll put a more complete description in the bug report.

This issue, from what I can tell only happens with very recent Cygwin 
versions. I'm running 1.7.9. When running the com/sun/jdi tests in a 
batch, in samevm mode, this test leave behind a file, NUL, in the 
scratch directory that cannot be deleted. This causes the remaining 
tests to also fail.

Thanks for the review,
-Chris.

On 08/ 9/11 04:52 PM, Daniel D. Daugherty wrote:
> On 8/9/11 8:52 AM, Chris Hegarty wrote:
>> Hi Dan, Alan,
>>
>> This is a trivial change to use /dev/null instead of NUL for Windows
>> test with Cygwin.
>>
>> http://cr.openjdk.java.net/~chegar/7076756/webrev.00/webrev/
>>
>> Thanks,
>> -Chris.
>
> I'm good with the change, but the bug report itself is less than clear.
>
> I run these tests all the time on WinXP/Cygwin so I'm guessing
> that there is more going on here than meets the eye. I'm going to
> guess that the '-samevm' option is the enabler for this failure
> mode. The failure mode that you fixed should also affect tests
> other than BreakpointWithFullGC.sh so I'm not quite sure why
> this issue appears with just that test. Or maybe it does appear
> with other tests, but again the bug report isn't clear.
>
> In any case, thumbs up on the change.
>
> Dan
>


From chris.hegarty at oracle.com  Tue Aug  9 16:00:41 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 09 Aug 2011 16:00:41 +0000
Subject: hg: jdk8/tl/jdk: 7076756: TEST_BUG:
	com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup in Cygwin
Message-ID: <20110809160051.5F3A647A58@hg.openjdk.java.net>

Changeset: cf203f293b4e
Author:    chegar
Date:      2011-08-09 16:59 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf203f293b4e

7076756: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup in Cygwin
Reviewed-by: alanb, dcubed

! test/com/sun/jdi/ShellScaffold.sh



From daniel.daugherty at oracle.com  Tue Aug  9 16:11:16 2011
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 09 Aug 2011 10:11:16 -0600
Subject: Fwd: Code Review 7073295:
	TEST_BUG:	test/java/lang/instrument/ManifestTest.sh
	causing havoc (win)
In-Reply-To: <4E414450.9040006@oracle.com>
References: <4E414450.9040006@oracle.com>
Message-ID: <4E415C24.1090302@oracle.com>

On 8/9/11 8:29 AM, Chris Hegarty wrote:
> Sorry, should have cc'ed serviceability-dev at openjdk.java.net too.
>
> -Chris.
>
> -------- Original Message --------
> Subject: Code Review 7073295: TEST_BUG: 
> test/java/lang/instrument/ManifestTest.sh causing havoc (win)
> Date: Tue, 09 Aug 2011 14:05:08 +0100
> From: Chris Hegarty <chris.hegarty at oracle.com>
> To: core-libs-dev <core-libs-dev at openjdk.java.net>, 
> "alan.bateman at oracle.com" <alan.bateman at oracle.com>
>
> Hi,
>
> This test creates temporary directories in the scratch area with spaces
> in their names. It fails on Cygwin because jtreg cannot cleanup after
> it. Easiest to just have the test cleanup (minimally) after itself.
>
> Webrev:
>   http://cr.openjdk.java.net/~chegar/7073295/webrev.00/webrev/
>
> Thanks,
> -Chris.

I run these tests all the time on WinXP/Cygwin so the use of the
'-samevm' option is the enabler here also. 'samevm' mode is mentioned
in this bug report (yeah!), but it could be more clear that the test
falls over because that option is used.

Alan and I discussed this test off list and our last hypothesis was
that the strange filenames/dirnames were the culprit. I just didn't
get back to the issue. Sorry about that.

I'm not quite sure I have my brain wrapped around why
ExampleForBootClassPath had to be added to the "@run build" line,
but I'm OK with that change also.

I'm presuming that you are only cleaning up the hard to remove stuff
and leaving the other dirs for JTREG to clean up. For example, there
are two dirs: "has_leading_blank" and " has_leading_blank". The dir
without the blank has the bad class file in it to make sure that we
actually use the right dir (the one with the blank in it). Your fix
only removes " has_leading_blank" and "has_leading_blank" is left
behind.

The bug ID list should also be updated, but that's a nit.

Thumbs up.

Dan





From james.holmlund at oracle.com  Tue Aug  9 16:18:38 2011
From: james.holmlund at oracle.com (Jim Holmlund)
Date: Tue, 09 Aug 2011 09:18:38 -0700
Subject: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup
	in Cygwin
In-Reply-To: <4E4158C1.8000502@oracle.com>
References: <4E4149B9.1010909@oracle.com> <4E4157D7.9060309@oracle.com>
	<4E4158C1.8000502@oracle.com>
Message-ID: <4E415DDE.1060504@oracle.com>

Will this work on older versions of cygwin?  Or do we have a spec someplace that says cygwin 
versions older than xxxx aren't supported?
- jjh


On 8/9/2011 8:56 AM, Chris Hegarty wrote:
> Sorry Dan, I'll put a more complete description in the bug report.
>
> This issue, from what I can tell only happens with very recent Cygwin versions. I'm running 1.7.9. 
> When running the com/sun/jdi tests in a batch, in samevm mode, this test leave behind a file, NUL, 
> in the scratch directory that cannot be deleted. This causes the remaining tests to also fail.
>
> Thanks for the review,
> -Chris.
>
> On 08/ 9/11 04:52 PM, Daniel D. Daugherty wrote:
>> On 8/9/11 8:52 AM, Chris Hegarty wrote:
>>> Hi Dan, Alan,
>>>
>>> This is a trivial change to use /dev/null instead of NUL for Windows
>>> test with Cygwin.
>>>
>>> http://cr.openjdk.java.net/~chegar/7076756/webrev.00/webrev/
>>>
>>> Thanks,
>>> -Chris.
>>
>> I'm good with the change, but the bug report itself is less than clear.
>>
>> I run these tests all the time on WinXP/Cygwin so I'm guessing
>> that there is more going on here than meets the eye. I'm going to
>> guess that the '-samevm' option is the enabler for this failure
>> mode. The failure mode that you fixed should also affect tests
>> other than BreakpointWithFullGC.sh so I'm not quite sure why
>> this issue appears with just that test. Or maybe it does appear
>> with other tests, but again the bug report isn't clear.
>>
>> In any case, thumbs up on the change.
>>
>> Dan
>>


From daniel.daugherty at oracle.com  Tue Aug  9 16:23:14 2011
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 09 Aug 2011 10:23:14 -0600
Subject: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup
	in Cygwin
In-Reply-To: <4E415DDE.1060504@oracle.com>
References: <4E4149B9.1010909@oracle.com> <4E4157D7.9060309@oracle.com>
	<4E4158C1.8000502@oracle.com> <4E415DDE.1060504@oracle.com>
Message-ID: <4E415EF2.4060709@oracle.com>

Yes, "/dev/null" works with the "1.5.X" version of Cygwin.
1.5.X is considered the "legacy" version of Cygwin and I
believe the VM/SQE is still using it in the nightly testing
infrastructure.

Dan

547 2011.08.09 10:22:32 $ uname -a
CYGWIN_NT-5.1 oliver-lt 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

548 2011.08.09 10:22:41 $ ls -l /dev/null
crw-rw-rw- 1 dcubed None 1, 3 Nov 30  2006 /dev/null

549 2011.08.09 10:22:45 $ echo "hello" > /dev/null

550 2011.08.09 10:22:52 $



On 8/9/11 10:18 AM, Jim Holmlund wrote:
> Will this work on older versions of cygwin?  Or do we have a spec 
> someplace that says cygwin versions older than xxxx aren't supported?
> - jjh
>
>
> On 8/9/2011 8:56 AM, Chris Hegarty wrote:
>> Sorry Dan, I'll put a more complete description in the bug report.
>>
>> This issue, from what I can tell only happens with very recent Cygwin 
>> versions. I'm running 1.7.9. When running the com/sun/jdi tests in a 
>> batch, in samevm mode, this test leave behind a file, NUL, in the 
>> scratch directory that cannot be deleted. This causes the remaining 
>> tests to also fail.
>>
>> Thanks for the review,
>> -Chris.
>>
>> On 08/ 9/11 04:52 PM, Daniel D. Daugherty wrote:
>>> On 8/9/11 8:52 AM, Chris Hegarty wrote:
>>>> Hi Dan, Alan,
>>>>
>>>> This is a trivial change to use /dev/null instead of NUL for Windows
>>>> test with Cygwin.
>>>>
>>>> http://cr.openjdk.java.net/~chegar/7076756/webrev.00/webrev/
>>>>
>>>> Thanks,
>>>> -Chris.
>>>
>>> I'm good with the change, but the bug report itself is less than clear.
>>>
>>> I run these tests all the time on WinXP/Cygwin so I'm guessing
>>> that there is more going on here than meets the eye. I'm going to
>>> guess that the '-samevm' option is the enabler for this failure
>>> mode. The failure mode that you fixed should also affect tests
>>> other than BreakpointWithFullGC.sh so I'm not quite sure why
>>> this issue appears with just that test. Or maybe it does appear
>>> with other tests, but again the bug report isn't clear.
>>>
>>> In any case, thumbs up on the change.
>>>
>>> Dan
>>>


From chris.hegarty at oracle.com  Tue Aug  9 16:25:55 2011
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 09 Aug 2011 17:25:55 +0100
Subject: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup
	in Cygwin
In-Reply-To: <4E415DDE.1060504@oracle.com>
References: <4E4149B9.1010909@oracle.com> <4E4157D7.9060309@oracle.com>
	<4E4158C1.8000502@oracle.com> <4E415DDE.1060504@oracle.com>
Message-ID: <4E415F93.4020605@oracle.com>

On 08/ 9/11 05:18 PM, Jim Holmlund wrote:
> Will this work on older versions of cygwin?  Or do we have a spec
> someplace that says cygwin versions older than xxxx aren't supported?

I have not seen any docs/spec anywhere for support of /dev/null in 
specific Cygwin releases, but I did test on 1.5 and 1.7.9 and MKS, and 
all went fine.

http://www.cygwin.com/cygwin-ug-net/using-specialnames.html

I didn't have time to submit a jprt job on this, but tested on Windows 
Cygwin/MKS, Solaris, and Linux. I believe the TL integrator will be 
doing a full jprt run later today.  If we don't see a few hundred 
failures then we should be good ;-)

-Chris.

> - jjh
>
>
> On 8/9/2011 8:56 AM, Chris Hegarty wrote:
>> Sorry Dan, I'll put a more complete description in the bug report.
>>
>> This issue, from what I can tell only happens with very recent Cygwin
>> versions. I'm running 1.7.9. When running the com/sun/jdi tests in a
>> batch, in samevm mode, this test leave behind a file, NUL, in the
>> scratch directory that cannot be deleted. This causes the remaining
>> tests to also fail.
>>
>> Thanks for the review,
>> -Chris.
>>
>> On 08/ 9/11 04:52 PM, Daniel D. Daugherty wrote:
>>> On 8/9/11 8:52 AM, Chris Hegarty wrote:
>>>> Hi Dan, Alan,
>>>>
>>>> This is a trivial change to use /dev/null instead of NUL for Windows
>>>> test with Cygwin.
>>>>
>>>> http://cr.openjdk.java.net/~chegar/7076756/webrev.00/webrev/
>>>>
>>>> Thanks,
>>>> -Chris.
>>>
>>> I'm good with the change, but the bug report itself is less than clear.
>>>
>>> I run these tests all the time on WinXP/Cygwin so I'm guessing
>>> that there is more going on here than meets the eye. I'm going to
>>> guess that the '-samevm' option is the enabler for this failure
>>> mode. The failure mode that you fixed should also affect tests
>>> other than BreakpointWithFullGC.sh so I'm not quite sure why
>>> this issue appears with just that test. Or maybe it does appear
>>> with other tests, but again the bug report isn't clear.
>>>
>>> In any case, thumbs up on the change.
>>>
>>> Dan
>>>


From james.holmlund at oracle.com  Tue Aug  9 16:59:36 2011
From: james.holmlund at oracle.com (Jim Holmlund)
Date: Tue, 09 Aug 2011 09:59:36 -0700
Subject: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup
	in Cygwin
In-Reply-To: <4E415F93.4020605@oracle.com>
References: <4E4149B9.1010909@oracle.com> <4E4157D7.9060309@oracle.com>
	<4E4158C1.8000502@oracle.com> <4E415DDE.1060504@oracle.com>
	<4E415F93.4020605@oracle.com>
Message-ID: <4E416778.1040509@oracle.com>


> Yes, "/dev/null" works with the "1.5.X" version of Cygwin.
> 1.5.X is considered the "legacy" version of Cygwin and I
> believe the VM/SQE is still using it in the nightly testing
> infrastructure.
>
> Dan

Ok thanks Chris and Dan.  When I created ShellScaffold.sh long ago and far away, it must have been 
on a pre 1.5 version of cygwin.
- jjh


On 8/9/2011 9:25 AM, Chris Hegarty wrote:
> On 08/ 9/11 05:18 PM, Jim Holmlund wrote:
>> Will this work on older versions of cygwin?  Or do we have a spec
>> someplace that says cygwin versions older than xxxx aren't supported?
>
> I have not seen any docs/spec anywhere for support of /dev/null in specific Cygwin releases, but I 
> did test on 1.5 and 1.7.9 and MKS, and all went fine.
>
> http://www.cygwin.com/cygwin-ug-net/using-specialnames.html
>
> I didn't have time to submit a jprt job on this, but tested on Windows Cygwin/MKS, Solaris, and 
> Linux. I believe the TL integrator will be doing a full jprt run later today.  If we don't see a 
> few hundred failures then we should be good ;-)
>
> -Chris.
>
>> - jjh
>>
>>
>> On 8/9/2011 8:56 AM, Chris Hegarty wrote:
>>> Sorry Dan, I'll put a more complete description in the bug report.
>>>
>>> This issue, from what I can tell only happens with very recent Cygwin
>>> versions. I'm running 1.7.9. When running the com/sun/jdi tests in a
>>> batch, in samevm mode, this test leave behind a file, NUL, in the
>>> scratch directory that cannot be deleted. This causes the remaining
>>> tests to also fail.
>>>
>>> Thanks for the review,
>>> -Chris.
>>>
>>> On 08/ 9/11 04:52 PM, Daniel D. Daugherty wrote:
>>>> On 8/9/11 8:52 AM, Chris Hegarty wrote:
>>>>> Hi Dan, Alan,
>>>>>
>>>>> This is a trivial change to use /dev/null instead of NUL for Windows
>>>>> test with Cygwin.
>>>>>
>>>>> http://cr.openjdk.java.net/~chegar/7076756/webrev.00/webrev/
>>>>>
>>>>> Thanks,
>>>>> -Chris.
>>>>
>>>> I'm good with the change, but the bug report itself is less than clear.
>>>>
>>>> I run these tests all the time on WinXP/Cygwin so I'm guessing
>>>> that there is more going on here than meets the eye. I'm going to
>>>> guess that the '-samevm' option is the enabler for this failure
>>>> mode. The failure mode that you fixed should also affect tests
>>>> other than BreakpointWithFullGC.sh so I'm not quite sure why
>>>> this issue appears with just that test. Or maybe it does appear
>>>> with other tests, but again the bug report isn't clear.
>>>>
>>>> In any case, thumbs up on the change.
>>>>
>>>> Dan
>>>>


From mike.duigou at oracle.com  Tue Aug  9 17:40:41 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 9 Aug 2011 10:40:41 -0700
Subject: 7015589: (spec) BufferedWriter.close leaves stream open if close
	of underlying Writer fails
In-Reply-To: <4E411D52.1080509@oracle.com>
References: <4E411D52.1080509@oracle.com>
Message-ID: <95B215C5-B5B6-4348-B5DE-DB8A91BEC63D@oracle.com>

This change looks good. I don't believe a compatibility switch for the FilterOutputStream is warranted.

On Aug 9 2011, at 04:43 , Alan Bateman wrote:

> 
> A few months back there was a bug report [1] pointing out that it's possible to continue writing to a BufferedWriter after invoking its close method and the close fails. A similar issue arises with BufferedOutputStream and other classes. At issue is whether a stream (or more generally a resource) is considered closed in the event that the close method fails. This isn't something that Closeable is clear on. Joe tells me that this didn't come up in the Coin discussions on try-with-resources either.
> 
> I think it's safe to say that it would be desirable that close releases the resources for failing cases as otherwise the resources may never be released (esp. with try-with-resources usages). Furthermore, when there are multiple resources involved, or cases like the bug report where one stream wraps another, then it would be desirable to keep the state of the resources in sync. To that end, the changes here propose adding an advisory note to AutoCloseable to advise implementers to release the underlying resources and to mark the resource as closed prior to throwing the exception.
> 
> For the specific buffering classes discussed at the time, these are changed to follow this advise (but their javadoc isn't changed as there may be other implementations or these classes extended in many ways). In the case of BufferedWriter it is also fixed so that any exception from flushing the underlying writer isn't supplanted by the exception from close. In the case of FilterOutputStream (BufferedOutputStream extends it) then it is fixed so that it doesn't ignore the exception thrown when flushing the underlying stream. This is clearly the right thing to do but it does mean that close can now throw an IOException for a case where it didn't before. For now I don't propose to include a compatibility switch but this may be something that has to revisited later. There are other classes in java.io that could also be cleaned up but I don't propose to do a complete audit at this time.
> 
> The webrev with the changes is here:
>  http://cr.openjdk.java.net/~alanb/7015589/webrev/
> 
> Thanks,
> Alan.
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005732.html



From chris.hegarty at oracle.com  Tue Aug  9 20:02:07 2011
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 09 Aug 2011 21:02:07 +0100
Subject: Fwd: Code Review 7073295:
	TEST_BUG:	test/java/lang/instrument/ManifestTest.sh
	causing havoc (win)
In-Reply-To: <4E415C24.1090302@oracle.com>
References: <4E414450.9040006@oracle.com> <4E415C24.1090302@oracle.com>
Message-ID: <4E41923F.1040004@oracle.com>

On 08/ 9/11 05:11 PM, Daniel D. Daugherty wrote:
> On 8/9/11 8:29 AM, Chris Hegarty wrote:
>> Sorry, should have cc'ed serviceability-dev at openjdk.java.net too.
>>
>> -Chris.
>>
>> -------- Original Message --------
>> Subject: Code Review 7073295: TEST_BUG:
>> test/java/lang/instrument/ManifestTest.sh causing havoc (win)
>> Date: Tue, 09 Aug 2011 14:05:08 +0100
>> From: Chris Hegarty <chris.hegarty at oracle.com>
>> To: core-libs-dev <core-libs-dev at openjdk.java.net>,
>> "alan.bateman at oracle.com" <alan.bateman at oracle.com>
>>
>> Hi,
>>
>> This test creates temporary directories in the scratch area with spaces
>> in their names. It fails on Cygwin because jtreg cannot cleanup after
>> it. Easiest to just have the test cleanup (minimally) after itself.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~chegar/7073295/webrev.00/webrev/
>>
>> Thanks,
>> -Chris.
>
> I run these tests all the time on WinXP/Cygwin so the use of the
> '-samevm' option is the enabler here also. 'samevm' mode is mentioned
> in this bug report (yeah!), but it could be more clear that the test
> falls over because that option is used.

Sorry my fault, most of our recent test issues have been caused by 
samevm mode, it's hard to think of anything else now ;-(

> Alan and I discussed this test off list and our last hypothesis was
> that the strange filenames/dirnames were the culprit. I just didn't
> get back to the issue. Sorry about that.
>
> I'm not quite sure I have my brain wrapped around why
> ExampleForBootClassPath had to be added to the "@run build" line,
> but I'm OK with that change also.

The reason for adding ExampleForBootClassPath to the build line is that 
the shell script at some point moves ExampleForBootClassPath.class to a 
different dir.  If the test is rerun without removing 
ManifestTestApp.class, then jtreg does not recompile 
ManifestTestApp.java, which means that ExampleForBootClassPath doesn't 
get compiled, which means the .class file is not in the expected dir. 
(Thanks JimH for finding this.)

Not a showstopper, but worth fixing since we noticed it.

> I'm presuming that you are only cleaning up the hard to remove stuff
> and leaving the other dirs for JTREG to clean up. For example, there
> are two dirs: "has_leading_blank" and " has_leading_blank". The dir
> without the blank has the bad class file in it to make sure that we
> actually use the right dir (the one with the blank in it). Your fix
> only removes " has_leading_blank" and "has_leading_blank" is left
> behind.

That's right, not exactly pretty but I though it was the simplest way to 
go here. jtreg can handle the rest.

> The bug ID list should also be updated, but that's a nit.

Ahhh... sorry. Probably not worth filing a CR to add this, but I will 
piggyback it to my next changeset if that is ok.

-Chris.

> Thumbs up.
>
> Dan
>
>
>


From daniel.daugherty at oracle.com  Tue Aug  9 20:06:49 2011
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 09 Aug 2011 14:06:49 -0600
Subject: Fwd: Code Review 7073295:
	TEST_BUG:	test/java/lang/instrument/ManifestTest.sh
	causing havoc (win)
In-Reply-To: <4E41923F.1040004@oracle.com>
References: <4E414450.9040006@oracle.com> <4E415C24.1090302@oracle.com>
	<4E41923F.1040004@oracle.com>
Message-ID: <4E419359.1000209@oracle.com>

Thanks for closing the loop. The changes are good as is.

Dan


On 8/9/11 2:02 PM, Chris Hegarty wrote:
> On 08/ 9/11 05:11 PM, Daniel D. Daugherty wrote:
>> On 8/9/11 8:29 AM, Chris Hegarty wrote:
>>> Sorry, should have cc'ed serviceability-dev at openjdk.java.net too.
>>>
>>> -Chris.
>>>
>>> -------- Original Message --------
>>> Subject: Code Review 7073295: TEST_BUG:
>>> test/java/lang/instrument/ManifestTest.sh causing havoc (win)
>>> Date: Tue, 09 Aug 2011 14:05:08 +0100
>>> From: Chris Hegarty <chris.hegarty at oracle.com>
>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>,
>>> "alan.bateman at oracle.com" <alan.bateman at oracle.com>
>>>
>>> Hi,
>>>
>>> This test creates temporary directories in the scratch area with spaces
>>> in their names. It fails on Cygwin because jtreg cannot cleanup after
>>> it. Easiest to just have the test cleanup (minimally) after itself.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~chegar/7073295/webrev.00/webrev/
>>>
>>> Thanks,
>>> -Chris.
>>
>> I run these tests all the time on WinXP/Cygwin so the use of the
>> '-samevm' option is the enabler here also. 'samevm' mode is mentioned
>> in this bug report (yeah!), but it could be more clear that the test
>> falls over because that option is used.
>
> Sorry my fault, most of our recent test issues have been caused by 
> samevm mode, it's hard to think of anything else now ;-(
>
>> Alan and I discussed this test off list and our last hypothesis was
>> that the strange filenames/dirnames were the culprit. I just didn't
>> get back to the issue. Sorry about that.
>>
>> I'm not quite sure I have my brain wrapped around why
>> ExampleForBootClassPath had to be added to the "@run build" line,
>> but I'm OK with that change also.
>
> The reason for adding ExampleForBootClassPath to the build line is 
> that the shell script at some point moves 
> ExampleForBootClassPath.class to a different dir.  If the test is 
> rerun without removing ManifestTestApp.class, then jtreg does not 
> recompile ManifestTestApp.java, which means that 
> ExampleForBootClassPath doesn't get compiled, which means the .class 
> file is not in the expected dir. (Thanks JimH for finding this.)
>
> Not a showstopper, but worth fixing since we noticed it.
>
>> I'm presuming that you are only cleaning up the hard to remove stuff
>> and leaving the other dirs for JTREG to clean up. For example, there
>> are two dirs: "has_leading_blank" and " has_leading_blank". The dir
>> without the blank has the bad class file in it to make sure that we
>> actually use the right dir (the one with the blank in it). Your fix
>> only removes " has_leading_blank" and "has_leading_blank" is left
>> behind.
>
> That's right, not exactly pretty but I though it was the simplest way 
> to go here. jtreg can handle the rest.
>
>> The bug ID list should also be updated, but that's a nit.
>
> Ahhh... sorry. Probably not worth filing a CR to add this, but I will 
> piggyback it to my next changeset if that is ok.
>
> -Chris.
>
>> Thumbs up.
>>
>> Dan
>>
>>
>>


From sebastian.sickelmann at gmx.de  Tue Aug  9 20:29:29 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Tue, 09 Aug 2011 22:29:29 +0200
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <CAGVnyzRg=GauJ03VYOODUP7uq6V-_cPbS4oVN5oNzZYpC=f8og@mail.gmail.com>
References: <4E3F7313.1020103@oracle.com>	<4E3FF183.7020806@gmx.de>	<4E401736.2090508@oracle.com>	<4E403685.9020802@gmx.de>	<4E404DB1.90406@gmx.de>
	<CAGVnyzRg=GauJ03VYOODUP7uq6V-_cPbS4oVN5oNzZYpC=f8og@mail.gmail.com>
Message-ID: <4E4198A9.3030102@gmx.de>

Hi David,

it would be nice to have some help on this.

I started fixing InternalError yesterday [1] and discovered that this 
job is for someone with much industrousness (hope the translation is 
somewhat correct).

First of all a quick look at [1] would be good.
And most imported someone of the commiters who want to sponsor this work.
Anyone interrested in supporting/guiding?

-Sebastian

[1] https://bugs.openjdk.java.net/attachment.cgi?id=229&action=diff)


Am 08.08.2011 23:28, schrieb David Schlosnagle:
> On Mon, Aug 8, 2011 at 4:57 PM, Sebastian Sickelmann
> <sebastian.sickelmann at gmx.de>  wrote:
>> These ones are candidates for cleanup too, but i want to discuss if someone
>> sees a good argument to not to change to
>>     throw new InternalError(e.getMessage(),e);
>>     or
>>     throw new InternalError("Lorem ipsum",e);
>>
>> Also i don't completely understand why Throwable(Throwable cause) uses
>> cause.toString() to fill the message instead of cause.getMessage().
>> Can someone explain to me why?
> If you look at Throwable.toString(), you'll see that it uses
> Throwable.getLocalizedMessage() which allows for localized exception
> messages, so I would avoid using getMessage() directly.
>
> I'd also be interested in helping out making the Throwable and
> Exception types provide the 4 consistent constructors if there are
> committers that would help guide us.
>
> - Dave



From joe.darcy at oracle.com  Tue Aug  9 20:46:26 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 09 Aug 2011 13:46:26 -0700
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <4E4198A9.3030102@gmx.de>
References: <4E3F7313.1020103@oracle.com>	<4E3FF183.7020806@gmx.de>	<4E401736.2090508@oracle.com>	<4E403685.9020802@gmx.de>	<4E404DB1.90406@gmx.de>	<CAGVnyzRg=GauJ03VYOODUP7uq6V-_cPbS4oVN5oNzZYpC=f8og@mail.gmail.com>
	<4E4198A9.3030102@gmx.de>
Message-ID: <4E419CA2.3040605@oracle.com>

Sebastian Sickelmann wrote:
> Hi David,
>
> it would be nice to have some help on this.
>
> I started fixing InternalError yesterday [1] and discovered that this 
> job is for someone with much industrousness (hope the translation is 
> somewhat correct).
>
> First of all a quick look at [1] would be good.
> And most imported someone of the commiters who want to sponsor this work.
> Anyone interrested in supporting/guiding?
>
> -Sebastian
>
> [1] https://bugs.openjdk.java.net/attachment.cgi?id=229&action=diff)

Some comments on [1], first I assume all the modified files are in the 
"jdk" repository.

As a typographical nit, in something like

    ew InternalError(ex.getMessage(),ex);

there should be a space between the comma and "ex".

In the javadoc of InternalError, prefer "{@code InternalError}" over 
"<code>InternalError</code>".

In a line like this from URLClassPath

                throw (InternalError) new InternalError(e);

the cast is no longer needed.

In ProxyClient.java, the new code is missing a throw statement.

-Joe

>
>
> Am 08.08.2011 23:28, schrieb David Schlosnagle:
>> On Mon, Aug 8, 2011 at 4:57 PM, Sebastian Sickelmann
>> <sebastian.sickelmann at gmx.de>  wrote:
>>> These ones are candidates for cleanup too, but i want to discuss if 
>>> someone
>>> sees a good argument to not to change to
>>>     throw new InternalError(e.getMessage(),e);
>>>     or
>>>     throw new InternalError("Lorem ipsum",e);
>>>
>>> Also i don't completely understand why Throwable(Throwable cause) uses
>>> cause.toString() to fill the message instead of cause.getMessage().
>>> Can someone explain to me why?
>> If you look at Throwable.toString(), you'll see that it uses
>> Throwable.getLocalizedMessage() which allows for localized exception
>> messages, so I would avoid using getMessage() directly.
>>
>> I'd also be interested in helping out making the Throwable and
>> Exception types provide the 4 consistent constructors if there are
>> committers that would help guide us.
>>
>> - Dave
>



From alexandre.boulgakov at oracle.com  Tue Aug  9 21:39:48 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Tue, 09 Aug 2011 14:39:48 -0700
Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build
	with javac -Xlint:all -Werror]
In-Reply-To: <4E410389.8070809@oracle.com>
References: <56aed32f-39b2-44c5-89a2-3cb58f0eabae@default>
	<4E410389.8070809@oracle.com>
Message-ID: <4E41A924.7040100@oracle.com>


On 8/9/2011 2:53 AM, Xuelei Fan wrote:
> On 8/9/2011 3:55 PM, Alexandre Boulgakov wrote:
>> That makes sense. I'll do that with automatic refactoring in Netbeans. Do you want me to send another webrev afterwards?
>>
> Just to confirm, you will change LdapNameClassPairEnumeration back to
> LdapNamingEnumeration, and will not change the name
> AbstractLdapNamingEnumeration, right? If the answer is right, I will not
> need to review the webrev any more.
Yes, that's what I did.
>
> Generally, I will always generate a webrev with the latest update before
> push the changes. Because in the future, some others may refer to the
> webrev for other work, such as researching regression failure, backport,
> etc.
That makes sense. For completeness of the record here's the webrev, 
http://cr.openjdk.java.net/~mduigou/7072353/3/webrev/ 
<http://cr.openjdk.java.net/%7Emduigou/7072353/3/webrev/>.
>
> Thanks for your cleanup the JNDI code.
Thanks for reviewing!

-Sasha
>
> Xuelei
>
>> Thanks,
>> Sasha
>>
>> ----- Original Message -----
>> From: Xuelei.Fan at oracle.com
>> To: alexandre.boulgakov at oracle.com
>> Cc: joe.darcy at oracle.com, core-libs-dev at openjdk.java.net
>> Sent: Monday, August 8, 2011 7:30:09 PM GMT -08:00 US/Canada Pacific
>> Subject: Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]
>>
>>
>>
>> On Aug 9, 2011, at 10:16 AM, Alexandre Boulgakov<alexandre.boulgakov at oracle.com>  wrote:
>>
>>> I can change it back to LdapNamingEnumeration. I just thought it would be more consistent with LdapBindingEnumeration and LdapSearchEnumeration. I did not think of the back-porting issue. Would it be better to change AbstractLdapNamingEnumeration to LdapNamingEnumeration, as far as back-porting, since they share the most code? Or do you mean for back-porting code that uses these enumerations?
>>>
>> I would prefer to change it back to LNE, and keep the new ALNE class, since the most confusing place is the code using the LNE, I think.
>>
>> Xuelei
>>
>>
>>
>>> I don't think you need to review the other changes; they are specific change that were already discussed and agreed on.
>>>
>>> Thanks,
>>> Sasha
>>>
>>> ----- Original Message -----
>>> From: xuelei.fan at oracle.com
>>> To: alexandre.boulgakov at oracle.com
>>> Cc: joe.darcy at oracle.com, core-libs-dev at openjdk.java.net
>>> Sent: Monday, August 8, 2011 6:58:41 PM GMT -08:00 US/Canada Pacific
>>> Subject: Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]
>>>
>>> On 8/6/2011 2:11 AM, Alexandre Boulgakov wrote:
>>>> Here's the second version:
>>>> http://cr.openjdk.java.net/~mduigou/7072353/2/webrev/
>>>> <http://cr.openjdk.java.net/%7Emduigou/7072353/2/webrev/>
>>>>
>>>>   * Changed LdapResult.referrals to be a Vector<Vector<String>>;
>>>>   * Refactored
>>>>       o com/sun/jndi/dns/DnsContext.java: BaseNameClassPairEnumeration<T>;
>>>>       o com/sun/jndi/toolkit/dir/HierMemDirCtx.java: BaseFlatNames<T>;
>>>>       o com/sun/jndi/ldap/*.java: refactored LdapNamingEnumeration into
>>>>         AbstractLdapNamingEnumeration, LdapNameClassPairEnumeration;
>>>>         changed LdapBindingEnumeration and LdapSearchEnumeration
>>>>         accordingly, as well as a few of their consumers;
>>> Is it necessary to rename LdapNamingEnumeration to
>>> LdapNameClassPairEnumeration? I think it might not good for sustaining
>>> work, as when backport a fix from JDK 8 to previous releases, we will
>>> have to recognize and rename the class accordingly.
>>>
>>> Otherwise, looks fine to me.
>>>
>>>>   * Made a few additional small changes that were discussed.
>>>>
>>> I did not review other updates. There are too many files, if you want me
>>> review all of the changes again, please let me know.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>> Thanks to everyone who reviewed the last version!
>>>>
>>>> Thanks,
>>>> Sasha
>>>>
>>>> On 8/4/2011 2:00 PM, Alexandre Boulgakov wrote:
>>>>> On 8/3/2011 10:44 PM, Joe Darcy wrote:
>>>>>> David Holmes wrote:
>>>>>>> Joe Darcy said the following on 08/04/11 12:33:
>>>>>>>> David Holmes wrote:
>>>>>>>>>> Using wildcards makes the subtyping work along the type argument
>>>>>>>>>> axis.
>>>>>>>>> So what is the right fix here? To declare the underlying Vector as
>>>>>>>>> a Vector<?>  and cast it to something concrete when needed? It
>>>>>>>>> seems very wrong to me to be inserting raw type casts all through
>>>>>>>>> this code.
>>>>>>>> It isn't entirely clear to be from a quick inspection of the code
>>>>>>>> what the actual type usage is.  A writable general Vector should be
>>>>>>>> a Vector<Object>  and Vector just meant for reading should be a
>>>>>>>> Vector<?>  (or the equivalent Vector<? extends Object>).
>>>>>>>>
>>>>>>>> If the type usage is "a sequence of X's and Y's" where X and Y
>>>>>>>> don't have some useful supertype, I would recommend using a
>>>>>>>> somewhat different set of data structures, like a list of type-safe
>>>>>>>> heterogeneous containers or a list of a new package-level XorY class.
>>>>>>> Buried in one of Sasha's emails it says:
>>>>>>>
>>>>>>> "The current code uses it to store Strings and Vector<String>s."
>>>>>>>
>>>>>>> Hence it is declared Vector<Object>.
>>>>>>>
>>>>>>> This is looking to me like code that should not have been generified.
>>>>>>>
>>>>>> Hmm.  If String or Vector<String>  are the two kinds of stored values,
>>>>>> I would recommend Vector<Vector<String>>  where a lone string was
>>>>>> wrapped in a vector.  (Actually, I would recommend a
>>>>>> List<List<String>>, but that may be beyond the scope of this cleanup.
>>>>> I can do Vector<Vector<String>>.
>>>>>
>>>>> List<List<String>>  is probably beyond the scope of removing compiler
>>>>> warnings; getting rid of Vectors and Hashtables in general could take
>>>>> a whole summer by itself, and would probably be best to do as a whole,
>>>>> since it's not always clear at first glance if other classes depend on
>>>>> a particular object being a Vector.
>>>>>
>>>>> -Sasha
>>>>>> -Joe
>>>>>>


From chris.hegarty at oracle.com  Wed Aug 10 11:32:02 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 10 Aug 2011 11:32:02 +0000
Subject: hg: jdk8/tl/jdk: 7076523: TEST_BUG:
	test/java/net/NetworkInterface/NetParamsTest.java can fail with NPE
Message-ID: <20110810113223.B96B047A8D@hg.openjdk.java.net>

Changeset: af15e902cf08
Author:    chegar
Date:      2011-08-10 12:30 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af15e902cf08

7076523: TEST_BUG: test/java/net/NetworkInterface/NetParamsTest.java can fail with NPE
Reviewed-by: alanb

! test/java/net/NetworkInterface/NetParamsTest.java



From alexandre.boulgakov at oracle.com  Wed Aug 10 18:36:35 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Wed, 10 Aug 2011 11:36:35 -0700
Subject: Code review request: 7077389 Reflection classes do not build with
	javac -Xlint:all -Werror
Message-ID: <4E42CFB3.4080901@oracle.com>

Hello Joe,

Could you please review these small changes to remove javac build 
warnings from the reflection classes?

Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
<http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>

I haven't updated the copyrights to avoid polluting the webrev.
I did not add JAVAC_WARNINGS_FATAL=true to the makefile because it is 
responsible for other packages which still have build warnings.

Thanks,
Sasha


From joe.darcy at oracle.com  Wed Aug 10 19:39:46 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 10 Aug 2011 12:39:46 -0700
Subject: Code review request: 7077389 Reflection classes do not build
	with javac -Xlint:all -Werror
In-Reply-To: <4E42CFB3.4080901@oracle.com>
References: <4E42CFB3.4080901@oracle.com>
Message-ID: <4E42DE82.5060600@oracle.com>

On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
> Hello Joe,
>
> Could you please review these small changes to remove javac build 
> warnings from the reflection classes?
>
> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
> webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
> <http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>
>
> I haven't updated the copyrights to avoid polluting the webrev.
> I did not add JAVAC_WARNINGS_FATAL=true to the makefile because it is 
> responsible for other packages which still have build warnings.
>
> Thanks,
> Sasha

Hi Sasha.

I approve the code changes with the following exceptions:

     src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java

Offhand, I'm not sure of the semantics of this change.

While adding serialVersionUIDs in sun/reflect/annotation/* is a good 
change, I believe this interacts with another bug I'm working on so 
please hold off on those changes for now.

Thanks,

-Joe


From alexandre.boulgakov at oracle.com  Wed Aug 10 19:53:34 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Wed, 10 Aug 2011 12:53:34 -0700
Subject: Code review request: 7077389 Reflection classes do not build
	with javac -Xlint:all -Werror
In-Reply-To: <4E42DE82.5060600@oracle.com>
References: <4E42CFB3.4080901@oracle.com> <4E42DE82.5060600@oracle.com>
Message-ID: <4E42E1BE.4000204@oracle.com>

Hello Joe,

Thanks for reviewing and responding so quickly!

On 8/10/2011 12:39 PM, Joe Darcy wrote:
> On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
>> Hello Joe,
>>
>> Could you please review these small changes to remove javac build 
>> warnings from the reflection classes?
>>
>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
>> webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
>> <http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>
>>
>> I haven't updated the copyrights to avoid polluting the webrev.
>> I did not add JAVAC_WARNINGS_FATAL=true to the makefile because it is 
>> responsible for other packages which still have build warnings.
>>
>> Thanks,
>> Sasha
>
> Hi Sasha.
>
> I approve the code changes with the following exceptions:
>
>     src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
>
> Offhand, I'm not sure of the semantics of this change.
Do you mean changing the type of fieldOffset or the change in the 
constructor? I changed fieldOffset from an int to a long per the 
specification change mentioned in Unsafe.staticFieldOffset(Field) and 
Unsafe.objectFieldOffset(Field). The change in the constructor is 
related and stems from the fact that Unsafe.fieldOffset(Field) is now 
deprecated. Since sun.reflect.UnsafeFieldAccessorImpl is 
package-private, this change should not have any external effects.

>
> While adding serialVersionUIDs in sun/reflect/annotation/* is a good 
> change, I believe this interacts with another bug I'm working on so 
> please hold off on those changes for now.
Since I only have one week left in my internship, I would like to get 
the changes in as quickly as possible. Should I remove the 
serialVersionUIDs but keep the remaining changes?

-Sasha

>
> Thanks,
>
> -Joe


From sebastian.sickelmann at gmx.de  Wed Aug 10 20:03:13 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 10 Aug 2011 22:03:13 +0200
Subject: JDK 8 code review request for 6380161 (reflect) Exception from
	newInstance() not chained to cause.
In-Reply-To: <4E419CA2.3040605@oracle.com>
References: <4E3F7313.1020103@oracle.com>	<4E3FF183.7020806@gmx.de>	<4E401736.2090508@oracle.com>	<4E403685.9020802@gmx.de>	<4E404DB1.90406@gmx.de>	<CAGVnyzRg=GauJ03VYOODUP7uq6V-_cPbS4oVN5oNzZYpC=f8og@mail.gmail.com>
	<4E4198A9.3030102@gmx.de> <4E419CA2.3040605@oracle.com>
Message-ID: <4E42E401.4050300@gmx.de>

Thanks for the quick first review. I have created to new patches for it:


Some logistics:
     - What is the best way to bring this into the real codebase? Patch 
by Patch, or some bigger Diff
     - How to integrate? Should we rebase our work every time and keep 
it actual to newest commits,
       or is it easy to merge later?
     - @David: How do we adjust/sync our work? Should we sync via 
private email? I think syncing via mailling list is like creating spam.
     - I think we should create at least 3 patches for each Exception we 
work on.
         - First: correct Exception/Error-Class
         - Second: adjust uses of corrected class (side-effect-free)
         - Third++: Make some further adjustments to uses of the 
corrected Exception, like plumbing causes in catches where actually is 
code like this
     try (XYZException e) { throw new CorrectedException(e.toString());}
to
     try (XYZException e) { throw new CorrectedException(e.toString(), e);}

I think the latter one(Third++) would sometimes lead to greater discussion.

-- Sebastian

Am 09.08.2011 22:46, schrieb Joe Darcy:
> Sebastian Sickelmann wrote:
>> Hi David,
>>
>> it would be nice to have some help on this.
>>
>> I started fixing InternalError yesterday [1] and discovered that this 
>> job is for someone with much industrousness (hope the translation is 
>> somewhat correct).
>>
>> First of all a quick look at [1] would be good.
>> And most imported someone of the commiters who want to sponsor this 
>> work.
>> Anyone interrested in supporting/guiding?
>>
>> -Sebastian
>>
>> [1] https://bugs.openjdk.java.net/attachment.cgi?id=229&action=diff)
>
> Some comments on [1], first I assume all the modified files are in the 
> "jdk" repository.
>
> As a typographical nit, in something like
>
>    ew InternalError(ex.getMessage(),ex);
>
> there should be a space between the comma and "ex".
>
> In the javadoc of InternalError, prefer "{@code InternalError}" over 
> "<code>InternalError</code>".
>
> In a line like this from URLClassPath
>
>                throw (InternalError) new InternalError(e);
>
> the cast is no longer needed.
>
> In ProxyClient.java, the new code is missing a throw statement.
>
> -Joe
>
>>
>>
>> Am 08.08.2011 23:28, schrieb David Schlosnagle:
>>> On Mon, Aug 8, 2011 at 4:57 PM, Sebastian Sickelmann
>>> <sebastian.sickelmann at gmx.de>  wrote:
>>>> These ones are candidates for cleanup too, but i want to discuss if 
>>>> someone
>>>> sees a good argument to not to change to
>>>>     throw new InternalError(e.getMessage(),e);
>>>>     or
>>>>     throw new InternalError("Lorem ipsum",e);
>>>>
>>>> Also i don't completely understand why Throwable(Throwable cause) uses
>>>> cause.toString() to fill the message instead of cause.getMessage().
>>>> Can someone explain to me why?
>>> If you look at Throwable.toString(), you'll see that it uses
>>> Throwable.getLocalizedMessage() which allows for localized exception
>>> messages, so I would avoid using getMessage() directly.
>>>
>>> I'd also be interested in helping out making the Throwable and
>>> Exception types provide the 4 consistent constructors if there are
>>> committers that would help guide us.
>>>
>>> - Dave
>>
>



From forax at univ-mlv.fr  Wed Aug 10 20:20:55 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Wed, 10 Aug 2011 22:20:55 +0200
Subject: Code review request: 7077389 Reflection classes do not build
	with javac -Xlint:all -Werror
In-Reply-To: <4E42DE82.5060600@oracle.com>
References: <4E42CFB3.4080901@oracle.com> <4E42DE82.5060600@oracle.com>
Message-ID: <4E42E827.1020103@univ-mlv.fr>

On 08/10/2011 09:39 PM, Joe Darcy wrote:
> On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
>> Hello Joe,
>>
>> Could you please review these small changes to remove javac build 
>> warnings from the reflection classes?
>>
>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
>> webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
>> <http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>
>>
>> I haven't updated the copyrights to avoid polluting the webrev.
>> I did not add JAVAC_WARNINGS_FATAL=true to the makefile because it is 
>> responsible for other packages which still have build warnings.
>>
>> Thanks,
>> Sasha
>
> Hi Sasha.
>
> I approve the code changes with the following exceptions:
>
>     src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
>
> Offhand, I'm not sure of the semantics of this change.
>
> While adding serialVersionUIDs in sun/reflect/annotation/* is a good 
> change, I believe this interacts with another bug I'm working on so 
> please hold off on those changes for now.
>
> Thanks,
>
> -Joe

In AccessorGenerator:

   protected static final Class<?>[] primitiveTypes = new Class[] {

should be

   protected static final Class<?>[] primitiveTypes = new Class<?>[] {

in AnnotationParser:

   type.getClassLoader(), new Class[] { type },

should be

   type.getClassLoader(), new Class<?>[] { type },


in TypeVariableImpl:

   TypeVariable<? extends GenericDeclaration>  that =
                     (TypeVariable<? extends GenericDeclaration>) o;

should be
    
   TypeVariable<?>  that =  (TypeVariable<?>) o;


In GenericDeclRepository:

   @SuppressWarnings("rawtypes")
             TypeVariable<?>[] tps = new TypeVariable[ftps.length];

should be
             TypeVariable<?>[] tps = new TypeVariable<?>[ftps.length];


It seems that the compiler is not able to find a raw type
if it's the component type of an array.
(CC to compiler-dev)

cheers,
R?mi



From forax at univ-mlv.fr  Wed Aug 10 20:22:15 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Wed, 10 Aug 2011 22:22:15 +0200
Subject: Code review request: 7077389 Reflection classes do not build
	with javac -Xlint:all -Werror
In-Reply-To: <4E42DE82.5060600@oracle.com>
References: <4E42CFB3.4080901@oracle.com> <4E42DE82.5060600@oracle.com>
Message-ID: <4E42E877.10302@univ-mlv.fr>

On 08/10/2011 09:39 PM, Joe Darcy wrote:
> On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
>> Hello Joe,
>>
>> Could you please review these small changes to remove javac build 
>> warnings from the reflection classes?
>>
>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
>> webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
>> <http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>
>>
>> I haven't updated the copyrights to avoid polluting the webrev.
>> I did not add JAVAC_WARNINGS_FATAL=true to the makefile because it is 
>> responsible for other packages which still have build warnings.
>>
>> Thanks,
>> Sasha
>
> Hi Sasha.
>
> I approve the code changes with the following exceptions:
>
>     src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
>
> Offhand, I'm not sure of the semantics of this change.
>
> While adding serialVersionUIDs in sun/reflect/annotation/* is a good 
> change, I believe this interacts with another bug I'm working on so 
> please hold off on those changes for now.
>
> Thanks,
>
> -Joe

In AccessorGenerator:

   protected static final Class<?>[] primitiveTypes = new Class[] {

should be

   protected static final Class<?>[] primitiveTypes = new Class<?>[] {

in AnnotationParser:

   type.getClassLoader(), new Class[] { type },

should be

   type.getClassLoader(), new Class<?>[] { type },


in TypeVariableImpl:

   TypeVariable<? extends GenericDeclaration>  that =
                     (TypeVariable<? extends GenericDeclaration>) o;

should be
    
   TypeVariable<?>  that =  (TypeVariable<?>) o;


In GenericDeclRepository:

   @SuppressWarnings("rawtypes")
             TypeVariable<?>[] tps = new TypeVariable[ftps.length];

should be
             TypeVariable<?>[] tps = new TypeVariable<?>[ftps.length];


It seems that the compiler is not able to find a raw type
if it's the component type of an array.
(CC to compiler-dev)

cheers,
R?mi



From lance.andersen at oracle.com  Wed Aug 10 20:25:05 2011
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Wed, 10 Aug 2011 20:25:05 +0000
Subject: hg: jdk8/tl/jdk: 7077451: SerialLob,
	SerialClob have the wrong checks for setStream methods
Message-ID: <20110810202515.3906547AA7@hg.openjdk.java.net>

Changeset: 7676670d1e97
Author:    lancea
Date:      2011-08-10 16:23 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7676670d1e97

7077451: SerialLob, SerialClob have the wrong checks for setStream methods
Reviewed-by: alanb
Contributed-by: Patrick Reinhart <patrick at reini.net>

! src/share/classes/javax/sql/rowset/serial/SerialBlob.java
! src/share/classes/javax/sql/rowset/serial/SerialClob.java
+ test/javax/sql/rowset/serial/SerialBlob/SetBinaryStream.java
+ test/javax/sql/rowset/serial/SerialClob/SetAsciiStream.java
+ test/javax/sql/rowset/serial/SerialClob/SetCharacterStream.java



From alexandre.boulgakov at oracle.com  Wed Aug 10 20:43:27 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Wed, 10 Aug 2011 13:43:27 -0700
Subject: Code review request: 7077389 Reflection classes do not build
	with javac -Xlint:all -Werror
In-Reply-To: <4E42E877.10302@univ-mlv.fr>
References: <4E42CFB3.4080901@oracle.com> <4E42DE82.5060600@oracle.com>
	<4E42E877.10302@univ-mlv.fr>
Message-ID: <4E42ED6F.5040700@oracle.com>

Hello Remi,

Thanks for the feedback!

On 8/10/2011 1:22 PM, R?mi Forax wrote:
> On 08/10/2011 09:39 PM, Joe Darcy wrote:
>> On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
>>> Hello Joe,
>>>
>>> Could you please review these small changes to remove javac build 
>>> warnings from the reflection classes?
>>>
>>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
>>> webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
>>> <http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>
>>>
>>> I haven't updated the copyrights to avoid polluting the webrev.
>>> I did not add JAVAC_WARNINGS_FATAL=true to the makefile because it 
>>> is responsible for other packages which still have build warnings.
>>>
>>> Thanks,
>>> Sasha
>>
>> Hi Sasha.
>>
>> I approve the code changes with the following exceptions:
>>
>>     src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
>>
>> Offhand, I'm not sure of the semantics of this change.
>>
>> While adding serialVersionUIDs in sun/reflect/annotation/* is a good 
>> change, I believe this interacts with another bug I'm working on so 
>> please hold off on those changes for now.
>>
>> Thanks,
>>
>> -Joe
>
> In AccessorGenerator:
>
>   protected static final Class<?>[] primitiveTypes = new Class[] {
>
> should be
>
>   protected static final Class<?>[] primitiveTypes = new Class<?>[] {
Generic array creation is not currently supported (here and for your 
other suggestions). Additionally, if I'm not mistaken, wildcards are 
limited to variable declarations, since they wouldn't make sense on a 
constructor or method call.
>
> in AnnotationParser:
>
>   type.getClassLoader(), new Class[] { type },
>
> should be
>
>   type.getClassLoader(), new Class<?>[] { type },
>
>
> in TypeVariableImpl:
>
>   TypeVariable<? extends GenericDeclaration>  that =
>                     (TypeVariable<? extends GenericDeclaration>) o;
>
> should be
>      TypeVariable<?>  that =  (TypeVariable<?>) o;
I believe that it is more clear why we can assign the result of 
that.getGenericDeclaration() to a GenericDeclaration if we include the " 
extends GenericDeclaration" constraint on the wildcard.

-Sasha
>
>
> In GenericDeclRepository:
>
>   @SuppressWarnings("rawtypes")
>             TypeVariable<?>[] tps = new TypeVariable[ftps.length];
>
> should be
>             TypeVariable<?>[] tps = new TypeVariable<?>[ftps.length];
>
>
> It seems that the compiler is not able to find a raw type
> if it's the component type of an array.
> (CC to compiler-dev)
> cheers,
> R?mi
>


From jonathan.gibbons at oracle.com  Wed Aug 10 21:09:18 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 10 Aug 2011 21:09:18 +0000
Subject: hg: jdk8/tl/jdk: 7072353: JNDI libraries do not build with javac
	-Xlint:all -Werror
Message-ID: <20110810210928.54A6E47AAC@hg.openjdk.java.net>

Changeset: 18329abcdb7c
Author:    jjg
Date:      2011-08-10 13:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18329abcdb7c

7072353: JNDI libraries do not build with javac -Xlint:all -Werror
Reviewed-by: xuelei
Contributed-by: alexandre.boulgakov at oracle.com

! make/com/sun/jndi/Makefile
! make/javax/others/Makefile
! src/share/classes/com/sun/jndi/cosnaming/CNBindingEnumeration.java
! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java
! src/share/classes/com/sun/jndi/cosnaming/CNNameParser.java
! src/share/classes/com/sun/jndi/cosnaming/ExceptionMapper.java
! src/share/classes/com/sun/jndi/cosnaming/IiopUrl.java
! src/share/classes/com/sun/jndi/dns/DnsClient.java
! src/share/classes/com/sun/jndi/dns/DnsContext.java
! src/share/classes/com/sun/jndi/dns/DnsContextFactory.java
! src/share/classes/com/sun/jndi/dns/DnsName.java
! src/share/classes/com/sun/jndi/dns/NameNode.java
! src/share/classes/com/sun/jndi/dns/Resolver.java
! src/share/classes/com/sun/jndi/dns/ResourceRecords.java
! src/share/classes/com/sun/jndi/dns/ZoneNode.java
+ src/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java
! src/share/classes/com/sun/jndi/ldap/Ber.java
! src/share/classes/com/sun/jndi/ldap/ClientId.java
! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/DigestClientId.java
! src/share/classes/com/sun/jndi/ldap/EventQueue.java
! src/share/classes/com/sun/jndi/ldap/EventSupport.java
! src/share/classes/com/sun/jndi/ldap/LdapAttribute.java
! src/share/classes/com/sun/jndi/ldap/LdapBindingEnumeration.java
! src/share/classes/com/sun/jndi/ldap/LdapClient.java
! src/share/classes/com/sun/jndi/ldap/LdapCtx.java
! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java
! src/share/classes/com/sun/jndi/ldap/LdapEntry.java
! src/share/classes/com/sun/jndi/ldap/LdapName.java
! src/share/classes/com/sun/jndi/ldap/LdapNamingEnumeration.java
! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java
! src/share/classes/com/sun/jndi/ldap/LdapReferralContext.java
! src/share/classes/com/sun/jndi/ldap/LdapReferralException.java
! src/share/classes/com/sun/jndi/ldap/LdapResult.java
! src/share/classes/com/sun/jndi/ldap/LdapSchemaCtx.java
! src/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java
! src/share/classes/com/sun/jndi/ldap/LdapSearchEnumeration.java
! src/share/classes/com/sun/jndi/ldap/NamingEventNotifier.java
! src/share/classes/com/sun/jndi/ldap/NotifierArgs.java
! src/share/classes/com/sun/jndi/ldap/Obj.java
! src/share/classes/com/sun/jndi/ldap/ReferralEnumeration.java
! src/share/classes/com/sun/jndi/ldap/ServiceLocator.java
! src/share/classes/com/sun/jndi/ldap/SimpleClientId.java
! src/share/classes/com/sun/jndi/ldap/UnsolicitedResponseImpl.java
! src/share/classes/com/sun/jndi/ldap/VersionHelper.java
! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java
! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java
! src/share/classes/com/sun/jndi/ldap/pool/Connections.java
! src/share/classes/com/sun/jndi/ldap/pool/ConnectionsWeakRef.java
! src/share/classes/com/sun/jndi/ldap/pool/Pool.java
! src/share/classes/com/sun/jndi/ldap/pool/PoolCleaner.java
! src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java
! src/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java
! src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java
! src/share/classes/com/sun/jndi/rmi/registry/RegistryContextFactory.java
! src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java
! src/share/classes/com/sun/jndi/toolkit/ctx/AtomicContext.java
! src/share/classes/com/sun/jndi/toolkit/ctx/AtomicDirContext.java
! src/share/classes/com/sun/jndi/toolkit/ctx/ComponentContext.java
! src/share/classes/com/sun/jndi/toolkit/ctx/ComponentDirContext.java
! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java
! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java
! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeDirContext.java
! src/share/classes/com/sun/jndi/toolkit/dir/ContainmentFilter.java
! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java
! src/share/classes/com/sun/jndi/toolkit/dir/DirSearch.java
! src/share/classes/com/sun/jndi/toolkit/dir/HierMemDirCtx.java
! src/share/classes/com/sun/jndi/toolkit/dir/LazySearchEnumerationImpl.java
! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java
! src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java
! src/share/classes/com/sun/jndi/toolkit/url/GenericURLDirContext.java
! src/share/classes/com/sun/jndi/url/dns/dnsURLContext.java
! src/share/classes/com/sun/jndi/url/dns/dnsURLContextFactory.java
! src/share/classes/com/sun/jndi/url/iiop/iiopURLContext.java
! src/share/classes/com/sun/jndi/url/iiop/iiopURLContextFactory.java
! src/share/classes/com/sun/jndi/url/ldap/ldapURLContext.java
! src/share/classes/com/sun/jndi/url/ldap/ldapURLContextFactory.java
! src/share/classes/com/sun/jndi/url/rmi/rmiURLContext.java
! src/share/classes/com/sun/jndi/url/rmi/rmiURLContextFactory.java
! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java
! src/share/classes/com/sun/naming/internal/NamedWeakReference.java
! src/share/classes/com/sun/naming/internal/ResourceManager.java
! src/share/classes/com/sun/naming/internal/VersionHelper.java
! src/share/classes/com/sun/naming/internal/VersionHelper12.java
! src/share/classes/javax/naming/CompositeName.java
! src/share/classes/javax/naming/CompoundName.java
! src/share/classes/javax/naming/InitialContext.java
! src/share/classes/javax/naming/NameImpl.java
! src/share/classes/javax/naming/Reference.java
! src/share/classes/javax/naming/directory/BasicAttribute.java
! src/share/classes/javax/naming/directory/BasicAttributes.java
! src/share/classes/javax/naming/ldap/InitialLdapContext.java
! src/share/classes/javax/naming/ldap/LdapName.java
! src/share/classes/javax/naming/ldap/Rdn.java
! src/share/classes/javax/naming/ldap/Rfc2253Parser.java
! src/share/classes/javax/naming/ldap/StartTlsRequest.java
! src/share/classes/javax/naming/spi/ContinuationContext.java
! src/share/classes/javax/naming/spi/ContinuationDirContext.java
! src/share/classes/javax/naming/spi/DirectoryManager.java
! src/share/classes/javax/naming/spi/NamingManager.java



From joe.darcy at oracle.com  Wed Aug 10 21:24:31 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 10 Aug 2011 14:24:31 -0700
Subject: Code review request for 4900206 "Include worst-case rounding tests
	for Math library functions"
Message-ID: <4E42F70F.5010608@oracle.com>

Hello.

Cleaning up my bug backlog, please review the addition of some new math 
library tests:

     4900206 "Include worst-case rounding tests for Math library functions"
     http://cr.openjdk.java.net/~darcy/4900206.0/

These tests probe at hard to round values generated by number-theoretic 
techniques.  I've verified the tests pass on Linux x86 and Solaris sparc.

Thanks,

-Joe


From patrick at reini.net  Wed Aug 10 21:59:37 2011
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 10 Aug 2011 23:59:37 +0200
Subject: hg: jdk8/tl/jdk: 7077451: SerialLob, SerialClob have the wrong
	checks for setStream methods
In-Reply-To: <20110810202515.3906547AA7@hg.openjdk.java.net>
References: <20110810202515.3906547AA7@hg.openjdk.java.net>
Message-ID: <4E42FF49.5050405@reini.net>

Thanks a lot :-)

Am 10.8.2011 22:25, schrieb lance.andersen at oracle.com:
> Changeset: 7676670d1e97
> Author:    lancea
> Date:      2011-08-10 16:23 -0400
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7676670d1e97
>
> 7077451: SerialLob, SerialClob have the wrong checks for setStream methods
> Reviewed-by: alanb
> Contributed-by: Patrick Reinhart<patrick at reini.net>
>
> ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java
> ! src/share/classes/javax/sql/rowset/serial/SerialClob.java
> + test/javax/sql/rowset/serial/SerialBlob/SetBinaryStream.java
> + test/javax/sql/rowset/serial/SerialClob/SetAsciiStream.java
> + test/javax/sql/rowset/serial/SerialClob/SetCharacterStream.java
>



From forax at univ-mlv.fr  Thu Aug 11 09:25:17 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Thu, 11 Aug 2011 11:25:17 +0200
Subject: Code review request: 7077389 Reflection classes do not build
	with javac -Xlint:all -Werror
In-Reply-To: <4E42ED6F.5040700@oracle.com>
References: <4E42CFB3.4080901@oracle.com> <4E42DE82.5060600@oracle.com>
	<4E42E877.10302@univ-mlv.fr> <4E42ED6F.5040700@oracle.com>
Message-ID: <4E439FFD.9030702@univ-mlv.fr>

On 08/10/2011 10:43 PM, Alexandre Boulgakov wrote:
> Hello Remi,
>

Hello,

> Thanks for the feedback!
>
> On 8/10/2011 1:22 PM, R?mi Forax wrote:
>> On 08/10/2011 09:39 PM, Joe Darcy wrote:
>>> On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
>>>> Hello Joe,
>>>>
>>>> Could you please review these small changes to remove javac build 
>>>> warnings from the reflection classes?
>>>>
>>>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
>>>> webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
>>>> <http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>
>>>>
>>>> I haven't updated the copyrights to avoid polluting the webrev.
>>>> I did not add JAVAC_WARNINGS_FATAL=true to the makefile because it 
>>>> is responsible for other packages which still have build warnings.
>>>>
>>>> Thanks,
>>>> Sasha
>>>
>>> Hi Sasha.
>>>
>>> I approve the code changes with the following exceptions:
>>>
>>>     src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
>>>
>>> Offhand, I'm not sure of the semantics of this change.
>>>
>>> While adding serialVersionUIDs in sun/reflect/annotation/* is a good 
>>> change, I believe this interacts with another bug I'm working on so 
>>> please hold off on those changes for now.
>>>
>>> Thanks,
>>>
>>> -Joe
>>
>> In AccessorGenerator:
>>
>>   protected static final Class<?>[] primitiveTypes = new Class[] {
>>
>> should be
>>
>>   protected static final Class<?>[] primitiveTypes = new Class<?>[] {
> Generic array creation is not currently supported (here and for your 
> other suggestions). 

If the generics is an unbound wildcard, there is no problem.
To reuse the JLS words, a type parametrized by an unbound wildcard is 
reified.

> Additionally, if I'm not mistaken, wildcards are limited to variable 
> declarations, since they wouldn't make sense on a constructor or 
> method call.

wildcards can be used only inside a parameterized type,  whenever you 
use that type to define
a local variable or the type used by new.
Also you can't use a wildcard as an argument type, i.e. you can't 
substitute a T to a ?.

So here, there is no problem.

>>
>> in AnnotationParser:
>>
>>   type.getClassLoader(), new Class[] { type },
>>
>> should be
>>
>>   type.getClassLoader(), new Class<?>[] { type },
>>
>>
>> in TypeVariableImpl:
>>
>>   TypeVariable<? extends GenericDeclaration>  that =
>>                     (TypeVariable<? extends GenericDeclaration>) o;
>>
>> should be
>>      TypeVariable<?>  that =  (TypeVariable<?>) o;
> I believe that it is more clear why we can assign the result of 
> that.getGenericDeclaration() to a GenericDeclaration if we include the 
> " extends GenericDeclaration" constraint on the wildcard.

but here you fall into a corner case of the spec,
a cast to TypeVariable<?> is safe (again it's a reified type) but
a cast to TypeVariable<? extends GenericDeclaration> is not safe
even if TypeVariable is declared like this:
   class TypeVariable<D extends GenericDeclaration> { ... }

>
> -Sasha

R?mi

>>
>>
>> In GenericDeclRepository:
>>
>>   @SuppressWarnings("rawtypes")
>>             TypeVariable<?>[] tps = new TypeVariable[ftps.length];
>>
>> should be
>>             TypeVariable<?>[] tps = new TypeVariable<?>[ftps.length];
>>
>>
>> It seems that the compiler is not able to find a raw type
>> if it's the component type of an array.
>> (CC to compiler-dev)
>> cheers,
>> R?mi
>>



From sean.coffey at oracle.com  Thu Aug 11 11:41:36 2011
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Thu, 11 Aug 2011 11:41:36 +0000
Subject: hg: jdk8/tl/jdk: 7047325: Internal API to improve management of
	direct buffers
Message-ID: <20110811114200.656D047ACD@hg.openjdk.java.net>

Changeset: ddcb874581eb
Author:    coffeys
Date:      2011-08-11 12:40 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddcb874581eb

7047325: Internal API to improve management of direct buffers
Reviewed-by: alanb, mduigou

! make/com/oracle/Makefile
- make/com/oracle/net/Makefile
! make/common/Release.gmk
! src/share/classes/java/nio/Bits.java
! src/share/classes/java/nio/Buffer.java
! src/share/classes/java/nio/Direct-X-Buffer.java.template
! src/share/classes/sun/misc/JavaNioAccess.java
! src/share/classes/sun/nio/ch/DirectBuffer.java



From Alan.Bateman at oracle.com  Thu Aug 11 14:20:03 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Aug 2011 15:20:03 +0100
Subject: Code review request for 4900206 "Include worst-case rounding
	tests for Math library functions"
In-Reply-To: <4E42F70F.5010608@oracle.com>
References: <4E42F70F.5010608@oracle.com>
Message-ID: <4E43E513.5070706@oracle.com>

Joe Darcy wrote:
> Hello.
>
> Cleaning up my bug backlog, please review the addition of some new 
> math library tests:
>
>     4900206 "Include worst-case rounding tests for Math library 
> functions"
>     http://cr.openjdk.java.net/~darcy/4900206.0/
>
> These tests probe at hard to round values generated by 
> number-theoretic techniques.  I've verified the tests pass on Linux 
> x86 and Solaris sparc.
>
> Thanks,
>
> -Joe
This looks good to me (I didn't of course check each case against the 
results on the JMD site). One small suggestion is to mention in the 
comment that its based on teh Sep 5, 2000 update on the off chance that 
new cases are added and we find ourselves wondering if the test is up to 
date.

-Alan.




From joe.darcy at oracle.com  Thu Aug 11 16:19:46 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 11 Aug 2011 09:19:46 -0700
Subject: Code review request: 7077389 Reflection classes do not build
	with javac -Xlint:all -Werror
In-Reply-To: <4E42E1BE.4000204@oracle.com>
References: <4E42CFB3.4080901@oracle.com> <4E42DE82.5060600@oracle.com>
	<4E42E1BE.4000204@oracle.com>
Message-ID: <4E440122.1040401@oracle.com>

Alexandre Boulgakov wrote:
> Hello Joe,
>
> Thanks for reviewing and responding so quickly!
>
> On 8/10/2011 12:39 PM, Joe Darcy wrote:
>> On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
>>> Hello Joe,
>>>
>>> Could you please review these small changes to remove javac build 
>>> warnings from the reflection classes?
>>>
>>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
>>> webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
>>> <http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>
>>>
>>> I haven't updated the copyrights to avoid polluting the webrev.
>>> I did not add JAVAC_WARNINGS_FATAL=true to the makefile because it 
>>> is responsible for other packages which still have build warnings.
>>>
>>> Thanks,
>>> Sasha
>>
>> Hi Sasha.
>>
>> I approve the code changes with the following exceptions:
>>
>>     src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
>>
>> Offhand, I'm not sure of the semantics of this change.
> Do you mean changing the type of fieldOffset or the change in the 
> constructor? I changed fieldOffset from an int to a long per the 
> specification change mentioned in Unsafe.staticFieldOffset(Field) and 
> Unsafe.objectFieldOffset(Field). The change in the constructor is 
> related and stems from the fact that Unsafe.fieldOffset(Field) is now 
> deprecated. Since sun.reflect.UnsafeFieldAccessorImpl is 
> package-private, this change should not have any external effects.

Okay; I wasn't aware of the reasoning for this change and I noted the 
int -> long field change; I think that change is fine then.



>
>>
>> While adding serialVersionUIDs in sun/reflect/annotation/* is a good 
>> change, I believe this interacts with another bug I'm working on so 
>> please hold off on those changes for now.
> Since I only have one week left in my internship, I would like to get 
> the changes in as quickly as possible. Should I remove the 
> serialVersionUIDs but keep the remaining changes?

Yes.

Thanks,

-Joe




From dmitry.nadezhin at gmail.com  Thu Aug 11 17:54:10 2011
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Thu, 11 Aug 2011 21:54:10 +0400
Subject: Code review request for 4900206 "Include worst-case rounding
	tests for Math library functions"
In-Reply-To: <4E42F70F.5010608@oracle.com>
References: <4E42F70F.5010608@oracle.com>
Message-ID: <CAAUNa5vmra0eG9fw6h2GA9TxGH+fid2E0cKiRMJ7-ZOF4hieZA@mail.gmail.com>

Your fix adds worst-case rounding tests for math functions.

It may also be useful to include worst-case rounding tests for number
conversions (string-to-double).

I have explored string-to-double issues, including problems when the
converted numbers are close to the breakpoints between doubles.  This
happens when the string is (m + 0.5 + eps)*2^exp

I found three relevant test cases:

1) The shortest string with eps = 0
"1e23" = 0x1.52d02c7e14af6p76 + (0.5 + 0.0)*1p24

2) The minimum positive eps = 2.1546568143020914E-19
"3743626360493413e-165" = 0x1.8823a57adbef9p-497 + (-0.5 +
2.1546568143020914E-19)*1p-549

3) The maximum negative eps = -8.318563789335443E-19
"1864950924021923e213" = 0x1.3ae60753af6cap758 + (0.5 +
-8.318563789335443E-19)*1p706


These examples may be useful for testing Double.parseDouble and
Double.toString

  -Dmitry

On Thu, Aug 11, 2011 at 1:24 AM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello.
>
> Cleaning up my bug backlog, please review the addition of some new math
> library tests:
>
>    4900206 "Include worst-case rounding tests for Math library functions"
>    http://cr.openjdk.java.net/~**darcy/4900206.0/<http://cr.openjdk.java.net/%7Edarcy/4900206.0/>
>
> These tests probe at hard to round values generated by number-theoretic
> techniques.  I've verified the tests pass on Linux x86 and Solaris sparc.
>
> Thanks,
>
> -Joe
>


From alexandre.boulgakov at oracle.com  Thu Aug 11 19:07:56 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Thu, 11 Aug 2011 12:07:56 -0700
Subject: Code review request: 7077672 jdk8_tl nightly fail in step-2 build
	on 8/10/11
Message-ID: <4E44288C.8000203@oracle.com>

Please review the attached patch to fix a build break.

The fix changes new Class<>[] to new Class<?>[] in two places.

Thanks,
Sasha
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 7077672.patch
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20110811/77d89d32/7077672.patch>

From alexandre.boulgakov at oracle.com  Thu Aug 11 20:14:06 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Thu, 11 Aug 2011 13:14:06 -0700
Subject: Code review request: 7077672 jdk8_tl nightly fail in step-2 build
	on 8/10/11
In-Reply-To: <4E44288C.8000203@oracle.com>
References: <4E44288C.8000203@oracle.com>
Message-ID: <4E44380E.7080804@oracle.com>

It seems that the line endings were broken in the attachment, so I'm 
going to resend the patch in-line.

-Sasha

----------------------------------------------
diff -r 18329abcdb7c src/share/classes/com/sun/jndi/ldap/Obj.java
--- a/src/share/classes/com/sun/jndi/ldap/Obj.java    Wed Aug 10 
13:44:58 2011 -0700
+++ b/src/share/classes/com/sun/jndi/ldap/Obj.java    Thu Aug 11 
12:02:25 2011 -0700
@@ -628,7 +628,7 @@
               boolean hasNonPublicInterface = false;

               // define proxy in class loader of non-public 
interface(s), if any
-             Class<?>[] classObjs = new Class<>[interfaces.length];
+             Class<?>[] classObjs = new Class<?>[interfaces.length];
               for (int i = 0; i < interfaces.length; i++) {
                   Class<?> cl = Class.forName(interfaces[i], false, 
classLoader);
                   if ((cl.getModifiers() & Modifier.PUBLIC) == 0) {
diff -r 18329abcdb7c 
src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java
--- a/src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java    
Wed Aug 10 13:44:58 2011 -0700
+++ b/src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java    
Thu Aug 11 12:02:25 2011 -0700
@@ -252,7 +252,7 @@

          try {
              connectMethod = corbaStubClass.getMethod("connect",
-                new Class<>[] {org.omg.CORBA.ORB.class});
+                new Class<?>[] {org.omg.CORBA.ORB.class});
          } catch (NoSuchMethodException e) {
              throw new IllegalStateException(
          "No method definition for 
javax.rmi.CORBA.Stub.connect(org.omg.CORBA.ORB)");


On 8/11/2011 12:07 PM, Alexandre Boulgakov wrote:
> Please review the attached patch to fix a build break.
>
> The fix changes new Class<>[] to new Class<?>[] in two places.
>
> Thanks,
> Sasha


From forax at univ-mlv.fr  Thu Aug 11 20:15:48 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Thu, 11 Aug 2011 22:15:48 +0200
Subject: Code review request: 7077672 jdk8_tl nightly fail in step-2 build
	on 8/10/11
In-Reply-To: <4E44288C.8000203@oracle.com>
References: <4E44288C.8000203@oracle.com>
Message-ID: <4E443874.809@univ-mlv.fr>

On 08/11/2011 09:07 PM, Alexandre Boulgakov wrote:
> Please review the attached patch to fix a build break.
>
> The fix changes new Class<>[] to new Class<?>[] in two places.
>
> Thanks,
> Sasha

Hi Sasha,
you can rewrite:

   connectMethod = corbaStubClass.getMethod("connect",
                 new Class<>[] {org.omg.CORBA.ORB.class});

to

   connectMethod = corbaStubClass.getMethod("connect",
                 org.omg.CORBA.ORB.class);

because getMethod is a varargs.

Anyways, the changes are ok for me without that.

R?mi



From assembling.signals at yandex.ru  Thu Aug 11 20:19:02 2011
From: assembling.signals at yandex.ru (assembling signals)
Date: Thu, 11 Aug 2011 22:19:02 +0200
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
Message-ID: <36481313093942@web58.yandex.ru>

Hello, community!

Enum does implement Comparable, while EnumSet does NOT implement SortedSet and EnumMap doesn NOT implement SortedMap.
Should I file a bug report (RFE), would there be a chance to see this being implemented in JDK8?

Best regards,
Ivan G Shevchenko


From mandy.chung at oracle.com  Thu Aug 11 20:28:17 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 Aug 2011 13:28:17 -0700
Subject: Code review request: 7077672 jdk8_tl nightly fail in step-2 build
	on 8/10/11
In-Reply-To: <4E44288C.8000203@oracle.com>
References: <4E44288C.8000203@oracle.com>
Message-ID: <4E443B61.8050104@oracle.com>

  On 08/11/11 12:07, Alexandre Boulgakov wrote:
> Please review the attached patch to fix a build break.
>
> The fix changes new Class<>[] to new Class<?>[] in two places.
>

The patch looks good to me.

Mandy



From jonathan.gibbons at oracle.com  Thu Aug 11 20:45:18 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 11 Aug 2011 20:45:18 +0000
Subject: hg: jdk8/tl/jdk: 7077672: jdk8_tl nightly fail in step-2 build on
	8/10/11
Message-ID: <20110811204536.D221847AE7@hg.openjdk.java.net>

Changeset: 79bd5691d85f
Author:    jjg
Date:      2011-08-11 13:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79bd5691d85f

7077672: jdk8_tl nightly fail in step-2 build on 8/10/11
Reviewed-by: mchung, jjg
Contributed-by: alexandre.boulgakov at oracle.com

! src/share/classes/com/sun/jndi/ldap/Obj.java
! src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java



From jonathan.gibbons at oracle.com  Thu Aug 11 20:55:10 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 Aug 2011 13:55:10 -0700
Subject: Code review request: 7077672 jdk8_tl nightly fail in step-2 build
	on 8/10/11
Message-ID: <4E4441AE.1070500@oracle.com>

R?mi, you wrote:

> On 08/11/2011 09:07 PM, Alexandre Boulgakov wrote:
> >/  Please review the attached patch to fix a build break.
> />/
> />/  The fix changes new Class<>[] to new Class<?>[] in two places.
> />/
> />/  Thanks,
> />/  Sasha
> /
> Hi Sasha,
> you can rewrite:
>
>     connectMethod = corbaStubClass.getMethod("connect",
>                   new Class<>[] {org.omg.CORBA.ORB.class});
>
> to
>
>     connectMethod = corbaStubClass.getMethod("connect",
>                   org.omg.CORBA.ORB.class);
>
> because getMethod is a varargs.
>
> Anyways, the changes are ok for me without that.
>
> R?mi

Thanks for the suggestion.  In this case we wanted a minimal fix to go 
back as safely and as quickly as possible.  But your suggestion leads to 
another, broader suggestion for a cleanup of places where the array 
declaration is no longer required.  Another one for the list!

-- Jon




From forax at univ-mlv.fr  Thu Aug 11 20:56:33 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 11 Aug 2011 22:56:33 +0200
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
In-Reply-To: <36481313093942@web58.yandex.ru>
References: <36481313093942@web58.yandex.ru>
Message-ID: <4E444201.20304@univ-mlv.fr>

On 08/11/2011 10:19 PM, assembling signals wrote:
> Hello, community!
>
> Enum does implement Comparable, while EnumSet does NOT implement SortedSet and EnumMap doesn NOT implement SortedMap.
> Should I file a bug report (RFE), would there be a chance to see this being implemented in JDK8?

I've asked the same question with NavigableSet/Map during the JDK6 timeframe
so you should find the answer by Doug Lea on the concurrency-interest list
concurrency-interest at cs.oswego.edu

Furthermore, you can't retrofit EnumSet to implement SortedSet
(an interface that already exists)
because since 1.5, a lot of code was written and some may rely on
the fact that EnumSet doesn't implement SortedSet.

>
> Best regards,
> Ivan G Shevchenko

R?mi



From alexandre.boulgakov at oracle.com  Thu Aug 11 21:25:16 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Thu, 11 Aug 2011 14:25:16 -0700
Subject: Code review request: 7077389 Reflection classes do not build
	with javac -Xlint:all -Werror
In-Reply-To: <4E440122.1040401@oracle.com>
References: <4E42CFB3.4080901@oracle.com> <4E42DE82.5060600@oracle.com>
	<4E42E1BE.4000204@oracle.com> <4E440122.1040401@oracle.com>
Message-ID: <4E4448BC.3010505@oracle.com>

Hello, Joe and R?mi:

Please review this updated webrev that incorporates your suggestions.
http://cr.openjdk.java.net/~mduigou/7077389/1/webrev/ 
<http://cr.openjdk.java.net/%7Emduigou/7077389/1/webrev/>

Specifically, I:

  * removed the 4 serialVersionUIDs I added;
  * used "new TypeName<?>[...]" in place of "new TypeName[...]" and
    removed associated SuppressWarnings annotations; and
  * changed TypeVariable<? extends GenericDeclaration> to
    TypeVariable<?> since the conversion would otherwise be unchecked.


Thanks,
Sasha

On 8/11/2011 9:19 AM, Joe Darcy wrote:
> Alexandre Boulgakov wrote:
>> Hello Joe,
>>
>> Thanks for reviewing and responding so quickly!
>>
>> On 8/10/2011 12:39 PM, Joe Darcy wrote:
>>> On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
>>>> Hello Joe,
>>>>
>>>> Could you please review these small changes to remove javac build 
>>>> warnings from the reflection classes?
>>>>
>>>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
>>>> webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
>>>> <http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>
>>>>
>>>> I haven't updated the copyrights to avoid polluting the webrev.
>>>> I did not add JAVAC_WARNINGS_FATAL=true to the makefile because it 
>>>> is responsible for other packages which still have build warnings.
>>>>
>>>> Thanks,
>>>> Sasha
>>>
>>> Hi Sasha.
>>>
>>> I approve the code changes with the following exceptions:
>>>
>>>     src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
>>>
>>> Offhand, I'm not sure of the semantics of this change.
>> Do you mean changing the type of fieldOffset or the change in the 
>> constructor? I changed fieldOffset from an int to a long per the 
>> specification change mentioned in Unsafe.staticFieldOffset(Field) and 
>> Unsafe.objectFieldOffset(Field). The change in the constructor is 
>> related and stems from the fact that Unsafe.fieldOffset(Field) is now 
>> deprecated. Since sun.reflect.UnsafeFieldAccessorImpl is 
>> package-private, this change should not have any external effects.
>
> Okay; I wasn't aware of the reasoning for this change and I noted the 
> int -> long field change; I think that change is fine then.
>
>
>
>>
>>>
>>> While adding serialVersionUIDs in sun/reflect/annotation/* is a good 
>>> change, I believe this interacts with another bug I'm working on so 
>>> please hold off on those changes for now.
>> Since I only have one week left in my internship, I would like to get 
>> the changes in as quickly as possible. Should I remove the 
>> serialVersionUIDs but keep the remaining changes?
>
> Yes.
>
> Thanks,
>
> -Joe
>
>


From forax at univ-mlv.fr  Thu Aug 11 21:41:09 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Thu, 11 Aug 2011 23:41:09 +0200
Subject: Code review request: 7077389 Reflection classes do not build
	with javac -Xlint:all -Werror
In-Reply-To: <4E4448BC.3010505@oracle.com>
References: <4E42CFB3.4080901@oracle.com> <4E42DE82.5060600@oracle.com>
	<4E42E1BE.4000204@oracle.com> <4E440122.1040401@oracle.com>
	<4E4448BC.3010505@oracle.com>
Message-ID: <4E444C75.40400@univ-mlv.fr>

On 08/11/2011 11:25 PM, Alexandre Boulgakov wrote:
> Hello, Joe and R?mi:
>
> Please review this updated webrev that incorporates your suggestions.
> http://cr.openjdk.java.net/~mduigou/7077389/1/webrev/ 
> <http://cr.openjdk.java.net/%7Emduigou/7077389/1/webrev/>
>
> Specifically, I:
>
>   * removed the 4 serialVersionUIDs I added;
>   * used "new TypeName<?>[...]" in place of "new TypeName[...]" and
>     removed associated SuppressWarnings annotations; and
>   * changed TypeVariable<? extends GenericDeclaration> to
>     TypeVariable<?> since the conversion would otherwise be unchecked.
>
>
> Thanks,
> Sasha

Looks good :)

cheers,
R?mi

>
> On 8/11/2011 9:19 AM, Joe Darcy wrote:
>> Alexandre Boulgakov wrote:
>>> Hello Joe,
>>>
>>> Thanks for reviewing and responding so quickly!
>>>
>>> On 8/10/2011 12:39 PM, Joe Darcy wrote:
>>>> On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
>>>>> Hello Joe,
>>>>>
>>>>> Could you please review these small changes to remove javac build 
>>>>> warnings from the reflection classes?
>>>>>
>>>>> Bug detail: 
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
>>>>> webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
>>>>> <http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>
>>>>>
>>>>> I haven't updated the copyrights to avoid polluting the webrev.
>>>>> I did not add JAVAC_WARNINGS_FATAL=true to the makefile because it 
>>>>> is responsible for other packages which still have build warnings.
>>>>>
>>>>> Thanks,
>>>>> Sasha
>>>>
>>>> Hi Sasha.
>>>>
>>>> I approve the code changes with the following exceptions:
>>>>
>>>>     src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
>>>>
>>>> Offhand, I'm not sure of the semantics of this change.
>>> Do you mean changing the type of fieldOffset or the change in the 
>>> constructor? I changed fieldOffset from an int to a long per the 
>>> specification change mentioned in Unsafe.staticFieldOffset(Field) 
>>> and Unsafe.objectFieldOffset(Field). The change in the constructor 
>>> is related and stems from the fact that Unsafe.fieldOffset(Field) is 
>>> now deprecated. Since sun.reflect.UnsafeFieldAccessorImpl is 
>>> package-private, this change should not have any external effects.
>>
>> Okay; I wasn't aware of the reasoning for this change and I noted the 
>> int -> long field change; I think that change is fine then.
>>
>>
>>
>>>
>>>>
>>>> While adding serialVersionUIDs in sun/reflect/annotation/* is a 
>>>> good change, I believe this interacts with another bug I'm working 
>>>> on so please hold off on those changes for now.
>>> Since I only have one week left in my internship, I would like to 
>>> get the changes in as quickly as possible. Should I remove the 
>>> serialVersionUIDs but keep the remaining changes?
>>
>> Yes.
>>
>> Thanks,
>>
>> -Joe
>>
>>



From forax at univ-mlv.fr  Thu Aug 11 21:56:01 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 11 Aug 2011 23:56:01 +0200
Subject: Code review request: 7077672 jdk8_tl nightly fail in step-2 build
	on 8/10/11
In-Reply-To: <4E4441AE.1070500@oracle.com>
References: <4E4441AE.1070500@oracle.com>
Message-ID: <4E444FF1.1040208@univ-mlv.fr>

On 08/11/2011 10:55 PM, Jonathan Gibbons wrote:
> R?mi, you wrote:
>
>> On 08/11/2011 09:07 PM, Alexandre Boulgakov wrote:
>> >/  Please review the attached patch to fix a build break.
>> />/
>> />/  The fix changes new Class<>[] to new Class<?>[] in two places.
>> />/
>> />/  Thanks,
>> />/  Sasha
>> /
>> Hi Sasha,
>> you can rewrite:
>>
>>     connectMethod = corbaStubClass.getMethod("connect",
>>                   new Class<>[] {org.omg.CORBA.ORB.class});
>>
>> to
>>
>>     connectMethod = corbaStubClass.getMethod("connect",
>>                   org.omg.CORBA.ORB.class);
>>
>> because getMethod is a varargs.
>>
>> Anyways, the changes are ok for me without that.
>>
>> R?mi
>
> Thanks for the suggestion.  In this case we wanted a minimal fix to go 
> back as safely and as quickly as possible.  But your suggestion leads 
> to another, broader suggestion for a cleanup of places where the array 
> declaration is no longer required.  Another one for the list!
>
> -- Jon

Hi Jon,
first I'm really happy of these clean up,
I used to use the JDK source code as an example of well written code for 
my students,
so any improvements is great.

Also I agree with you, the proposed change above is not as important as
the changes Sasha is doing because it just improves the readability
not the type safety.
So it can be done later.

cheers,
R?mi



From joe.darcy at oracle.com  Thu Aug 11 21:58:26 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 11 Aug 2011 14:58:26 -0700
Subject: Code review request for 4900206 "Include worst-case rounding
	tests for Math library functions"
In-Reply-To: <4E43E513.5070706@oracle.com>
References: <4E42F70F.5010608@oracle.com> <4E43E513.5070706@oracle.com>
Message-ID: <4E445082.5000505@oracle.com>

Hi Alan.

On 8/11/2011 7:20 AM, Alan Bateman wrote:
> Joe Darcy wrote:
>> Hello.
>>
>> Cleaning up my bug backlog, please review the addition of some new 
>> math library tests:
>>
>>     4900206 "Include worst-case rounding tests for Math library 
>> functions"
>>     http://cr.openjdk.java.net/~darcy/4900206.0/
>>
>> These tests probe at hard to round values generated by 
>> number-theoretic techniques.  I've verified the tests pass on Linux 
>> x86 and Solaris sparc.
>>
>> Thanks,
>>
>> -Joe
> This looks good to me (I didn't of course check each case against the 
> results on the JMD site). One small suggestion is to mention in the 
> comment that its based on teh Sep 5, 2000 update on the off chance 
> that new cases are added and we find ourselves wondering if the test 
> is up to date.
>
> -Alan.
>

I've revised and augmented  tests in a few ways.  I've added more test 
cases from some more recent work on the team in question and included a 
URL to that paper.  Additionally, following an off-list suggestion from 
you, I've added @run tag using the Xcomp option.

New webrev is here:

     http://cr.openjdk.java.net/~darcy/4900206.1/

Thanks,

-Joe



From joe.darcy at oracle.com  Thu Aug 11 23:03:43 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 11 Aug 2011 16:03:43 -0700
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
In-Reply-To: <4E444201.20304@univ-mlv.fr>
References: <36481313093942@web58.yandex.ru> <4E444201.20304@univ-mlv.fr>
Message-ID: <4E445FCF.50803@oracle.com>

Hello.

On 8/11/2011 1:56 PM, R?mi Forax wrote:
> On 08/11/2011 10:19 PM, assembling signals wrote:
>> Hello, community!
>>
>> Enum does implement Comparable, while EnumSet does NOT implement 
>> SortedSet and EnumMap doesn NOT implement SortedMap.
>> Should I file a bug report (RFE), would there be a chance to see this 
>> being implemented in JDK8?
>
> I've asked the same question with NavigableSet/Map during the JDK6 
> timeframe
> so you should find the answer by Doug Lea on the concurrency-interest 
> list
> concurrency-interest at cs.oswego.edu
>
> Furthermore, you can't retrofit EnumSet to implement SortedSet
> (an interface that already exists)
> because since 1.5, a lot of code was written and some may rely on
> the fact that EnumSet doesn't implement SortedSet.

Actually, that is not the sort of compatibility contract we usually 
worry about enforcing over time.  For example, in JDK 7 I retrofitted 
the java.io.Closeable interface to several long-standing classes with 
close methods that were not retrofitted before.

Cheers,

-Joe


From joe.darcy at oracle.com  Thu Aug 11 23:17:07 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 11 Aug 2011 16:17:07 -0700
Subject: Code review request: 7077389 Reflection classes do not build
	with javac -Xlint:all -Werror
In-Reply-To: <4E444C75.40400@univ-mlv.fr>
References: <4E42CFB3.4080901@oracle.com> <4E42DE82.5060600@oracle.com>
	<4E42E1BE.4000204@oracle.com> <4E440122.1040401@oracle.com>
	<4E4448BC.3010505@oracle.com> <4E444C75.40400@univ-mlv.fr>
Message-ID: <4E4462F3.40903@oracle.com>

Agreed; looks good!

Thanks,

-Joe

On 8/11/2011 2:41 PM, R?mi Forax wrote:
> On 08/11/2011 11:25 PM, Alexandre Boulgakov wrote:
>> Hello, Joe and R?mi:
>>
>> Please review this updated webrev that incorporates your suggestions.
>> http://cr.openjdk.java.net/~mduigou/7077389/1/webrev/ 
>> <http://cr.openjdk.java.net/%7Emduigou/7077389/1/webrev/>
>>
>> Specifically, I:
>>
>>     * removed the 4 serialVersionUIDs I added;
>>     * used "new TypeName<?>[...]" in place of "new TypeName[...]" and
>>       removed associated SuppressWarnings annotations; and
>>     * changed TypeVariable<? extends GenericDeclaration> to
>>       TypeVariable<?> since the conversion would otherwise be unchecked.
>>
>>
>> Thanks,
>> Sasha
>
> Looks good :)
>
> cheers,
> R?mi
>
>>
>> On 8/11/2011 9:19 AM, Joe Darcy wrote:
>>> Alexandre Boulgakov wrote:
>>>> Hello Joe,
>>>>
>>>> Thanks for reviewing and responding so quickly!
>>>>
>>>> On 8/10/2011 12:39 PM, Joe Darcy wrote:
>>>>> On 8/10/2011 11:36 AM, Alexandre Boulgakov wrote:
>>>>>> Hello Joe,
>>>>>>
>>>>>> Could you please review these small changes to remove javac build 
>>>>>> warnings from the reflection classes?
>>>>>>
>>>>>> Bug detail: 
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7077389
>>>>>> webrev: http://cr.openjdk.java.net/~mduigou/7077389/0/webrev/ 
>>>>>> <http://cr.openjdk.java.net/%7Emduigou/7077389/0/webrev/>
>>>>>>
>>>>>> I haven't updated the copyrights to avoid polluting the webrev.
>>>>>> I did not add JAVAC_WARNINGS_FATAL=true to the makefile because 
>>>>>> it is responsible for other packages which still have build 
>>>>>> warnings.
>>>>>>
>>>>>> Thanks,
>>>>>> Sasha
>>>>>
>>>>> Hi Sasha.
>>>>>
>>>>> I approve the code changes with the following exceptions:
>>>>>
>>>>>     src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
>>>>>
>>>>> Offhand, I'm not sure of the semantics of this change.
>>>> Do you mean changing the type of fieldOffset or the change in the 
>>>> constructor? I changed fieldOffset from an int to a long per the 
>>>> specification change mentioned in Unsafe.staticFieldOffset(Field) 
>>>> and Unsafe.objectFieldOffset(Field). The change in the constructor 
>>>> is related and stems from the fact that Unsafe.fieldOffset(Field) 
>>>> is now deprecated. Since sun.reflect.UnsafeFieldAccessorImpl is 
>>>> package-private, this change should not have any external effects.
>>>
>>> Okay; I wasn't aware of the reasoning for this change and I noted 
>>> the int -> long field change; I think that change is fine then.
>>>
>>>
>>>
>>>>
>>>>>
>>>>> While adding serialVersionUIDs in sun/reflect/annotation/* is a 
>>>>> good change, I believe this interacts with another bug I'm working 
>>>>> on so please hold off on those changes for now.
>>>> Since I only have one week left in my internship, I would like to 
>>>> get the changes in as quickly as possible. Should I remove the 
>>>> serialVersionUIDs but keep the remaining changes?
>>>
>>> Yes.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>>
>



From jonathan.gibbons at oracle.com  Thu Aug 11 23:29:22 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 Aug 2011 16:29:22 -0700
Subject: Code review request: 7077672 jdk8_tl nightly fail in step-2 build
	on 8/10/11
In-Reply-To: <4E444FF1.1040208@univ-mlv.fr>
References: <4E4441AE.1070500@oracle.com> <4E444FF1.1040208@univ-mlv.fr>
Message-ID: <4E4465D2.8070306@oracle.com>

On 08/11/2011 02:56 PM, R?mi Forax wrote:
> On 08/11/2011 10:55 PM, Jonathan Gibbons wrote:
>> R?mi, you wrote:
>>
>>> On 08/11/2011 09:07 PM, Alexandre Boulgakov wrote:
>>> >/  Please review the attached patch to fix a build break.
>>> />/
>>> />/  The fix changes new Class<>[] to new Class<?>[] in two places.
>>> />/
>>> />/  Thanks,
>>> />/  Sasha
>>> /
>>> Hi Sasha,
>>> you can rewrite:
>>>
>>>     connectMethod = corbaStubClass.getMethod("connect",
>>>                   new Class<>[] {org.omg.CORBA.ORB.class});
>>>
>>> to
>>>
>>>     connectMethod = corbaStubClass.getMethod("connect",
>>>                   org.omg.CORBA.ORB.class);
>>>
>>> because getMethod is a varargs.
>>>
>>> Anyways, the changes are ok for me without that.
>>>
>>> R?mi
>>
>> Thanks for the suggestion.  In this case we wanted a minimal fix to 
>> go back as safely and as quickly as possible.  But your suggestion 
>> leads to another, broader suggestion for a cleanup of places where 
>> the array declaration is no longer required.  Another one for the list!
>>
>> -- Jon
>
> Hi Jon,
> first I'm really happy of these clean up,
> I used to use the JDK source code as an example of well written code 
> for my students,
> so any improvements is great.
>
> Also I agree with you, the proposed change above is not as important as
> the changes Sasha is doing because it just improves the readability
> not the type safety.
> So it can be done later.
>
> cheers,
> R?mi
>

R?mi,

"I used to use ...." ?    :-(

If you see any more opportunities for cleanup, I hope you'll let us 
know.  Patches (or even changesets) would be even better :-)   You could 
even have fun with the compiler and tree API to find examples of unclean 
code that are candidates for cleanup.  After all, why should we have all 
the fun?

-- Jon


From Ulf.Zibis at gmx.de  Fri Aug 12 00:21:37 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 12 Aug 2011 02:21:37 +0200
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
In-Reply-To: <4E445FCF.50803@oracle.com>
References: <36481313093942@web58.yandex.ru> <4E444201.20304@univ-mlv.fr>
	<4E445FCF.50803@oracle.com>
Message-ID: <4E447211.9030008@gmx.de>

Am 12.08.2011 01:03, schrieb Joe Darcy:
> Hello.
>
> On 8/11/2011 1:56 PM, R?mi Forax wrote:
>> On 08/11/2011 10:19 PM, assembling signals wrote:
>>> Hello, community!
>>>
>>> Enum does implement Comparable, while EnumSet does NOT implement SortedSet and EnumMap doesn NOT 
>>> implement SortedMap.
>>> Should I file a bug report (RFE), would there be a chance to see this being implemented in JDK8?
>>
>> I've asked the same question with NavigableSet/Map during the JDK6 timeframe
>> so you should find the answer by Doug Lea on the concurrency-interest list
>> concurrency-interest at cs.oswego.edu
>>
>> Furthermore, you can't retrofit EnumSet to implement SortedSet
>> (an interface that already exists)
>> because since 1.5, a lot of code was written and some may rely on
>> the fact that EnumSet doesn't implement SortedSet.
>
> Actually, that is not the sort of compatibility contract we usually worry about enforcing over 
> time.  For example, in JDK 7 I retrofitted the java.io.Closeable interface to several 
> long-standing classes with close methods that were not retrofitted before.
>

If this is correct, why can't we add method clone to interface Cloneable? See Bug ID: 4098033 
Cloneable doesn't define .clone <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4098033> .

I think you can add methods (e.g. via adding an interface) to an existing *regular* class, but not 
to an abstract class or interface without breaking source compatibility seriously.
EnumSet is *abstract* class.

Am I wrong, please correct me?

-Ulf



From joe.darcy at oracle.com  Fri Aug 12 00:27:59 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 11 Aug 2011 17:27:59 -0700
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
In-Reply-To: <4E447211.9030008@gmx.de>
References: <36481313093942@web58.yandex.ru> <4E444201.20304@univ-mlv.fr>
	<4E445FCF.50803@oracle.com> <4E447211.9030008@gmx.de>
Message-ID: <4E44738F.30202@oracle.com>

On 8/11/2011 5:21 PM, Ulf Zibis wrote:
> Am 12.08.2011 01:03, schrieb Joe Darcy:
>> Hello.
>>
>> On 8/11/2011 1:56 PM, R?mi Forax wrote:
>>> On 08/11/2011 10:19 PM, assembling signals wrote:
>>>> Hello, community!
>>>>
>>>> Enum does implement Comparable, while EnumSet does NOT implement 
>>>> SortedSet and EnumMap doesn NOT implement SortedMap.
>>>> Should I file a bug report (RFE), would there be a chance to see 
>>>> this being implemented in JDK8?
>>>
>>> I've asked the same question with NavigableSet/Map during the JDK6 
>>> timeframe
>>> so you should find the answer by Doug Lea on the 
>>> concurrency-interest list
>>> concurrency-interest at cs.oswego.edu
>>>
>>> Furthermore, you can't retrofit EnumSet to implement SortedSet
>>> (an interface that already exists)
>>> because since 1.5, a lot of code was written and some may rely on
>>> the fact that EnumSet doesn't implement SortedSet.
>>
>> Actually, that is not the sort of compatibility contract we usually 
>> worry about enforcing over time.  For example, in JDK 7 I retrofitted 
>> the java.io.Closeable interface to several long-standing classes with 
>> close methods that were not retrofitted before.
>>
>
> If this is correct, why can't we add method clone to interface 
> Cloneable? See Bug ID: 4098033 Cloneable doesn't define .clone 
> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4098033> .
>
> I think you can add methods (e.g. via adding an interface) to an 
> existing *regular* class, but not to an abstract class or interface 
> without breaking source compatibility seriously.
> EnumSet is *abstract* class.
>
> Am I wrong, please correct me?
>
> -Ulf
>

EnumSet is an effectively final class since it has no public or 
protected constructors.  The fact that the class is marked abstract is 
an implementation detail in this case.  Therefore, augmenting EnumSet to 
implement another interface would follow the usual source, binary, and 
behavioral compatibility [1] policies we use to evolve the JDK.

-Joe

[1] 
http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#compatibility


From mike.duigou at oracle.com  Fri Aug 12 00:28:34 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 11 Aug 2011 17:28:34 -0700
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
In-Reply-To: <36481313093942@web58.yandex.ru>
References: <36481313093942@web58.yandex.ru>
Message-ID: <D892FAD1-27F5-4DBD-B0CE-16DF7DECEC1D@oracle.com>

There's an existing RFE for this request: CR#6278287

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6278287

Wherein Kevin Bourrillion provides some excellent analysis. 

The RFE hasn't been targeted to Java 8 and I'm unaware of any plan to escalate the priority. It would be a very good issue for an enthusiastic community hacker to really get involved in OpenJDK development. I can't imagine that if an implementation and test suite arrived that it wouldn't be gratefully accepted. 

To be very frank, while Oracle has increased and is still increasing staffing levels on Java (I'm one of the "increase"), there are more than 200 outstanding RFEs for Java Collections. For prioritization and quality reasons only a fraction of these will get addressed in JDK8. There will always be more RFEs than can be completed in any release. Running out of RFEs would be a very bad sign. ;-)

Community contributions are essential to Java just as they are for Linux. ?Do you pine for the nice days of Minix-1.1, when men were men and wrote their own device drivers?? -- Linus Torvalds. Good news, writing JDK classes isn't (usually) as hard as writing device drivers!

Cheers,

Mike

On Aug 11 2011, at 13:19 , assembling signals wrote:

> Hello, community!
> 
> Enum does implement Comparable, while EnumSet does NOT implement SortedSet and EnumMap doesn NOT implement SortedMap.
> Should I file a bug report (RFE), would there be a chance to see this being implemented in JDK8?
> 
> Best regards,
> Ivan G Shevchenko



From weijun.wang at oracle.com  Fri Aug 12 03:23:51 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 12 Aug 2011 03:23:51 +0000
Subject: hg: jdk8/tl/jdk: 7076415: sun/security/krb5/runNameEquals.sh failed
	on sles 10
Message-ID: <20110812032401.2A32D47AFA@hg.openjdk.java.net>

Changeset: 4574445f35ac
Author:    weijun
Date:      2011-08-12 11:20 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4574445f35ac

7076415: sun/security/krb5/runNameEquals.sh failed on sles 10
Reviewed-by: xuelei

! test/sun/security/krb5/Krb5NameEquals.java



From weijun.wang at oracle.com  Fri Aug 12 04:27:31 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 12 Aug 2011 04:27:31 +0000
Subject: hg: jdk8/tl/jdk: 7055363: jdk_security3 test target cleanup
Message-ID: <20110812042741.0F97947AFD@hg.openjdk.java.net>

Changeset: cb83fe13af98
Author:    weijun
Date:      2011-08-12 12:26 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb83fe13af98

7055363: jdk_security3 test target cleanup
Reviewed-by: alanb, xuelei

! test/Makefile
! test/ProblemList.txt
! test/com/sun/security/auth/login/ConfigFile/IllegalURL.java
+ test/java/security/testlibrary/Providers.java
! test/javax/security/auth/login/LoginContext/ResetConfigModule.java
! test/sun/security/ec/TestEC.java
! test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java
! test/sun/security/pkcs11/PKCS11Test.java
! test/sun/security/pkcs11/Secmod/AddPrivateKey.java
! test/sun/security/pkcs11/Secmod/AddTrustedCert.java
! test/sun/security/pkcs11/Secmod/Crypto.java
! test/sun/security/pkcs11/Secmod/GetPrivateKey.java
! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java
! test/sun/security/pkcs11/Secmod/TrustAnchors.java
! test/sun/security/pkcs11/SecmodTest.java
! test/sun/security/pkcs11/ec/ReadCertificates.java
! test/sun/security/pkcs11/ec/ReadPKCS12.java
! test/sun/security/pkcs11/ec/TestECDH.java
! test/sun/security/pkcs11/ec/TestECDSA.java
! test/sun/security/pkcs11/fips/CipherTest.java
! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java
! test/sun/security/pkcs11/fips/TrustManagerTest.java
! test/sun/security/pkcs11/rsa/TestCACerts.java
! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java
! test/sun/security/pkcs12/PKCS12SameKeyId.java
! test/sun/security/provider/PolicyFile/Comparator.java
! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/ClientHelloRead.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ProtocolVersion/HttpsProtocols.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java
! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyAuthTest.java
! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ServerIdentityTest.java
! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java
! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java
! test/sun/security/ssl/javax/net/ssl/Fix5070632.java
! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ComURLNulls.java
! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java
! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/JavaxURLNulls.java
! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java
! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/KeyManagerTrustManager.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java
! test/sun/security/ssl/javax/net/ssl/SSLServerSocket/DefaultSSLServSocketFac.java
! test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java
! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java
! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java
! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java
! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java
! test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java
! test/sun/security/ssl/sanity/pluggability/CheckSockFacExport1.java
! test/sun/security/ssl/sanity/pluggability/CheckSockFacExport2.java
! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/RetryHttps.java
! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java
! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java
! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHTTPSConnection.java
! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java
! test/sun/security/ssl/templates/SSLEngineTemplate.java
! test/sun/security/ssl/templates/SSLSocketTemplate.java
! test/sun/security/tools/keytool/StartDateTest.java
! test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java



From forax at univ-mlv.fr  Fri Aug 12 12:18:46 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 12 Aug 2011 14:18:46 +0200
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
In-Reply-To: <4E445FCF.50803@oracle.com>
References: <36481313093942@web58.yandex.ru> <4E444201.20304@univ-mlv.fr>
	<4E445FCF.50803@oracle.com>
Message-ID: <4E451A26.5070104@univ-mlv.fr>

On 08/12/2011 01:03 AM, Joe Darcy wrote:
> Hello.
>
> On 8/11/2011 1:56 PM, R?mi Forax wrote:
>> On 08/11/2011 10:19 PM, assembling signals wrote:
>>> Hello, community!
>>>
>>> Enum does implement Comparable, while EnumSet does NOT implement 
>>> SortedSet and EnumMap doesn NOT implement SortedMap.
>>> Should I file a bug report (RFE), would there be a chance to see 
>>> this being implemented in JDK8?
>>
>> I've asked the same question with NavigableSet/Map during the JDK6 
>> timeframe
>> so you should find the answer by Doug Lea on the concurrency-interest 
>> list
>> concurrency-interest at cs.oswego.edu
>>
>> Furthermore, you can't retrofit EnumSet to implement SortedSet
>> (an interface that already exists)
>> because since 1.5, a lot of code was written and some may rely on
>> the fact that EnumSet doesn't implement SortedSet.
>
> Actually, that is not the sort of compatibility contract we usually 
> worry about enforcing over time.  For example, in JDK 7 I retrofitted 
> the java.io.Closeable interface to several long-standing classes with 
> close methods that were not retrofitted before.
>
> Cheers,
>
> -Joe

Hi Joe, I disagree,
SortedSet is not Closeable.

It's not rare to use instanceof to check the interface implemented by a 
collections
to guarantee the complexity of an algorithm.
It's a common trick, and there is no better alternative.

Most operations on an EnumSet are done in O(1),
most implementations of SortedSet offers operations that are done in 
O(ln n).

If you retrofit EnumSet to implement SortedSet, the risk to change the 
complexity
of an existing algorithm is far from negligible.

cheers,
R?mi



From forax at univ-mlv.fr  Fri Aug 12 12:28:44 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 12 Aug 2011 14:28:44 +0200
Subject: Code review request: 7077672 jdk8_tl nightly fail in step-2 build
	on 8/10/11
In-Reply-To: <4E4465D2.8070306@oracle.com>
References: <4E4441AE.1070500@oracle.com> <4E444FF1.1040208@univ-mlv.fr>
	<4E4465D2.8070306@oracle.com>
Message-ID: <4E451C7C.4050603@univ-mlv.fr>

On 08/12/2011 01:29 AM, Jonathan Gibbons wrote:
> On 08/11/2011 02:56 PM, R?mi Forax wrote:
>> On 08/11/2011 10:55 PM, Jonathan Gibbons wrote:
>>> R?mi, you wrote:
>>>
>>>> On 08/11/2011 09:07 PM, Alexandre Boulgakov wrote:
>>>> >/  Please review the attached patch to fix a build break.
>>>> />/
>>>> />/  The fix changes new Class<>[] to new Class<?>[] in two places.
>>>> />/
>>>> />/  Thanks,
>>>> />/  Sasha
>>>> /
>>>> Hi Sasha,
>>>> you can rewrite:
>>>>
>>>>     connectMethod = corbaStubClass.getMethod("connect",
>>>>                   new Class<>[] {org.omg.CORBA.ORB.class});
>>>>
>>>> to
>>>>
>>>>     connectMethod = corbaStubClass.getMethod("connect",
>>>>                   org.omg.CORBA.ORB.class);
>>>>
>>>> because getMethod is a varargs.
>>>>
>>>> Anyways, the changes are ok for me without that.
>>>>
>>>> R?mi
>>>
>>> Thanks for the suggestion.  In this case we wanted a minimal fix to 
>>> go back as safely and as quickly as possible.  But your suggestion 
>>> leads to another, broader suggestion for a cleanup of places where 
>>> the array declaration is no longer required.  Another one for the list!
>>>
>>> -- Jon
>>
>> Hi Jon,
>> first I'm really happy of these clean up,
>> I used to use the JDK source code as an example of well written code 
>> for my students,
>> so any improvements is great.
>>
>> Also I agree with you, the proposed change above is not as important as
>> the changes Sasha is doing because it just improves the readability
>> not the type safety.
>> So it can be done later.
>>
>> cheers,
>> R?mi
>>
>
> R?mi,
>
> "I used to use ...." ?    :-(

To be crystal clear, the code deliver with JDK 1.5 was full of raw 
types, rare types etc
not something you want beginners be exposed.
The code is now in better shape.

>
> If you see any more opportunities for cleanup, I hope you'll let us 
> know.  Patches (or even changesets) would be even better :-)   You 
> could even have fun with the compiler and tree API to find examples of 
> unclean code that are candidates for cleanup.

I think you have found a good project for my students :)

> After all, why should we have all the fun?
>
> -- Jon

R?mi



From mike.skells at talk21.com  Fri Aug 12 12:46:02 2011
From: mike.skells at talk21.com (mike.skells at talk21.com)
Date: Fri, 12 Aug 2011 12:46:02 +0000
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
In-Reply-To: <4E451A26.5070104@univ-mlv.fr>
References: <36481313093942@web58.yandex.ru>
	<4E444201.20304@univ-mlv.fr><4E445FCF.50803@oracle.com><4E451A26.5070104@univ-mlv.fr>
Message-ID: <1898934967-1313153144-cardhu_decombobulator_blackberry.rim.net-435289203-@b25.c3.bise7.blackberry>

Hi Remi,
Your argument is flawed

The complexity of the operations is not defined by the interface or the presence or absence of the interface

If you have complexity algo checks then these can only be applied to known classes where the complexity is defined in the interface or class

As such the code that infers this behaviour is broken and needs to be fixed.

If the arbitrary missasumptions as to non functional characteristics is the driver that blocks evolution of the java ecosystem then java is dead and we may as well keep starting again.

As an aside IMO the complexity specification issue could be better addressed with the interface evolution in Java 8. There have been other discussion of improvements to performance of the algos in collections that do require this metadata. This would allow the broken code to be fixed 

Regards
Mike
Sent from my BlackBerry? wireless device

-----Original Message-----
From: R?mi Forax <forax at univ-mlv.fr>
Sender: core-libs-dev-bounces at openjdk.java.net
Date: Fri, 12 Aug 2011 14:18:46 
To: <core-libs-dev at openjdk.java.net>
Subject: Re: Any chance to see EnumSet implement SortedSet in JDK8?

On 08/12/2011 01:03 AM, Joe Darcy wrote:
> Hello.
>
> On 8/11/2011 1:56 PM, R?mi Forax wrote:
>> On 08/11/2011 10:19 PM, assembling signals wrote:
>>> Hello, community!
>>>
>>> Enum does implement Comparable, while EnumSet does NOT implement 
>>> SortedSet and EnumMap doesn NOT implement SortedMap.
>>> Should I file a bug report (RFE), would there be a chance to see 
>>> this being implemented in JDK8?
>>
>> I've asked the same question with NavigableSet/Map during the JDK6 
>> timeframe
>> so you should find the answer by Doug Lea on the concurrency-interest 
>> list
>> concurrency-interest at cs.oswego.edu
>>
>> Furthermore, you can't retrofit EnumSet to implement SortedSet
>> (an interface that already exists)
>> because since 1.5, a lot of code was written and some may rely on
>> the fact that EnumSet doesn't implement SortedSet.
>
> Actually, that is not the sort of compatibility contract we usually 
> worry about enforcing over time.  For example, in JDK 7 I retrofitted 
> the java.io.Closeable interface to several long-standing classes with 
> close methods that were not retrofitted before.
>
> Cheers,
>
> -Joe

Hi Joe, I disagree,
SortedSet is not Closeable.

It's not rare to use instanceof to check the interface implemented by a 
collections
to guarantee the complexity of an algorithm.
It's a common trick, and there is no better alternative.

Most operations on an EnumSet are done in O(1),
most implementations of SortedSet offers operations that are done in 
O(ln n).

If you retrofit EnumSet to implement SortedSet, the risk to change the 
complexity
of an existing algorithm is far from negligible.

cheers,
R?mi


From weijun.wang at oracle.com  Fri Aug 12 13:05:21 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 12 Aug 2011 13:05:21 +0000
Subject: hg: jdk8/tl/jdk: 7078355:
	sun/net/www/protocol/file/DirPermissionDenied.sh leaves garbage
	on some linux systems
Message-ID: <20110812130539.86C6547B18@hg.openjdk.java.net>

Changeset: e533c13df9ad
Author:    weijun
Date:      2011-08-12 21:04 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e533c13df9ad

7078355: sun/net/www/protocol/file/DirPermissionDenied.sh leaves garbage on some linux systems
Reviewed-by: chegar

! test/sun/net/www/protocol/file/DirPermissionDenied.sh



From forax at univ-mlv.fr  Fri Aug 12 13:06:11 2011
From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=)
Date: Fri, 12 Aug 2011 15:06:11 +0200
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
In-Reply-To: <1898934967-1313153144-cardhu_decombobulator_blackberry.rim.net-435289203-@b25.c3.bise7.blackberry>
References: <36481313093942@web58.yandex.ru>
	<4E444201.20304@univ-mlv.fr><4E445FCF.50803@oracle.com><4E451A26.5070104@univ-mlv.fr>
	<1898934967-1313153144-cardhu_decombobulator_blackberry.rim.net-435289203-@b25.c3.bise7.blackberry>
Message-ID: <4E452543.7060406@univ-mlv.fr>

On 08/12/2011 02:46 PM, mike.skells at talk21.com wrote:
> Hi Remi,
> Your argument is flawed
>
> The complexity of the operations is not defined by the interface or the presence or absence of the interface

In theory yes, but in practice ...
What is the purpose of java.util.RandomAccess ?

> If you have complexity algo checks then these can only be applied to known classes where the complexity is defined in the interface or class
>
> As such the code that infers this behaviour is broken and needs to be fixed.

Ok, how to remove the instanceof RandomAccess in Collections.shuffle (by 
example).

>
> If the arbitrary missasumptions as to non functional characteristics is the driver that blocks evolution of the java ecosystem then java is dead and we may as well keep starting again.

Common misconception, if Java was blocked it was because Sun was dying,
not because Java has a strong tradition of backward compatibility.
You can always built a new package like java.nio if the old one block 
your evolution.

>
> As an aside IMO the complexity specification issue could be better addressed with the interface evolution in Java 8. There have been other discussion of improvements to performance of the algos in collections that do require this metadata. This would allow the broken code to be fixed
>
> Regards
> Mike
> Sent from my BlackBerry? wireless device

regards,
R?mi



From schlosna at gmail.com  Fri Aug 12 16:24:04 2011
From: schlosna at gmail.com (David Schlosnagle)
Date: Fri, 12 Aug 2011 12:24:04 -0400
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
In-Reply-To: <4E452543.7060406@univ-mlv.fr>
References: <36481313093942@web58.yandex.ru> <4E444201.20304@univ-mlv.fr>
	<4E445FCF.50803@oracle.com> <4E451A26.5070104@univ-mlv.fr>
	<1898934967-1313153144-cardhu_decombobulator_blackberry.rim.net-435289203-@b25.c3.bise7.blackberry>
	<4E452543.7060406@univ-mlv.fr>
Message-ID: <CAGVnyzQxJVvXQSPs7iV0B4tpSpG-JDJZShV=3ARqKN9XufVZEA@mail.gmail.com>

On Fri, Aug 12, 2011 at 9:06 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
> On 08/12/2011 02:46 PM, mike.skells at talk21.com wrote:
>>
>> Hi Remi,
>> Your argument is flawed
>>
>> The complexity of the operations is not defined by the interface or the
>> presence or absence of the interface
>
> In theory yes, but in practice ...
> What is the purpose of java.util.RandomAccess ?
>
>> If you have complexity algo checks then these can only be applied to known
>> classes where the complexity is defined in the interface or class
>>
>> As such the code that infers this behaviour is broken and needs to be
>> fixed.
>
> Ok, how to remove the instanceof RandomAccess in Collections.shuffle (by
> example).

Does anyone know if there has ever been a proposal or experiments to
use annotations to provide algorithmic complexity information for a
given method implementation? This might be an interesting experiment
rather than adding marker interfaces that apply to an entire class.

- Dave


From mike.skells at talk21.com  Fri Aug 12 18:16:24 2011
From: mike.skells at talk21.com (mike.skells at talk21.com)
Date: Fri, 12 Aug 2011 18:16:24 +0000
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
Message-ID: <1250698461-1313172966-cardhu_decombobulator_blackberry.rim.net-1344758999-@b25.c3.bise7.blackberry>

Hi David,
It doesn't work really in the general case because of wrapper classes

Collections.unmodifyableCollection(c) for instance need to infer the characteristics from the content

It could be a default implementation though

Regards
Mike
------Original Message------
From: David Schlosnagle
To: R?mi Forax
Cc: Mike Skells
Cc: core-libs-dev at openjdk.java.net
Subject: Re: Any chance to see EnumSet implement SortedSet in JDK8?
Sent: 12 Aug 2011 17:24

On Fri, Aug 12, 2011 at 9:06 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
> On 08/12/2011 02:46 PM, mike.skells at talk21.com wrote:
>>
>> Hi Remi,
>> Your argument is flawed
>>
>> The complexity of the operations is not defined by the interface or the
>> presence or absence of the interface
>
> In theory yes, but in practice ...
> What is the purpose of java.util.RandomAccess ?
>
>> If you have complexity algo checks then these can only be applied to known
>> classes where the complexity is defined in the interface or class
>>
>> As such the code that infers this behaviour is broken and needs to be
>> fixed.
>
> Ok, how to remove the instanceof RandomAccess in Collections.shuffle (by
> example).

Does anyone know if there has ever been a proposal or experiments to
use annotations to provide algorithmic complexity information for a
given method implementation? This might be an interesting experiment
rather than adding marker interfaces that apply to an entire class.

- Dave


Sent from my BlackBerry? wireless device

From mike.skells at talk21.com  Fri Aug 12 18:21:43 2011
From: mike.skells at talk21.com (mike.skells at talk21.com)
Date: Fri, 12 Aug 2011 18:21:43 +0000
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
Message-ID: <592192599-1313173285-cardhu_decombobulator_blackberry.rim.net-875729915-@b25.c3.bise7.blackberry>

Hi Remi
That is precisely my point
The specification of RandomAccess defines the non functional behaviour so you are not inferring it you are using the specification

You cannot assume that a list that does not implement RA has any preferred iteration characteristics though

Regards
Mike
------Original Message------
From: R?mi Forax
To: Mike Skells
Cc: core-libs-dev at openjdk.java.net
Subject: Re: Any chance to see EnumSet implement SortedSet in JDK8?
Sent: 12 Aug 2011 14:06

On 08/12/2011 02:46 PM, mike.skells at talk21.com wrote:
> Hi Remi,
> Your argument is flawed
>
> The complexity of the operations is not defined by the interface or the presence or absence of the interface

In theory yes, but in practice ...
What is the purpose of java.util.RandomAccess ?

> If you have complexity algo checks then these can only be applied to known classes where the complexity is defined in the interface or class
>
> As such the code that infers this behaviour is broken and needs to be fixed.

Ok, how to remove the instanceof RandomAccess in Collections.shuffle (by 
example).

>
> If the arbitrary missasumptions as to non functional characteristics is the driver that blocks evolution of the java ecosystem then java is dead and we may as well keep starting again.

Common misconception, if Java was blocked it was because Sun was dying,
not because Java has a strong tradition of backward compatibility.
You can always built a new package like java.nio if the old one block 
your evolution.

>
> As an aside IMO the complexity specification issue could be better addressed with the interface evolution in Java 8. There have been other discussion of improvements to performance of the algos in collections that do require this metadata. This would allow the broken code to be fixed
>
> Regards
> Mike
> Sent from my BlackBerry? wireless device

regards,
R?mi



Sent from my BlackBerry? wireless device

From forax at univ-mlv.fr  Fri Aug 12 20:22:47 2011
From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=)
Date: Fri, 12 Aug 2011 22:22:47 +0200
Subject: Any chance to see EnumSet implement SortedSet in JDK8?
In-Reply-To: <592192599-1313173285-cardhu_decombobulator_blackberry.rim.net-875729915-@b25.c3.bise7.blackberry>
References: <592192599-1313173285-cardhu_decombobulator_blackberry.rim.net-875729915-@b25.c3.bise7.blackberry>
Message-ID: <4E458B97.2070605@univ-mlv.fr>

On 08/12/2011 08:21 PM, mike.skells at talk21.com wrote:
> Hi Remi
> That is precisely my point
> The specification of RandomAccess defines the non functional behaviour so you are not inferring it you are using the specification
>
> You cannot assume that a list that does not implement RA has any preferred iteration characteristics though

Shuffle doc says that it run in linear time.
You can't guarantee that if there is no guarantee that:
   - toArray() run in linear time and listIterator.set run in constant time
   - RandomAccess list get/set run in constant time

You will no find such guarantees in the spec.
So practically, you have to 'infer' it.

> Regards
> Mike

Regards,
R?mi

> ------Original Message------
> From: R?mi Forax
> To: Mike Skells
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: Any chance to see EnumSet implement SortedSet in JDK8?
> Sent: 12 Aug 2011 14:06
>
> On 08/12/2011 02:46 PM, mike.skells at talk21.com wrote:
>> Hi Remi,
>> Your argument is flawed
>>
>> The complexity of the operations is not defined by the interface or the presence or absence of the interface
> In theory yes, but in practice ...
> What is the purpose of java.util.RandomAccess ?
>
>> If you have complexity algo checks then these can only be applied to known classes where the complexity is defined in the interface or class
>>
>> As such the code that infers this behaviour is broken and needs to be fixed.
> Ok, how to remove the instanceof RandomAccess in Collections.shuffle (by
> example).
>
>> If the arbitrary missasumptions as to non functional characteristics is the driver that blocks evolution of the java ecosystem then java is dead and we may as well keep starting again.
> Common misconception, if Java was blocked it was because Sun was dying,
> not because Java has a strong tradition of backward compatibility.
> You can always built a new package like java.nio if the old one block
> your evolution.
>
>> As an aside IMO the complexity specification issue could be better addressed with the interface evolution in Java 8. There have been other discussion of improvements to performance of the algos in collections that do require this metadata. This would allow the broken code to be fixed
>>
>> Regards
>> Mike
>> Sent from my BlackBerry? wireless device
> regards,
> R?mi
>
>
>
> Sent from my BlackBerry? wireless device



From joe.darcy at oracle.com  Fri Aug 12 20:37:51 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Fri, 12 Aug 2011 20:37:51 +0000
Subject: hg: jdk8/tl/jdk: 4900206: Include worst-case rounding tests for Math
	library functions
Message-ID: <20110812203812.09B1647B2A@hg.openjdk.java.net>

Changeset: 8f962aca221e
Author:    darcy
Date:      2011-08-12 13:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f962aca221e

4900206: Include worst-case rounding tests for Math library functions
Reviewed-by: alanb

! test/java/lang/Math/Tests.java
+ test/java/lang/Math/WorstCaseTests.java



From stuart.marks at oracle.com  Fri Aug 12 21:55:03 2011
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Fri, 12 Aug 2011 21:55:03 +0000
Subject: hg: jdk8/tl/jdk: 7076526: add test
	MemoryMXBean/CollectionUsageThreshold to the problem list
Message-ID: <20110812215514.64F1347B2F@hg.openjdk.java.net>

Changeset: 3f66f9ca1ba5
Author:    smarks
Date:      2011-08-12 14:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f66f9ca1ba5

7076526: add test MemoryMXBean/CollectionUsageThreshold to the problem list
Reviewed-by: weijun, alanb

! test/ProblemList.txt



From jonathan.gibbons at oracle.com  Sat Aug 13 00:56:58 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 12 Aug 2011 17:56:58 -0700
Subject: Code review request: 7077672 jdk8_tl nightly fail in step-2 build
	on 8/10/11
In-Reply-To: <4E451C7C.4050603@univ-mlv.fr>
References: <4E4441AE.1070500@oracle.com> <4E444FF1.1040208@univ-mlv.fr>
	<4E4465D2.8070306@oracle.com> <4E451C7C.4050603@univ-mlv.fr>
Message-ID: <4E45CBDA.3020902@oracle.com>

On 08/12/2011 05:28 AM, R?mi Forax wrote:
> On 08/12/2011 01:29 AM, Jonathan Gibbons wrote:
>> If you see any more opportunities for cleanup, I hope you'll let us 
>> know.  Patches (or even changesets) would be even better :-)   You 
>> could even have fun with the compiler and tree API to find examples 
>> of unclean code that are candidates for cleanup.
>
> I think you have found a good project for my students :)

Sounds good to me.  Note that small changes like these do not require 
the OCA to be signed, so it should be easier for such changes to be 
accepted into OpenJDK.

-- Jon



From weijun.wang at oracle.com  Mon Aug 15 02:43:29 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Mon, 15 Aug 2011 02:43:29 +0000
Subject: hg: jdk8/tl/jdk: 7078816:
	/test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure
Message-ID: <20110815024347.3805347BA1@hg.openjdk.java.net>

Changeset: b759d1a55cd4
Author:    weijun
Date:      2011-08-15 10:42 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b759d1a55cd4

7078816: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure
Reviewed-by: alanb

! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh



From weijun.wang at oracle.com  Mon Aug 15 03:43:39 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Mon, 15 Aug 2011 03:43:39 +0000
Subject: hg: jdk8/tl/jdk: 7079144: concise_jarsigner.sh test often fails on
	solaris
Message-ID: <20110815034349.2E59D47BA4@hg.openjdk.java.net>

Changeset: 4af32446555d
Author:    weijun
Date:      2011-08-15 11:43 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4af32446555d

7079144: concise_jarsigner.sh test often fails on solaris
Reviewed-by: xuelei

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



From sebastian.sickelmann at gmx.de  Mon Aug 15 06:17:50 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Mon, 15 Aug 2011 08:17:50 +0200
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK 8
	code review request for 6380161 (reflect) Exception from	newInstance()
	not chained to cause.
Message-ID: <4E48BA0E.6090702@gmx.de>

Hi,

some time ago, i wrote[5] with Joe and David about advancing some 
exception-types to the 4 standard ctors.

The first Exception i have looked at was InternalError and now(after 
some struggeling with gnumake and hg) my patches for reviewing are ready.

I uploaded them at [4]

I split the changes into 3 parts.

1. Added 2 ctors to InternalError and VirtualMachineError****[1]
2. Use the two ctors of InternalError****[2] (based on [1])
3. Chain Rootcause into InternalError**[3] (based also on [1])

I think part 1 and 2 are uncritical. Part 3 is more critical because it 
changes behavior (exception-chaining). But i don't think that part 3 is 
unimportable, because in case of an InternalError (use should not be 
able to recover) there shouldn't be a problem with a little longer 
exception-chain.

Is there someone who what to sponsor this or parts of it?

[1] https://bugs.openjdk.java.net/attachment.cgi?id=233
[2] https://bugs.openjdk.java.net/attachment.cgi?id=234
[3] https://bugs.openjdk.java.net/attachment.cgi?id=235
[4] https://bugs.openjdk.java.net/show_bug.cgi?id=100201
[5] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html


From xuelei.fan at oracle.com  Mon Aug 15 07:31:16 2011
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Mon, 15 Aug 2011 07:31:16 +0000
Subject: hg: jdk8/tl/jdk: 7063647: To use synchronized map in key manager
Message-ID: <20110815073126.0CF0E47BAD@hg.openjdk.java.net>

Changeset: b07cf6cbb62a
Author:    xuelei
Date:      2011-08-15 00:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b07cf6cbb62a

7063647: To use synchronized map in key manager
Reviewed-by: wetmore, weijun

! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java



From eliasen at mindspring.com  Mon Aug 15 08:39:42 2011
From: eliasen at mindspring.com (Alan Eliasen)
Date: Mon, 15 Aug 2011 02:39:42 -0600
Subject: Are the faster versions of HashMap and BigInteger going into jdk7?
In-Reply-To: <4AE69D6D.7010500@mindspring.com>
References: <212322090910230801k518cb2cew36cb50fa96c0723e@mail.gmail.com>	<17c6771e0910230812g771347d8gcf2d55045e9f6460@mail.gmail.com>	<212322090910230907u326420ccte673af409e5e24c5@mail.gmail.com>
	<17c6771e0910231001g9fcd67bt489309dfeec60016@mail.gmail.com>
	<4AE69D6D.7010500@mindspring.com>
Message-ID: <4E48DB4E.2060401@mindspring.com>

On 10/27/2009 01:12 AM, Alan Eliasen wrote:
> On 10/23/2009 11:01 AM, Andrew John Hughes wrote:
>> 6622432 is the one of the ones I just pointed to i.e. it's in JDK7.
>> If Alan has a further patch and hasn't even submitted it for
>> inclusion, it's obviously not in.
> 
>    I had just queried Joe Darcy at Sun about reviewing my patches for
> Karatsuba and Toom-Cook multiplication in BigInteger again last week.
> His reply was:
> 
>    "Yes, I apologize again for the repeated delays; I want to get your
> Karatsuba work reviewed and integrated within this JDK 7 milestone (the
> next few weeks)."

  How's this going?  (2 years later.)

-- 
  Alan Eliasen
  eliasen at mindspring.com
  http://futureboy.us/


From joe.darcy at oracle.com  Mon Aug 15 19:17:03 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 15 Aug 2011 12:17:03 -0700
Subject: JDK 8 code review request for 4850225: Integer.getInteger() : Bad
	reference to getProperty?
Message-ID: <4E4970AF.9020905@oracle.com>

Hello.

More bug cleanup, please review this small change to correct a 
misstatement in the javadoc of Integer and Long about getProperty; along 
the way, some more uses of multi-catch are added:

    4850225: Integer.getInteger() : Bad reference to getProperty?
    http://cr.openjdk.java.net/~darcy/4850225.0/

Thanks,

-Joe


From alexandre.boulgakov at oracle.com  Mon Aug 15 19:23:20 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Mon, 15 Aug 2011 12:23:20 -0700
Subject: JDK 8 code review request for 4850225: Integer.getInteger() :
	Bad reference to getProperty?
In-Reply-To: <4E4970AF.9020905@oracle.com>
References: <4E4970AF.9020905@oracle.com>
Message-ID: <4E497228.7020808@oracle.com>

Hello Joe,

It looks like you have added multiple spaces between some sentences. Is 
this intentional?

Cheers,
Sasha

On 8/15/2011 12:17 PM, Joe Darcy wrote:
> Hello.
>
> More bug cleanup, please review this small change to correct a 
> misstatement in the javadoc of Integer and Long about getProperty; 
> along the way, some more uses of multi-catch are added:
>
>    4850225: Integer.getInteger() : Bad reference to getProperty?
>    http://cr.openjdk.java.net/~darcy/4850225.0/
>
> Thanks,
>
> -Joe


From Lance.Andersen at oracle.com  Mon Aug 15 19:27:52 2011
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Mon, 15 Aug 2011 15:27:52 -0400
Subject: JDK 8 code review request for 4850225: Integer.getInteger() : Bad
	reference to getProperty?
In-Reply-To: <4E4970AF.9020905@oracle.com>
References: <4E4970AF.9020905@oracle.com>
Message-ID: <55293942-DF95-4531-A4FC-5BB8A269ACF2@oracle.com>

looks fine Joe...

Best
Lance
On Aug 15, 2011, at 3:17 PM, Joe Darcy wrote:

> Hello.
> 
> More bug cleanup, please review this small change to correct a misstatement in the javadoc of Integer and Long about getProperty; along the way, some more uses of multi-catch are added:
> 
>   4850225: Integer.getInteger() : Bad reference to getProperty?
>   http://cr.openjdk.java.net/~darcy/4850225.0/
> 
> Thanks,
> 
> -Joe


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



From joe.darcy at oracle.com  Mon Aug 15 19:33:10 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 15 Aug 2011 12:33:10 -0700
Subject: JDK 8 code review request for 4850225: Integer.getInteger() :
	Bad reference to getProperty?
In-Reply-To: <4E497228.7020808@oracle.com>
References: <4E4970AF.9020905@oracle.com> <4E497228.7020808@oracle.com>
Message-ID: <4E497476.4020208@oracle.com>

Hi Sasha.

What is an example of what you're referring to?  In the sdiff of the 
changes, the paragraph breaks are roughly the same.  (I did reformat 
some paragraphs for line breaks, etc.)

-Joe

Alexandre Boulgakov wrote:
> Hello Joe,
>
> It looks like you have added multiple spaces between some sentences. 
> Is this intentional?
>
> Cheers,
> Sasha
>
> On 8/15/2011 12:17 PM, Joe Darcy wrote:
>> Hello.
>>
>> More bug cleanup, please review this small change to correct a 
>> misstatement in the javadoc of Integer and Long about getProperty; 
>> along the way, some more uses of multi-catch are added:
>>
>>    4850225: Integer.getInteger() : Bad reference to getProperty?
>>    http://cr.openjdk.java.net/~darcy/4850225.0/
>>
>> Thanks,
>>
>> -Joe



From alexandre.boulgakov at oracle.com  Mon Aug 15 19:36:21 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Mon, 15 Aug 2011 12:36:21 -0700
Subject: JDK 8 code review request for 4850225: Integer.getInteger() :
	Bad reference to getProperty?
In-Reply-To: <4E497476.4020208@oracle.com>
References: <4E4970AF.9020905@oracle.com> <4E497228.7020808@oracle.com>
	<4E497476.4020208@oracle.com>
Message-ID: <4E497535.5000703@oracle.com>

In Integer.java, lines 779-780, there are multiple spaces between the 
sentences:
779 * <p>The first argument is treated as the name of a system
780 * property.  System properties are accessible through the {@link

-Sasha

On 8/15/2011 12:33 PM, Joe Darcy wrote:
> Hi Sasha.
>
> What is an example of what you're referring to?  In the sdiff of the 
> changes, the paragraph breaks are roughly the same.  (I did reformat 
> some paragraphs for line breaks, etc.)
>
> -Joe
>
> Alexandre Boulgakov wrote:
>> Hello Joe,
>>
>> It looks like you have added multiple spaces between some sentences. 
>> Is this intentional?
>>
>> Cheers,
>> Sasha
>>
>> On 8/15/2011 12:17 PM, Joe Darcy wrote:
>>> Hello.
>>>
>>> More bug cleanup, please review this small change to correct a 
>>> misstatement in the javadoc of Integer and Long about getProperty; 
>>> along the way, some more uses of multi-catch are added:
>>>
>>>    4850225: Integer.getInteger() : Bad reference to getProperty?
>>>    http://cr.openjdk.java.net/~darcy/4850225.0/
>>>
>>> Thanks,
>>>
>>> -Joe
>


From joe.darcy at oracle.com  Mon Aug 15 19:51:57 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 15 Aug 2011 12:51:57 -0700
Subject: JDK 8 code review request for 4850225: Integer.getInteger() :
	Bad reference to getProperty?
In-Reply-To: <4E497535.5000703@oracle.com>
References: <4E4970AF.9020905@oracle.com> <4E497228.7020808@oracle.com>
	<4E497476.4020208@oracle.com> <4E497535.5000703@oracle.com>
Message-ID: <4E4978DD.90201@oracle.com>

Hi Sasha.

In the JDK javadoc, I don't think we are that consistent on one or two 
spaces between sentences so the change below is fine.

Thanks for checking,

-Joe

Alexandre Boulgakov wrote:
> In Integer.java, lines 779-780, there are multiple spaces between the 
> sentences:
> 779 * <p>The first argument is treated as the name of a system
> 780 * property.  System properties are accessible through the {@link
>
> -Sasha
>
> On 8/15/2011 12:33 PM, Joe Darcy wrote:
>> Hi Sasha.
>>
>> What is an example of what you're referring to?  In the sdiff of the 
>> changes, the paragraph breaks are roughly the same.  (I did reformat 
>> some paragraphs for line breaks, etc.)
>>
>> -Joe
>>
>> Alexandre Boulgakov wrote:
>>> Hello Joe,
>>>
>>> It looks like you have added multiple spaces between some sentences. 
>>> Is this intentional?
>>>
>>> Cheers,
>>> Sasha
>>>
>>> On 8/15/2011 12:17 PM, Joe Darcy wrote:
>>>> Hello.
>>>>
>>>> More bug cleanup, please review this small change to correct a 
>>>> misstatement in the javadoc of Integer and Long about getProperty; 
>>>> along the way, some more uses of multi-catch are added:
>>>>
>>>>    4850225: Integer.getInteger() : Bad reference to getProperty?
>>>>    http://cr.openjdk.java.net/~darcy/4850225.0/
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>



From joe.darcy at oracle.com  Mon Aug 15 19:57:23 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Mon, 15 Aug 2011 19:57:23 +0000
Subject: hg: jdk8/tl/jdk: 4850225: Integer.getInteger() : Bad reference to
	getProperty?
Message-ID: <20110815195733.4E65947BCD@hg.openjdk.java.net>

Changeset: 6e9ed747d0ca
Author:    darcy
Date:      2011-08-15 12:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e9ed747d0ca

4850225: Integer.getInteger() : Bad reference to getProperty?
Reviewed-by: lancea

! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java



From jonathan.gibbons at oracle.com  Mon Aug 15 21:31:35 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 15 Aug 2011 21:31:35 +0000
Subject: hg: jdk8/tl/jdk: 7064075: Security libraries don't build with javac
	-Xlint:all, -deprecation -Werror
Message-ID: <20110815213145.F2CA047BD5@hg.openjdk.java.net>

Changeset: afb6f2370cd3
Author:    jjg
Date:      2011-08-15 11:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/afb6f2370cd3

7064075: Security libraries don't build with javac -Xlint:all,-deprecation -Werror
Reviewed-by: xuelei, mullan
Contributed-by: alexandre.boulgakov at oracle.com

! make/com/sun/crypto/provider/Makefile
! make/com/sun/security/Makefile
! make/java/security/Makefile
! make/javax/crypto/Makefile
! make/sun/security/Makefile
! make/sun/security/ec/Makefile
! make/sun/security/other/Makefile
! make/sun/security/pkcs11/Makefile
! src/share/classes/com/sun/crypto/provider/AESCrypt.java
! src/share/classes/com/sun/crypto/provider/AESParameters.java
! src/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java
! src/share/classes/com/sun/crypto/provider/BlowfishParameters.java
! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java
! src/share/classes/com/sun/crypto/provider/CipherCore.java
! src/share/classes/com/sun/crypto/provider/DESCrypt.java
! src/share/classes/com/sun/crypto/provider/DESKey.java
! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java
! src/share/classes/com/sun/crypto/provider/DESParameters.java
! src/share/classes/com/sun/crypto/provider/DESedeKey.java
! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java
! src/share/classes/com/sun/crypto/provider/DESedeParameters.java
! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java
! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java
! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java
! src/share/classes/com/sun/crypto/provider/DHParameters.java
! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java
! src/share/classes/com/sun/crypto/provider/DHPublicKey.java
! src/share/classes/com/sun/crypto/provider/EncryptedPrivateKeyInfo.java
! src/share/classes/com/sun/crypto/provider/HmacCore.java
! src/share/classes/com/sun/crypto/provider/JceKeyStore.java
! src/share/classes/com/sun/crypto/provider/KeyProtector.java
! src/share/classes/com/sun/crypto/provider/OAEPParameters.java
! src/share/classes/com/sun/crypto/provider/PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/PBEKey.java
! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java
! src/share/classes/com/sun/crypto/provider/PBEParameters.java
! src/share/classes/com/sun/crypto/provider/PBKDF2HmacSHA1Factory.java
! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
! src/share/classes/com/sun/crypto/provider/PCBC.java
! src/share/classes/com/sun/crypto/provider/RC2Cipher.java
! src/share/classes/com/sun/crypto/provider/RC2Parameters.java
! src/share/classes/com/sun/crypto/provider/RSACipher.java
! src/share/classes/com/sun/crypto/provider/SunJCE.java
! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
! src/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java
! src/share/classes/com/sun/security/auth/PolicyFile.java
! src/share/classes/com/sun/security/auth/SubjectCodeSource.java
! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java
! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java
! src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java
! src/share/classes/com/sun/security/ntlm/NTLMException.java
! src/share/classes/com/sun/security/sasl/CramMD5Server.java
! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java
! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java
! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java
! src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java
! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
! src/share/classes/com/sun/security/sasl/util/PolicyUtils.java
! src/share/classes/java/security/AccessControlContext.java
! src/share/classes/java/security/AccessController.java
! src/share/classes/java/security/BasicPermission.java
! src/share/classes/java/security/Permissions.java
! src/share/classes/java/security/Policy.java
! src/share/classes/java/security/ProtectionDomain.java
! src/share/classes/java/security/Provider.java
! src/share/classes/java/security/Security.java
! src/share/classes/java/security/UnresolvedPermission.java
! src/share/classes/java/security/UnresolvedPermissionCollection.java
! src/share/classes/java/security/cert/CertificateRevokedException.java
! src/share/classes/java/security/cert/X509CRLSelector.java
! src/share/classes/java/security/cert/X509CertSelector.java
! src/share/classes/javax/crypto/Cipher.java
! src/share/classes/javax/crypto/CryptoAllPermission.java
! src/share/classes/javax/crypto/CryptoPermission.java
! src/share/classes/javax/crypto/CryptoPermissions.java
! src/share/classes/javax/crypto/CryptoPolicyParser.java
! src/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java
! src/share/classes/javax/crypto/JarVerifier.java
! src/share/classes/javax/crypto/JceSecurity.java
! src/share/classes/javax/crypto/JceSecurityManager.java
! src/share/classes/javax/crypto/KeyAgreement.java
! src/share/classes/javax/crypto/KeyGenerator.java
! src/share/classes/javax/crypto/Mac.java
! src/share/classes/javax/crypto/SealedObject.java
! src/share/classes/javax/crypto/SecretKeyFactory.java
! src/share/classes/javax/crypto/SecretKeyFactorySpi.java
! src/share/classes/javax/crypto/spec/DESKeySpec.java
! src/share/classes/javax/crypto/spec/DESedeKeySpec.java
! src/share/classes/javax/crypto/spec/IvParameterSpec.java
! src/share/classes/javax/crypto/spec/PBEKeySpec.java
! src/share/classes/javax/crypto/spec/PBEParameterSpec.java
! src/share/classes/javax/crypto/spec/PSource.java
! src/share/classes/javax/crypto/spec/RC2ParameterSpec.java
! src/share/classes/javax/crypto/spec/RC5ParameterSpec.java
! src/share/classes/javax/crypto/spec/SecretKeySpec.java
! src/share/classes/sun/security/acl/AclEntryImpl.java
! src/share/classes/sun/security/action/PutAllAction.java
! src/share/classes/sun/security/ec/ECDSASignature.java
! src/share/classes/sun/security/ec/ECKeyFactory.java
! src/share/classes/sun/security/ec/ECParameters.java
! src/share/classes/sun/security/jca/GetInstance.java
! src/share/classes/sun/security/jca/ProviderList.java
! src/share/classes/sun/security/jca/Providers.java
! src/share/classes/sun/security/jgss/GSSUtil.java
! src/share/classes/sun/security/jgss/krb5/CipherHelper.java
! src/share/classes/sun/security/jgss/krb5/Krb5Context.java
! src/share/classes/sun/security/jgss/krb5/Krb5Util.java
! src/share/classes/sun/security/jgss/krb5/MessageToken.java
! src/share/classes/sun/security/jgss/krb5/SubjectComber.java
! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
! src/share/classes/sun/security/jgss/wrapper/NativeGSSFactory.java
! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java
! src/share/classes/sun/security/krb5/Checksum.java
! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/KrbServiceLocator.java
! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
! src/share/classes/sun/security/pkcs/ContentInfo.java
! src/share/classes/sun/security/pkcs/PKCS10.java
! src/share/classes/sun/security/pkcs/PKCS7.java
! src/share/classes/sun/security/pkcs/PKCS8Key.java
! src/share/classes/sun/security/pkcs/PKCS9Attribute.java
! src/share/classes/sun/security/pkcs/SignerInfo.java
! src/share/classes/sun/security/pkcs11/Config.java
! src/share/classes/sun/security/pkcs11/P11Cipher.java
! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11Key.java
! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java
! src/share/classes/sun/security/pkcs11/P11KeyFactory.java
! src/share/classes/sun/security/pkcs11/P11KeyStore.java
! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11Signature.java
! src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java
! src/share/classes/sun/security/pkcs11/P11Util.java
! src/share/classes/sun/security/pkcs11/Secmod.java
! src/share/classes/sun/security/pkcs11/wrapper/Functions.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11RuntimeException.java
! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
! src/share/classes/sun/security/provider/DSAKeyFactory.java
! src/share/classes/sun/security/provider/DSAParameters.java
! src/share/classes/sun/security/provider/MD4.java
! src/share/classes/sun/security/provider/PolicyFile.java
! src/share/classes/sun/security/provider/certpath/AdaptableX509CertSelector.java
! src/share/classes/sun/security/provider/certpath/Builder.java
! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java
! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
! src/share/classes/sun/security/provider/certpath/ForwardState.java
! src/share/classes/sun/security/provider/certpath/IndexedCollectionCertStore.java
! src/share/classes/sun/security/provider/certpath/OCSP.java
! src/share/classes/sun/security/provider/certpath/OCSPChecker.java
! src/share/classes/sun/security/provider/certpath/OCSPResponse.java
! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java
! src/share/classes/sun/security/provider/certpath/PolicyChecker.java
! src/share/classes/sun/security/provider/certpath/ReverseState.java
! src/share/classes/sun/security/provider/certpath/URICertStore.java
! src/share/classes/sun/security/provider/certpath/Vertex.java
! src/share/classes/sun/security/provider/certpath/X509CertPath.java
! src/share/classes/sun/security/rsa/RSAKeyFactory.java
! src/share/classes/sun/security/rsa/RSASignature.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/HandshakeMessage.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/timestamp/HttpTimestamper.java
! src/share/classes/sun/security/timestamp/TSResponse.java
! src/share/classes/sun/security/tools/JarSigner.java
! src/share/classes/sun/security/tools/KeyTool.java
! src/share/classes/sun/security/tools/TimestampedSigner.java
! src/share/classes/sun/security/tools/policytool/PolicyTool.java
! src/share/classes/sun/security/util/Cache.java
! src/share/classes/sun/security/util/ManifestDigester.java
! src/share/classes/sun/security/util/Password.java
! src/share/classes/sun/security/util/SignatureFileVerifier.java
! src/share/classes/sun/security/validator/SimpleValidator.java
! src/share/classes/sun/security/x509/AVA.java
! src/share/classes/sun/security/x509/AccessDescription.java
! src/share/classes/sun/security/x509/AlgorithmId.java
! src/share/classes/sun/security/x509/AuthorityInfoAccessExtension.java
! src/share/classes/sun/security/x509/CRLDistributionPointsExtension.java
! src/share/classes/sun/security/x509/CRLExtensions.java
! src/share/classes/sun/security/x509/CRLNumberExtension.java
! src/share/classes/sun/security/x509/CRLReasonCodeExtension.java
! src/share/classes/sun/security/x509/CertAndKeyGen.java
! src/share/classes/sun/security/x509/CertificateAlgorithmId.java
! src/share/classes/sun/security/x509/CertificateExtensions.java
! src/share/classes/sun/security/x509/CertificateIssuerExtension.java
! src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
! src/share/classes/sun/security/x509/CertificatePoliciesExtension.java
! src/share/classes/sun/security/x509/CertificatePolicyId.java
! src/share/classes/sun/security/x509/CertificateSerialNumber.java
! src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
! src/share/classes/sun/security/x509/CertificateValidity.java
! src/share/classes/sun/security/x509/CertificateVersion.java
! src/share/classes/sun/security/x509/CertificateX509Key.java
! src/share/classes/sun/security/x509/ExtendedKeyUsageExtension.java
! src/share/classes/sun/security/x509/Extension.java
! src/share/classes/sun/security/x509/InhibitAnyPolicyExtension.java
! src/share/classes/sun/security/x509/InvalidityDateExtension.java
! src/share/classes/sun/security/x509/IssuerAlternativeNameExtension.java
! src/share/classes/sun/security/x509/KeyUsageExtension.java
! src/share/classes/sun/security/x509/NameConstraintsExtension.java
! src/share/classes/sun/security/x509/NetscapeCertTypeExtension.java
! src/share/classes/sun/security/x509/OIDMap.java
! src/share/classes/sun/security/x509/OIDName.java
! src/share/classes/sun/security/x509/OtherName.java
! src/share/classes/sun/security/x509/PolicyConstraintsExtension.java
! src/share/classes/sun/security/x509/PolicyInformation.java
! src/share/classes/sun/security/x509/PolicyMappingsExtension.java
! src/share/classes/sun/security/x509/PrivateKeyUsageExtension.java
! src/share/classes/sun/security/x509/RDN.java
! src/share/classes/sun/security/x509/SubjectAlternativeNameExtension.java
! src/share/classes/sun/security/x509/SubjectInfoAccessExtension.java
! src/share/classes/sun/security/x509/SubjectKeyIdentifierExtension.java
! src/share/classes/sun/security/x509/X500Name.java
! src/share/classes/sun/security/x509/X509CRLEntryImpl.java
! src/share/classes/sun/security/x509/X509CRLImpl.java
! src/share/classes/sun/security/x509/X509CertImpl.java
! src/share/classes/sun/security/x509/X509CertInfo.java
! src/share/classes/sun/security/x509/X509Key.java
! src/windows/classes/sun/security/mscapi/KeyStore.java
! src/windows/classes/sun/security/mscapi/PRNG.java
! src/windows/classes/sun/security/mscapi/RSAPrivateKey.java
! src/windows/classes/sun/security/mscapi/RSAPublicKey.java
! src/windows/classes/sun/security/mscapi/RSASignature.java
! src/windows/classes/sun/security/mscapi/SunMSCAPI.java



From weijun.wang at oracle.com  Tue Aug 16 00:53:42 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Tue, 16 Aug 2011 00:53:42 +0000
Subject: hg: jdk8/tl/jdk: 7079204: add several security and networking tests
	to problems list
Message-ID: <20110816005353.2695847BDE@hg.openjdk.java.net>

Changeset: dd218ad64d5c
Author:    weijun
Date:      2011-08-16 08:53 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd218ad64d5c

7079204: add several security and networking tests to problems list
Reviewed-by: smarks

! test/ProblemList.txt



From ahughes at redhat.com  Tue Aug 16 02:10:57 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Tue, 16 Aug 2011 03:10:57 +0100
Subject: Are the faster versions of HashMap and BigInteger going into jdk7?
In-Reply-To: <4E48DB4E.2060401@mindspring.com>
References: <212322090910230801k518cb2cew36cb50fa96c0723e@mail.gmail.com>
	<17c6771e0910230812g771347d8gcf2d55045e9f6460@mail.gmail.com>
	<212322090910230907u326420ccte673af409e5e24c5@mail.gmail.com>
	<17c6771e0910231001g9fcd67bt489309dfeec60016@mail.gmail.com>
	<4AE69D6D.7010500@mindspring.com> <4E48DB4E.2060401@mindspring.com>
Message-ID: <20110816021057.GB16879@rivendell.middle-earth.co.uk>

On 02:39 Mon 15 Aug     , Alan Eliasen wrote:
> On 10/27/2009 01:12 AM, Alan Eliasen wrote:
> > On 10/23/2009 11:01 AM, Andrew John Hughes wrote:
> >> 6622432 is the one of the ones I just pointed to i.e. it's in JDK7.
> >> If Alan has a further patch and hasn't even submitted it for
> >> inclusion, it's obviously not in.
> > 
> >    I had just queried Joe Darcy at Sun about reviewing my patches for
> > Karatsuba and Toom-Cook multiplication in BigInteger again last week.
> > His reply was:
> > 
> >    "Yes, I apologize again for the repeated delays; I want to get your
> > Karatsuba work reviewed and integrated within this JDK 7 milestone (the
> > next few weeks)."
> 
>   How's this going?  (2 years later.)
> 

Did you post the patches to the list?  Do you have a link if so?

> -- 
>   Alan Eliasen
>   eliasen at mindspring.com
>   http://futureboy.us/

-- 
Andrew :)

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

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From Alan.Bateman at oracle.com  Tue Aug 16 11:35:26 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Aug 2011 12:35:26 +0100
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E48BA0E.6090702@gmx.de>
References: <4E48BA0E.6090702@gmx.de>
Message-ID: <4E4A55FE.3040405@oracle.com>

Sebastian Sickelmann wrote:
> Hi,
>
> some time ago, i wrote[5] with Joe and David about advancing some 
> exception-types to the 4 standard ctors.
>
> The first Exception i have looked at was InternalError and now(after 
> some struggeling with gnumake and hg) my patches for reviewing are ready.
>
> I uploaded them at [4]
>
> I split the changes into 3 parts.
>
> 1. Added 2 ctors to InternalError and VirtualMachineError****[1]
> 2. Use the two ctors of InternalError****[2] (based on [1])
> 3. Chain Rootcause into InternalError**[3] (based also on [1])
>
> I think part 1 and 2 are uncritical. Part 3 is more critical because 
> it changes behavior (exception-chaining). But i don't think that part 
> 3 is unimportable, because in case of an InternalError (use should not 
> be able to recover) there shouldn't be a problem with a little longer 
> exception-chain.
>
> Is there someone who what to sponsor this or parts of it?
I don't have cycles but I can generate a webrev (essentially browsable 
diffs) for you that would make this easy to review. Do you mind 
re-basing your patches so that they can be applied to jdk8/tl/jdk? I 
think Sasha got in before you and has already changesd several places to 
use multi-catch that are in your patches too.

-Alan.


From sebastian.sickelmann at gmx.de  Tue Aug 16 18:11:48 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Tue, 16 Aug 2011 20:11:48 +0200
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E4A55FE.3040405@oracle.com>
References: <4E48BA0E.6090702@gmx.de> <4E4A55FE.3040405@oracle.com>
Message-ID: <4E4AB2E4.5070300@gmx.de>

Am 16.08.2011 13:35, schrieb Alan Bateman:
> Sebastian Sickelmann wrote:
>> Hi,
>>
>> some time ago, i wrote[5] with Joe and David about advancing some 
>> exception-types to the 4 standard ctors.
>>
>> The first Exception i have looked at was InternalError and now(after 
>> some struggeling with gnumake and hg) my patches for reviewing are 
>> ready.
>>
>> I uploaded them at [4]
>>
>> I split the changes into 3 parts.
>>
>> 1. Added 2 ctors to InternalError and VirtualMachineError****[1]
>> 2. Use the two ctors of InternalError****[2] (based on [1])
>> 3. Chain Rootcause into InternalError**[3] (based also on [1])
>>
>> I think part 1 and 2 are uncritical. Part 3 is more critical because 
>> it changes behavior (exception-chaining). But i don't think that part 
>> 3 is unimportable, because in case of an InternalError (use should 
>> not be able to recover) there shouldn't be a problem with a little 
>> longer exception-chain.
>>
>> Is there someone who what to sponsor this or parts of it?
> I don't have cycles but I can generate a webrev (essentially browsable 
> diffs) for you that would make this easy to review. Do you mind 
> re-basing your patches so that they can be applied to jdk8/tl/jdk? I 
> think Sasha got in before you and has already changesd several places 
> to use multi-catch that are in your patches too.
>
> -Alan.
It would be great to have a webrev for them.
I rebased my patches on dd218ad64d5c of 
http://hg.openjdk.java.net/jdk8/tl/jdk/

The patches are here:
https://bugs.openjdk.java.net/attachment.cgi?id=236 (diff view: 
https://bugs.openjdk.java.net/attachment.cgi?id=236&action=diff)
https://bugs.openjdk.java.net/attachment.cgi?id=237 (diff view: 
https://bugs.openjdk.java.net/attachment.cgi?id=237&action=diff)
https://bugs.openjdk.java.net/attachment.cgi?id=238 (diff view: 
https://bugs.openjdk.java.net/attachment.cgi?id=238&action=diff)

Is there a way to create webrev on my linux box (ubuntu)? Is there a 
good description for it?

I have another(RuntimeException) patch here:
https://bugs.openjdk.java.net/attachment.cgi?id=239 (diff view: 
https://bugs.openjdk.java.net/attachment.cgi?id=239&action=diff)
Maybe i can create a webrev on my own for this.

-- Sebastian


From Alan.Bateman at oracle.com  Tue Aug 16 20:37:39 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Aug 2011 21:37:39 +0100
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E4AB2E4.5070300@gmx.de>
References: <4E48BA0E.6090702@gmx.de> <4E4A55FE.3040405@oracle.com>
	<4E4AB2E4.5070300@gmx.de>
Message-ID: <4E4AD513.6090402@oracle.com>

Sebastian Sickelmann wrote:
> It would be great to have a webrev for them.
> I rebased my patches on dd218ad64d5c of 
> http://hg.openjdk.java.net/jdk8/tl/jdk/
>
> The patches are here:
> https://bugs.openjdk.java.net/attachment.cgi?id=236 (diff view: 
> https://bugs.openjdk.java.net/attachment.cgi?id=236&action=diff)
> https://bugs.openjdk.java.net/attachment.cgi?id=237 (diff view: 
> https://bugs.openjdk.java.net/attachment.cgi?id=237&action=diff)
> https://bugs.openjdk.java.net/attachment.cgi?id=238 (diff view: 
> https://bugs.openjdk.java.net/attachment.cgi?id=238&action=diff)
>
> Is there a way to create webrev on my linux box (ubuntu)? Is there a 
> good description for it?
>
> I have another(RuntimeException) patch here:
> https://bugs.openjdk.java.net/attachment.cgi?id=239 (diff view: 
> https://bugs.openjdk.java.net/attachment.cgi?id=239&action=diff)
> Maybe i can create a webrev on my own for this.
>
> -- Sebastian
If you are on Linux then webrev is easy to use. It's located in the 
top-level repo in the make/scripts directory, just do webrev.ksh -N to 
generate a webrev from the files that "hg status" indicates has changed. 
The output will go to a webrev directory that you can publish on any 
http servers.

-Alan




From joe.darcy at oracle.com  Wed Aug 17 01:11:04 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 16 Aug 2011 18:11:04 -0700
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E48BA0E.6090702@gmx.de>
References: <4E48BA0E.6090702@gmx.de>
Message-ID: <4E4B1528.8060306@oracle.com>

Hello.

On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote:
> Hi,
>
> some time ago, i wrote[5] with Joe and David about advancing some 
> exception-types to the 4 standard ctors.
>
> The first Exception i have looked at was InternalError and now(after 
> some struggeling with gnumake and hg) my patches for reviewing are ready.
>
> I uploaded them at [4]
>
> I split the changes into 3 parts.
>
> 1. Added 2 ctors to InternalError and VirtualMachineError****[1]
> 2. Use the two ctors of InternalError****[2] (based on [1])
> 3. Chain Rootcause into InternalError**[3] (based also on [1])
>
> I think part 1 and 2 are uncritical. Part 3 is more critical because 
> it changes behavior (exception-chaining). But i don't think that part 
> 3 is unimportable, because in case of an InternalError (use should not 
> be able to recover) there shouldn't be a problem with a little longer 
> exception-chain.
>
> Is there someone who what to sponsor this or parts of it?
>
> [1] https://bugs.openjdk.java.net/attachment.cgi?id=233
> [2] https://bugs.openjdk.java.net/attachment.cgi?id=234
> [3] https://bugs.openjdk.java.net/attachment.cgi?id=235
> [4] https://bugs.openjdk.java.net/show_bug.cgi?id=100201
> [5] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html 
>

I am willing to sponsor this work and I've filed bug 7080020 "Add 
conventional constructors to InternalError" for it.

For adding constructors to InternalError (or VirtualMachineError), the 
push that adds the constructors should include some usage of them.  
Therefore, at least portions of 1) and 2) above should be combined.  If 
there are easy to find usages of a cause for VirtualMachineError, then 
those should be included at the same time any new constructors are added 
there.

There is some currently Oracle-internal paperwork which needs to be 
filed to make an API change; I'll file that paperwork once there is 
verification on whether updates to both InternalError and 
VirtualMachineError will be included in this round of work.  The 
paperwork needs to be approved before the change is pushed and typically 
takes a few days to be processed.

Cheers,

-Joe



From xueming.shen at oracle.com  Wed Aug 17 08:42:06 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 17 Aug 2011 01:42:06 -0700
Subject: Request for review 6237353: Remove sun.io package from j2se binary
Message-ID: <4E4B7EDE.6040006@oracle.com>

Hi,

This is something long over due. Some background info.

(1)The java.nio.charset package (to replace the private sun.io package) 
is added into
      JDK 1.4 as the result of the nio JSR. Part of the sun.io 
converters were migrated to
      the java.nio.charset  implementation in JDK8.
(2) All supported charsets/converters were migrated to java.nio.charset 
in JDK5. As the
      result no more bug fix/rfe maintenance work for sun.io since then.
(3) Removed all sun.io dependencies (internal sun.io usage inside JDK) 
from the JDK
      repository at the beginning of JDK6.
(4) The sun.io package was removed from the JDK runtime at JDK6 b29.

But we then had one important licensee strongly asked to undo the 
removal. The sun.io
was putback in JDK6 6u59/beta.

Now let's try this again in JDK8, the licensee that was against it in 
JDK6 last time has been
communicated and is OK with the plan this time. And the JDBC EG group 
(which heavily
used sun.io package in the past)  is/will be noticed as well. We assume 
after 3 major releases
the risk of breaking someone's application (as the result of this 
change) is limited.

Here is the webrev. Since we have tried it already (the workspace had 
been cleaned up
already) in jdk6 again already, the change this time is relatively 
simple, mainly only 2 makefile
changes. The rest is the "deleting" and several minor changes in testing.

http://cr.openjdk.java.net/~sherman/6237353/webrev/
http://cr.openjdk.java.net/~sherman/6237353/closed/

-Sherman





From Alan.Bateman at oracle.com  Wed Aug 17 09:07:59 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Aug 2011 10:07:59 +0100
Subject: Request for review 6237353: Remove sun.io package from j2se binary
In-Reply-To: <4E4B7EDE.6040006@oracle.com>
References: <4E4B7EDE.6040006@oracle.com>
Message-ID: <4E4B84EF.9000005@oracle.com>

Xueming Shen wrote:
> Hi,
>
> This is something long over due. Some background info.
>
> (1)The java.nio.charset package (to replace the private sun.io 
> package) is added into
>      JDK 1.4 as the result of the nio JSR. Part of the sun.io 
> converters were migrated to
>      the java.nio.charset  implementation in JDK8.
> (2) All supported charsets/converters were migrated to 
> java.nio.charset in JDK5. As the
>      result no more bug fix/rfe maintenance work for sun.io since then.
> (3) Removed all sun.io dependencies (internal sun.io usage inside JDK) 
> from the JDK
>      repository at the beginning of JDK6.
> (4) The sun.io package was removed from the JDK runtime at JDK6 b29.
>
> But we then had one important licensee strongly asked to undo the 
> removal. The sun.io
> was putback in JDK6 6u59/beta.
>
> Now let's try this again in JDK8, the licensee that was against it in 
> JDK6 last time has been
> communicated and is OK with the plan this time. And the JDBC EG group 
> (which heavily
> used sun.io package in the past)  is/will be noticed as well. We 
> assume after 3 major releases
> the risk of breaking someone's application (as the result of this 
> change) is limited.
>
> Here is the webrev. Since we have tried it already (the workspace had 
> been cleaned up
> already) in jdk6 again already, the change this time is relatively 
> simple, mainly only 2 makefile
> changes. The rest is the "deleting" and several minor changes in testing.
>
> http://cr.openjdk.java.net/~sherman/6237353/webrev/
Thanks for doing this, and thanks Lance for checking with all the JDBC 
folks in your phone book.

The changes looks good to me. Push it quick and run :-)

-Alan



From Alan.Bateman at oracle.com  Wed Aug 17 11:45:33 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Aug 2011 12:45:33 +0100
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E4B1528.8060306@oracle.com>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
Message-ID: <4E4BA9DD.20706@oracle.com>

joe.darcy at oracle.com wrote:
>
> I am willing to sponsor this work and I've filed bug 7080020 "Add 
> conventional constructors to InternalError" for it.
>
Thanks Joe, and to help this along here's the webrev with Sebastian's 
patches:
   http://cr.openjdk.java.net/~alanb/7080020/webrev/

I haven't really looked but one thing I did notice is that the 
multi-catch usages need to be checked as Sasha cleaned up a few of these 
recently.

-Alan.


From Ulf.Zibis at gmx.de  Wed Aug 17 12:37:23 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 17 Aug 2011 14:37:23 +0200
Subject: Request for review 6237353: Remove sun.io package from j2se binary
In-Reply-To: <4E4B7EDE.6040006@oracle.com>
References: <4E4B7EDE.6040006@oracle.com>
Message-ID: <4E4BB603.4050604@gmx.de>

As a consequence, allmost all classes in sun.nio.cs and templates in make/tools/CharsetMapping could 
be made package private, at least all access to the mapping tables!

... and don't forget to remove in each sun.nio.cs class and template:

     /**
      * These accessors are temporarily supplied while sun.io
      * converters co-exist with the sun.nio.cs.{ext} charset coders
      * These facilitate sharing of conversion tables between the
      * two co-existing implementations. When sun.io converters
      * are made extinct these will be unncessary and should be removed
      */

     public String getDecoderSingleByteMappings() {
         return b2cTable;
     }

     public short[] getDecoderIndex1() {
         return Decoder.index1;
     }

     public String[] getDecoderIndex2() {
         return Decoder.index2;

     }

     public short[] getEncoderIndex1() {
         return Encoder.index1;

     }
     public String[] getEncoderIndex2() {
         return Encoder.index2;

     }

Additionally, you could mention my wrapper classes [1] in the WORKAROUND section of bug 6237353

[1] http://java.net/projects/java-nio-charset-enhanced/sources/svn/show/trunk/src/sun/io/


-Ulf




From alexandre.boulgakov at oracle.com  Wed Aug 17 12:54:30 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Wed, 17 Aug 2011 05:54:30 -0700
Subject: Request for review 6237353: Remove sun.io package from j2se binary
In-Reply-To: <4E4B84EF.9000005@oracle.com>
References: <4E4B7EDE.6040006@oracle.com> <4E4B84EF.9000005@oracle.com>
Message-ID: <4E4BBA06.2030305@oracle.com>

Hello Sherman,

Can you check if any deprecation warnings are generated from the other 
classes built by java/sun_nio/Makefile? Suppressing deprecation warnings 
might no longer be necessary now that sun.io is gone, and then you can 
change lines 34-35 in the makefile to "JAVAC_MAX_WARNINGS = true".

Cheers,
Sasha

On 8/17/2011 2:07 AM, Alan Bateman wrote:
> Xueming Shen wrote:
>> Hi,
>>
>> This is something long over due. Some background info.
>>
>> (1)The java.nio.charset package (to replace the private sun.io 
>> package) is added into
>>      JDK 1.4 as the result of the nio JSR. Part of the sun.io 
>> converters were migrated to
>>      the java.nio.charset  implementation in JDK8.
>> (2) All supported charsets/converters were migrated to 
>> java.nio.charset in JDK5. As the
>>      result no more bug fix/rfe maintenance work for sun.io since then.
>> (3) Removed all sun.io dependencies (internal sun.io usage inside 
>> JDK) from the JDK
>>      repository at the beginning of JDK6.
>> (4) The sun.io package was removed from the JDK runtime at JDK6 b29.
>>
>> But we then had one important licensee strongly asked to undo the 
>> removal. The sun.io
>> was putback in JDK6 6u59/beta.
>>
>> Now let's try this again in JDK8, the licensee that was against it in 
>> JDK6 last time has been
>> communicated and is OK with the plan this time. And the JDBC EG group 
>> (which heavily
>> used sun.io package in the past)  is/will be noticed as well. We 
>> assume after 3 major releases
>> the risk of breaking someone's application (as the result of this 
>> change) is limited.
>>
>> Here is the webrev. Since we have tried it already (the workspace had 
>> been cleaned up
>> already) in jdk6 again already, the change this time is relatively 
>> simple, mainly only 2 makefile
>> changes. The rest is the "deleting" and several minor changes in 
>> testing.
>>
>> http://cr.openjdk.java.net/~sherman/6237353/webrev/
> Thanks for doing this, and thanks Lance for checking with all the JDBC 
> folks in your phone book.
>
> The changes looks good to me. Push it quick and run :-)
>
> -Alan
>


From sebastian.sickelmann at gmx.de  Wed Aug 17 14:43:10 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 17 Aug 2011 16:43:10 +0200
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E4BA9DD.20706@oracle.com>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
	<4E4BA9DD.20706@oracle.com>
Message-ID: <4E4BD37E.4060402@gmx.de>

Am 17.08.2011 13:45, schrieb Alan Bateman:
> joe.darcy at oracle.com wrote:
>>
>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
>> conventional constructors to InternalError" for it.
>>
> Thanks Joe, and to help this along here's the webrev with Sebastian's 
> patches:
>   http://cr.openjdk.java.net/~alanb/7080020/webrev/
>
> I haven't really looked but one thing I did notice is that the 
> multi-catch usages need to be checked as Sasha cleaned up a few of 
> these recently.
>
> -Alan.
Thanks for the webrev.

I think it is very hard to start with the complete patch. Or is it 
better to review it all at once?

I have created a webrev for my patches 0 and 1 and uploaded it here:
http://oss-patches.24.eu/openjdk8/InternalError/part1/

After i have pulled from tl/jdk i got problems with building.
I got warnings so that i must build with JAVAC_WARNINGS_FATAL=false, is 
this ok for tl-repo?

-- Sebastian


From alexandre.boulgakov at oracle.com  Wed Aug 17 14:58:43 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Wed, 17 Aug 2011 07:58:43 -0700
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E4BD37E.4060402@gmx.de>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
	<4E4BA9DD.20706@oracle.com> <4E4BD37E.4060402@gmx.de>
Message-ID: <4E4BD723.2040702@oracle.com>

Hello Sebastian.

On 8/17/2011 7:43 AM, Sebastian Sickelmann wrote:
> Am 17.08.2011 13:45, schrieb Alan Bateman:
>> joe.darcy at oracle.com wrote:
>>>
>>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
>>> conventional constructors to InternalError" for it.
>>>
>> Thanks Joe, and to help this along here's the webrev with Sebastian's 
>> patches:
>>   http://cr.openjdk.java.net/~alanb/7080020/webrev/
>>
>> I haven't really looked but one thing I did notice is that the 
>> multi-catch usages need to be checked as Sasha cleaned up a few of 
>> these recently.
>>
>> -Alan.
> Thanks for the webrev.
>
> I think it is very hard to start with the complete patch. Or is it 
> better to review it all at once?
>
> I have created a webrev for my patches 0 and 1 and uploaded it here:
> http://oss-patches.24.eu/openjdk8/InternalError/part1/
>
> After i have pulled from tl/jdk i got problems with building.
> I got warnings so that i must build with JAVAC_WARNINGS_FATAL=false, 
> is this ok for tl-repo?

You should not set JAVAC_WARNINGS_FATAL manually, and you can ignore any 
preexisting warnings (although you should not introduce any new ones). 
The makefiles where it is safe to compile with JAVAC_WARNINGS_FATAL will 
set it appropriately. There is an ongoing effort to reduce javac 
warnings (including lint warnings, which are not currently enabled in 
all parts of the code). If you build with JAVAC_MAX_WARNINGS=true, you 
will notice that there are just over 10,000 javac build warnings in 
tl/jdk...

Cheers,
Sasha

>
> -- Sebastian


From lvjing at linux.vnet.ibm.com  Wed Aug 17 16:41:31 2011
From: lvjing at linux.vnet.ibm.com (Jing LV)
Date: Thu, 18 Aug 2011 00:41:31 +0800
Subject: 7015589: (spec) BufferedWriter.close leaves stream open if close
	of underlying Writer fails
In-Reply-To: <4E411D52.1080509@oracle.com>
References: <4E411D52.1080509@oracle.com>
Message-ID: <4E4BEF3B.2060001@linux.vnet.ibm.com>

Hi Alan,

Sorry for late reply, I somehow miss this mail. The patch seems perfect. 
Just a curious question about the fix in BufferedWriter:

-            try {
+            try (Writer w = out) {
                  flushBuffer();
              } finally {
-                out.close();
                  out = null;
                  cb = null;
              }

    I see this is a java7 new feature (try-catch-resource), but it use a new variable.
    I am not very familiar with the new feature yet, so is this better than put out.close() in finally block?
    And if we'd like to fix java6 as well, we may use finally? Not sure if the complied binary would be the same?



? 2011-8-9 19:43, Alan Bateman ??:
>
> A few months back there was a bug report [1] pointing out that it's 
> possible to continue writing to a BufferedWriter after invoking its 
> close method and the close fails. A similar issue arises with 
> BufferedOutputStream and other classes. At issue is whether a stream 
> (or more generally a resource) is considered closed in the event that 
> the close method fails. This isn't something that Closeable is clear 
> on. Joe tells me that this didn't come up in the Coin discussions on 
> try-with-resources either.
>
> I think it's safe to say that it would be desirable that close 
> releases the resources for failing cases as otherwise the resources 
> may never be released (esp. with try-with-resources usages). 
> Furthermore, when there are multiple resources involved, or cases like 
> the bug report where one stream wraps another, then it would be 
> desirable to keep the state of the resources in sync. To that end, the 
> changes here propose adding an advisory note to AutoCloseable to 
> advise implementers to release the underlying resources and to mark 
> the resource as closed prior to throwing the exception.
>
> For the specific buffering classes discussed at the time, these are 
> changed to follow this advise (but their javadoc isn't changed as 
> there may be other implementations or these classes extended in many 
> ways). In the case of BufferedWriter it is also fixed so that any 
> exception from flushing the underlying writer isn't supplanted by the 
> exception from close. In the case of FilterOutputStream 
> (BufferedOutputStream extends it) then it is fixed so that it doesn't 
> ignore the exception thrown when flushing the underlying stream. This 
> is clearly the right thing to do but it does mean that close can now 
> throw an IOException for a case where it didn't before. For now I 
> don't propose to include a compatibility switch but this may be 
> something that has to revisited later. There are other classes in 
> java.io that could also be cleaned up but I don't propose to do a 
> complete audit at this time.
>
> The webrev with the changes is here:
> http://cr.openjdk.java.net/~alanb/7015589/webrev/
>
> Thanks,
> Alan.
>
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005732.html


-- 
Best Regards,
Jimmy, Jing LV




From forax at univ-mlv.fr  Wed Aug 17 17:30:01 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Wed, 17 Aug 2011 19:30:01 +0200
Subject: 7015589: (spec) BufferedWriter.close leaves stream open if close
	of underlying Writer fails
In-Reply-To: <4E4BEF3B.2060001@linux.vnet.ibm.com>
References: <4E411D52.1080509@oracle.com> <4E4BEF3B.2060001@linux.vnet.ibm.com>
Message-ID: <4E4BFA99.2000107@univ-mlv.fr>

On 08/17/2011 06:41 PM, Jing LV wrote:
> Hi Alan,
>
> Sorry for late reply, I somehow miss this mail. The patch seems 
> perfect. Just a curious question about the fix in BufferedWriter:
>
> -            try {
> +            try (Writer w = out) {
>                  flushBuffer();
>              } finally {
> -                out.close();
>                  out = null;
>                  cb = null;
>              }
>
>    I see this is a java7 new feature (try-catch-resource), but it use 
> a new variable.

Yes, you have to declare a new variable, you can't use an expression.

>    I am not very familiar with the new feature yet, so is this better 
> than put out.close() in finally block?

see 
http://download.oracle.com/javase/7/docs/technotes/guides/language/try-with-resources.html
the difference is the way the exception that is thrown by out.close() if 
fushBuffer()
also throws an exception is managed (see supressed exception)

>    And if we'd like to fix java6 as well, we may use finally? Not sure 
> if the complied binary would be the same?

It will not be the same but jdk6 has no suppressed exception.

R?mi



From naoto.sato at oracle.com  Wed Aug 17 18:10:16 2011
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 17 Aug 2011 18:10:16 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20110817181050.4D8BB47C69@hg.openjdk.java.net>

Changeset: c3a8d5feee94
Author:    naoto
Date:      2011-08-17 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3a8d5feee94

7073906: Locale.getDefault() returns wrong Locale for Java SE 7
Reviewed-by: okutsu

! src/windows/native/java/lang/java_props_md.c

Changeset: f59c83f515e6
Author:    naoto
Date:      2011-08-17 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f59c83f515e6

7079486: Locale.getDisplayScript() (no args) does not honor default DISPLAY locale
Reviewed-by: okutsu

! src/share/classes/java/util/Locale.java
! test/java/util/Locale/LocaleCategory.java
! test/java/util/Locale/LocaleCategory.sh



From xueming.shen at oracle.com  Wed Aug 17 18:41:52 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 17 Aug 2011 11:41:52 -0700
Subject: Request for review 6237353: Remove sun.io package from j2se binary
In-Reply-To: <4E4BBA06.2030305@oracle.com>
References: <4E4B7EDE.6040006@oracle.com> <4E4B84EF.9000005@oracle.com>
	<4E4BBA06.2030305@oracle.com>
Message-ID: <4E4C0B70.6010907@oracle.com>

Thanks Sasha,

The flag has been set to true, as suggested.

The webrev has been updated according.

http://cr.openjdk.java.net/~sherman/6237353/webrev/ 
<http://cr.openjdk.java.net/%7Esherman/6237353/webrev/>

-Sherman

On 08/17/2011 05:54 AM, Alexandre Boulgakov wrote:
> Hello Sherman,
>
> Can you check if any deprecation warnings are generated from the other 
> classes built by java/sun_nio/Makefile? Suppressing deprecation 
> warnings might no longer be necessary now that sun.io is gone, and 
> then you can change lines 34-35 in the makefile to "JAVAC_MAX_WARNINGS 
> = true".
>
> Cheers,
> Sasha
>
> On 8/17/2011 2:07 AM, Alan Bateman wrote:
>> Xueming Shen wrote:
>>> Hi,
>>>
>>> This is something long over due. Some background info.
>>>
>>> (1)The java.nio.charset package (to replace the private sun.io 
>>> package) is added into
>>>      JDK 1.4 as the result of the nio JSR. Part of the sun.io 
>>> converters were migrated to
>>>      the java.nio.charset  implementation in JDK8.
>>> (2) All supported charsets/converters were migrated to 
>>> java.nio.charset in JDK5. As the
>>>      result no more bug fix/rfe maintenance work for sun.io since then.
>>> (3) Removed all sun.io dependencies (internal sun.io usage inside 
>>> JDK) from the JDK
>>>      repository at the beginning of JDK6.
>>> (4) The sun.io package was removed from the JDK runtime at JDK6 b29.
>>>
>>> But we then had one important licensee strongly asked to undo the 
>>> removal. The sun.io
>>> was putback in JDK6 6u59/beta.
>>>
>>> Now let's try this again in JDK8, the licensee that was against it 
>>> in JDK6 last time has been
>>> communicated and is OK with the plan this time. And the JDBC EG 
>>> group (which heavily
>>> used sun.io package in the past)  is/will be noticed as well. We 
>>> assume after 3 major releases
>>> the risk of breaking someone's application (as the result of this 
>>> change) is limited.
>>>
>>> Here is the webrev. Since we have tried it already (the workspace 
>>> had been cleaned up
>>> already) in jdk6 again already, the change this time is relatively 
>>> simple, mainly only 2 makefile
>>> changes. The rest is the "deleting" and several minor changes in 
>>> testing.
>>>
>>> http://cr.openjdk.java.net/~sherman/6237353/webrev/
>> Thanks for doing this, and thanks Lance for checking with all the 
>> JDBC folks in your phone book.
>>
>> The changes looks good to me. Push it quick and run :-)
>>
>> -Alan
>>



From xueming.shen at oracle.com  Wed Aug 17 18:41:57 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 17 Aug 2011 11:41:57 -0700
Subject: Request for review 6237353: Remove sun.io package from j2se binary
In-Reply-To: <4E4BB603.4050604@gmx.de>
References: <4E4B7EDE.6040006@oracle.com> <4E4BB603.4050604@gmx.de>
Message-ID: <4E4C0B75.9070004@oracle.com>

Ulf,

I tried to be conservative to not touch the source code, just in case I 
might be forced
to put them back again:-) But since I have already removed the whole 
sun.io source
branch, it's reasonable to do the complete cleanup up as well. The 
webrev has been
updated accordingly (to remove those comments and methods)

http://cr.openjdk.java.net/~sherman/6237353/webrev 
<http://cr.openjdk.java.net/%7Esherman/6237353/webrev/>

Thanks!

-Sherman


On 08/17/2011 05:37 AM, Ulf Zibis wrote:
> As a consequence, allmost all classes in sun.nio.cs and templates in 
> make/tools/CharsetMapping could be made package private, at least all 
> access to the mapping tables!
>
> ... and don't forget to remove in each sun.nio.cs class and template:
>
>     /**
>      * These accessors are temporarily supplied while sun.io
>      * converters co-exist with the sun.nio.cs.{ext} charset coders
>      * These facilitate sharing of conversion tables between the
>      * two co-existing implementations. When sun.io converters
>      * are made extinct these will be unncessary and should be removed
>      */
>
>     public String getDecoderSingleByteMappings() {
>         return b2cTable;
>     }
>
>     public short[] getDecoderIndex1() {
>         return Decoder.index1;
>     }
>
>     public String[] getDecoderIndex2() {
>         return Decoder.index2;
>
>     }
>
>     public short[] getEncoderIndex1() {
>         return Encoder.index1;
>
>     }
>     public String[] getEncoderIndex2() {
>         return Encoder.index2;
>
>     }
>
> Additionally, you could mention my wrapper classes [1] in the 
> WORKAROUND section of bug 6237353
>
> [1] 
> http://java.net/projects/java-nio-charset-enhanced/sources/svn/show/trunk/src/sun/io/
>
>
> -Ulf
>
>



From alexandre.boulgakov at oracle.com  Wed Aug 17 18:34:03 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Wed, 17 Aug 2011 11:34:03 -0700
Subject: Request for review 6237353: Remove sun.io package from j2se binary
In-Reply-To: <4E4C0B70.6010907@oracle.com>
References: <4E4B7EDE.6040006@oracle.com> <4E4B84EF.9000005@oracle.com>
	<4E4BBA06.2030305@oracle.com> <4E4C0B70.6010907@oracle.com>
Message-ID: <4E4C099B.5010203@oracle.com>

Hello Sherman,

You would also need to remove "JAVAC_LINT_OPTIONS = 
-Xlint:all,-deprecation" on line 35. When JAVAC_MAX_WARNINGS=true, 
JAVAC_LINT_OPTIONS automatically gets set to -Xlint:all [1], so that 
line will not do anything.

Thanks,
Sasha

[1] Actually, it gets set to "-Xlint:all -Xlint:-path", but that's 
temporary. This happens in jdk/make/common/shared/Defs-java.gmk.

On 8/17/2011 11:41 AM, Xueming Shen wrote:
> Thanks Sasha,
>
> The flag has been set to true, as suggested.
>
> The webrev has been updated according.
>
> http://cr.openjdk.java.net/~sherman/6237353/webrev/ 
> <http://cr.openjdk.java.net/%7Esherman/6237353/webrev/>
>
> -Sherman
>
> On 08/17/2011 05:54 AM, Alexandre Boulgakov wrote:
>> Hello Sherman,
>>
>> Can you check if any deprecation warnings are generated from the 
>> other classes built by java/sun_nio/Makefile? Suppressing deprecation 
>> warnings might no longer be necessary now that sun.io is gone, and 
>> then you can change lines 34-35 in the makefile to 
>> "JAVAC_MAX_WARNINGS = true".
>>
>> Cheers,
>> Sasha
>>
>> On 8/17/2011 2:07 AM, Alan Bateman wrote:
>>> Xueming Shen wrote:
>>>> Hi,
>>>>
>>>> This is something long over due. Some background info.
>>>>
>>>> (1)The java.nio.charset package (to replace the private sun.io 
>>>> package) is added into
>>>>      JDK 1.4 as the result of the nio JSR. Part of the sun.io 
>>>> converters were migrated to
>>>>      the java.nio.charset  implementation in JDK8.
>>>> (2) All supported charsets/converters were migrated to 
>>>> java.nio.charset in JDK5. As the
>>>>      result no more bug fix/rfe maintenance work for sun.io since 
>>>> then.
>>>> (3) Removed all sun.io dependencies (internal sun.io usage inside 
>>>> JDK) from the JDK
>>>>      repository at the beginning of JDK6.
>>>> (4) The sun.io package was removed from the JDK runtime at JDK6 b29.
>>>>
>>>> But we then had one important licensee strongly asked to undo the 
>>>> removal. The sun.io
>>>> was putback in JDK6 6u59/beta.
>>>>
>>>> Now let's try this again in JDK8, the licensee that was against it 
>>>> in JDK6 last time has been
>>>> communicated and is OK with the plan this time. And the JDBC EG 
>>>> group (which heavily
>>>> used sun.io package in the past)  is/will be noticed as well. We 
>>>> assume after 3 major releases
>>>> the risk of breaking someone's application (as the result of this 
>>>> change) is limited.
>>>>
>>>> Here is the webrev. Since we have tried it already (the workspace 
>>>> had been cleaned up
>>>> already) in jdk6 again already, the change this time is relatively 
>>>> simple, mainly only 2 makefile
>>>> changes. The rest is the "deleting" and several minor changes in 
>>>> testing.
>>>>
>>>> http://cr.openjdk.java.net/~sherman/6237353/webrev/
>>> Thanks for doing this, and thanks Lance for checking with all the 
>>> JDBC folks in your phone book.
>>>
>>> The changes looks good to me. Push it quick and run :-)
>>>
>>> -Alan
>>>
>


From jonathan.gibbons at oracle.com  Wed Aug 17 19:11:07 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 17 Aug 2011 19:11:07 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20110817191127.0FDE947C6C@hg.openjdk.java.net>

Changeset: f4fe826b8034
Author:    jjg
Date:      2011-08-17 05:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4fe826b8034

7079606: tl nightly build failure due to incomplete generification
Reviewed-by: jjg
Contributed-by: alexandre.boulgakov at oracle.com

! make/com/sun/security/Makefile

Changeset: 259b2536d11c
Author:    jjg
Date:      2011-08-17 12:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/259b2536d11c

Merge




From jonathan.gibbons at oracle.com  Wed Aug 17 19:12:52 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 17 Aug 2011 19:12:52 +0000
Subject: hg: jdk8/tl/jdk: 7077389: Reflection classes do not build with javac
	-Xlint:all -Werror
Message-ID: <20110817191302.1AC1247C6D@hg.openjdk.java.net>

Changeset: e59aad6ed600
Author:    jjg
Date:      2011-08-15 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e59aad6ed600

7077389: Reflection classes do not build with javac -Xlint:all -Werror
Reviewed-by: darcy
Contributed-by: alexandre.boulgakov at oracle.com

! make/java/java/Makefile
! src/share/classes/java/lang/reflect/Array.java
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/sun/reflect/AccessorGenerator.java
! src/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java
! src/share/classes/sun/reflect/ClassDefiner.java
! src/share/classes/sun/reflect/ConstantPool.java
! src/share/classes/sun/reflect/Label.java
! src/share/classes/sun/reflect/MethodAccessorGenerator.java
! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java
! src/share/classes/sun/reflect/Reflection.java
! src/share/classes/sun/reflect/ReflectionFactory.java
! src/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java
! src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
! src/share/classes/sun/reflect/annotation/AnnotationParser.java
! src/share/classes/sun/reflect/annotation/EnumConstantNotPresentExceptionProxy.java
! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java
! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
! src/share/classes/sun/reflect/generics/scope/AbstractScope.java
! src/share/classes/sun/reflect/generics/scope/ConstructorScope.java
! src/share/classes/sun/reflect/generics/tree/ClassSignature.java
! src/share/classes/sun/reflect/generics/tree/MethodTypeSignature.java



From sebastian.sickelmann at gmx.de  Wed Aug 17 19:23:31 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 17 Aug 2011 21:23:31 +0200
Subject: Two heads after pull of tl/jdk and jdk8/jdk
Message-ID: <4E4C1533.70500@gmx.de>

Hi,

after pulling from both sources
http://hg.openjdk.java.net/jdk8/tl/jdk/
http://hg.openjdk.java.net/jdk8/jdk8/jdk/

i see that i got two heads.

Is it because in all the other repositorys jdk8/*/jdk there are also 
many changes to the jdk-sub-repo?
Should i worry about these changes and merge it? Or is there an "Merge 
Inspector" in the jdk8/tl/* who does the job.
I think creating a webrev for such a change isn't worth it. And we 
non-commiters haven't any change to merge those for the public, isn't it?

-- Sebastian


From xueming.shen at oracle.com  Wed Aug 17 19:47:01 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 17 Aug 2011 12:47:01 -0700
Subject: Request for review 6237353: Remove sun.io package from j2se binary
In-Reply-To: <4E4C099B.5010203@oracle.com>
References: <4E4B7EDE.6040006@oracle.com> <4E4B84EF.9000005@oracle.com>
	<4E4BBA06.2030305@oracle.com> <4E4C0B70.6010907@oracle.com>
	<4E4C099B.5010203@oracle.com>
Message-ID: <4E4C1AB5.6050506@oracle.com>

Updated accordingly. Thanks!

-Sherman

On 08/17/2011 11:34 AM, Alexandre Boulgakov wrote:
> Hello Sherman,
>
> You would also need to remove "JAVAC_LINT_OPTIONS = 
> -Xlint:all,-deprecation" on line 35. When JAVAC_MAX_WARNINGS=true, 
> JAVAC_LINT_OPTIONS automatically gets set to -Xlint:all [1], so that 
> line will not do anything.
>
> Thanks,
> Sasha
>
> [1] Actually, it gets set to "-Xlint:all -Xlint:-path", but that's 
> temporary. This happens in jdk/make/common/shared/Defs-java.gmk.
>
> On 8/17/2011 11:41 AM, Xueming Shen wrote:
>> Thanks Sasha,
>>
>> The flag has been set to true, as suggested.
>>
>> The webrev has been updated according.
>>
>> http://cr.openjdk.java.net/~sherman/6237353/webrev/ 
>> <http://cr.openjdk.java.net/%7Esherman/6237353/webrev/>
>>
>> -Sherman
>>
>> On 08/17/2011 05:54 AM, Alexandre Boulgakov wrote:
>>> Hello Sherman,
>>>
>>> Can you check if any deprecation warnings are generated from the 
>>> other classes built by java/sun_nio/Makefile? Suppressing 
>>> deprecation warnings might no longer be necessary now that sun.io is 
>>> gone, and then you can change lines 34-35 in the makefile to 
>>> "JAVAC_MAX_WARNINGS = true".
>>>
>>> Cheers,
>>> Sasha
>>>
>>> On 8/17/2011 2:07 AM, Alan Bateman wrote:
>>>> Xueming Shen wrote:
>>>>> Hi,
>>>>>
>>>>> This is something long over due. Some background info.
>>>>>
>>>>> (1)The java.nio.charset package (to replace the private sun.io 
>>>>> package) is added into
>>>>>      JDK 1.4 as the result of the nio JSR. Part of the sun.io 
>>>>> converters were migrated to
>>>>>      the java.nio.charset  implementation in JDK8.
>>>>> (2) All supported charsets/converters were migrated to 
>>>>> java.nio.charset in JDK5. As the
>>>>>      result no more bug fix/rfe maintenance work for sun.io since 
>>>>> then.
>>>>> (3) Removed all sun.io dependencies (internal sun.io usage inside 
>>>>> JDK) from the JDK
>>>>>      repository at the beginning of JDK6.
>>>>> (4) The sun.io package was removed from the JDK runtime at JDK6 b29.
>>>>>
>>>>> But we then had one important licensee strongly asked to undo the 
>>>>> removal. The sun.io
>>>>> was putback in JDK6 6u59/beta.
>>>>>
>>>>> Now let's try this again in JDK8, the licensee that was against it 
>>>>> in JDK6 last time has been
>>>>> communicated and is OK with the plan this time. And the JDBC EG 
>>>>> group (which heavily
>>>>> used sun.io package in the past)  is/will be noticed as well. We 
>>>>> assume after 3 major releases
>>>>> the risk of breaking someone's application (as the result of this 
>>>>> change) is limited.
>>>>>
>>>>> Here is the webrev. Since we have tried it already (the workspace 
>>>>> had been cleaned up
>>>>> already) in jdk6 again already, the change this time is relatively 
>>>>> simple, mainly only 2 makefile
>>>>> changes. The rest is the "deleting" and several minor changes in 
>>>>> testing.
>>>>>
>>>>> http://cr.openjdk.java.net/~sherman/6237353/webrev/
>>>> Thanks for doing this, and thanks Lance for checking with all the 
>>>> JDBC folks in your phone book.
>>>>
>>>> The changes looks good to me. Push it quick and run :-)
>>>>
>>>> -Alan
>>>>
>>



From forax at univ-mlv.fr  Wed Aug 17 20:47:41 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 17 Aug 2011 22:47:41 +0200
Subject: hg: jdk8/tl/jdk: 7077389: Reflection classes do not build with
	javac -Xlint:all -Werror
In-Reply-To: <20110817191302.1AC1247C6D@hg.openjdk.java.net>
References: <20110817191302.1AC1247C6D@hg.openjdk.java.net>
Message-ID: <4E4C28ED.9000004@univ-mlv.fr>

One day, someone brave enough should rewrite  sun/reflect/generics
because there is a lot of boilerplate in this package.
The same code in ASM is at least 5 times shorter.

R?mi

On 08/17/2011 09:12 PM, jonathan.gibbons at oracle.com wrote:
> Changeset: e59aad6ed600
> Author:    jjg
> Date:      2011-08-15 17:17 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e59aad6ed600
>
> 7077389: Reflection classes do not build with javac -Xlint:all -Werror
> Reviewed-by: darcy
> Contributed-by: alexandre.boulgakov at oracle.com
>
> ! make/java/java/Makefile
> ! src/share/classes/java/lang/reflect/Array.java
> ! src/share/classes/java/lang/reflect/Constructor.java
> ! src/share/classes/java/lang/reflect/Executable.java
> ! src/share/classes/java/lang/reflect/Field.java
> ! src/share/classes/java/lang/reflect/Method.java
> ! src/share/classes/java/lang/reflect/Proxy.java
> ! src/share/classes/sun/reflect/AccessorGenerator.java
> ! src/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java
> ! src/share/classes/sun/reflect/ClassDefiner.java
> ! src/share/classes/sun/reflect/ConstantPool.java
> ! src/share/classes/sun/reflect/Label.java
> ! src/share/classes/sun/reflect/MethodAccessorGenerator.java
> ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java
> ! src/share/classes/sun/reflect/Reflection.java
> ! src/share/classes/sun/reflect/ReflectionFactory.java
> ! src/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java
> ! src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java
> ! src/share/classes/sun/reflect/annotation/AnnotationParser.java
> ! src/share/classes/sun/reflect/annotation/EnumConstantNotPresentExceptionProxy.java
> ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java
> ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
> ! src/share/classes/sun/reflect/generics/scope/AbstractScope.java
> ! src/share/classes/sun/reflect/generics/scope/ConstructorScope.java
> ! src/share/classes/sun/reflect/generics/tree/ClassSignature.java
> ! src/share/classes/sun/reflect/generics/tree/MethodTypeSignature.java
>



From sebastian.sickelmann at gmx.de  Wed Aug 17 21:00:42 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 17 Aug 2011 23:00:42 +0200
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E4B1528.8060306@oracle.com>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
Message-ID: <4E4C2BFA.40207@gmx.de>

Am 17.08.2011 03:11, schrieb joe.darcy at oracle.com:
> Hello.
>
> On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote:
>> Hi,
>>
>> some time ago, i wrote[5] with Joe and David about advancing some 
>> exception-types to the 4 standard ctors.
>>
>> The first Exception i have looked at was InternalError and now(after 
>> some struggeling with gnumake and hg) my patches for reviewing are 
>> ready.
>>
>> I uploaded them at [4]
>>
>> I split the changes into 3 parts.
>>
>> 1. Added 2 ctors to InternalError and VirtualMachineError****[1]
>> 2. Use the two ctors of InternalError****[2] (based on [1])
>> 3. Chain Rootcause into InternalError**[3] (based also on [1])
>>
>> I think part 1 and 2 are uncritical. Part 3 is more critical because 
>> it changes behavior (exception-chaining). But i don't think that part 
>> 3 is unimportable, because in case of an InternalError (use should 
>> not be able to recover) there shouldn't be a problem with a little 
>> longer exception-chain.
>>
>> Is there someone who what to sponsor this or parts of it?
>>
>> [1] https://bugs.openjdk.java.net/attachment.cgi?id=233
>> [2] https://bugs.openjdk.java.net/attachment.cgi?id=234
>> [3] https://bugs.openjdk.java.net/attachment.cgi?id=235
>> [4] https://bugs.openjdk.java.net/show_bug.cgi?id=100201
>> [5] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html 
>>
>
> I am willing to sponsor this work and I've filed bug 7080020 "Add 
> conventional constructors to InternalError" for it.
>
> For adding constructors to InternalError (or VirtualMachineError), the 
> push that adds the constructors should include some usage of them.  
> Therefore, at least portions of 1) and 2) above should be combined.  
> If there are easy to find usages of a cause for VirtualMachineError, 
> then those should be included at the same time any new constructors 
> are added there.
VirtualMachineError is changed because it is the abstract super class of 
InternalError so use of the VirtualMachineError ctors is inside of the 
InternalError ctors
>
> There is some currently Oracle-internal paperwork which needs to be 
> filed to make an API change; I'll file that paperwork once there is 
> verification on whether updates to both InternalError and 
> VirtualMachineError will be included in this round of work.  The 
> paperwork needs to be approved before the change is pushed and 
> typically takes a few days to be processed.
>
OK. That much work for just chaining up exceptions.
I am happy that i needn't to do this paperwork. I hope it's virtual 
paperwork. ;-)

I will post the change in 2 webrevs than.
One for the smaller part (Change of the InternalError itself + some 
small changes "initCause usage to ctor parameter")
And one for the bigger part (Chain all uses of InternalError with the 
root-cause if any root-cause exists)

i must rebase it again. Will post webrev url at the other thread in short.
> Cheers,
>
> -Joe
>
-- Sebastian


From sebastian.sickelmann at gmx.de  Wed Aug 17 21:04:49 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 17 Aug 2011 23:04:49 +0200
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E4BD723.2040702@oracle.com>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
	<4E4BA9DD.20706@oracle.com> <4E4BD37E.4060402@gmx.de>
	<4E4BD723.2040702@oracle.com>
Message-ID: <4E4C2CF1.8020203@gmx.de>

Am 17.08.2011 16:58, schrieb Alexandre Boulgakov:
> Hello Sebastian.
>
> On 8/17/2011 7:43 AM, Sebastian Sickelmann wrote:
>> Am 17.08.2011 13:45, schrieb Alan Bateman:
>>> joe.darcy at oracle.com wrote:
>>>>
>>>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
>>>> conventional constructors to InternalError" for it.
>>>>
>>> Thanks Joe, and to help this along here's the webrev with 
>>> Sebastian's patches:
>>>   http://cr.openjdk.java.net/~alanb/7080020/webrev/
>>>
>>> I haven't really looked but one thing I did notice is that the 
>>> multi-catch usages need to be checked as Sasha cleaned up a few of 
>>> these recently.
>>>
>>> -Alan.
>> Thanks for the webrev.
>>
>> I think it is very hard to start with the complete patch. Or is it 
>> better to review it all at once?
>>
>> I have created a webrev for my patches 0 and 1 and uploaded it here:
>> http://oss-patches.24.eu/openjdk8/InternalError/part1/
>>
>> After i have pulled from tl/jdk i got problems with building.
>> I got warnings so that i must build with JAVAC_WARNINGS_FATAL=false, 
>> is this ok for tl-repo?
>
> You should not set JAVAC_WARNINGS_FATAL manually, and you can ignore 
> any preexisting warnings (although you should not introduce any new 
> ones). The makefiles where it is safe to compile with 
> JAVAC_WARNINGS_FATAL will set it appropriately. There is an ongoing 
> effort to reduce javac warnings (including lint warnings, which are 
> not currently enabled in all parts of the code). If you build with 
> JAVAC_MAX_WARNINGS=true, you will notice that there are just over 
> 10,000 javac build warnings in tl/jdk...
OK. Actually there aren't any warnings. The are all gone after i did a 
make clean & make all.
Can that be? Is there an issue like : "make all doen't find all changes 
to rebuild all dependencies", or is this a quite normal behavior?
>
> Cheers,
> Sasha
>
>>
>> -- Sebastian



From xueming.shen at oracle.com  Wed Aug 17 21:05:55 2011
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 17 Aug 2011 21:05:55 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20110817210614.B652147C73@hg.openjdk.java.net>

Changeset: 2961329a6774
Author:    sherman
Date:      2011-08-17 14:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2961329a6774

6237353: Remove sun.io package from j2se binary
Summary: Removed sun.io package and related test cases
Reviewed-by: alanb

! make/java/sun_nio/FILES_java.gmk
! make/java/sun_nio/Makefile
! make/sun/nio/cs/FILES_java.gmk
! make/tools/CharsetMapping/SingleByte-X.java.template
- src/share/classes/sun/io/ByteToCharASCII.java
- src/share/classes/sun/io/ByteToCharBig5.java
- src/share/classes/sun/io/ByteToCharBig5_HKSCS.java
- src/share/classes/sun/io/ByteToCharBig5_Solaris.java
- src/share/classes/sun/io/ByteToCharConverter.java
- src/share/classes/sun/io/ByteToCharCp037.java
- src/share/classes/sun/io/ByteToCharCp1006.java
- src/share/classes/sun/io/ByteToCharCp1025.java
- src/share/classes/sun/io/ByteToCharCp1026.java
- src/share/classes/sun/io/ByteToCharCp1046.java
- src/share/classes/sun/io/ByteToCharCp1047.java
- src/share/classes/sun/io/ByteToCharCp1097.java
- src/share/classes/sun/io/ByteToCharCp1098.java
- src/share/classes/sun/io/ByteToCharCp1112.java
- src/share/classes/sun/io/ByteToCharCp1122.java
- src/share/classes/sun/io/ByteToCharCp1123.java
- src/share/classes/sun/io/ByteToCharCp1124.java
- src/share/classes/sun/io/ByteToCharCp1140.java
- src/share/classes/sun/io/ByteToCharCp1141.java
- src/share/classes/sun/io/ByteToCharCp1142.java
- src/share/classes/sun/io/ByteToCharCp1143.java
- src/share/classes/sun/io/ByteToCharCp1144.java
- src/share/classes/sun/io/ByteToCharCp1145.java
- src/share/classes/sun/io/ByteToCharCp1146.java
- src/share/classes/sun/io/ByteToCharCp1147.java
- src/share/classes/sun/io/ByteToCharCp1148.java
- src/share/classes/sun/io/ByteToCharCp1149.java
- src/share/classes/sun/io/ByteToCharCp1250.java
- src/share/classes/sun/io/ByteToCharCp1251.java
- src/share/classes/sun/io/ByteToCharCp1252.java
- src/share/classes/sun/io/ByteToCharCp1253.java
- src/share/classes/sun/io/ByteToCharCp1254.java
- src/share/classes/sun/io/ByteToCharCp1255.java
- src/share/classes/sun/io/ByteToCharCp1256.java
- src/share/classes/sun/io/ByteToCharCp1257.java
- src/share/classes/sun/io/ByteToCharCp1258.java
- src/share/classes/sun/io/ByteToCharCp1381.java
- src/share/classes/sun/io/ByteToCharCp1383.java
- src/share/classes/sun/io/ByteToCharCp273.java
- src/share/classes/sun/io/ByteToCharCp277.java
- src/share/classes/sun/io/ByteToCharCp278.java
- src/share/classes/sun/io/ByteToCharCp280.java
- src/share/classes/sun/io/ByteToCharCp284.java
- src/share/classes/sun/io/ByteToCharCp285.java
- src/share/classes/sun/io/ByteToCharCp297.java
- src/share/classes/sun/io/ByteToCharCp33722.java
- src/share/classes/sun/io/ByteToCharCp420.java
- src/share/classes/sun/io/ByteToCharCp424.java
- src/share/classes/sun/io/ByteToCharCp437.java
- src/share/classes/sun/io/ByteToCharCp500.java
- src/share/classes/sun/io/ByteToCharCp737.java
- src/share/classes/sun/io/ByteToCharCp775.java
- src/share/classes/sun/io/ByteToCharCp833.java
- src/share/classes/sun/io/ByteToCharCp834.java
- src/share/classes/sun/io/ByteToCharCp838.java
- src/share/classes/sun/io/ByteToCharCp850.java
- src/share/classes/sun/io/ByteToCharCp852.java
- src/share/classes/sun/io/ByteToCharCp855.java
- src/share/classes/sun/io/ByteToCharCp856.java
- src/share/classes/sun/io/ByteToCharCp857.java
- src/share/classes/sun/io/ByteToCharCp858.java
- src/share/classes/sun/io/ByteToCharCp860.java
- src/share/classes/sun/io/ByteToCharCp861.java
- src/share/classes/sun/io/ByteToCharCp862.java
- src/share/classes/sun/io/ByteToCharCp863.java
- src/share/classes/sun/io/ByteToCharCp864.java
- src/share/classes/sun/io/ByteToCharCp865.java
- src/share/classes/sun/io/ByteToCharCp866.java
- src/share/classes/sun/io/ByteToCharCp868.java
- src/share/classes/sun/io/ByteToCharCp869.java
- src/share/classes/sun/io/ByteToCharCp870.java
- src/share/classes/sun/io/ByteToCharCp871.java
- src/share/classes/sun/io/ByteToCharCp874.java
- src/share/classes/sun/io/ByteToCharCp875.java
- src/share/classes/sun/io/ByteToCharCp918.java
- src/share/classes/sun/io/ByteToCharCp921.java
- src/share/classes/sun/io/ByteToCharCp922.java
- src/share/classes/sun/io/ByteToCharCp930.java
- src/share/classes/sun/io/ByteToCharCp933.java
- src/share/classes/sun/io/ByteToCharCp935.java
- src/share/classes/sun/io/ByteToCharCp937.java
- src/share/classes/sun/io/ByteToCharCp939.java
- src/share/classes/sun/io/ByteToCharCp942.java
- src/share/classes/sun/io/ByteToCharCp942C.java
- src/share/classes/sun/io/ByteToCharCp943.java
- src/share/classes/sun/io/ByteToCharCp943C.java
- src/share/classes/sun/io/ByteToCharCp948.java
- src/share/classes/sun/io/ByteToCharCp949.java
- src/share/classes/sun/io/ByteToCharCp949C.java
- src/share/classes/sun/io/ByteToCharCp950.java
- src/share/classes/sun/io/ByteToCharCp964.java
- src/share/classes/sun/io/ByteToCharCp970.java
- src/share/classes/sun/io/ByteToCharDBCS_ASCII.java
- src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java
- src/share/classes/sun/io/ByteToCharDoubleByte.java
- src/share/classes/sun/io/ByteToCharEUC.java
- src/share/classes/sun/io/ByteToCharEUC2.java
- src/share/classes/sun/io/ByteToCharEUC_CN.java
- src/share/classes/sun/io/ByteToCharEUC_JP.java
- src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java
- src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java
- src/share/classes/sun/io/ByteToCharEUC_KR.java
- src/share/classes/sun/io/ByteToCharEUC_TW.java
- src/share/classes/sun/io/ByteToCharGB18030.java
- src/share/classes/sun/io/ByteToCharGB18030DB.java
- src/share/classes/sun/io/ByteToCharGBK.java
- src/share/classes/sun/io/ByteToCharISCII91.java
- src/share/classes/sun/io/ByteToCharISO2022.java
- src/share/classes/sun/io/ByteToCharISO2022CN.java
- src/share/classes/sun/io/ByteToCharISO2022JP.java
- src/share/classes/sun/io/ByteToCharISO2022KR.java
- src/share/classes/sun/io/ByteToCharISO8859_1.java
- src/share/classes/sun/io/ByteToCharISO8859_13.java
- src/share/classes/sun/io/ByteToCharISO8859_15.java
- src/share/classes/sun/io/ByteToCharISO8859_2.java
- src/share/classes/sun/io/ByteToCharISO8859_3.java
- src/share/classes/sun/io/ByteToCharISO8859_4.java
- src/share/classes/sun/io/ByteToCharISO8859_5.java
- src/share/classes/sun/io/ByteToCharISO8859_6.java
- src/share/classes/sun/io/ByteToCharISO8859_7.java
- src/share/classes/sun/io/ByteToCharISO8859_8.java
- src/share/classes/sun/io/ByteToCharISO8859_9.java
- src/share/classes/sun/io/ByteToCharJIS0201.java
- src/share/classes/sun/io/ByteToCharJIS0208.java
- src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java
- src/share/classes/sun/io/ByteToCharJIS0212.java
- src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java
- src/share/classes/sun/io/ByteToCharJISAutoDetect.java
- src/share/classes/sun/io/ByteToCharJohab.java
- src/share/classes/sun/io/ByteToCharKOI8_R.java
- src/share/classes/sun/io/ByteToCharMS874.java
- src/share/classes/sun/io/ByteToCharMS932.java
- src/share/classes/sun/io/ByteToCharMS936.java
- src/share/classes/sun/io/ByteToCharMS949.java
- src/share/classes/sun/io/ByteToCharMS950.java
- src/share/classes/sun/io/ByteToCharMS950_HKSCS.java
- src/share/classes/sun/io/ByteToCharMacArabic.java
- src/share/classes/sun/io/ByteToCharMacCentralEurope.java
- src/share/classes/sun/io/ByteToCharMacCroatian.java
- src/share/classes/sun/io/ByteToCharMacCyrillic.java
- src/share/classes/sun/io/ByteToCharMacDingbat.java
- src/share/classes/sun/io/ByteToCharMacGreek.java
- src/share/classes/sun/io/ByteToCharMacHebrew.java
- src/share/classes/sun/io/ByteToCharMacIceland.java
- src/share/classes/sun/io/ByteToCharMacRoman.java
- src/share/classes/sun/io/ByteToCharMacRomania.java
- src/share/classes/sun/io/ByteToCharMacSymbol.java
- src/share/classes/sun/io/ByteToCharMacThai.java
- src/share/classes/sun/io/ByteToCharMacTurkish.java
- src/share/classes/sun/io/ByteToCharMacUkraine.java
- src/share/classes/sun/io/ByteToCharPCK.java
- src/share/classes/sun/io/ByteToCharSJIS.java
- src/share/classes/sun/io/ByteToCharSingleByte.java
- src/share/classes/sun/io/ByteToCharTIS620.java
- src/share/classes/sun/io/ByteToCharUTF16.java
- src/share/classes/sun/io/ByteToCharUTF8.java
- src/share/classes/sun/io/ByteToCharUnicode.java
- src/share/classes/sun/io/ByteToCharUnicodeBig.java
- src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java
- src/share/classes/sun/io/ByteToCharUnicodeLittle.java
- src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java
- src/share/classes/sun/io/CharToByteASCII.java
- src/share/classes/sun/io/CharToByteBig5.java
- src/share/classes/sun/io/CharToByteBig5_HKSCS.java
- src/share/classes/sun/io/CharToByteBig5_Solaris.java
- src/share/classes/sun/io/CharToByteConverter.java
- src/share/classes/sun/io/CharToByteCp037.java
- src/share/classes/sun/io/CharToByteCp1006.java
- src/share/classes/sun/io/CharToByteCp1025.java
- src/share/classes/sun/io/CharToByteCp1026.java
- src/share/classes/sun/io/CharToByteCp1046.java
- src/share/classes/sun/io/CharToByteCp1047.java
- src/share/classes/sun/io/CharToByteCp1097.java
- src/share/classes/sun/io/CharToByteCp1098.java
- src/share/classes/sun/io/CharToByteCp1112.java
- src/share/classes/sun/io/CharToByteCp1122.java
- src/share/classes/sun/io/CharToByteCp1123.java
- src/share/classes/sun/io/CharToByteCp1124.java
- src/share/classes/sun/io/CharToByteCp1140.java
- src/share/classes/sun/io/CharToByteCp1141.java
- src/share/classes/sun/io/CharToByteCp1142.java
- src/share/classes/sun/io/CharToByteCp1143.java
- src/share/classes/sun/io/CharToByteCp1144.java
- src/share/classes/sun/io/CharToByteCp1145.java
- src/share/classes/sun/io/CharToByteCp1146.java
- src/share/classes/sun/io/CharToByteCp1147.java
- src/share/classes/sun/io/CharToByteCp1148.java
- src/share/classes/sun/io/CharToByteCp1149.java
- src/share/classes/sun/io/CharToByteCp1250.java
- src/share/classes/sun/io/CharToByteCp1251.java
- src/share/classes/sun/io/CharToByteCp1252.java
- src/share/classes/sun/io/CharToByteCp1253.java
- src/share/classes/sun/io/CharToByteCp1254.java
- src/share/classes/sun/io/CharToByteCp1255.java
- src/share/classes/sun/io/CharToByteCp1256.java
- src/share/classes/sun/io/CharToByteCp1257.java
- src/share/classes/sun/io/CharToByteCp1258.java
- src/share/classes/sun/io/CharToByteCp1381.java
- src/share/classes/sun/io/CharToByteCp1383.java
- src/share/classes/sun/io/CharToByteCp273.java
- src/share/classes/sun/io/CharToByteCp277.java
- src/share/classes/sun/io/CharToByteCp278.java
- src/share/classes/sun/io/CharToByteCp280.java
- src/share/classes/sun/io/CharToByteCp284.java
- src/share/classes/sun/io/CharToByteCp285.java
- src/share/classes/sun/io/CharToByteCp297.java
- src/share/classes/sun/io/CharToByteCp33722.java
- src/share/classes/sun/io/CharToByteCp420.java
- src/share/classes/sun/io/CharToByteCp424.java
- src/share/classes/sun/io/CharToByteCp437.java
- src/share/classes/sun/io/CharToByteCp500.java
- src/share/classes/sun/io/CharToByteCp737.java
- src/share/classes/sun/io/CharToByteCp775.java
- src/share/classes/sun/io/CharToByteCp833.java
- src/share/classes/sun/io/CharToByteCp834.java
- src/share/classes/sun/io/CharToByteCp838.java
- src/share/classes/sun/io/CharToByteCp850.java
- src/share/classes/sun/io/CharToByteCp852.java
- src/share/classes/sun/io/CharToByteCp855.java
- src/share/classes/sun/io/CharToByteCp856.java
- src/share/classes/sun/io/CharToByteCp857.java
- src/share/classes/sun/io/CharToByteCp858.java
- src/share/classes/sun/io/CharToByteCp860.java
- src/share/classes/sun/io/CharToByteCp861.java
- src/share/classes/sun/io/CharToByteCp862.java
- src/share/classes/sun/io/CharToByteCp863.java
- src/share/classes/sun/io/CharToByteCp864.java
- src/share/classes/sun/io/CharToByteCp865.java
- src/share/classes/sun/io/CharToByteCp866.java
- src/share/classes/sun/io/CharToByteCp868.java
- src/share/classes/sun/io/CharToByteCp869.java
- src/share/classes/sun/io/CharToByteCp870.java
- src/share/classes/sun/io/CharToByteCp871.java
- src/share/classes/sun/io/CharToByteCp874.java
- src/share/classes/sun/io/CharToByteCp875.java
- src/share/classes/sun/io/CharToByteCp918.java
- src/share/classes/sun/io/CharToByteCp921.java
- src/share/classes/sun/io/CharToByteCp922.java
- src/share/classes/sun/io/CharToByteCp930.java
- src/share/classes/sun/io/CharToByteCp933.java
- src/share/classes/sun/io/CharToByteCp935.java
- src/share/classes/sun/io/CharToByteCp937.java
- src/share/classes/sun/io/CharToByteCp939.java
- src/share/classes/sun/io/CharToByteCp942.java
- src/share/classes/sun/io/CharToByteCp942C.java
- src/share/classes/sun/io/CharToByteCp943.java
- src/share/classes/sun/io/CharToByteCp943C.java
- src/share/classes/sun/io/CharToByteCp948.java
- src/share/classes/sun/io/CharToByteCp949.java
- src/share/classes/sun/io/CharToByteCp949C.java
- src/share/classes/sun/io/CharToByteCp950.java
- src/share/classes/sun/io/CharToByteCp964.java
- src/share/classes/sun/io/CharToByteCp970.java
- src/share/classes/sun/io/CharToByteDBCS_ASCII.java
- src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java
- src/share/classes/sun/io/CharToByteDoubleByte.java
- src/share/classes/sun/io/CharToByteEUC.java
- src/share/classes/sun/io/CharToByteEUC_CN.java
- src/share/classes/sun/io/CharToByteEUC_JP.java
- src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java
- src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java
- src/share/classes/sun/io/CharToByteEUC_KR.java
- src/share/classes/sun/io/CharToByteEUC_TW.java
- src/share/classes/sun/io/CharToByteGB18030.java
- src/share/classes/sun/io/CharToByteGBK.java
- src/share/classes/sun/io/CharToByteISCII91.java
- src/share/classes/sun/io/CharToByteISO2022.java
- src/share/classes/sun/io/CharToByteISO2022CN_CNS.java
- src/share/classes/sun/io/CharToByteISO2022CN_GB.java
- src/share/classes/sun/io/CharToByteISO2022JP.java
- src/share/classes/sun/io/CharToByteISO2022KR.java
- src/share/classes/sun/io/CharToByteISO8859_1.java
- src/share/classes/sun/io/CharToByteISO8859_13.java
- src/share/classes/sun/io/CharToByteISO8859_15.java
- src/share/classes/sun/io/CharToByteISO8859_2.java
- src/share/classes/sun/io/CharToByteISO8859_3.java
- src/share/classes/sun/io/CharToByteISO8859_4.java
- src/share/classes/sun/io/CharToByteISO8859_5.java
- src/share/classes/sun/io/CharToByteISO8859_6.java
- src/share/classes/sun/io/CharToByteISO8859_7.java
- src/share/classes/sun/io/CharToByteISO8859_8.java
- src/share/classes/sun/io/CharToByteISO8859_9.java
- src/share/classes/sun/io/CharToByteJIS0201.java
- src/share/classes/sun/io/CharToByteJIS0208.java
- src/share/classes/sun/io/CharToByteJIS0208_Solaris.java
- src/share/classes/sun/io/CharToByteJIS0212.java
- src/share/classes/sun/io/CharToByteJIS0212_Solaris.java
- src/share/classes/sun/io/CharToByteJohab.java
- src/share/classes/sun/io/CharToByteKOI8_R.java
- src/share/classes/sun/io/CharToByteMS874.java
- src/share/classes/sun/io/CharToByteMS932.java
- src/share/classes/sun/io/CharToByteMS936.java
- src/share/classes/sun/io/CharToByteMS949.java
- src/share/classes/sun/io/CharToByteMS950.java
- src/share/classes/sun/io/CharToByteMS950_HKSCS.java
- src/share/classes/sun/io/CharToByteMacArabic.java
- src/share/classes/sun/io/CharToByteMacCentralEurope.java
- src/share/classes/sun/io/CharToByteMacCroatian.java
- src/share/classes/sun/io/CharToByteMacCyrillic.java
- src/share/classes/sun/io/CharToByteMacDingbat.java
- src/share/classes/sun/io/CharToByteMacGreek.java
- src/share/classes/sun/io/CharToByteMacHebrew.java
- src/share/classes/sun/io/CharToByteMacIceland.java
- src/share/classes/sun/io/CharToByteMacRoman.java
- src/share/classes/sun/io/CharToByteMacRomania.java
- src/share/classes/sun/io/CharToByteMacSymbol.java
- src/share/classes/sun/io/CharToByteMacThai.java
- src/share/classes/sun/io/CharToByteMacTurkish.java
- src/share/classes/sun/io/CharToByteMacUkraine.java
- src/share/classes/sun/io/CharToBytePCK.java
- src/share/classes/sun/io/CharToByteSJIS.java
- src/share/classes/sun/io/CharToByteSingleByte.java
- src/share/classes/sun/io/CharToByteTIS620.java
- src/share/classes/sun/io/CharToByteUTF16.java
- src/share/classes/sun/io/CharToByteUTF8.java
- src/share/classes/sun/io/CharToByteUnicode.java
- src/share/classes/sun/io/CharToByteUnicodeBig.java
- src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java
- src/share/classes/sun/io/CharToByteUnicodeLittle.java
- src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java
- src/share/classes/sun/io/CharacterEncoding.java
- src/share/classes/sun/io/ConversionBufferFullException.java
- src/share/classes/sun/io/Converters.java
- src/share/classes/sun/io/MalformedInputException.java
- src/share/classes/sun/io/UnknownCharacterException.java
! src/share/classes/sun/nio/cs/ext/GB18030.java
! src/share/classes/sun/nio/cs/ext/IBM33722.java
! src/share/classes/sun/nio/cs/ext/IBM964.java
! src/share/classes/sun/nio/cs/ext/ISCII91.java
! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java
! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java
! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java
! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java
! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java
! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java
! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java
! test/sun/nio/cs/TestCp834_SBCS.java
- test/sun/nio/cs/TestISCII91.java

Changeset: 07ad16388170
Author:    sherman
Date:      2011-08-17 14:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07ad16388170

Merge




From forax at univ-mlv.fr  Wed Aug 17 21:14:48 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 17 Aug 2011 23:14:48 +0200
Subject: hg: jdk8/tl/jdk: 2 new changesets
In-Reply-To: <20110817210614.B652147C73@hg.openjdk.java.net>
References: <20110817210614.B652147C73@hg.openjdk.java.net>
Message-ID: <4E4C2F48.4020501@univ-mlv.fr>

Hurrah, this is the changeset of the month,
removing things is always a win.

R?mi

On 08/17/2011 11:05 PM, xueming.shen at oracle.com wrote:
> Changeset: 2961329a6774
> Author:    sherman
> Date:      2011-08-17 14:14 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2961329a6774
>
> 6237353: Remove sun.io package from j2se binary
> Summary: Removed sun.io package and related test cases
> Reviewed-by: alanb
>
> ! make/java/sun_nio/FILES_java.gmk
> ! make/java/sun_nio/Makefile
> ! make/sun/nio/cs/FILES_java.gmk
> ! make/tools/CharsetMapping/SingleByte-X.java.template
> - src/share/classes/sun/io/ByteToCharASCII.java
> - src/share/classes/sun/io/ByteToCharBig5.java
> - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java
> - src/share/classes/sun/io/ByteToCharBig5_Solaris.java
> - src/share/classes/sun/io/ByteToCharConverter.java
> - src/share/classes/sun/io/ByteToCharCp037.java
> - src/share/classes/sun/io/ByteToCharCp1006.java
> - src/share/classes/sun/io/ByteToCharCp1025.java
> - src/share/classes/sun/io/ByteToCharCp1026.java
> - src/share/classes/sun/io/ByteToCharCp1046.java
> - src/share/classes/sun/io/ByteToCharCp1047.java
> - src/share/classes/sun/io/ByteToCharCp1097.java
> - src/share/classes/sun/io/ByteToCharCp1098.java
> - src/share/classes/sun/io/ByteToCharCp1112.java
> - src/share/classes/sun/io/ByteToCharCp1122.java
> - src/share/classes/sun/io/ByteToCharCp1123.java
> - src/share/classes/sun/io/ByteToCharCp1124.java
> - src/share/classes/sun/io/ByteToCharCp1140.java
> - src/share/classes/sun/io/ByteToCharCp1141.java
> - src/share/classes/sun/io/ByteToCharCp1142.java
> - src/share/classes/sun/io/ByteToCharCp1143.java
> - src/share/classes/sun/io/ByteToCharCp1144.java
> - src/share/classes/sun/io/ByteToCharCp1145.java
> - src/share/classes/sun/io/ByteToCharCp1146.java
> - src/share/classes/sun/io/ByteToCharCp1147.java
> - src/share/classes/sun/io/ByteToCharCp1148.java
> - src/share/classes/sun/io/ByteToCharCp1149.java
> - src/share/classes/sun/io/ByteToCharCp1250.java
> - src/share/classes/sun/io/ByteToCharCp1251.java
> - src/share/classes/sun/io/ByteToCharCp1252.java
> - src/share/classes/sun/io/ByteToCharCp1253.java
> - src/share/classes/sun/io/ByteToCharCp1254.java
> - src/share/classes/sun/io/ByteToCharCp1255.java
> - src/share/classes/sun/io/ByteToCharCp1256.java
> - src/share/classes/sun/io/ByteToCharCp1257.java
> - src/share/classes/sun/io/ByteToCharCp1258.java
> - src/share/classes/sun/io/ByteToCharCp1381.java
> - src/share/classes/sun/io/ByteToCharCp1383.java
> - src/share/classes/sun/io/ByteToCharCp273.java
> - src/share/classes/sun/io/ByteToCharCp277.java
> - src/share/classes/sun/io/ByteToCharCp278.java
> - src/share/classes/sun/io/ByteToCharCp280.java
> - src/share/classes/sun/io/ByteToCharCp284.java
> - src/share/classes/sun/io/ByteToCharCp285.java
> - src/share/classes/sun/io/ByteToCharCp297.java
> - src/share/classes/sun/io/ByteToCharCp33722.java
> - src/share/classes/sun/io/ByteToCharCp420.java
> - src/share/classes/sun/io/ByteToCharCp424.java
> - src/share/classes/sun/io/ByteToCharCp437.java
> - src/share/classes/sun/io/ByteToCharCp500.java
> - src/share/classes/sun/io/ByteToCharCp737.java
> - src/share/classes/sun/io/ByteToCharCp775.java
> - src/share/classes/sun/io/ByteToCharCp833.java
> - src/share/classes/sun/io/ByteToCharCp834.java
> - src/share/classes/sun/io/ByteToCharCp838.java
> - src/share/classes/sun/io/ByteToCharCp850.java
> - src/share/classes/sun/io/ByteToCharCp852.java
> - src/share/classes/sun/io/ByteToCharCp855.java
> - src/share/classes/sun/io/ByteToCharCp856.java
> - src/share/classes/sun/io/ByteToCharCp857.java
> - src/share/classes/sun/io/ByteToCharCp858.java
> - src/share/classes/sun/io/ByteToCharCp860.java
> - src/share/classes/sun/io/ByteToCharCp861.java
> - src/share/classes/sun/io/ByteToCharCp862.java
> - src/share/classes/sun/io/ByteToCharCp863.java
> - src/share/classes/sun/io/ByteToCharCp864.java
> - src/share/classes/sun/io/ByteToCharCp865.java
> - src/share/classes/sun/io/ByteToCharCp866.java
> - src/share/classes/sun/io/ByteToCharCp868.java
> - src/share/classes/sun/io/ByteToCharCp869.java
> - src/share/classes/sun/io/ByteToCharCp870.java
> - src/share/classes/sun/io/ByteToCharCp871.java
> - src/share/classes/sun/io/ByteToCharCp874.java
> - src/share/classes/sun/io/ByteToCharCp875.java
> - src/share/classes/sun/io/ByteToCharCp918.java
> - src/share/classes/sun/io/ByteToCharCp921.java
> - src/share/classes/sun/io/ByteToCharCp922.java
> - src/share/classes/sun/io/ByteToCharCp930.java
> - src/share/classes/sun/io/ByteToCharCp933.java
> - src/share/classes/sun/io/ByteToCharCp935.java
> - src/share/classes/sun/io/ByteToCharCp937.java
> - src/share/classes/sun/io/ByteToCharCp939.java
> - src/share/classes/sun/io/ByteToCharCp942.java
> - src/share/classes/sun/io/ByteToCharCp942C.java
> - src/share/classes/sun/io/ByteToCharCp943.java
> - src/share/classes/sun/io/ByteToCharCp943C.java
> - src/share/classes/sun/io/ByteToCharCp948.java
> - src/share/classes/sun/io/ByteToCharCp949.java
> - src/share/classes/sun/io/ByteToCharCp949C.java
> - src/share/classes/sun/io/ByteToCharCp950.java
> - src/share/classes/sun/io/ByteToCharCp964.java
> - src/share/classes/sun/io/ByteToCharCp970.java
> - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java
> - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java
> - src/share/classes/sun/io/ByteToCharDoubleByte.java
> - src/share/classes/sun/io/ByteToCharEUC.java
> - src/share/classes/sun/io/ByteToCharEUC2.java
> - src/share/classes/sun/io/ByteToCharEUC_CN.java
> - src/share/classes/sun/io/ByteToCharEUC_JP.java
> - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java
> - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java
> - src/share/classes/sun/io/ByteToCharEUC_KR.java
> - src/share/classes/sun/io/ByteToCharEUC_TW.java
> - src/share/classes/sun/io/ByteToCharGB18030.java
> - src/share/classes/sun/io/ByteToCharGB18030DB.java
> - src/share/classes/sun/io/ByteToCharGBK.java
> - src/share/classes/sun/io/ByteToCharISCII91.java
> - src/share/classes/sun/io/ByteToCharISO2022.java
> - src/share/classes/sun/io/ByteToCharISO2022CN.java
> - src/share/classes/sun/io/ByteToCharISO2022JP.java
> - src/share/classes/sun/io/ByteToCharISO2022KR.java
> - src/share/classes/sun/io/ByteToCharISO8859_1.java
> - src/share/classes/sun/io/ByteToCharISO8859_13.java
> - src/share/classes/sun/io/ByteToCharISO8859_15.java
> - src/share/classes/sun/io/ByteToCharISO8859_2.java
> - src/share/classes/sun/io/ByteToCharISO8859_3.java
> - src/share/classes/sun/io/ByteToCharISO8859_4.java
> - src/share/classes/sun/io/ByteToCharISO8859_5.java
> - src/share/classes/sun/io/ByteToCharISO8859_6.java
> - src/share/classes/sun/io/ByteToCharISO8859_7.java
> - src/share/classes/sun/io/ByteToCharISO8859_8.java
> - src/share/classes/sun/io/ByteToCharISO8859_9.java
> - src/share/classes/sun/io/ByteToCharJIS0201.java
> - src/share/classes/sun/io/ByteToCharJIS0208.java
> - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java
> - src/share/classes/sun/io/ByteToCharJIS0212.java
> - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java
> - src/share/classes/sun/io/ByteToCharJISAutoDetect.java
> - src/share/classes/sun/io/ByteToCharJohab.java
> - src/share/classes/sun/io/ByteToCharKOI8_R.java
> - src/share/classes/sun/io/ByteToCharMS874.java
> - src/share/classes/sun/io/ByteToCharMS932.java
> - src/share/classes/sun/io/ByteToCharMS936.java
> - src/share/classes/sun/io/ByteToCharMS949.java
> - src/share/classes/sun/io/ByteToCharMS950.java
> - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java
> - src/share/classes/sun/io/ByteToCharMacArabic.java
> - src/share/classes/sun/io/ByteToCharMacCentralEurope.java
> - src/share/classes/sun/io/ByteToCharMacCroatian.java
> - src/share/classes/sun/io/ByteToCharMacCyrillic.java
> - src/share/classes/sun/io/ByteToCharMacDingbat.java
> - src/share/classes/sun/io/ByteToCharMacGreek.java
> - src/share/classes/sun/io/ByteToCharMacHebrew.java
> - src/share/classes/sun/io/ByteToCharMacIceland.java
> - src/share/classes/sun/io/ByteToCharMacRoman.java
> - src/share/classes/sun/io/ByteToCharMacRomania.java
> - src/share/classes/sun/io/ByteToCharMacSymbol.java
> - src/share/classes/sun/io/ByteToCharMacThai.java
> - src/share/classes/sun/io/ByteToCharMacTurkish.java
> - src/share/classes/sun/io/ByteToCharMacUkraine.java
> - src/share/classes/sun/io/ByteToCharPCK.java
> - src/share/classes/sun/io/ByteToCharSJIS.java
> - src/share/classes/sun/io/ByteToCharSingleByte.java
> - src/share/classes/sun/io/ByteToCharTIS620.java
> - src/share/classes/sun/io/ByteToCharUTF16.java
> - src/share/classes/sun/io/ByteToCharUTF8.java
> - src/share/classes/sun/io/ByteToCharUnicode.java
> - src/share/classes/sun/io/ByteToCharUnicodeBig.java
> - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java
> - src/share/classes/sun/io/ByteToCharUnicodeLittle.java
> - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java
> - src/share/classes/sun/io/CharToByteASCII.java
> - src/share/classes/sun/io/CharToByteBig5.java
> - src/share/classes/sun/io/CharToByteBig5_HKSCS.java
> - src/share/classes/sun/io/CharToByteBig5_Solaris.java
> - src/share/classes/sun/io/CharToByteConverter.java
> - src/share/classes/sun/io/CharToByteCp037.java
> - src/share/classes/sun/io/CharToByteCp1006.java
> - src/share/classes/sun/io/CharToByteCp1025.java
> - src/share/classes/sun/io/CharToByteCp1026.java
> - src/share/classes/sun/io/CharToByteCp1046.java
> - src/share/classes/sun/io/CharToByteCp1047.java
> - src/share/classes/sun/io/CharToByteCp1097.java
> - src/share/classes/sun/io/CharToByteCp1098.java
> - src/share/classes/sun/io/CharToByteCp1112.java
> - src/share/classes/sun/io/CharToByteCp1122.java
> - src/share/classes/sun/io/CharToByteCp1123.java
> - src/share/classes/sun/io/CharToByteCp1124.java
> - src/share/classes/sun/io/CharToByteCp1140.java
> - src/share/classes/sun/io/CharToByteCp1141.java
> - src/share/classes/sun/io/CharToByteCp1142.java
> - src/share/classes/sun/io/CharToByteCp1143.java
> - src/share/classes/sun/io/CharToByteCp1144.java
> - src/share/classes/sun/io/CharToByteCp1145.java
> - src/share/classes/sun/io/CharToByteCp1146.java
> - src/share/classes/sun/io/CharToByteCp1147.java
> - src/share/classes/sun/io/CharToByteCp1148.java
> - src/share/classes/sun/io/CharToByteCp1149.java
> - src/share/classes/sun/io/CharToByteCp1250.java
> - src/share/classes/sun/io/CharToByteCp1251.java
> - src/share/classes/sun/io/CharToByteCp1252.java
> - src/share/classes/sun/io/CharToByteCp1253.java
> - src/share/classes/sun/io/CharToByteCp1254.java
> - src/share/classes/sun/io/CharToByteCp1255.java
> - src/share/classes/sun/io/CharToByteCp1256.java
> - src/share/classes/sun/io/CharToByteCp1257.java
> - src/share/classes/sun/io/CharToByteCp1258.java
> - src/share/classes/sun/io/CharToByteCp1381.java
> - src/share/classes/sun/io/CharToByteCp1383.java
> - src/share/classes/sun/io/CharToByteCp273.java
> - src/share/classes/sun/io/CharToByteCp277.java
> - src/share/classes/sun/io/CharToByteCp278.java
> - src/share/classes/sun/io/CharToByteCp280.java
> - src/share/classes/sun/io/CharToByteCp284.java
> - src/share/classes/sun/io/CharToByteCp285.java
> - src/share/classes/sun/io/CharToByteCp297.java
> - src/share/classes/sun/io/CharToByteCp33722.java
> - src/share/classes/sun/io/CharToByteCp420.java
> - src/share/classes/sun/io/CharToByteCp424.java
> - src/share/classes/sun/io/CharToByteCp437.java
> - src/share/classes/sun/io/CharToByteCp500.java
> - src/share/classes/sun/io/CharToByteCp737.java
> - src/share/classes/sun/io/CharToByteCp775.java
> - src/share/classes/sun/io/CharToByteCp833.java
> - src/share/classes/sun/io/CharToByteCp834.java
> - src/share/classes/sun/io/CharToByteCp838.java
> - src/share/classes/sun/io/CharToByteCp850.java
> - src/share/classes/sun/io/CharToByteCp852.java
> - src/share/classes/sun/io/CharToByteCp855.java
> - src/share/classes/sun/io/CharToByteCp856.java
> - src/share/classes/sun/io/CharToByteCp857.java
> - src/share/classes/sun/io/CharToByteCp858.java
> - src/share/classes/sun/io/CharToByteCp860.java
> - src/share/classes/sun/io/CharToByteCp861.java
> - src/share/classes/sun/io/CharToByteCp862.java
> - src/share/classes/sun/io/CharToByteCp863.java
> - src/share/classes/sun/io/CharToByteCp864.java
> - src/share/classes/sun/io/CharToByteCp865.java
> - src/share/classes/sun/io/CharToByteCp866.java
> - src/share/classes/sun/io/CharToByteCp868.java
> - src/share/classes/sun/io/CharToByteCp869.java
> - src/share/classes/sun/io/CharToByteCp870.java
> - src/share/classes/sun/io/CharToByteCp871.java
> - src/share/classes/sun/io/CharToByteCp874.java
> - src/share/classes/sun/io/CharToByteCp875.java
> - src/share/classes/sun/io/CharToByteCp918.java
> - src/share/classes/sun/io/CharToByteCp921.java
> - src/share/classes/sun/io/CharToByteCp922.java
> - src/share/classes/sun/io/CharToByteCp930.java
> - src/share/classes/sun/io/CharToByteCp933.java
> - src/share/classes/sun/io/CharToByteCp935.java
> - src/share/classes/sun/io/CharToByteCp937.java
> - src/share/classes/sun/io/CharToByteCp939.java
> - src/share/classes/sun/io/CharToByteCp942.java
> - src/share/classes/sun/io/CharToByteCp942C.java
> - src/share/classes/sun/io/CharToByteCp943.java
> - src/share/classes/sun/io/CharToByteCp943C.java
> - src/share/classes/sun/io/CharToByteCp948.java
> - src/share/classes/sun/io/CharToByteCp949.java
> - src/share/classes/sun/io/CharToByteCp949C.java
> - src/share/classes/sun/io/CharToByteCp950.java
> - src/share/classes/sun/io/CharToByteCp964.java
> - src/share/classes/sun/io/CharToByteCp970.java
> - src/share/classes/sun/io/CharToByteDBCS_ASCII.java
> - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java
> - src/share/classes/sun/io/CharToByteDoubleByte.java
> - src/share/classes/sun/io/CharToByteEUC.java
> - src/share/classes/sun/io/CharToByteEUC_CN.java
> - src/share/classes/sun/io/CharToByteEUC_JP.java
> - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java
> - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java
> - src/share/classes/sun/io/CharToByteEUC_KR.java
> - src/share/classes/sun/io/CharToByteEUC_TW.java
> - src/share/classes/sun/io/CharToByteGB18030.java
> - src/share/classes/sun/io/CharToByteGBK.java
> - src/share/classes/sun/io/CharToByteISCII91.java
> - src/share/classes/sun/io/CharToByteISO2022.java
> - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java
> - src/share/classes/sun/io/CharToByteISO2022CN_GB.java
> - src/share/classes/sun/io/CharToByteISO2022JP.java
> - src/share/classes/sun/io/CharToByteISO2022KR.java
> - src/share/classes/sun/io/CharToByteISO8859_1.java
> - src/share/classes/sun/io/CharToByteISO8859_13.java
> - src/share/classes/sun/io/CharToByteISO8859_15.java
> - src/share/classes/sun/io/CharToByteISO8859_2.java
> - src/share/classes/sun/io/CharToByteISO8859_3.java
> - src/share/classes/sun/io/CharToByteISO8859_4.java
> - src/share/classes/sun/io/CharToByteISO8859_5.java
> - src/share/classes/sun/io/CharToByteISO8859_6.java
> - src/share/classes/sun/io/CharToByteISO8859_7.java
> - src/share/classes/sun/io/CharToByteISO8859_8.java
> - src/share/classes/sun/io/CharToByteISO8859_9.java
> - src/share/classes/sun/io/CharToByteJIS0201.java
> - src/share/classes/sun/io/CharToByteJIS0208.java
> - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java
> - src/share/classes/sun/io/CharToByteJIS0212.java
> - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java
> - src/share/classes/sun/io/CharToByteJohab.java
> - src/share/classes/sun/io/CharToByteKOI8_R.java
> - src/share/classes/sun/io/CharToByteMS874.java
> - src/share/classes/sun/io/CharToByteMS932.java
> - src/share/classes/sun/io/CharToByteMS936.java
> - src/share/classes/sun/io/CharToByteMS949.java
> - src/share/classes/sun/io/CharToByteMS950.java
> - src/share/classes/sun/io/CharToByteMS950_HKSCS.java
> - src/share/classes/sun/io/CharToByteMacArabic.java
> - src/share/classes/sun/io/CharToByteMacCentralEurope.java
> - src/share/classes/sun/io/CharToByteMacCroatian.java
> - src/share/classes/sun/io/CharToByteMacCyrillic.java
> - src/share/classes/sun/io/CharToByteMacDingbat.java
> - src/share/classes/sun/io/CharToByteMacGreek.java
> - src/share/classes/sun/io/CharToByteMacHebrew.java
> - src/share/classes/sun/io/CharToByteMacIceland.java
> - src/share/classes/sun/io/CharToByteMacRoman.java
> - src/share/classes/sun/io/CharToByteMacRomania.java
> - src/share/classes/sun/io/CharToByteMacSymbol.java
> - src/share/classes/sun/io/CharToByteMacThai.java
> - src/share/classes/sun/io/CharToByteMacTurkish.java
> - src/share/classes/sun/io/CharToByteMacUkraine.java
> - src/share/classes/sun/io/CharToBytePCK.java
> - src/share/classes/sun/io/CharToByteSJIS.java
> - src/share/classes/sun/io/CharToByteSingleByte.java
> - src/share/classes/sun/io/CharToByteTIS620.java
> - src/share/classes/sun/io/CharToByteUTF16.java
> - src/share/classes/sun/io/CharToByteUTF8.java
> - src/share/classes/sun/io/CharToByteUnicode.java
> - src/share/classes/sun/io/CharToByteUnicodeBig.java
> - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java
> - src/share/classes/sun/io/CharToByteUnicodeLittle.java
> - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java
> - src/share/classes/sun/io/CharacterEncoding.java
> - src/share/classes/sun/io/ConversionBufferFullException.java
> - src/share/classes/sun/io/Converters.java
> - src/share/classes/sun/io/MalformedInputException.java
> - src/share/classes/sun/io/UnknownCharacterException.java
> ! src/share/classes/sun/nio/cs/ext/GB18030.java
> ! src/share/classes/sun/nio/cs/ext/IBM33722.java
> ! src/share/classes/sun/nio/cs/ext/IBM964.java
> ! src/share/classes/sun/nio/cs/ext/ISCII91.java
> ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java
> ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java
> ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java
> ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java
> ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java
> ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java
> ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java
> ! test/sun/nio/cs/TestCp834_SBCS.java
> - test/sun/nio/cs/TestISCII91.java
>
> Changeset: 07ad16388170
> Author:    sherman
> Date:      2011-08-17 14:18 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07ad16388170
>
> Merge
>
>



From xueming.shen at oracle.com  Wed Aug 17 21:37:18 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 17 Aug 2011 14:37:18 -0700
Subject: Request for review for 7066490: @since 1.7 tag is missing for
	java.util.regex.Matcher.group(java.lang.String)
Message-ID: <4E4C348E.1030504@oracle.com>

The @since 1.7 tag was missed when regex groupname suport was added in JDK7.
Here is the webrev for adding it back in.

http://cr.openjdk.java.net/~sherman/7066490/webrev 
<http://cr.openjdk.java.net/%7Esherman/7066490/webrev/>

Thanks!

-Sherman


From sebastian.sickelmann at gmx.de  Wed Aug 17 21:31:58 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 17 Aug 2011 23:31:58 +0200
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect)
	Exception	from	newInstance() not chained to cause.
In-Reply-To: <4E4BD37E.4060402@gmx.de>
References: <4E48BA0E.6090702@gmx.de>
	<4E4B1528.8060306@oracle.com>	<4E4BA9DD.20706@oracle.com>
	<4E4BD37E.4060402@gmx.de>
Message-ID: <4E4C334E.4000508@gmx.de>

Am 17.08.2011 16:43, schrieb Sebastian Sickelmann:
> Am 17.08.2011 13:45, schrieb Alan Bateman:
>> joe.darcy at oracle.com wrote:
>>>
>>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
>>> conventional constructors to InternalError" for it.
>>>
>> Thanks Joe, and to help this along here's the webrev with Sebastian's 
>> patches:
>>   http://cr.openjdk.java.net/~alanb/7080020/webrev/
>>
>> I haven't really looked but one thing I did notice is that the 
>> multi-catch usages need to be checked as Sasha cleaned up a few of 
>> these recently.
>>
>> -Alan.
> Thanks for the webrev.
>
> I think it is very hard to start with the complete patch. Or is it 
> better to review it all at once?
>
> I have created a webrev for my patches 0 and 1 and uploaded it here:
> http://oss-patches.24.eu/openjdk8/InternalError/part1/
>
> After i have pulled from tl/jdk i got problems with building.
> I got warnings so that i must build with JAVAC_WARNINGS_FATAL=false, 
> is this ok for tl-repo?
>
> -- Sebastian
Ok. Rebased again.

Now the webrevs are:
http://oss-patches.24.eu/openjdk8/InternalError/part1/REBASED_ON_e59aad6ed600/
http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_e59aad6ed600/

Unfortunatly after i have uploaded the webrev(takes some time because 
128kbit/sek up is not the fastest)
there was a change that i not rebased on.
rev 2961329a6774
6237353: Remove sun.io package from j2se binary

rebasing on this removes some files in sun.io package these files should 
be ignored while reviewing my webrevs.

If someone needs the rebased webrevs, let me know.

-- Sebastian


From mike.duigou at oracle.com  Wed Aug 17 21:33:34 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 17 Aug 2011 14:33:34 -0700
Subject: Request for review for 7066490: @since 1.7 tag is missing for
	java.util.regex.Matcher.group(java.lang.String)
In-Reply-To: <4E4C348E.1030504@oracle.com>
References: <4E4C348E.1030504@oracle.com>
Message-ID: <31514907-82E8-4190-857E-B8759CEE8DB9@oracle.com>

Looks good. This should be backported to 7 updates.

Mike

On Aug 17 2011, at 14:37 , Xueming Shen wrote:

> The @since 1.7 tag was missed when regex groupname suport was added in JDK7.
> Here is the webrev for adding it back in.
> 
> http://cr.openjdk.java.net/~sherman/7066490/webrev <http://cr.openjdk.java.net/%7Esherman/7066490/webrev/>
> 
> Thanks!
> 
> -Sherman



From sebastian.sickelmann at gmx.de  Wed Aug 17 21:33:56 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 17 Aug 2011 23:33:56 +0200
Subject: hg: jdk8/tl/jdk: 2 new changesets
In-Reply-To: <4E4C2F48.4020501@univ-mlv.fr>
References: <20110817210614.B652147C73@hg.openjdk.java.net>
	<4E4C2F48.4020501@univ-mlv.fr>
Message-ID: <4E4C33C4.6060406@gmx.de>

It breaks my webrev a did 2 minutes before my upload completed. :-(
But never mind. You are right. Removing is always a win. ;-)

Am 17.08.2011 23:14, schrieb R?mi Forax:
> Hurrah, this is the changeset of the month,
> removing things is always a win.
>
> R?mi
>
> On 08/17/2011 11:05 PM, xueming.shen at oracle.com wrote:
>> Changeset: 2961329a6774
>> Author:    sherman
>> Date:      2011-08-17 14:14 -0700
>> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2961329a6774
>>
>> 6237353: Remove sun.io package from j2se binary
>> Summary: Removed sun.io package and related test cases
>> Reviewed-by: alanb
>>
>> ! make/java/sun_nio/FILES_java.gmk
>> ! make/java/sun_nio/Makefile
>> ! make/sun/nio/cs/FILES_java.gmk
>> ! make/tools/CharsetMapping/SingleByte-X.java.template
>> - src/share/classes/sun/io/ByteToCharASCII.java
>> - src/share/classes/sun/io/ByteToCharBig5.java
>> - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java
>> - src/share/classes/sun/io/ByteToCharBig5_Solaris.java
>> - src/share/classes/sun/io/ByteToCharConverter.java
>> - src/share/classes/sun/io/ByteToCharCp037.java
>> - src/share/classes/sun/io/ByteToCharCp1006.java
>> - src/share/classes/sun/io/ByteToCharCp1025.java
>> - src/share/classes/sun/io/ByteToCharCp1026.java
>> - src/share/classes/sun/io/ByteToCharCp1046.java
>> - src/share/classes/sun/io/ByteToCharCp1047.java
>> - src/share/classes/sun/io/ByteToCharCp1097.java
>> - src/share/classes/sun/io/ByteToCharCp1098.java
>> - src/share/classes/sun/io/ByteToCharCp1112.java
>> - src/share/classes/sun/io/ByteToCharCp1122.java
>> - src/share/classes/sun/io/ByteToCharCp1123.java
>> - src/share/classes/sun/io/ByteToCharCp1124.java
>> - src/share/classes/sun/io/ByteToCharCp1140.java
>> - src/share/classes/sun/io/ByteToCharCp1141.java
>> - src/share/classes/sun/io/ByteToCharCp1142.java
>> - src/share/classes/sun/io/ByteToCharCp1143.java
>> - src/share/classes/sun/io/ByteToCharCp1144.java
>> - src/share/classes/sun/io/ByteToCharCp1145.java
>> - src/share/classes/sun/io/ByteToCharCp1146.java
>> - src/share/classes/sun/io/ByteToCharCp1147.java
>> - src/share/classes/sun/io/ByteToCharCp1148.java
>> - src/share/classes/sun/io/ByteToCharCp1149.java
>> - src/share/classes/sun/io/ByteToCharCp1250.java
>> - src/share/classes/sun/io/ByteToCharCp1251.java
>> - src/share/classes/sun/io/ByteToCharCp1252.java
>> - src/share/classes/sun/io/ByteToCharCp1253.java
>> - src/share/classes/sun/io/ByteToCharCp1254.java
>> - src/share/classes/sun/io/ByteToCharCp1255.java
>> - src/share/classes/sun/io/ByteToCharCp1256.java
>> - src/share/classes/sun/io/ByteToCharCp1257.java
>> - src/share/classes/sun/io/ByteToCharCp1258.java
>> - src/share/classes/sun/io/ByteToCharCp1381.java
>> - src/share/classes/sun/io/ByteToCharCp1383.java
>> - src/share/classes/sun/io/ByteToCharCp273.java
>> - src/share/classes/sun/io/ByteToCharCp277.java
>> - src/share/classes/sun/io/ByteToCharCp278.java
>> - src/share/classes/sun/io/ByteToCharCp280.java
>> - src/share/classes/sun/io/ByteToCharCp284.java
>> - src/share/classes/sun/io/ByteToCharCp285.java
>> - src/share/classes/sun/io/ByteToCharCp297.java
>> - src/share/classes/sun/io/ByteToCharCp33722.java
>> - src/share/classes/sun/io/ByteToCharCp420.java
>> - src/share/classes/sun/io/ByteToCharCp424.java
>> - src/share/classes/sun/io/ByteToCharCp437.java
>> - src/share/classes/sun/io/ByteToCharCp500.java
>> - src/share/classes/sun/io/ByteToCharCp737.java
>> - src/share/classes/sun/io/ByteToCharCp775.java
>> - src/share/classes/sun/io/ByteToCharCp833.java
>> - src/share/classes/sun/io/ByteToCharCp834.java
>> - src/share/classes/sun/io/ByteToCharCp838.java
>> - src/share/classes/sun/io/ByteToCharCp850.java
>> - src/share/classes/sun/io/ByteToCharCp852.java
>> - src/share/classes/sun/io/ByteToCharCp855.java
>> - src/share/classes/sun/io/ByteToCharCp856.java
>> - src/share/classes/sun/io/ByteToCharCp857.java
>> - src/share/classes/sun/io/ByteToCharCp858.java
>> - src/share/classes/sun/io/ByteToCharCp860.java
>> - src/share/classes/sun/io/ByteToCharCp861.java
>> - src/share/classes/sun/io/ByteToCharCp862.java
>> - src/share/classes/sun/io/ByteToCharCp863.java
>> - src/share/classes/sun/io/ByteToCharCp864.java
>> - src/share/classes/sun/io/ByteToCharCp865.java
>> - src/share/classes/sun/io/ByteToCharCp866.java
>> - src/share/classes/sun/io/ByteToCharCp868.java
>> - src/share/classes/sun/io/ByteToCharCp869.java
>> - src/share/classes/sun/io/ByteToCharCp870.java
>> - src/share/classes/sun/io/ByteToCharCp871.java
>> - src/share/classes/sun/io/ByteToCharCp874.java
>> - src/share/classes/sun/io/ByteToCharCp875.java
>> - src/share/classes/sun/io/ByteToCharCp918.java
>> - src/share/classes/sun/io/ByteToCharCp921.java
>> - src/share/classes/sun/io/ByteToCharCp922.java
>> - src/share/classes/sun/io/ByteToCharCp930.java
>> - src/share/classes/sun/io/ByteToCharCp933.java
>> - src/share/classes/sun/io/ByteToCharCp935.java
>> - src/share/classes/sun/io/ByteToCharCp937.java
>> - src/share/classes/sun/io/ByteToCharCp939.java
>> - src/share/classes/sun/io/ByteToCharCp942.java
>> - src/share/classes/sun/io/ByteToCharCp942C.java
>> - src/share/classes/sun/io/ByteToCharCp943.java
>> - src/share/classes/sun/io/ByteToCharCp943C.java
>> - src/share/classes/sun/io/ByteToCharCp948.java
>> - src/share/classes/sun/io/ByteToCharCp949.java
>> - src/share/classes/sun/io/ByteToCharCp949C.java
>> - src/share/classes/sun/io/ByteToCharCp950.java
>> - src/share/classes/sun/io/ByteToCharCp964.java
>> - src/share/classes/sun/io/ByteToCharCp970.java
>> - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java
>> - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java
>> - src/share/classes/sun/io/ByteToCharDoubleByte.java
>> - src/share/classes/sun/io/ByteToCharEUC.java
>> - src/share/classes/sun/io/ByteToCharEUC2.java
>> - src/share/classes/sun/io/ByteToCharEUC_CN.java
>> - src/share/classes/sun/io/ByteToCharEUC_JP.java
>> - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java
>> - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java
>> - src/share/classes/sun/io/ByteToCharEUC_KR.java
>> - src/share/classes/sun/io/ByteToCharEUC_TW.java
>> - src/share/classes/sun/io/ByteToCharGB18030.java
>> - src/share/classes/sun/io/ByteToCharGB18030DB.java
>> - src/share/classes/sun/io/ByteToCharGBK.java
>> - src/share/classes/sun/io/ByteToCharISCII91.java
>> - src/share/classes/sun/io/ByteToCharISO2022.java
>> - src/share/classes/sun/io/ByteToCharISO2022CN.java
>> - src/share/classes/sun/io/ByteToCharISO2022JP.java
>> - src/share/classes/sun/io/ByteToCharISO2022KR.java
>> - src/share/classes/sun/io/ByteToCharISO8859_1.java
>> - src/share/classes/sun/io/ByteToCharISO8859_13.java
>> - src/share/classes/sun/io/ByteToCharISO8859_15.java
>> - src/share/classes/sun/io/ByteToCharISO8859_2.java
>> - src/share/classes/sun/io/ByteToCharISO8859_3.java
>> - src/share/classes/sun/io/ByteToCharISO8859_4.java
>> - src/share/classes/sun/io/ByteToCharISO8859_5.java
>> - src/share/classes/sun/io/ByteToCharISO8859_6.java
>> - src/share/classes/sun/io/ByteToCharISO8859_7.java
>> - src/share/classes/sun/io/ByteToCharISO8859_8.java
>> - src/share/classes/sun/io/ByteToCharISO8859_9.java
>> - src/share/classes/sun/io/ByteToCharJIS0201.java
>> - src/share/classes/sun/io/ByteToCharJIS0208.java
>> - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java
>> - src/share/classes/sun/io/ByteToCharJIS0212.java
>> - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java
>> - src/share/classes/sun/io/ByteToCharJISAutoDetect.java
>> - src/share/classes/sun/io/ByteToCharJohab.java
>> - src/share/classes/sun/io/ByteToCharKOI8_R.java
>> - src/share/classes/sun/io/ByteToCharMS874.java
>> - src/share/classes/sun/io/ByteToCharMS932.java
>> - src/share/classes/sun/io/ByteToCharMS936.java
>> - src/share/classes/sun/io/ByteToCharMS949.java
>> - src/share/classes/sun/io/ByteToCharMS950.java
>> - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java
>> - src/share/classes/sun/io/ByteToCharMacArabic.java
>> - src/share/classes/sun/io/ByteToCharMacCentralEurope.java
>> - src/share/classes/sun/io/ByteToCharMacCroatian.java
>> - src/share/classes/sun/io/ByteToCharMacCyrillic.java
>> - src/share/classes/sun/io/ByteToCharMacDingbat.java
>> - src/share/classes/sun/io/ByteToCharMacGreek.java
>> - src/share/classes/sun/io/ByteToCharMacHebrew.java
>> - src/share/classes/sun/io/ByteToCharMacIceland.java
>> - src/share/classes/sun/io/ByteToCharMacRoman.java
>> - src/share/classes/sun/io/ByteToCharMacRomania.java
>> - src/share/classes/sun/io/ByteToCharMacSymbol.java
>> - src/share/classes/sun/io/ByteToCharMacThai.java
>> - src/share/classes/sun/io/ByteToCharMacTurkish.java
>> - src/share/classes/sun/io/ByteToCharMacUkraine.java
>> - src/share/classes/sun/io/ByteToCharPCK.java
>> - src/share/classes/sun/io/ByteToCharSJIS.java
>> - src/share/classes/sun/io/ByteToCharSingleByte.java
>> - src/share/classes/sun/io/ByteToCharTIS620.java
>> - src/share/classes/sun/io/ByteToCharUTF16.java
>> - src/share/classes/sun/io/ByteToCharUTF8.java
>> - src/share/classes/sun/io/ByteToCharUnicode.java
>> - src/share/classes/sun/io/ByteToCharUnicodeBig.java
>> - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java
>> - src/share/classes/sun/io/ByteToCharUnicodeLittle.java
>> - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java
>> - src/share/classes/sun/io/CharToByteASCII.java
>> - src/share/classes/sun/io/CharToByteBig5.java
>> - src/share/classes/sun/io/CharToByteBig5_HKSCS.java
>> - src/share/classes/sun/io/CharToByteBig5_Solaris.java
>> - src/share/classes/sun/io/CharToByteConverter.java
>> - src/share/classes/sun/io/CharToByteCp037.java
>> - src/share/classes/sun/io/CharToByteCp1006.java
>> - src/share/classes/sun/io/CharToByteCp1025.java
>> - src/share/classes/sun/io/CharToByteCp1026.java
>> - src/share/classes/sun/io/CharToByteCp1046.java
>> - src/share/classes/sun/io/CharToByteCp1047.java
>> - src/share/classes/sun/io/CharToByteCp1097.java
>> - src/share/classes/sun/io/CharToByteCp1098.java
>> - src/share/classes/sun/io/CharToByteCp1112.java
>> - src/share/classes/sun/io/CharToByteCp1122.java
>> - src/share/classes/sun/io/CharToByteCp1123.java
>> - src/share/classes/sun/io/CharToByteCp1124.java
>> - src/share/classes/sun/io/CharToByteCp1140.java
>> - src/share/classes/sun/io/CharToByteCp1141.java
>> - src/share/classes/sun/io/CharToByteCp1142.java
>> - src/share/classes/sun/io/CharToByteCp1143.java
>> - src/share/classes/sun/io/CharToByteCp1144.java
>> - src/share/classes/sun/io/CharToByteCp1145.java
>> - src/share/classes/sun/io/CharToByteCp1146.java
>> - src/share/classes/sun/io/CharToByteCp1147.java
>> - src/share/classes/sun/io/CharToByteCp1148.java
>> - src/share/classes/sun/io/CharToByteCp1149.java
>> - src/share/classes/sun/io/CharToByteCp1250.java
>> - src/share/classes/sun/io/CharToByteCp1251.java
>> - src/share/classes/sun/io/CharToByteCp1252.java
>> - src/share/classes/sun/io/CharToByteCp1253.java
>> - src/share/classes/sun/io/CharToByteCp1254.java
>> - src/share/classes/sun/io/CharToByteCp1255.java
>> - src/share/classes/sun/io/CharToByteCp1256.java
>> - src/share/classes/sun/io/CharToByteCp1257.java
>> - src/share/classes/sun/io/CharToByteCp1258.java
>> - src/share/classes/sun/io/CharToByteCp1381.java
>> - src/share/classes/sun/io/CharToByteCp1383.java
>> - src/share/classes/sun/io/CharToByteCp273.java
>> - src/share/classes/sun/io/CharToByteCp277.java
>> - src/share/classes/sun/io/CharToByteCp278.java
>> - src/share/classes/sun/io/CharToByteCp280.java
>> - src/share/classes/sun/io/CharToByteCp284.java
>> - src/share/classes/sun/io/CharToByteCp285.java
>> - src/share/classes/sun/io/CharToByteCp297.java
>> - src/share/classes/sun/io/CharToByteCp33722.java
>> - src/share/classes/sun/io/CharToByteCp420.java
>> - src/share/classes/sun/io/CharToByteCp424.java
>> - src/share/classes/sun/io/CharToByteCp437.java
>> - src/share/classes/sun/io/CharToByteCp500.java
>> - src/share/classes/sun/io/CharToByteCp737.java
>> - src/share/classes/sun/io/CharToByteCp775.java
>> - src/share/classes/sun/io/CharToByteCp833.java
>> - src/share/classes/sun/io/CharToByteCp834.java
>> - src/share/classes/sun/io/CharToByteCp838.java
>> - src/share/classes/sun/io/CharToByteCp850.java
>> - src/share/classes/sun/io/CharToByteCp852.java
>> - src/share/classes/sun/io/CharToByteCp855.java
>> - src/share/classes/sun/io/CharToByteCp856.java
>> - src/share/classes/sun/io/CharToByteCp857.java
>> - src/share/classes/sun/io/CharToByteCp858.java
>> - src/share/classes/sun/io/CharToByteCp860.java
>> - src/share/classes/sun/io/CharToByteCp861.java
>> - src/share/classes/sun/io/CharToByteCp862.java
>> - src/share/classes/sun/io/CharToByteCp863.java
>> - src/share/classes/sun/io/CharToByteCp864.java
>> - src/share/classes/sun/io/CharToByteCp865.java
>> - src/share/classes/sun/io/CharToByteCp866.java
>> - src/share/classes/sun/io/CharToByteCp868.java
>> - src/share/classes/sun/io/CharToByteCp869.java
>> - src/share/classes/sun/io/CharToByteCp870.java
>> - src/share/classes/sun/io/CharToByteCp871.java
>> - src/share/classes/sun/io/CharToByteCp874.java
>> - src/share/classes/sun/io/CharToByteCp875.java
>> - src/share/classes/sun/io/CharToByteCp918.java
>> - src/share/classes/sun/io/CharToByteCp921.java
>> - src/share/classes/sun/io/CharToByteCp922.java
>> - src/share/classes/sun/io/CharToByteCp930.java
>> - src/share/classes/sun/io/CharToByteCp933.java
>> - src/share/classes/sun/io/CharToByteCp935.java
>> - src/share/classes/sun/io/CharToByteCp937.java
>> - src/share/classes/sun/io/CharToByteCp939.java
>> - src/share/classes/sun/io/CharToByteCp942.java
>> - src/share/classes/sun/io/CharToByteCp942C.java
>> - src/share/classes/sun/io/CharToByteCp943.java
>> - src/share/classes/sun/io/CharToByteCp943C.java
>> - src/share/classes/sun/io/CharToByteCp948.java
>> - src/share/classes/sun/io/CharToByteCp949.java
>> - src/share/classes/sun/io/CharToByteCp949C.java
>> - src/share/classes/sun/io/CharToByteCp950.java
>> - src/share/classes/sun/io/CharToByteCp964.java
>> - src/share/classes/sun/io/CharToByteCp970.java
>> - src/share/classes/sun/io/CharToByteDBCS_ASCII.java
>> - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java
>> - src/share/classes/sun/io/CharToByteDoubleByte.java
>> - src/share/classes/sun/io/CharToByteEUC.java
>> - src/share/classes/sun/io/CharToByteEUC_CN.java
>> - src/share/classes/sun/io/CharToByteEUC_JP.java
>> - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java
>> - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java
>> - src/share/classes/sun/io/CharToByteEUC_KR.java
>> - src/share/classes/sun/io/CharToByteEUC_TW.java
>> - src/share/classes/sun/io/CharToByteGB18030.java
>> - src/share/classes/sun/io/CharToByteGBK.java
>> - src/share/classes/sun/io/CharToByteISCII91.java
>> - src/share/classes/sun/io/CharToByteISO2022.java
>> - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java
>> - src/share/classes/sun/io/CharToByteISO2022CN_GB.java
>> - src/share/classes/sun/io/CharToByteISO2022JP.java
>> - src/share/classes/sun/io/CharToByteISO2022KR.java
>> - src/share/classes/sun/io/CharToByteISO8859_1.java
>> - src/share/classes/sun/io/CharToByteISO8859_13.java
>> - src/share/classes/sun/io/CharToByteISO8859_15.java
>> - src/share/classes/sun/io/CharToByteISO8859_2.java
>> - src/share/classes/sun/io/CharToByteISO8859_3.java
>> - src/share/classes/sun/io/CharToByteISO8859_4.java
>> - src/share/classes/sun/io/CharToByteISO8859_5.java
>> - src/share/classes/sun/io/CharToByteISO8859_6.java
>> - src/share/classes/sun/io/CharToByteISO8859_7.java
>> - src/share/classes/sun/io/CharToByteISO8859_8.java
>> - src/share/classes/sun/io/CharToByteISO8859_9.java
>> - src/share/classes/sun/io/CharToByteJIS0201.java
>> - src/share/classes/sun/io/CharToByteJIS0208.java
>> - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java
>> - src/share/classes/sun/io/CharToByteJIS0212.java
>> - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java
>> - src/share/classes/sun/io/CharToByteJohab.java
>> - src/share/classes/sun/io/CharToByteKOI8_R.java
>> - src/share/classes/sun/io/CharToByteMS874.java
>> - src/share/classes/sun/io/CharToByteMS932.java
>> - src/share/classes/sun/io/CharToByteMS936.java
>> - src/share/classes/sun/io/CharToByteMS949.java
>> - src/share/classes/sun/io/CharToByteMS950.java
>> - src/share/classes/sun/io/CharToByteMS950_HKSCS.java
>> - src/share/classes/sun/io/CharToByteMacArabic.java
>> - src/share/classes/sun/io/CharToByteMacCentralEurope.java
>> - src/share/classes/sun/io/CharToByteMacCroatian.java
>> - src/share/classes/sun/io/CharToByteMacCyrillic.java
>> - src/share/classes/sun/io/CharToByteMacDingbat.java
>> - src/share/classes/sun/io/CharToByteMacGreek.java
>> - src/share/classes/sun/io/CharToByteMacHebrew.java
>> - src/share/classes/sun/io/CharToByteMacIceland.java
>> - src/share/classes/sun/io/CharToByteMacRoman.java
>> - src/share/classes/sun/io/CharToByteMacRomania.java
>> - src/share/classes/sun/io/CharToByteMacSymbol.java
>> - src/share/classes/sun/io/CharToByteMacThai.java
>> - src/share/classes/sun/io/CharToByteMacTurkish.java
>> - src/share/classes/sun/io/CharToByteMacUkraine.java
>> - src/share/classes/sun/io/CharToBytePCK.java
>> - src/share/classes/sun/io/CharToByteSJIS.java
>> - src/share/classes/sun/io/CharToByteSingleByte.java
>> - src/share/classes/sun/io/CharToByteTIS620.java
>> - src/share/classes/sun/io/CharToByteUTF16.java
>> - src/share/classes/sun/io/CharToByteUTF8.java
>> - src/share/classes/sun/io/CharToByteUnicode.java
>> - src/share/classes/sun/io/CharToByteUnicodeBig.java
>> - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java
>> - src/share/classes/sun/io/CharToByteUnicodeLittle.java
>> - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java
>> - src/share/classes/sun/io/CharacterEncoding.java
>> - src/share/classes/sun/io/ConversionBufferFullException.java
>> - src/share/classes/sun/io/Converters.java
>> - src/share/classes/sun/io/MalformedInputException.java
>> - src/share/classes/sun/io/UnknownCharacterException.java
>> ! src/share/classes/sun/nio/cs/ext/GB18030.java
>> ! src/share/classes/sun/nio/cs/ext/IBM33722.java
>> ! src/share/classes/sun/nio/cs/ext/IBM964.java
>> ! src/share/classes/sun/nio/cs/ext/ISCII91.java
>> ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java
>> ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java
>> ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java
>> ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java
>> ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java
>> ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java
>> ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java
>> ! test/sun/nio/cs/TestCp834_SBCS.java
>> - test/sun/nio/cs/TestISCII91.java
>>
>> Changeset: 07ad16388170
>> Author:    sherman
>> Date:      2011-08-17 14:18 -0700
>> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07ad16388170
>>
>> Merge
>>
>>
>



From alexandre.boulgakov at oracle.com  Wed Aug 17 21:34:01 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Wed, 17 Aug 2011 14:34:01 -0700
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E4C2CF1.8020203@gmx.de>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
	<4E4BA9DD.20706@oracle.com> <4E4BD37E.4060402@gmx.de>
	<4E4BD723.2040702@oracle.com> <4E4C2CF1.8020203@gmx.de>
Message-ID: <4E4C33C9.1070803@oracle.com>

On 8/17/2011 2:04 PM, Sebastian Sickelmann wrote:
> Am 17.08.2011 16:58, schrieb Alexandre Boulgakov:
>> Hello Sebastian.
>>
>> On 8/17/2011 7:43 AM, Sebastian Sickelmann wrote:
>>> Am 17.08.2011 13:45, schrieb Alan Bateman:
>>>> joe.darcy at oracle.com wrote:
>>>>>
>>>>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
>>>>> conventional constructors to InternalError" for it.
>>>>>
>>>> Thanks Joe, and to help this along here's the webrev with 
>>>> Sebastian's patches:
>>>>   http://cr.openjdk.java.net/~alanb/7080020/webrev/
>>>>
>>>> I haven't really looked but one thing I did notice is that the 
>>>> multi-catch usages need to be checked as Sasha cleaned up a few of 
>>>> these recently.
>>>>
>>>> -Alan.
>>> Thanks for the webrev.
>>>
>>> I think it is very hard to start with the complete patch. Or is it 
>>> better to review it all at once?
>>>
>>> I have created a webrev for my patches 0 and 1 and uploaded it here:
>>> http://oss-patches.24.eu/openjdk8/InternalError/part1/
>>>
>>> After i have pulled from tl/jdk i got problems with building.
>>> I got warnings so that i must build with JAVAC_WARNINGS_FATAL=false, 
>>> is this ok for tl-repo?
>>
>> You should not set JAVAC_WARNINGS_FATAL manually, and you can ignore 
>> any preexisting warnings (although you should not introduce any new 
>> ones). The makefiles where it is safe to compile with 
>> JAVAC_WARNINGS_FATAL will set it appropriately. There is an ongoing 
>> effort to reduce javac warnings (including lint warnings, which are 
>> not currently enabled in all parts of the code). If you build with 
>> JAVAC_MAX_WARNINGS=true, you will notice that there are just over 
>> 10,000 javac build warnings in tl/jdk...
> OK. Actually there aren't any warnings. The are all gone after i did a 
> make clean & make all.
> Can that be? Is there an issue like : "make all doen't find all 
> changes to rebuild all dependencies", or is this a quite normal behavior?
That doesn't sound right... Are you sure there aren't any warnings? They 
can get lost among the other output. If you are redirecting output to a 
file and then checking for warnings, you should make sure to redirect 
both the standard output (&1) and the standard error (&2) streams since 
the output gets split between those.

That said, you shouldn't have as many as 10 000 on a normal build, but 
there should be some coming from different tools including javac, the C 
compiler, the linker, and more.

-Sasha
>>
>> Cheers,
>> Sasha
>>
>>>
>>> -- Sebastian
>


From sebastian.sickelmann at gmx.de  Wed Aug 17 21:37:41 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 17 Aug 2011 23:37:41 +0200
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E4C33C9.1070803@oracle.com>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
	<4E4BA9DD.20706@oracle.com> <4E4BD37E.4060402@gmx.de>
	<4E4BD723.2040702@oracle.com> <4E4C2CF1.8020203@gmx.de>
	<4E4C33C9.1070803@oracle.com>
Message-ID: <4E4C34A5.5070506@gmx.de>

Am 17.08.2011 23:34, schrieb Alexandre Boulgakov:
> On 8/17/2011 2:04 PM, Sebastian Sickelmann wrote:
>> Am 17.08.2011 16:58, schrieb Alexandre Boulgakov:
>>> Hello Sebastian.
>>>
>>> On 8/17/2011 7:43 AM, Sebastian Sickelmann wrote:
>>>> Am 17.08.2011 13:45, schrieb Alan Bateman:
>>>>> joe.darcy at oracle.com wrote:
>>>>>>
>>>>>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
>>>>>> conventional constructors to InternalError" for it.
>>>>>>
>>>>> Thanks Joe, and to help this along here's the webrev with 
>>>>> Sebastian's patches:
>>>>>   http://cr.openjdk.java.net/~alanb/7080020/webrev/
>>>>>
>>>>> I haven't really looked but one thing I did notice is that the 
>>>>> multi-catch usages need to be checked as Sasha cleaned up a few of 
>>>>> these recently.
>>>>>
>>>>> -Alan.
>>>> Thanks for the webrev.
>>>>
>>>> I think it is very hard to start with the complete patch. Or is it 
>>>> better to review it all at once?
>>>>
>>>> I have created a webrev for my patches 0 and 1 and uploaded it here:
>>>> http://oss-patches.24.eu/openjdk8/InternalError/part1/
>>>>
>>>> After i have pulled from tl/jdk i got problems with building.
>>>> I got warnings so that i must build with 
>>>> JAVAC_WARNINGS_FATAL=false, is this ok for tl-repo?
>>>
>>> You should not set JAVAC_WARNINGS_FATAL manually, and you can ignore 
>>> any preexisting warnings (although you should not introduce any new 
>>> ones). The makefiles where it is safe to compile with 
>>> JAVAC_WARNINGS_FATAL will set it appropriately. There is an ongoing 
>>> effort to reduce javac warnings (including lint warnings, which are 
>>> not currently enabled in all parts of the code). If you build with 
>>> JAVAC_MAX_WARNINGS=true, you will notice that there are just over 
>>> 10,000 javac build warnings in tl/jdk...
>> OK. Actually there aren't any warnings. The are all gone after i did 
>> a make clean & make all.
>> Can that be? Is there an issue like : "make all doen't find all 
>> changes to rebuild all dependencies", or is this a quite normal 
>> behavior?
> That doesn't sound right... Are you sure there aren't any warnings? 
> They can get lost among the other output. If you are redirecting 
> output to a file and then checking for warnings, you should make sure 
> to redirect both the standard output (&1) and the standard error (&2) 
> streams since the output gets split between those.
Ohh sorry, i explained it wrong. After clean rebuild the problem that 
there is a warning that is handled as a fatal error was away.  Haven't 
checks for "normal" warnings. I think there are some. I will check if i 
introduce some new warnings, but i don't think so.
>
> That said, you shouldn't have as many as 10 000 on a normal build, but 
> there should be some coming from different tools including javac, the 
> C compiler, the linker, and more.
>
> -Sasha
>>>
>>> Cheers,
>>> Sasha
>>>
>>>>
>>>> -- Sebastian
>>



From forax at univ-mlv.fr  Wed Aug 17 21:40:50 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 17 Aug 2011 23:40:50 +0200
Subject: Request for review for 7066490: @since 1.7 tag is missing for
	java.util.regex.Matcher.group(java.lang.String)
In-Reply-To: <4E4C348E.1030504@oracle.com>
References: <4E4C348E.1030504@oracle.com>
Message-ID: <4E4C3562.4090107@univ-mlv.fr>

On 08/17/2011 11:37 PM, Xueming Shen wrote:
> The @since 1.7 tag was missed when regex groupname suport was added in 
> JDK7.
> Here is the webrev for adding it back in.
>
> http://cr.openjdk.java.net/~sherman/7066490/webrev 
> <http://cr.openjdk.java.net/%7Esherman/7066490/webrev/>
>
> Thanks!
>
> -Sherman

looks good.

R?mi



From joe.darcy at oracle.com  Wed Aug 17 22:01:54 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 17 Aug 2011 15:01:54 -0700
Subject: Request for review for 7066490: @since 1.7 tag is missing for
	java.util.regex.Matcher.group(java.lang.String)
In-Reply-To: <31514907-82E8-4190-857E-B8759CEE8DB9@oracle.com>
References: <4E4C348E.1030504@oracle.com>
	<31514907-82E8-4190-857E-B8759CEE8DB9@oracle.com>
Message-ID: <4E4C3A52.4020802@oracle.com>

Mike Duigou wrote:
> Looks good. This should be backported to 7 updates.
>   

I would say "yes" in case the javadoc gets regenerated at some point.

-Joe

> Mike
>
> On Aug 17 2011, at 14:37 , Xueming Shen wrote:
>
>   
>> The @since 1.7 tag was missed when regex groupname suport was added in JDK7.
>> Here is the webrev for adding it back in.
>>
>> http://cr.openjdk.java.net/~sherman/7066490/webrev <http://cr.openjdk.java.net/%7Esherman/7066490/webrev/>
>>
>> Thanks!
>>
>> -Sherman
>>     
>
>   



From xueming.shen at oracle.com  Wed Aug 17 22:05:47 2011
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 17 Aug 2011 22:05:47 +0000
Subject: hg: jdk8/tl/jdk: 7066490: @since 1.7 tag is missing for
	java.util.regex.Matcher.group(java.lang.String)
Message-ID: <20110817220558.C539D47C77@hg.openjdk.java.net>

Changeset: 11cc9c2e0431
Author:    sherman
Date:      2011-08-17 15:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11cc9c2e0431

7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String)
Summary: Added the @since 1.7 tag
Reviewed-by: mduigou, forax

! src/share/classes/java/util/regex/Matcher.java



From Ulf.Zibis at gmx.de  Wed Aug 17 22:08:36 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 18 Aug 2011 00:08:36 +0200
Subject: Request for review 6237353: Remove sun.io package from j2se binary
In-Reply-To: <4E4C0B75.9070004@oracle.com>
References: <4E4B7EDE.6040006@oracle.com> <4E4BB603.4050604@gmx.de>
	<4E4C0B75.9070004@oracle.com>
Message-ID: <4E4C3BE4.6000403@gmx.de>

Sherman,

thanks.
There are some more public sun.io-bridge-methods which could be saved or at least made 
package-private, e.g.:
- EUC_TW.Encoder.toEUC()
- EUC_TW.Decoder.toUnicode()
- DoubleByte.Encoder.encodeChar()
- DoubleByte.Decoder.decodeSingle()
- DoubleByte.Decoder.decodeDouble()
- DoubleByteEncoder.encodeSingle()
- DoubleByteEncoder.encodeDouble()
- etc.

I think, all sun.nio.cs charsets have been made public for the sun.io access. Why don't make them 
package-private? Nobody from outside should access them directly.


Am 17.08.2011 20:41, schrieb Xueming Shen:
> Ulf,
>
> I tried to be conservative to not touch the source code, just in case I might be forced
> to put them back again:-)
Then we could provide my small sun.io-wrapper, maybe as additional resource like JDK DST Timezone 
Update Tool. ;-)

-Ulf


> But since I have already removed the whole sun.io source
> branch, it's reasonable to do the complete cleanup up as well. The webrev has been
> updated accordingly (to remove those comments and methods)
>
> http://cr.openjdk.java.net/~sherman/6237353/webrev 
> <http://cr.openjdk.java.net/%7Esherman/6237353/webrev/>
>
> Thanks!
>
> -Sherman
>


From xueming.shen at oracle.com  Wed Aug 17 22:23:23 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 17 Aug 2011 15:23:23 -0700
Subject: Request for review 6237353: Remove sun.io package from j2se binary
In-Reply-To: <4E4C3BE4.6000403@gmx.de>
References: <4E4B7EDE.6040006@oracle.com>
	<4E4BB603.4050604@gmx.de>	<4E4C0B75.9070004@oracle.com>
	<4E4C3BE4.6000403@gmx.de>
Message-ID: <4E4C3F5B.80809@oracle.com>

Those charsets at sun.awt.motif are using some of them.

-Sherman

On 8/17/2011 3:08 PM, Ulf Zibis wrote:
> Sherman,
>
> thanks.
> There are some more public sun.io-bridge-methods which could be saved 
> or at least made package-private, e.g.:
> - EUC_TW.Encoder.toEUC()
> - EUC_TW.Decoder.toUnicode()
> - DoubleByte.Encoder.encodeChar()
> - DoubleByte.Decoder.decodeSingle()
> - DoubleByte.Decoder.decodeDouble()
> - DoubleByteEncoder.encodeSingle()
> - DoubleByteEncoder.encodeDouble()
> - etc.
>
> I think, all sun.nio.cs charsets have been made public for the sun.io 
> access. Why don't make them package-private? Nobody from outside 
> should access them directly.
>
>
> Am 17.08.2011 20:41, schrieb Xueming Shen:
>> Ulf,
>>
>> I tried to be conservative to not touch the source code, just in case 
>> I might be forced
>> to put them back again:-)
> Then we could provide my small sun.io-wrapper, maybe as additional 
> resource like JDK DST Timezone Update Tool. ;-)
>
> -Ulf
>
>
>> But since I have already removed the whole sun.io source
>> branch, it's reasonable to do the complete cleanup up as well. The 
>> webrev has been
>> updated accordingly (to remove those comments and methods)
>>
>> http://cr.openjdk.java.net/~sherman/6237353/webrev 
>> <http://cr.openjdk.java.net/%7Esherman/6237353/webrev/>
>>
>> Thanks!
>>
>> -Sherman
>>


From sebastian.sickelmann at gmx.de  Wed Aug 17 22:45:48 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Thu, 18 Aug 2011 00:45:48 +0200
Subject: Request Review for small change to remove 2 warnings in rmic
Message-ID: <4E4C449C.7050707@gmx.de>

Hi while searching if i created warnings with an change i have seen that 
there are 2 warnings in rmic that are easy to remove.

Please review this hg export (no webrev unfortunately, because my 
free-file-host-provider is out of service :-( )

# HG changeset patch
# User Sebastian
# Date 1313620914 -7200
# Node ID 1dd60cdcf67183afd12323258307f2d78bdd3979
# Parent  07ad163881707c67a0365090ff2192878d266542
Removed some compile-warnings in rmic

diff -r 07ad16388170 -r 1dd60cdcf671 
src/share/classes/sun/rmi/rmic/Main.java
--- a/src/share/classes/sun/rmi/rmic/Main.java    Wed Aug 17 14:18:30 
2011 -0700
+++ b/src/share/classes/sun/rmi/rmic/Main.java    Thu Aug 18 00:41:54 
2011 +0200
@@ -879,6 +879,6 @@
          args[1] = (arg1 != null ? arg1.toString() : "null");
          args[2] = (arg2 != null ? arg2.toString() : "null");

-        return java.text.MessageFormat.format(format, args);
+        return java.text.MessageFormat.format(format, (Object[]) args);
      }
  }
diff -r 07ad16388170 -r 1dd60cdcf671 
src/share/classes/sun/rmi/rmic/newrmic/Resources.java
--- a/src/share/classes/sun/rmi/rmic/newrmic/Resources.java    Wed Aug 
17 14:18:30 2011 -0700
+++ b/src/share/classes/sun/rmi/rmic/newrmic/Resources.java    Thu Aug 
18 00:41:54 2011 +0200
@@ -69,7 +69,7 @@
              format = "missing resource key: key = \"" + key + "\", " +
                  "arguments = \"{0}\", \"{1}\", \"{2}\"";
          }
-        return MessageFormat.format(format, args);
+        return MessageFormat.format(format, (Object[]) args);
      }

      /**


From mandy.chung at oracle.com  Wed Aug 17 22:52:25 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 17 Aug 2011 15:52:25 -0700
Subject: Request Review for small change to remove 2 warnings in rmic
In-Reply-To: <4E4C449C.7050707@gmx.de>
References: <4E4C449C.7050707@gmx.de>
Message-ID: <4E4C4629.7060101@oracle.com>

Thumbs up from me.   Are you going to include this change with another 
CR that you have a fix to be pushed?

Mandy

On 8/17/11 3:45 PM, Sebastian Sickelmann wrote:
> Hi while searching if i created warnings with an change i have seen 
> that there are 2 warnings in rmic that are easy to remove.
>
> Please review this hg export (no webrev unfortunately, because my 
> free-file-host-provider is out of service :-( )
>
> # HG changeset patch
> # User Sebastian
> # Date 1313620914 -7200
> # Node ID 1dd60cdcf67183afd12323258307f2d78bdd3979
> # Parent  07ad163881707c67a0365090ff2192878d266542
> Removed some compile-warnings in rmic
>
> diff -r 07ad16388170 -r 1dd60cdcf671 
> src/share/classes/sun/rmi/rmic/Main.java
> --- a/src/share/classes/sun/rmi/rmic/Main.java    Wed Aug 17 14:18:30 
> 2011 -0700
> +++ b/src/share/classes/sun/rmi/rmic/Main.java    Thu Aug 18 00:41:54 
> 2011 +0200
> @@ -879,6 +879,6 @@
>          args[1] = (arg1 != null ? arg1.toString() : "null");
>          args[2] = (arg2 != null ? arg2.toString() : "null");
>
> -        return java.text.MessageFormat.format(format, args);
> +        return java.text.MessageFormat.format(format, (Object[]) args);
>      }
>  }
> diff -r 07ad16388170 -r 1dd60cdcf671 
> src/share/classes/sun/rmi/rmic/newrmic/Resources.java
> --- a/src/share/classes/sun/rmi/rmic/newrmic/Resources.java    Wed Aug 
> 17 14:18:30 2011 -0700
> +++ b/src/share/classes/sun/rmi/rmic/newrmic/Resources.java    Thu Aug 
> 18 00:41:54 2011 +0200
> @@ -69,7 +69,7 @@
>              format = "missing resource key: key = \"" + key + "\", " +
>                  "arguments = \"{0}\", \"{1}\", \"{2}\"";
>          }
> -        return MessageFormat.format(format, args);
> +        return MessageFormat.format(format, (Object[]) args);
>      }
>
>      /**



From sebastian.sickelmann at gmx.de  Thu Aug 18 04:46:08 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Thu, 18 Aug 2011 06:46:08 +0200
Subject: Request Review for small change to remove 2 warnings in rmic
In-Reply-To: <4E4C4629.7060101@oracle.com>
References: <4E4C449C.7050707@gmx.de> <4E4C4629.7060101@oracle.com>
Message-ID: <4E4C9910.2070808@gmx.de>

Am 18.08.2011 00:52, schrieb Mandy Chung:
> Thumbs up from me.   Are you going to include this change with another 
> CR that you have a fix to be pushed?
>
I have some other improved that are reviewed by Joe actually. But there 
are on a completly other topic and it
should take some days to have all prepared for the push.

Is the CR to small, or what is the reason for your question?

I think i can fix 2 other warnings of the same kind and fix them together.
src/solaris/classes/sun/awt/X11/XIconWindow.java:95: warning: 
non-varargs call of varargs method with inexact argument type for last 
parameter;
src/share/classes/sun/tools/serialver/SerialVer.java:462: warning: 
non-varargs call of varargs method with inexact argument type for last 
parameter;

I send in a combined webrev in shortly.
> Mandy
>
> On 8/17/11 3:45 PM, Sebastian Sickelmann wrote:
>> Hi while searching if i created warnings with an change i have seen 
>> that there are 2 warnings in rmic that are easy to remove.
>>
>> Please review this hg export (no webrev unfortunately, because my 
>> free-file-host-provider is out of service :-( )
>>
>> # HG changeset patch
>> # User Sebastian
>> # Date 1313620914 -7200
>> # Node ID 1dd60cdcf67183afd12323258307f2d78bdd3979
>> # Parent  07ad163881707c67a0365090ff2192878d266542
>> Removed some compile-warnings in rmic
>>
>> diff -r 07ad16388170 -r 1dd60cdcf671 
>> src/share/classes/sun/rmi/rmic/Main.java
>> --- a/src/share/classes/sun/rmi/rmic/Main.java    Wed Aug 17 14:18:30 
>> 2011 -0700
>> +++ b/src/share/classes/sun/rmi/rmic/Main.java    Thu Aug 18 00:41:54 
>> 2011 +0200
>> @@ -879,6 +879,6 @@
>>          args[1] = (arg1 != null ? arg1.toString() : "null");
>>          args[2] = (arg2 != null ? arg2.toString() : "null");
>>
>> -        return java.text.MessageFormat.format(format, args);
>> +        return java.text.MessageFormat.format(format, (Object[]) args);
>>      }
>>  }
>> diff -r 07ad16388170 -r 1dd60cdcf671 
>> src/share/classes/sun/rmi/rmic/newrmic/Resources.java
>> --- a/src/share/classes/sun/rmi/rmic/newrmic/Resources.java    Wed 
>> Aug 17 14:18:30 2011 -0700
>> +++ b/src/share/classes/sun/rmi/rmic/newrmic/Resources.java    Thu 
>> Aug 18 00:41:54 2011 +0200
>> @@ -69,7 +69,7 @@
>>              format = "missing resource key: key = \"" + key + "\", " +
>>                  "arguments = \"{0}\", \"{1}\", \"{2}\"";
>>          }
>> -        return MessageFormat.format(format, args);
>> +        return MessageFormat.format(format, (Object[]) args);
>>      }
>>
>>      /**
>



From sebastian.sickelmann at gmx.de  Thu Aug 18 04:54:39 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Thu, 18 Aug 2011 06:54:39 +0200
Subject: Request Review for small change to remove 2 warnings in rmic
In-Reply-To: <4E4C9910.2070808@gmx.de>
References: <4E4C449C.7050707@gmx.de> <4E4C4629.7060101@oracle.com>
	<4E4C9910.2070808@gmx.de>
Message-ID: <4E4C9B0F.2030604@gmx.de>

Am 18.08.2011 06:46, schrieb Sebastian Sickelmann:
> Am 18.08.2011 00:52, schrieb Mandy Chung:
>> Thumbs up from me.   Are you going to include this change with 
>> another CR that you have a fix to be pushed?
>>
> I have some other improved that are reviewed by Joe actually. But 
> there are on a completly other topic and it
> should take some days to have all prepared for the push.
>
> Is the CR to small, or what is the reason for your question?
>
> I think i can fix 2 other warnings of the same kind and fix them 
> together.
> src/solaris/classes/sun/awt/X11/XIconWindow.java:95: warning: 
> non-varargs call of varargs method with inexact argument type for last 
> parameter;
> src/share/classes/sun/tools/serialver/SerialVer.java:462: warning: 
> non-varargs call of varargs method with inexact argument type for last 
> parameter;
>
> I send in a combined webrev in shortly.
>> Mandy
>>
>> On 8/17/11 3:45 PM, Sebastian Sickelmann wrote:
>>> Hi while searching if i created warnings with an change i have seen 
>>> that there are 2 warnings in rmic that are easy to remove.
>>>
>>> Please review this hg export (no webrev unfortunately, because my 
>>> free-file-host-provider is out of service :-( )
>>>
>>> # HG changeset patch
>>> # User Sebastian
>>> # Date 1313620914 -7200
>>> # Node ID 1dd60cdcf67183afd12323258307f2d78bdd3979
>>> # Parent  07ad163881707c67a0365090ff2192878d266542
>>> Removed some compile-warnings in rmic
>>>
>>> diff -r 07ad16388170 -r 1dd60cdcf671 
>>> src/share/classes/sun/rmi/rmic/Main.java
>>> --- a/src/share/classes/sun/rmi/rmic/Main.java    Wed Aug 17 
>>> 14:18:30 2011 -0700
>>> +++ b/src/share/classes/sun/rmi/rmic/Main.java    Thu Aug 18 
>>> 00:41:54 2011 +0200
>>> @@ -879,6 +879,6 @@
>>>          args[1] = (arg1 != null ? arg1.toString() : "null");
>>>          args[2] = (arg2 != null ? arg2.toString() : "null");
>>>
>>> -        return java.text.MessageFormat.format(format, args);
>>> +        return java.text.MessageFormat.format(format, (Object[]) 
>>> args);
>>>      }
>>>  }
>>> diff -r 07ad16388170 -r 1dd60cdcf671 
>>> src/share/classes/sun/rmi/rmic/newrmic/Resources.java
>>> --- a/src/share/classes/sun/rmi/rmic/newrmic/Resources.java    Wed 
>>> Aug 17 14:18:30 2011 -0700
>>> +++ b/src/share/classes/sun/rmi/rmic/newrmic/Resources.java    Thu 
>>> Aug 18 00:41:54 2011 +0200
>>> @@ -69,7 +69,7 @@
>>>              format = "missing resource key: key = \"" + key + "\", " +
>>>                  "arguments = \"{0}\", \"{1}\", \"{2}\"";
>>>          }
>>> -        return MessageFormat.format(format, args);
>>> +        return MessageFormat.format(format, (Object[]) args);
>>>      }
>>>
>>>      /**
>>
>
My filehoster is working again.
Here is the combined webrev:

http://oss-patches.24.eu/openjdk8/Varargs_Warning/

-- Sebastian


From sebastian.sickelmann at gmx.de  Thu Aug 18 05:01:00 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Thu, 18 Aug 2011 07:01:00 +0200
Subject: Request for Review: Chain more Exceptions (RuntimeException)
Message-ID: <4E4C9C8C.90503@gmx.de>

Hi,

i have created a fix for fixing Exception-Chains in case of an rethrown 
RuntimeException.

I am not quite sure if this is inside the scope of what i 
discussed[0][1] with Joe. But it is
fixed in the same manner as the patches there.

http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_07ad16388170/

Someone who wants to review / sponsor this?


-- Sebastian

[0] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007399.html




From lana.steuck at oracle.com  Thu Aug 18 06:07:56 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Thu, 18 Aug 2011 06:07:56 +0000
Subject: hg: jdk8/tl/jdk: 7 new changesets
Message-ID: <20110818060904.5F79447CC5@hg.openjdk.java.net>

Changeset: 34fdcdb70d20
Author:    rupashka
Date:      2011-07-28 18:13 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34fdcdb70d20

6995769: occasion NPE thrown from SwingUtilities.computeIntersection()
Reviewed-by: alexp

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

Changeset: 86098b3f7789
Author:    rupashka
Date:      2011-07-28 18:24 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86098b3f7789

7071166: LayoutStyle.getPreferredGap()  - IAE is expected but not thrown
Reviewed-by: peterz

! src/share/classes/sun/swing/DefaultLayoutStyle.java
+ test/javax/swing/GroupLayout/7071166/bug7071166.java

Changeset: 0ce1f0b21446
Author:    serb
Date:      2011-08-01 17:05 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ce1f0b21446

7068060: closed/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java failed on windows
Reviewed-by: art, dcherepanov

+ test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java

Changeset: 854e74d8d956
Author:    rupashka
Date:      2011-08-03 16:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/854e74d8d956

7072328: Sun URL in the MetalLookAndFeel.getLayoutStyle() specification should be replaced with Oracle one
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java

Changeset: 634c2a492cf5
Author:    lana
Date:      2011-08-05 15:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/634c2a492cf5

Merge

- src/share/classes/java/lang/invoke/FilterGeneric.java
- src/share/classes/java/lang/invoke/FilterOneArgument.java
- src/share/classes/java/lang/invoke/FromGeneric.java
- src/share/classes/java/lang/invoke/SpreadGeneric.java
- src/share/classes/java/lang/invoke/ToGeneric.java

Changeset: 2cdbbc4a6359
Author:    lana
Date:      2011-08-09 17:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cdbbc4a6359

Merge

- src/share/native/java/lang/fdlibm/src/e_acosh.c
- src/share/native/java/lang/fdlibm/src/e_gamma.c
- src/share/native/java/lang/fdlibm/src/e_gamma_r.c
- src/share/native/java/lang/fdlibm/src/e_j0.c
- src/share/native/java/lang/fdlibm/src/e_j1.c
- src/share/native/java/lang/fdlibm/src/e_jn.c
- src/share/native/java/lang/fdlibm/src/e_lgamma.c
- src/share/native/java/lang/fdlibm/src/e_lgamma_r.c
- src/share/native/java/lang/fdlibm/src/s_asinh.c
- src/share/native/java/lang/fdlibm/src/s_erf.c
- src/share/native/java/lang/fdlibm/src/w_acosh.c
- src/share/native/java/lang/fdlibm/src/w_gamma.c
- src/share/native/java/lang/fdlibm/src/w_gamma_r.c
- src/share/native/java/lang/fdlibm/src/w_j0.c
- src/share/native/java/lang/fdlibm/src/w_j1.c
- src/share/native/java/lang/fdlibm/src/w_jn.c
- src/share/native/java/lang/fdlibm/src/w_lgamma.c
- src/share/native/java/lang/fdlibm/src/w_lgamma_r.c

Changeset: 7d8927b76d68
Author:    lana
Date:      2011-08-17 22:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d8927b76d68

Merge




From littlee at linux.vnet.ibm.com  Thu Aug 18 09:04:20 2011
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Thu, 18 Aug 2011 17:04:20 +0800
Subject: Two heads after pull of tl/jdk and jdk8/jdk
In-Reply-To: <4E4C1533.70500@gmx.de>
References: <4E4C1533.70500@gmx.de>
Message-ID: <4E4CD594.4010501@linux.vnet.ibm.com>

On 08/18/2011 03:23 AM, Sebastian Sickelmann wrote:
> Hi,
>
> after pulling from both sources
> http://hg.openjdk.java.net/jdk8/tl/jdk/
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/
>
> i see that i got two heads.
>
> Is it because in all the other repositorys jdk8/*/jdk there are also 
> many changes to the jdk-sub-repo?
> Should i worry about these changes and merge it? Or is there an "Merge 
> Inspector" in the jdk8/tl/* who does the job.
> I think creating a webrev for such a change isn't worth it. And we 
> non-commiters haven't any change to merge those for the public, isn't it?
>
> -- Sebastian
Hi Sebastian,
http://hg.openjdk.java.net/jdk8/tl is for "tools and language"
http://hg.openjdk.java.net/jdk8/jdk8 is for publish openjdk8.

Changes in the "tools and language" will be merged in the "publish openjdk8"


-- 
Yours Charles



From weijun.wang at oracle.com  Thu Aug 18 10:00:29 2011
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 18 Aug 2011 18:00:29 +0800
Subject: Two heads after pull of tl/jdk and jdk8/jdk
In-Reply-To: <4E4CD594.4010501@linux.vnet.ibm.com>
References: <4E4C1533.70500@gmx.de> <4E4CD594.4010501@linux.vnet.ibm.com>
Message-ID: <4E4CE2BD.1060506@oracle.com>



On 08/18/2011 05:04 PM, Charles Lee wrote:
> On 08/18/2011 03:23 AM, Sebastian Sickelmann wrote:
>> Hi,
>>
>> after pulling from both sources
>> http://hg.openjdk.java.net/jdk8/tl/jdk/
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/
>>
>> i see that i got two heads.
>>
>> Is it because in all the other repositorys jdk8/*/jdk there are also
>> many changes to the jdk-sub-repo?

Different teams work on their own sub repos, and an integrator syncs 
them with the main repo when a jdk build is to be published (promoted). 
Multiple heads might appear during the integration and the integrator 
does the merges.

>> Should i worry about these changes and merge it? Or is there an "Merge
>> Inspector" in the jdk8/tl/* who does the job.
>> I think creating a webrev for such a change isn't worth it. And we
>> non-commiters haven't any change to merge those for the public, isn't it?

You should clone from a single repo, either a sub repo, or the main one, 
depending on what you are interested in.

A commiter always clones a sub repo of his own team, because normal 
changesets (not a merge) can only be pushed into a sub repo (thru its gate).

-Max


>>
>> -- Sebastian
> Hi Sebastian,
> http://hg.openjdk.java.net/jdk8/tl is for "tools and language"
> http://hg.openjdk.java.net/jdk8/jdk8 is for publish openjdk8.
>
> Changes in the "tools and language" will be merged in the "publish
> openjdk8"
>
>


From Alan.Bateman at oracle.com  Thu Aug 18 14:11:13 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Aug 2011 15:11:13 +0100
Subject: Request Review for small change to remove 2 warnings in rmic
In-Reply-To: <4E4C4629.7060101@oracle.com>
References: <4E4C449C.7050707@gmx.de> <4E4C4629.7060101@oracle.com>
Message-ID: <4E4D1D81.4090209@oracle.com>

Mandy Chung wrote:
> Thumbs up from me.   Are you going to include this change with another 
> CR that you have a fix to be pushed?
>
> Mandy
I think it's best to separate this fix and so I've created the following 
to track it:
  7080622: Remove varargs warnings from rmic

-Alan.



From sebastian.sickelmann at gmx.de  Thu Aug 18 14:48:11 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Thu, 18 Aug 2011 16:48:11 +0200
Subject: Fwd: Re: Request Review for small change to remove 2 warnings in rmic
Message-ID: <8eedf9bc-f808-4008-81c6-4c20bffffa55@email.android.com>

Sorry. Does't Poster it to the list


-------- Original-Nachricht --------
Betreff: Re: Request Review for small change to remove 2 warnings in rmic
Von: Sebastian Sickelmann <sebastian.sickelmann at gmx.de>
An: Alan Bateman <Alan.Bateman at oracle.com>
CC: 

I updated my Patch so that it handles all varargs warnings in jdk subrepo.  http://oss-patches.24.eu/openjdk8/Varargs_Warning

I hope that is ok because the bug Name names only rmic

--Sebastian 


Alan Bateman <Alan.Bateman at oracle.com> schrieb:

>Mandy Chung wrote:
>> Thumbs up from me.   Are you going to include this change with another 
>> CR that you have a fix to be pushed?
>>
>> Mandy
>I think it's best to separate this fix and so I've created the following 
>to track it:
>  7080622: Remove varargs warnings from rmic
>
>-Alan.
>

-- 
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
-- 
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.


From mandy.chung at oracle.com  Thu Aug 18 14:57:45 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 Aug 2011 07:57:45 -0700
Subject: Request Review for small change to remove 2 warnings in rmic
In-Reply-To: <4E4C9910.2070808@gmx.de>
References: <4E4C449C.7050707@gmx.de> <4E4C4629.7060101@oracle.com>
	<4E4C9910.2070808@gmx.de>
Message-ID: <4E4D2869.40402@oracle.com>

On 8/17/11 9:46 PM, Sebastian Sickelmann wrote:
>> Are you going to include this change with another CR that you have a 
>> fix to be pushed? 
>
> Is the CR to small, or what is the reason for your question? 

I was just curious which CR this change is going into since it's not 
mentioned in your email.   I'm fine with this change going with another 
warning cleanup CR or a new one.

Alan has created a separate CR for the rmic change:
    7080622: Remove varargs warnings from rmic

Mandy


From alan.bateman at oracle.com  Thu Aug 18 15:54:11 2011
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 18 Aug 2011 15:54:11 +0000
Subject: hg: jdk8/tl/jdk: 7015589: (spec) BufferedWriter.close leaves stream
	open if close of underlying Writer fails
Message-ID: <20110818155435.84FEE47D09@hg.openjdk.java.net>

Changeset: 759aa847dcaf
Author:    alanb
Date:      2011-08-18 16:47 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/759aa847dcaf

7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails
Reviewed-by: forax, mduigou

! src/share/classes/java/io/BufferedReader.java
! src/share/classes/java/io/BufferedWriter.java
! src/share/classes/java/io/Closeable.java
! src/share/classes/java/io/FilterOutputStream.java
! src/share/classes/java/lang/AutoCloseable.java
+ test/java/io/etc/FailingFlushAndClose.java
! test/java/lang/ProcessBuilder/Basic.java



From ahughes at redhat.com  Thu Aug 18 16:43:20 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 18 Aug 2011 17:43:20 +0100
Subject: Request for Review: Chain more Exceptions (RuntimeException)
In-Reply-To: <4E4C9C8C.90503@gmx.de>
References: <4E4C9C8C.90503@gmx.de>
Message-ID: <20110818164320.GJ9583@rivendell.middle-earth.co.uk>

On 07:01 Thu 18 Aug     , Sebastian Sickelmann wrote:
> Hi,
> 
> i have created a fix for fixing Exception-Chains in case of an rethrown 
> RuntimeException.
> 
> I am not quite sure if this is inside the scope of what i 
> discussed[0][1] with Joe. But it is
> fixed in the same manner as the patches there.
> 
> http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_07ad16388170/
> 
> Someone who wants to review / sponsor this?
> 

Looks good to me.  Nice cleanup.

> 
> -- Sebastian
> 
> [0] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007399.html
> 
> 

-- 
Andrew :)

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

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From Alan.Bateman at oracle.com  Thu Aug 18 20:14:12 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Aug 2011 21:14:12 +0100
Subject: Request for Review: Chain more Exceptions (RuntimeException)
In-Reply-To: <4E4C9C8C.90503@gmx.de>
References: <4E4C9C8C.90503@gmx.de>
Message-ID: <4E4D7294.60807@oracle.com>

Sebastian Sickelmann wrote:
> Hi,
>
> i have created a fix for fixing Exception-Chains in case of an 
> rethrown RuntimeException.
>
> I am not quite sure if this is inside the scope of what i 
> discussed[0][1] with Joe. But it is
> fixed in the same manner as the patches there.
>
> http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_07ad16388170/ 
>
>
> Someone who wants to review / sponsor this?
>
I agree with Andrew that this is good clean-up.

I think the changes to 
src/share/classes/javax/xml/crypto/NoSuchMechanismException.java need 
closer examination. Removing the 3 methods that it overloads should be 
okay. Adding @since 1.8 to the existing constructor is not okay Removing 
the cause field given that it's serializable, I need to remind myself 
how this works.

A minor nit but I notice in many places where you've introduced 
multicatch that you put the vertical bar at the beginning of the next 
line whereas I think we've mostly been putting it on the right. In 
src/share/classes/javax/management/relation/RelationService.java I see 
you've got both. I don't know if coding conventions have been 
established on this.

-Alan.


From joe.darcy at oracle.com  Thu Aug 18 22:55:04 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 18 Aug 2011 15:55:04 -0700
Subject: Request for Review: Chain more Exceptions (RuntimeException)
In-Reply-To: <4E4D7294.60807@oracle.com>
References: <4E4C9C8C.90503@gmx.de> <4E4D7294.60807@oracle.com>
Message-ID: <4E4D9848.5000500@oracle.com>



On 8/18/2011 1:14 PM, Alan Bateman wrote:
> Sebastian Sickelmann wrote:
>> Hi,
>>
>> i have created a fix for fixing Exception-Chains in case of an 
>> rethrown RuntimeException.
>>
>> I am not quite sure if this is inside the scope of what i 
>> discussed[0][1] with Joe. But it is
>> fixed in the same manner as the patches there.
>>
>> http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_07ad16388170/ 
>>
>>
>> Someone who wants to review / sponsor this?
>>
> I agree with Andrew that this is good clean-up.
>
> I think the changes to 
> src/share/classes/javax/xml/crypto/NoSuchMechanismException.java need 
> closer examination. Removing the 3 methods that it overloads should be 
> okay. Adding @since 1.8 to the existing constructor is not okay 
> Removing the cause field given that it's serializable, I need to 
> remind myself how this works.
>
> A minor nit but I notice in many places where you've introduced 
> multicatch that you put the vertical bar at the beginning of the next 
> line whereas I think we've mostly been putting it on the right. In 
> src/share/classes/javax/management/relation/RelationService.java I see 
> you've got both. I don't know if coding conventions have been 
> established on this.
>

For multi-catch, I would actually recommend having the multiple 
exceptions listed on a single line, subject go general line length concerns.

Personally I find

    catch(FirstException | SecondException e) {...}

to be more readable than

    catch(FirstException
             | Second Exception) {...}

I agree with Alan that if the sequence of exception types is going to be 
split across lines, it is better to be split as

    catch(First Exception |
             SecondException e)

rather than having the "|" start the subsequent line.

Cheers,

-Joe


From mike.duigou at oracle.com  Thu Aug 18 23:48:50 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 18 Aug 2011 16:48:50 -0700
Subject: Request for Review: Chain more Exceptions (RuntimeException)
In-Reply-To: <4E4C9C8C.90503@gmx.de>
References: <4E4C9C8C.90503@gmx.de>
Message-ID: <FC5612C1-10D4-4F37-BD1D-8456BCF967D7@oracle.com>

I will echo Joe's comments about putting the "|" at the end of the line rather than at the beginning of the next line.

Not a comment on your patch but some of the use of raw RuntimeException is rather weak. I saw a few cases where IllegalStateException or UnsupportedOperationException would be a better choice

src/share/classes/javax/swing/text/html/HTMLEditorKit.java:

- I don't think the "+ e" is necessary.

src/share/classes/java/awt/dnd/DragSource.java:

- I don;t think the "+ e.getMessage()" is necessary.

src/share/classes/java/beans/Encoder.java:

- Same for " + exp.toString()"

src/share/classes/sun/security/provider/certpath/URICertStore.java:
src/share/classes/sun/security/ssl/CipherBox.java:
src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignerOutputStream.java:
(and perhaps elsewhere)

- You might want to use (e.getMessage(), e) variant rather than just the (Throwable) constructor if previously the message was initialized.

src/share/classes/javax/xml/crypto/NoSuchMechanismException.java:

- @since 1.8 seems incorrect.

Very good cleanup on the rest!

Great work!

Mike

On Aug 17 2011, at 22:01 , Sebastian Sickelmann wrote:

> Hi,
> 
> i have created a fix for fixing Exception-Chains in case of an rethrown RuntimeException.
> 
> I am not quite sure if this is inside the scope of what i discussed[0][1] with Joe. But it is
> fixed in the same manner as the patches there.
> 
> http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_07ad16388170/
> 
> Someone who wants to review / sponsor this?
> 
> 
> -- Sebastian
> 
> [0] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007399.html
> 
> 



From sebastian.sickelmann at gmx.de  Fri Aug 19 04:50:00 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 19 Aug 2011 06:50:00 +0200
Subject: Request Review for small change to remove 2 warnings in rmic
In-Reply-To: <4E4D1D81.4090209@oracle.com>
References: <4E4C449C.7050707@gmx.de> <4E4C4629.7060101@oracle.com>
	<4E4D1D81.4090209@oracle.com>
Message-ID: <4E4DEB78.5050808@gmx.de>


Am 18.08.2011 16:11, schrieb Alan Bateman:
> Mandy Chung wrote:
>> Thumbs up from me.   Are you going to include this change with 
>> another CR that you have a fix to be pushed?
>>
>> Mandy
> I think it's best to separate this fix and so I've created the 
> following to track it:
>  7080622: Remove varargs warnings from rmic

I updated my Patch so that it handles all varargs warnings in jdk subrepo.http://oss-patches.24.eu/openjdk8/Varargs_Warning

I hope that is ok because the bug Name names only rmic

--Sebastian

>
> -Alan.
>



From weijun.wang at oracle.com  Fri Aug 19 05:43:33 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 19 Aug 2011 05:43:33 +0000
Subject: hg: jdk8/tl/jdk: 7043847: NTML impl of SaslServer throws
	UnsupportedOperationException from (un)wrap method; ...
Message-ID: <20110819054352.194BE47DBF@hg.openjdk.java.net>

Changeset: 55952703809f
Author:    weijun
Date:      2011-08-19 13:42 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55952703809f

7043847: NTML impl of SaslServer throws UnsupportedOperationException from (un)wrap method
7043860: NTML impl of SaslServer doesn't throw ISE from getAuthorizationID() method
7043882: NTML impl of SaslServer doesn't throw ISE from getNegotiatedProperty() method
7043938: NTML impl of SaslClientFactory throws NPE instead of SaslException
7043959: NTML impl of SaslClientFactory throws NPE for null CallBackHandler instance
Reviewed-by: vinnie

! src/share/classes/com/sun/security/ntlm/Client.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/sasl/ntlm/FactoryImpl.java
! src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java
! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
+ test/com/sun/security/sasl/ntlm/Conformance.java



From chris.hegarty at oracle.com  Fri Aug 19 09:56:45 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 19 Aug 2011 09:56:45 +0000
Subject: hg: jdk8/tl/jdk: 7025938: Add bitmap mime type to
	content-types.properties
Message-ID: <20110819095709.84ABF47DDC@hg.openjdk.java.net>

Changeset: 46b53f80ab0a
Author:    chegar
Date:      2011-08-19 10:55 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46b53f80ab0a

7025938: Add bitmap mime type to content-types.properties
Reviewed-by: chegar, alanb, michaelm
Contributed-by: lvjing at linux.vnet.ibm.com

! src/solaris/lib/content-types.properties
! src/windows/lib/content-types.properties



From Lance.Andersen at oracle.com  Fri Aug 19 12:25:14 2011
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 19 Aug 2011 08:25:14 -0400
Subject: Request for Review: Chain more Exceptions (RuntimeException)
In-Reply-To: <4E4D9848.5000500@oracle.com>
References: <4E4C9C8C.90503@gmx.de> <4E4D7294.60807@oracle.com>
	<4E4D9848.5000500@oracle.com>
Message-ID: <F61584C2-FB59-4B50-BE1C-D488B7056020@oracle.com>

Should we start a page on OpenJDK as a coding practice FAQ for code and tests? 


On Aug 18, 2011, at 6:55 PM, joe.darcy at oracle.com wrote:

> 
> 
> On 8/18/2011 1:14 PM, Alan Bateman wrote:
>> Sebastian Sickelmann wrote:
>>> Hi,
>>> 
>>> i have created a fix for fixing Exception-Chains in case of an rethrown RuntimeException.
>>> 
>>> I am not quite sure if this is inside the scope of what i discussed[0][1] with Joe. But it is
>>> fixed in the same manner as the patches there.
>>> 
>>> http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_07ad16388170/ 
>>> 
>>> Someone who wants to review / sponsor this?
>>> 
>> I agree with Andrew that this is good clean-up.
>> 
>> I think the changes to src/share/classes/javax/xml/crypto/NoSuchMechanismException.java need closer examination. Removing the 3 methods that it overloads should be okay. Adding @since 1.8 to the existing constructor is not okay Removing the cause field given that it's serializable, I need to remind myself how this works.
>> 
>> A minor nit but I notice in many places where you've introduced multicatch that you put the vertical bar at the beginning of the next line whereas I think we've mostly been putting it on the right. In src/share/classes/javax/management/relation/RelationService.java I see you've got both. I don't know if coding conventions have been established on this.
>> 
> 
> For multi-catch, I would actually recommend having the multiple exceptions listed on a single line, subject go general line length concerns.
> 
> Personally I find
> 
>   catch(FirstException | SecondException e) {...}
> 
> to be more readable than
> 
>   catch(FirstException
>            | Second Exception) {...}
> 
> I agree with Alan that if the sequence of exception types is going to be split across lines, it is better to be split as
> 
>   catch(First Exception |
>            SecondException e)
> 
> rather than having the "|" start the subsequent line.
> 
> Cheers,
> 
> -Joe


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



From sebastian.sickelmann at gmx.de  Fri Aug 19 14:05:24 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 19 Aug 2011 16:05:24 +0200
Subject: Request for Review: Chain more Exceptions (RuntimeException)
In-Reply-To: <4E4D7294.60807@oracle.com>
References: <4E4C9C8C.90503@gmx.de> <4E4D7294.60807@oracle.com>
Message-ID: <4E4E6DA4.5020209@gmx.de>

Am 18.08.2011 22:14, schrieb Alan Bateman:
> Sebastian Sickelmann wrote:
>> Hi,
>>
>> i have created a fix for fixing Exception-Chains in case of an 
>> rethrown RuntimeException.
>>
>> I am not quite sure if this is inside the scope of what i 
>> discussed[0][1] with Joe. But it is
>> fixed in the same manner as the patches there.
>>
>> http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_07ad16388170/ 
>>
>>
>> Someone who wants to review / sponsor this?
>>
> I agree with Andrew that this is good clean-up.
>
> I think the changes to 
> src/share/classes/javax/xml/crypto/NoSuchMechanismException.java need 
> closer examination. Removing the 3 methods that it overloads should be 
> okay. Adding @since 1.8 to the existing constructor is not okay 
> Removing the cause field given that it's serializable, I need to 
> remind myself how this works.
OK. We need to change the serialversion. But is this enough? May we 
break applications out there which serialized NoSuchMechanismExceptions 
or extended classes? I have compiled it with no explicit 
serialversionUID and started
./serialver javax.xml.crypto.NoSuchMechanismException
to show the generated serialversionUID. The new is 4170396067457259019L.

Was that the right way to do? Is there an easyier and faster way?
> A minor nit but I notice in many places where you've introduced 
> multicatch that you put the vertical bar at the beginning of the next 
> line whereas I think we've mostly been putting it on the right. In 
> src/share/classes/javax/management/relation/RelationService.java I see 
> you've got both. I don't know if coding conventions have been 
> established on this.
I have updated my webrev to fix serialversionUID and this code-style 
related as Joe suggests its in the other post.
The new webrev is:

http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_55952703809f/
>
> -Alan.
- Sebastian


From Alan.Bateman at oracle.com  Fri Aug 19 21:21:29 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Aug 2011 22:21:29 +0100
Subject: Request for Review: Chain more Exceptions (RuntimeException)
In-Reply-To: <4E4E6DA4.5020209@gmx.de>
References: <4E4C9C8C.90503@gmx.de> <4E4D7294.60807@oracle.com>
	<4E4E6DA4.5020209@gmx.de>
Message-ID: <4E4ED3D9.20000@oracle.com>

Sebastian Sickelmann wrote:
> OK. We need to change the serialversion. But is this enough? May we 
> break applications out there which serialized 
> NoSuchMechanismExceptions or extended classes? I have compiled it with 
> no explicit serialversionUID and started
> ./serialver javax.xml.crypto.NoSuchMechanismException
> to show the generated serialversionUID. The new is 4170396067457259019L.
>
I don't have time to send a detailed reply on this now but we can't 
change the serialVersionUID.

-Alan.


From sebastian.sickelmann at gmx.de  Fri Aug 19 21:39:18 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 19 Aug 2011 23:39:18 +0200
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161
	(reflect)	Exception	from	newInstance() not chained to cause.
In-Reply-To: <4E4C334E.4000508@gmx.de>
References: <4E48BA0E.6090702@gmx.de>	<4E4B1528.8060306@oracle.com>	<4E4BA9DD.20706@oracle.com>	<4E4BD37E.4060402@gmx.de>
	<4E4C334E.4000508@gmx.de>
Message-ID: <4E4ED806.8040900@gmx.de>

Am 17.08.2011 23:31, schrieb Sebastian Sickelmann:
> Ok. Rebased again.
>
> Now the webrevs are:
> http://oss-patches.24.eu/openjdk8/InternalError/part1/REBASED_ON_e59aad6ed600/ 
>
> http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_e59aad6ed600/ 
>
>
> Unfortunatly after i have uploaded the webrev(takes some time because 
> 128kbit/sek up is not the fastest)
> there was a change that i not rebased on.
> rev 2961329a6774
> 6237353: Remove sun.io package from j2se binary
>
> rebasing on this removes some files in sun.io package these files 
> should be ignored while reviewing my webrevs.
>
> If someone needs the rebased webrevs, let me know.
>
> -- Sebastian
I change the code style for multi-catch and fixed the bug that there 
were two Classes with <<<<< >>>>> lines in it.
Sorry for this failure with the <<<<<< >>>>>> lines

The new webrevs are here:

http://oss-patches.24.eu/openjdk8/InternalError/part1/REBASED_ON_46b53f80ab0a
http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_46b53f80ab0a

-- Sebastian


From sebastian.sickelmann at gmx.de  Fri Aug 19 21:39:23 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 19 Aug 2011 23:39:23 +0200
Subject: Warning without cleanbuild
Message-ID: <4E4ED80B.1090105@gmx.de>

Hi,

i sometimes get this warning if i don't execute a "make clean" before my 
"make all" in jdk repository.

/home/sebastian/deve/openjdk8/build/linux-i586/j2sdk-image/bin/javac 
-J-XX:ThreadStackSize=768 -J-XX:-PrintVMOptions 
-J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-client -J-Xmx512m 
-J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -Werror -Xlint:all 
-Xlint:-path -source 7 -target 7 -encoding ascii 
-Xbootclasspath:../../../build/linux-i586/classes -sourcepath 
../../../build/linux-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes 
-d ../../../build/linux-i586/classes 
@../../../build/linux-i586/tmp/java/java.nio/nio/.classes.list.filtered
../../../src/solaris/classes/sun/nio/ch/InheritedChannel.java:169: 
warning: [rawtypes] found raw type: Constructor
         Constructor ctr = 
Reflect.lookupConstructor("java.io.FileDescriptor",
         ^
   missing type arguments for generic class Constructor<T>
   where T is a type-variable:
     T extends Object declared in class Constructor
error: warnings found and -Werror specified


I uploaded the complete messages here.
http://oss-patches.24.eu/openjdk8/warningWithoutCleanBuild.log

last time it happend after i updated to 46b53f80ab0a of 
http://hg.openjdk.java.net/jdk8/tl/jdk/ and import the following 2 patches
http://oss-patches.24.eu/openjdk8/InternalError/part1/REBASED_ON_46b53f80ab0a/openjdk8-jdk-only.patch
http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_46b53f80ab0a/openjdk8-jdk-only.patch

you can maybe reproduce it with the following sequence:
hg update -r 46b53f80ab0a
make clean
make all
hg import --no-commit 
http://oss-patches.24.eu/openjdk8/InternalError/part1/REBASED_ON_46b53f80ab0a/openjdk8-jdk-only.patch
make all
hg import --force --no-commit 
http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_46b53f80ab0a/openjdk8-jdk-only.patch
make all  --->> Warning

Is it my Patch? But why?
or is there something in the buildscript that does not recompile 
dependencies correctly? may i expect that the build skript should handle 
that correctly?

-- Sebastian


From sebastian.sickelmann at gmx.de  Fri Aug 19 22:04:46 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Sat, 20 Aug 2011 00:04:46 +0200
Subject: Request for Review: Chain more Exceptions (RuntimeException)
In-Reply-To: <4E4ED3D9.20000@oracle.com>
References: <4E4C9C8C.90503@gmx.de> <4E4D7294.60807@oracle.com>
	<4E4E6DA4.5020209@gmx.de> <4E4ED3D9.20000@oracle.com>
Message-ID: <4E4EDDFE.6000504@gmx.de>

Am 19.08.2011 23:21, schrieb Alan Bateman:
> Sebastian Sickelmann wrote:
>> OK. We need to change the serialversion. But is this enough? May we 
>> break applications out there which serialized 
>> NoSuchMechanismExceptions or extended classes? I have compiled it 
>> with no explicit serialversionUID and started
>> ./serialver javax.xml.crypto.NoSuchMechanismException
>> to show the generated serialversionUID. The new is 4170396067457259019L.
>>
> I don't have time to send a detailed reply on this now but we can't 
> change the serialVersionUID.
>
> -Alan.
In normal closed Application Development you only ensure to mark the 
serialization incompatible and ready.
If you need to store objects most developers are doing custom 
xml-serialization (because peak brackets(translated from german term of 
abuse for <>) are so sexy :-(    ).

I think i know what you mean and how to solve it.
I think you mean somethink like this: 
http://download.oracle.com/javase/7/docs/platform/serialization/spec/version.html

I was always interessted into how to make serialized object realy 
versioned in a way designed for the jvm.
I will read this tomorrow and try to fix the changed 
NoSuchMechanismException.

If i am totally wrong with my guess, this is no problem , than i have 
read this specification and know more about a interessting topic. ;-)

-- Sebastian


From joe.darcy at oracle.com  Sat Aug 20 00:42:47 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Sat, 20 Aug 2011 00:42:47 +0000
Subject: hg: jdk8/tl/jdk: 4748706: typos in java.util.Observable documentation
Message-ID: <20110820004257.3A94E47E7A@hg.openjdk.java.net>

Changeset: 8018d541a7b2
Author:    darcy
Date:      2011-08-19 17:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8018d541a7b2

4748706: typos in java.util.Observable documentation
Reviewed-by: iris

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



From sebastian.sickelmann at gmx.de  Sun Aug 21 20:52:54 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Sun, 21 Aug 2011 22:52:54 +0200
Subject: Request for Review: Chain more Exceptions (RuntimeException)
In-Reply-To: <4E4EDDFE.6000504@gmx.de>
References: <4E4C9C8C.90503@gmx.de>
	<4E4D7294.60807@oracle.com>	<4E4E6DA4.5020209@gmx.de>
	<4E4ED3D9.20000@oracle.com> <4E4EDDFE.6000504@gmx.de>
Message-ID: <4E517026.3090607@gmx.de>

Am 20.08.2011 00:04, schrieb Sebastian Sickelmann:
> Am 19.08.2011 23:21, schrieb Alan Bateman:
>> Sebastian Sickelmann wrote:
>>> OK. We need to change the serialversion. But is this enough? May we 
>>> break applications out there which serialized 
>>> NoSuchMechanismExceptions or extended classes? I have compiled it 
>>> with no explicit serialversionUID and started
>>> ./serialver javax.xml.crypto.NoSuchMechanismException
>>> to show the generated serialversionUID. The new is 
>>> 4170396067457259019L.
>>>
>> I don't have time to send a detailed reply on this now but we can't 
>> change the serialVersionUID.
>>
>> -Alan.
> In normal closed Application Development you only ensure to mark the 
> serialization incompatible and ready.
> If you need to store objects most developers are doing custom 
> xml-serialization (because peak brackets(translated from german term 
> of abuse for <>) are so sexy :-(    ).
>
> I think i know what you mean and how to solve it.
> I think you mean somethink like this: 
> http://download.oracle.com/javase/7/docs/platform/serialization/spec/version.html
>
> I was always interessted into how to make serialized object realy 
> versioned in a way designed for the jvm.
> I will read this tomorrow and try to fix the changed 
> NoSuchMechanismException.
>
> If i am totally wrong with my guess, this is no problem , than i have 
> read this specification and know more about a interessting topic. ;-)
>
> -- Sebastian
Ok. I think i solved it.

But i think it would be good to keep this change here simple and remove 
NoSuchMechanismException from it. I uploaded a new webrev here without 
changes to NoSuchMechanismException:

http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_8018d541a7b2/

If i saw it right the old webrev was reviewed by Alan,Andrew,Joe and 
Mike. If nobody finds new failures, is there someone (maybe one of the 
4) that want to sponsor this one?

For the additional comments regarding "weak uses of 
RuntimeException-ctors" from Mike i want to create another Patch, 
because i think such changes are in another "change-category". Hope to 
be back on this soon.

I will start a new thread for NoSuchMechanismException because there are 
some testing problems to solve for it.

-- Sebastian


From sebastian.sickelmann at gmx.de  Sun Aug 21 21:16:11 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Sun, 21 Aug 2011 23:16:11 +0200
Subject: Review Request and Testing Question on: Remove unnecessary field
	and methods from NoSuchMechanismException
Message-ID: <4E51759B.9010507@gmx.de>

Hi,

while making some change for using exception-chaining on 
RuntimeException in more cases, i found that 
javax.xml.crypto.NoSuchMechnismException had a private cause field that 
isn't necessary since throwable can handle it. But just removing isn't 
that simple as Alan pointed out[1].
First of all i thought just changing the serialversionUID was the right 
solution, but Alan disagreed and i actually think that too. Unfortunatly 
Alan doen't had the time to explain it in detail, but i think that we 
must search for a solution that doen't break backward serialization 
compatability.

I created a webrev for my suggested change here:
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2/

The problem i have is that i think we should add some test for this. But 
got no real clue how to do it right. I tested it manually with the 
source here[2] and the files in here[3].

The files are created with an openjdk7 build(Unfortunatly i think with 
an quite old private build) and with an openjdk8(with my patches to 
NoSuchMechanismException). I tested it manually with my openjdk 7 and 8 
build and in both cases the serialized objects could be loaded correctly 
in all cases.

What is the best way to test this automatically. I thought about 
checking if the newly created openjdk8 serialization is binary equal to 
the jdk7 output, but it isn't because of some unavoidable changes (ex. 
jdk8 has the custom-serialization-bit)

-- Sebastian

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007462.html
[2] 
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/SeriallizeTest.java
[3] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/


From Alan.Bateman at oracle.com  Mon Aug 22 09:10:23 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Aug 2011 10:10:23 +0100
Subject: Warning without cleanbuild
In-Reply-To: <4E4ED80B.1090105@gmx.de>
References: <4E4ED80B.1090105@gmx.de>
Message-ID: <4E521CFF.9050304@oracle.com>

Sebastian Sickelmann wrote:
> Hi,
>
> i sometimes get this warning if i don't execute a "make clean" before 
> my "make all" in jdk repository.
>
> /home/sebastian/deve/openjdk8/build/linux-i586/j2sdk-image/bin/javac 
> -J-XX:ThreadStackSize=768 -J-XX:-PrintVMOptions 
> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-client 
> -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m 
> -Werror -Xlint:all -Xlint:-path -source 7 -target 7 -encoding ascii 
> -Xbootclasspath:../../../build/linux-i586/classes -sourcepath 
> ../../../build/linux-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes 
> -d ../../../build/linux-i586/classes 
> @../../../build/linux-i586/tmp/java/java.nio/nio/.classes.list.filtered
> ../../../src/solaris/classes/sun/nio/ch/InheritedChannel.java:169: 
> warning: [rawtypes] found raw type: Constructor
>         Constructor ctr = 
> Reflect.lookupConstructor("java.io.FileDescriptor",
>         ^
>   missing type arguments for generic class Constructor<T>
>   where T is a type-variable:
>     T extends Object declared in class Constructor
> error: warnings found and -Werror specified
We had an intern in Oracle this summer doing excellent work to address 
warnings that javac reports when compiling with -Xlint:all. The approach 
was to clean-up all warnings in an area and then change the make file 
for the area to add -Xlint:all -Werror so that we keep the area warning 
free. In this case it looks like one raw type in one source file was 
missed. Missed because it's compiled implicitly when doing a full build. 
However when compiled with make/java/nio/Makefile then it's compiling 
with -Xlint:all -Werror. I've created 7081796 to track this and we 
should have the fix in jdk8/tl/jdk today.

-Alan.





From Alan.Bateman at oracle.com  Mon Aug 22 09:56:03 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Aug 2011 10:56:03 +0100
Subject: Review Request and Testing Question on: Remove unnecessary field
	and methods from NoSuchMechanismException
In-Reply-To: <4E51759B.9010507@gmx.de>
References: <4E51759B.9010507@gmx.de>
Message-ID: <4E5227B3.4030909@oracle.com>

Sebastian Sickelmann wrote:
> Hi,
>
> while making some change for using exception-chaining on 
> RuntimeException in more cases, i found that 
> javax.xml.crypto.NoSuchMechnismException had a private cause field 
> that isn't necessary since throwable can handle it. But just removing 
> isn't that simple as Alan pointed out[1].
> First of all i thought just changing the serialversionUID was the 
> right solution, but Alan disagreed and i actually think that too. 
> Unfortunatly Alan doen't had the time to explain it in detail, but i 
> think that we must search for a solution that doen't break backward 
> serialization compatability.
As you've found then changing the serialVersionUID would is an 
incompatible change and removing a field is usually problematic too. I 
see you've got an updated webrev where you implement readObject and 
writeObject and that seems the right approach to me. I think it makes 
sense to split this one out from the other clean-ups and to that end 
I've created a separate bug for it:

7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException

As this exception class came via JSR-105 (XML-DSIG) then I think it's 
best to get it reviewed on security-dev as that is where the XML-DSIG 
code is maintained.

I see in your other mail that you asked about creating an automated 
test. I think the best you can do is save the serialized form of the 
exception with a build of openjdk6 or 7 and use that in the test that 
will go into jdk8's test directory. We try to avoid checking in binary 
files into the repository so having a byte[] in the test with the bytes 
is probably the only thing you can do.

-Alan.


From Alan.Bateman at oracle.com  Mon Aug 22 10:30:28 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Aug 2011 11:30:28 +0100
Subject: 7081813: ProblemList.txt updates (8/2011)
Message-ID: <4E522FC4.6040909@oracle.com>


It's whack-a-testmole time again and I'd like to update the ProblemList 
to add several tests that fail for various reasons. In some cases it's 
shell tests that need updating to work with Cygwin, in other cases it's 
tests that make assumptions that aren't run when run in Solaris zones, 
and in a few other cases it's tests that have timing issues. Bugs have 
been created for all these issues and the tests can be removed from the 
problem list when they are fixed. In addition there is one dangerous 
test that is disabled completely.

Thanks,
Alan.


diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -198,9 +198,15 @@ java/beans/XMLEncoder/6329581/Test632958
 # requires junit
 java/lang/invoke/InvokeDynamicPrintArgs.java                    generic-all
 
+# 7079093
+java/lang/instrument/ManifestTest.sh                           windows-all
+
 ############################################################################
 
 # jdk_management
+
+# 6944188
+java/lang/management/ThreadMXBean/ThreadStateTest.java         generic-all
 
 # 7067973
 java/lang/management/MemoryMXBean/CollectionUsageThreshold.java generic-all
@@ -368,6 +374,12 @@ 
com/sun/net/httpserver/Test9a.java                         ge
 # 7079145 java/net/ipv6tests/UdpTest.java hang at IPv6 only data exchange
 java/net/ipv6tests/UdpTest.java                                 linux-all
 
+# 7079012
+java/net/NetworkInterface/NetParamsTest.java                   solaris-all
+
+# 7081476
+java/net/InetSocketAddress/B6469803.java                       generic-all
+
 ############################################################################
 
 # jdk_io
@@ -375,12 +387,21 @@ java/net/ipv6tests/UdpTest.java        
 # 6962637
 java/io/File/MaxPathLength.java                                 windows-all
 
+# 6671616
+java/io/File/BlockIsDirectory.java                             solaris-all
+
+# 7076644
+java/io/File/Basic.java                                                
windows-all
+
 ############################################################################
 
 # jdk_nio
 
 # 6963118
 java/nio/channels/Selector/Wakeup.java                          windows-all
+
+# 7076700
+java/nio/channels/SocketChannel/AdaptSocket.java               generic-all
 
 ############################################################################
 
@@ -499,6 +520,9 @@ sun/security/ssl/sanity/interop/ClientJS
 # 7079203 sun/security/tools/keytool/printssl.sh fails on solaris with 
timeout
 sun/security/tools/keytool/printssl.sh                          solaris-all
 
+# 7081817
+sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java   
generic-all
+
 ############################################################################
 
 # jdk_swing (not using samevm)
diff --git a/test/java/io/IOException/LastErrorString.java 
b/test/java/io/IOException/LastErrorString.java
--- a/test/java/io/IOException/LastErrorString.java
+++ b/test/java/io/IOException/LastErrorString.java
@@ -23,6 +23,7 @@
 
 /* @test
    @bug 4167937
+   @ignore Test truncates system files when run as root, see 7042603
    @summary Test code paths that use the JVM_LastErrorString procedure
  */




From alan.bateman at oracle.com  Mon Aug 22 10:41:52 2011
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 22 Aug 2011 10:41:52 +0000
Subject: hg: jdk8/tl/jdk: 7081796: (ch) rawtype warning in
	sun.nio.ch.InheritedChannel
Message-ID: <20110822104215.F3F9F47FCD@hg.openjdk.java.net>

Changeset: b3425b50bc36
Author:    alanb
Date:      2011-08-22 11:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3425b50bc36

7081796: (ch) rawtype warning in sun.nio.ch.InheritedChannel
Reviewed-by: chegar

! src/solaris/classes/sun/nio/ch/InheritedChannel.java



From sebastian.sickelmann at gmx.de  Mon Aug 22 13:03:02 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Mon, 22 Aug 2011 15:03:02 +0200
Subject: 7081804: Remove cause field from
	javax.xml.crypto.NoSuchMechnismException
Message-ID: <4E525386.9000207@gmx.de>

Hi,

while making some change for using exception-chaining on 
RuntimeException in more cases, i found that 
javax.xml.crypto.NoSuchMechnismException had a private cause field that 
isn't necessary since throwable can handle it. But just removing isn't 
that simple as Alan pointed out[1].
First of all i thought just changing the serialversionUID was the right 
solution, but Alan disagreed and i actually think that too. Unfortunatly 
Alan doen't had the time to explain it in detail, but i think that we 
must search for a solution that doen't break backward serialization 
compatability.

I created a webrev for my suggested change here:
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2/ 


In a following post Alan writes that this should best be discussed here. 
What is the hg repository for patches in this mailinglist? I don't see 
any security-dev related repository for openjdk8 in 
http://hg.openjdk.java.net/ the patch is based on *** 
<http://hg.openjdk.java.net/jdk8/tl/jdk/>*jdk8/tl/jdk maybe i should 
rebase it onto another repository.

Another problem i have is testing. I think we should add some test for 
this. But got no real clue how to do it right. I tested it manually with 
the source here[2] and the files in here[3].

The files are created with an openjdk7 build(Unfortunatly i think with 
an quite old private build) and with an openjdk8(with my patches to 
NoSuchMechanismException). I tested it manually with my openjdk 7 and 8 
build and in both cases the serialized objects could be loaded correctly 
in all cases.

What is the best way to test this automatically. I thought about 
checking if the newly created openjdk8 serialization is binary equal to 
the jdk7 output, but it isn't because of some unavoidable changes (ex. 
jdk8 has the custom-serialization-bit)

Alan mentioned that it may be ok to embed some serialized-objects as 
byte[] in testcode.
I will try to create a jtreg for this. Hope to be back on this soon. In 
the meantime it would be great to have someone reviewed the webrev.

@core-libs-dev: I crosspost it to core-libs-dev because the thread 
started there. So the interessted parties can move over to security-dev 
archive[4]

-- Sebastian

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007462.html 

[2] 
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/SeriallizeTest.java 

[3] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/
[4] 
http://mail.openjdk.java.net/pipermail/security-dev/2011-August/thread.html


From chris.hegarty at oracle.com  Mon Aug 22 13:10:33 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 22 Aug 2011 13:10:33 +0000
Subject: hg: jdk8/tl/jdk: 7023713: HttpCookie.domainMatches("hostname.local", 
	"hostname") should return true
Message-ID: <20110822131044.950FF47FD3@hg.openjdk.java.net>

Changeset: 5c1f90dd0405
Author:    chegar
Date:      2011-08-22 14:09 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c1f90dd0405

7023713: HttpCookie.domainMatches("hostname.local", "hostname") should return true
Reviewed-by: chegar
Contributed-by: zhouyx at linux.vnet.ibm.com

! src/share/classes/java/net/HttpCookie.java
! test/java/net/CookieHandler/TestHttpCookie.java



From mandy.chung at oracle.com  Mon Aug 22 14:35:03 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 22 Aug 2011 07:35:03 -0700
Subject: 7081813: ProblemList.txt updates (8/2011)
In-Reply-To: <4E522FC4.6040909@oracle.com>
References: <4E522FC4.6040909@oracle.com>
Message-ID: <4E526917.7070009@oracle.com>

Looks okay.

Mandy

On 8/22/11 3:30 AM, Alan Bateman wrote:
>
> It's whack-a-testmole time again and I'd like to update the 
> ProblemList to add several tests that fail for various reasons. In 
> some cases it's shell tests that need updating to work with Cygwin, in 
> other cases it's tests that make assumptions that aren't run when run 
> in Solaris zones, and in a few other cases it's tests that have timing 
> issues. Bugs have been created for all these issues and the tests can 
> be removed from the problem list when they are fixed. In addition 
> there is one dangerous test that is disabled completely.
>
> Thanks,
> Alan.
>
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -198,9 +198,15 @@ java/beans/XMLEncoder/6329581/Test632958
> # requires junit
> java/lang/invoke/InvokeDynamicPrintArgs.java                    
> generic-all
>
> +# 7079093
> +java/lang/instrument/ManifestTest.sh                           
> windows-all
> +
> ############################################################################ 
>
>
> # jdk_management
> +
> +# 6944188
> +java/lang/management/ThreadMXBean/ThreadStateTest.java         
> generic-all
>
> # 7067973
> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java 
> generic-all
> @@ -368,6 +374,12 @@ 
> com/sun/net/httpserver/Test9a.java                         ge
> # 7079145 java/net/ipv6tests/UdpTest.java hang at IPv6 only data exchange
> java/net/ipv6tests/UdpTest.java                                 linux-all
>
> +# 7079012
> +java/net/NetworkInterface/NetParamsTest.java                   
> solaris-all
> +
> +# 7081476
> +java/net/InetSocketAddress/B6469803.java                       
> generic-all
> +
> ############################################################################ 
>
>
> # jdk_io
> @@ -375,12 +387,21 @@ java/net/ipv6tests/UdpTest.java        # 6962637
> java/io/File/MaxPathLength.java                                 
> windows-all
>
> +# 6671616
> +java/io/File/BlockIsDirectory.java                             
> solaris-all
> +
> +# 7076644
> +java/io/File/Basic.java                                                windows-all 
>
> +
> ############################################################################ 
>
>
> # jdk_nio
>
> # 6963118
> java/nio/channels/Selector/Wakeup.java                          
> windows-all
> +
> +# 7076700
> +java/nio/channels/SocketChannel/AdaptSocket.java               
> generic-all
>
> ############################################################################ 
>
>
> @@ -499,6 +520,9 @@ sun/security/ssl/sanity/interop/ClientJS
> # 7079203 sun/security/tools/keytool/printssl.sh fails on solaris with 
> timeout
> sun/security/tools/keytool/printssl.sh                          
> solaris-all
>
> +# 7081817
> +sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java   generic-all 
>
> +
> ############################################################################ 
>
>
> # jdk_swing (not using samevm)
> diff --git a/test/java/io/IOException/LastErrorString.java 
> b/test/java/io/IOException/LastErrorString.java
> --- a/test/java/io/IOException/LastErrorString.java
> +++ b/test/java/io/IOException/LastErrorString.java
> @@ -23,6 +23,7 @@
>
> /* @test
>    @bug 4167937
> +   @ignore Test truncates system files when run as root, see 7042603
>    @summary Test code paths that use the JVM_LastErrorString procedure
>  */
>
>



From Alan.Bateman at oracle.com  Mon Aug 22 14:38:35 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Aug 2011 15:38:35 +0100
Subject: 7081804: Remove cause field from
	javax.xml.crypto.NoSuchMechnismException
In-Reply-To: <4E525386.9000207@gmx.de>
References: <4E525386.9000207@gmx.de>
Message-ID: <4E5269EB.5040308@oracle.com>

Sebastian Sickelmann wrote:
> :
>
> In a following post Alan writes that this should best be discussed 
> here. What is the hg repository for patches in this mailinglist? I 
> don't see any security-dev related repository for openjdk8 in 
> http://hg.openjdk.java.net/ the patch is based on *** 
> <http://hg.openjdk.java.net/jdk8/tl/jdk/>*jdk8/tl/jdk maybe i should 
> rebase it onto another repository.
Security changes are also pushed to jdk8/tl/jdk, it's just a different 
mailing list for this area.

-Alan.


From alan.bateman at oracle.com  Mon Aug 22 15:06:25 2011
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 22 Aug 2011 15:06:25 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20110822150645.EE18247FD9@hg.openjdk.java.net>

Changeset: fd07a2b7bf4d
Author:    alanb
Date:      2011-08-22 16:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fd07a2b7bf4d

7081813: ProblemList.txt updates (8/2011)
Reviewed-by: weijun, mchung

! test/ProblemList.txt
! test/java/io/IOException/LastErrorString.java

Changeset: 605ea77f2e6f
Author:    alanb
Date:      2011-08-22 16:05 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/605ea77f2e6f

Merge




From joe.darcy at oracle.com  Mon Aug 22 19:16:58 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Mon, 22 Aug 2011 19:16:58 +0000
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors to
	InternalError and VirtualMachineError
Message-ID: <20110822191717.9FF1347FE5@hg.openjdk.java.net>

Changeset: c43af666d130
Author:    darcy
Date:      2011-08-22 12:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130

7080020: Add conventional constructors to InternalError and VirtualMachineError
Reviewed-by: darcy
Contributed-by: nsebastian.sickelmann at gmx.de

! src/share/classes/com/sun/servicetag/SunConnection.java
! src/share/classes/java/lang/InternalError.java
! src/share/classes/java/lang/VirtualMachineError.java
! src/share/classes/java/util/prefs/Preferences.java
! src/share/classes/sun/font/FontManagerFactory.java
! src/share/classes/sun/misc/URLClassPath.java
! src/share/classes/sun/reflect/MethodAccessorGenerator.java
! src/share/classes/sun/security/x509/X500Name.java
! src/share/classes/sun/tools/jconsole/ProxyClient.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java



From joe.darcy at oracle.com  Mon Aug 22 19:19:12 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 22 Aug 2011 12:19:12 -0700
Subject: Request for review: Rework cause-chaining in Exceptions was:JDK
	8 code review request for 6380161 (reflect) Exception
	from	newInstance() not chained to cause.
In-Reply-To: <4E4C2BFA.40207@gmx.de>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
	<4E4C2BFA.40207@gmx.de>
Message-ID: <4E52ABB0.1030605@oracle.com>

Sebastian Sickelmann wrote:
> Am 17.08.2011 03:11, schrieb joe.darcy at oracle.com:
>> Hello.
>>
>> On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote:
>>> Hi,
>>>
>>> some time ago, i wrote[5] with Joe and David about advancing some 
>>> exception-types to the 4 standard ctors.
>>>
>>> The first Exception i have looked at was InternalError and now(after 
>>> some struggeling with gnumake and hg) my patches for reviewing are 
>>> ready.
>>>
>>> I uploaded them at [4]
>>>
>>> I split the changes into 3 parts.
>>>
>>> 1. Added 2 ctors to InternalError and VirtualMachineError****[1]
>>> 2. Use the two ctors of InternalError****[2] (based on [1])
>>> 3. Chain Rootcause into InternalError**[3] (based also on [1])
>>>
>>> I think part 1 and 2 are uncritical. Part 3 is more critical because 
>>> it changes behavior (exception-chaining). But i don't think that 
>>> part 3 is unimportable, because in case of an InternalError (use 
>>> should not be able to recover) there shouldn't be a problem with a 
>>> little longer exception-chain.
>>>
>>> Is there someone who what to sponsor this or parts of it?
>>>
>>> [1] https://bugs.openjdk.java.net/attachment.cgi?id=233
>>> [2] https://bugs.openjdk.java.net/attachment.cgi?id=234
>>> [3] https://bugs.openjdk.java.net/attachment.cgi?id=235
>>> [4] https://bugs.openjdk.java.net/show_bug.cgi?id=100201
>>> [5] 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html 
>>>
>>
>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
>> conventional constructors to InternalError" for it.
>>
>> For adding constructors to InternalError (or VirtualMachineError), 
>> the push that adds the constructors should include some usage of 
>> them.  Therefore, at least portions of 1) and 2) above should be 
>> combined.  If there are easy to find usages of a cause for 
>> VirtualMachineError, then those should be included at the same time 
>> any new constructors are added there.
> VirtualMachineError is changed because it is the abstract super class 
> of InternalError so use of the VirtualMachineError ctors is inside of 
> the InternalError ctors
>>
>> There is some currently Oracle-internal paperwork which needs to be 
>> filed to make an API change; I'll file that paperwork once there is 
>> verification on whether updates to both InternalError and 
>> VirtualMachineError will be included in this round of work.  The 
>> paperwork needs to be approved before the change is pushed and 
>> typically takes a few days to be processed.
>>
> OK. That much work for just chaining up exceptions.
> I am happy that i needn't to do this paperwork. I hope it's virtual 
> paperwork. ;-)
>
> I will post the change in 2 webrevs than.
> One for the smaller part (Change of the InternalError itself + some 
> small changes "initCause usage to ctor parameter")
> And one for the bigger part (Chain all uses of InternalError with the 
> root-cause if any root-cause exists)
>
> i must rebase it again. Will post webrev url at the other thread in 
> short.

Hello.

The internal API paperwork went through; I've just pushed a changeset 
with the additional constructors and some usage of them to replace calls 
to initCause methods:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130

Thanks,

-Joe


From joe.darcy at oracle.com  Tue Aug 23 00:13:40 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 23 Aug 2011 00:13:40 +0000
Subject: hg: jdk8/tl/jdk: 6476261: (reflect) GenericSignatureFormatError When
	signature includes nested inner classes; ...
Message-ID: <20110823001350.8555147FF3@hg.openjdk.java.net>

Changeset: b1f99f9c2879
Author:    darcy
Date:      2011-08-22 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1f99f9c2879

6476261: (reflect) GenericSignatureFormatError When signature includes nested inner classes
6832374: (reflect) malformed signature can cause parser to go into infinite loop
7052898: (reflect) SignatureParser will accept strings outside of the grammar
Summary: Various signature parsing fixes; additional review by sonali.goel at oracle.com
Reviewed-by: alanb

! src/share/classes/sun/reflect/generics/parser/SignatureParser.java
! test/java/lang/reflect/Generics/Probe.java
+ test/java/lang/reflect/Generics/SignatureTest.java
+ test/java/lang/reflect/Generics/TestBadSignatures.java



From joe.darcy at oracle.com  Tue Aug 23 00:34:46 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 23 Aug 2011 00:34:46 +0000
Subject: hg: jdk8/tl/jdk: 7080038: (ann) Serializable types in
	sun.reflect.annotation do not declare serialVersionUIDs
Message-ID: <20110823003457.AF30C47FF6@hg.openjdk.java.net>

Changeset: 71e353aba896
Author:    darcy
Date:      2011-08-22 17:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71e353aba896

7080038: (ann) Serializable types in sun.reflect.annotation do not declare serialVersionUIDs
Reviewed-by: alanb

! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
! src/share/classes/sun/reflect/annotation/AnnotationTypeMismatchExceptionProxy.java
! src/share/classes/sun/reflect/annotation/EnumConstantNotPresentExceptionProxy.java
! src/share/classes/sun/reflect/annotation/TypeNotPresentExceptionProxy.java



From joe.darcy at oracle.com  Tue Aug 23 00:38:48 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 22 Aug 2011 17:38:48 -0700
Subject: Comments on 7080038: "(ann) Serializable types in
	sun.reflect.annotation do not declare serialVersionUIDs"
Message-ID: <4E52F698.1010601@oracle.com>

Hello.

A few comments on the fix for 7080038: (ann) Serializable types in 
sun.reflect.annotation do not declare serialVersionUIDs recently pushed 
into the JDK 8 TL forest:

    http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71e353aba896

In some testing that occurred post JDK 7 GA, we found a compatibility 
issue in serializing annotation objects across releases.  An otherwise 
innocuous bug fix in JDK 7 (6761678) inadvertently changed the 
serialVersionUID of one of the classes used to represent serialized 
annotation objects.  This fix restores the original serialVersionUID 
values in those classes to the values from JDK 5/JDK 6 and thus restores 
serial compatibility.

The addition of these explicit serialVersionUIDs will also be done to 
other affected release trains, including JDK 7 update and OpenJDK 6.

Cheers,

-Joe


From xuelei.fan at oracle.com  Tue Aug 23 01:23:09 2011
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Tue, 23 Aug 2011 01:23:09 +0000
Subject: hg: jdk8/tl/jdk: 7081817:
	test/sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java
	failing
Message-ID: <20110823012319.B160447FFB@hg.openjdk.java.net>

Changeset: 21f4d2d96191
Author:    xuelei
Date:      2011-08-22 18:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21f4d2d96191

7081817: test/sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java failing
Reviewed-by: alanb, weijun

! src/share/classes/sun/security/provider/certpath/X509CertPath.java



From sebastian.sickelmann at gmx.de  Tue Aug 23 12:16:31 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Tue, 23 Aug 2011 14:16:31 +0200
Subject: Request for review: More cause-chaining for InternalError
In-Reply-To: <4E52ABB0.1030605@oracle.com>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
	<4E4C2BFA.40207@gmx.de> <4E52ABB0.1030605@oracle.com>
Message-ID: <4E539A1F.106@gmx.de>

Am 22.08.2011 21:19, schrieb Joe Darcy:
> Sebastian Sickelmann wrote:
>> Am 17.08.2011 03:11, schrieb joe.darcy at oracle.com:
>>> Hello.
>>>
>>> On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote:
>>>> Hi,
>>>>
>>>> some time ago, i wrote[5] with Joe and David about advancing some 
>>>> exception-types to the 4 standard ctors.
>>>>
>>>> The first Exception i have looked at was InternalError and 
>>>> now(after some struggeling with gnumake and hg) my patches for 
>>>> reviewing are ready.
>>>>
>>>> I uploaded them at [4]
>>>>
>>>> I split the changes into 3 parts.
>>>>
>>>> 1. Added 2 ctors to InternalError and VirtualMachineError****[1]
>>>> 2. Use the two ctors of InternalError****[2] (based on [1])
>>>> 3. Chain Rootcause into InternalError**[3] (based also on [1])
>>>>
>>>> I think part 1 and 2 are uncritical. Part 3 is more critical 
>>>> because it changes behavior (exception-chaining). But i don't think 
>>>> that part 3 is unimportable, because in case of an InternalError 
>>>> (use should not be able to recover) there shouldn't be a problem 
>>>> with a little longer exception-chain.
>>>>
>>>> Is there someone who what to sponsor this or parts of it?
>>>>
>>>> [1] https://bugs.openjdk.java.net/attachment.cgi?id=233
>>>> [2] https://bugs.openjdk.java.net/attachment.cgi?id=234
>>>> [3] https://bugs.openjdk.java.net/attachment.cgi?id=235
>>>> [4] https://bugs.openjdk.java.net/show_bug.cgi?id=100201
>>>> [5] 
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html 
>>>>
>>>
>>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
>>> conventional constructors to InternalError" for it.
>>>
>>> For adding constructors to InternalError (or VirtualMachineError), 
>>> the push that adds the constructors should include some usage of 
>>> them.  Therefore, at least portions of 1) and 2) above should be 
>>> combined.  If there are easy to find usages of a cause for 
>>> VirtualMachineError, then those should be included at the same time 
>>> any new constructors are added there.
>> VirtualMachineError is changed because it is the abstract super class 
>> of InternalError so use of the VirtualMachineError ctors is inside of 
>> the InternalError ctors
>>>
>>> There is some currently Oracle-internal paperwork which needs to be 
>>> filed to make an API change; I'll file that paperwork once there is 
>>> verification on whether updates to both InternalError and 
>>> VirtualMachineError will be included in this round of work.  The 
>>> paperwork needs to be approved before the change is pushed and 
>>> typically takes a few days to be processed.
>>>
>> OK. That much work for just chaining up exceptions.
>> I am happy that i needn't to do this paperwork. I hope it's virtual 
>> paperwork. ;-)
>>
>> I will post the change in 2 webrevs than.
>> One for the smaller part (Change of the InternalError itself + some 
>> small changes "initCause usage to ctor parameter")
>> And one for the bigger part (Chain all uses of InternalError with the 
>> root-cause if any root-cause exists)
>>
>> i must rebase it again. Will post webrev url at the other thread in 
>> short.
>
> Hello.
>
> The internal API paperwork went through; I've just pushed a changeset 
> with the additional constructors and some usage of them to replace 
> calls to initCause methods:
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130
>
> Thanks,
>
> -Joe
Thanks for commiting. My email-adress has a typo but that isn't a real 
problem ;-)

I have rebased my "additional chainings of InternalError" on your commit.

The webrev is:
http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_c43af666d130/

Reviews are welcome for this too.

- Sebastian


From mandy.chung at oracle.com  Tue Aug 23 17:36:29 2011
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 23 Aug 2011 17:36:29 +0000
Subject: hg: jdk8/tl/jdk: 7068328: BufferPoolMXBean and PlatformLoggingMXBean
	getObjectName may return null
Message-ID: <20110823173654.5A11347033@hg.openjdk.java.net>

Changeset: 4e53fc6bcac0
Author:    mchung
Date:      2011-08-23 10:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e53fc6bcac0

7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may return null
Reviewed-by: alanb
Contributed-by: spoole at uk.ibm.com

! src/share/classes/sun/management/ManagementFactoryHelper.java
+ test/java/lang/management/ManagementFactory/GetObjectName.java



From joe.darcy at oracle.com  Tue Aug 23 22:43:57 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 23 Aug 2011 15:43:57 -0700
Subject: JDK 8 code review request for 7082231 "Put a @since 1.7 on
	System.lineSeparator"
Message-ID: <4E542D2D.10103@oracle.com>

Hello.

Please review this simple patch to fix 7082231 "Put a @since 1.7 on 
System.lineSeparator", which will correct an @since tag omitted by the 
JDK 7 fix for 6900043 "Add method to return line.separator property."

diff --git a/src/share/classes/java/lang/System.java 
b/src/share/classes/java/lang/System.java
--- a/src/share/classes/java/lang/System.java
+++ b/src/share/classes/java/lang/System.java
@@ -632,6 +632,7 @@
      *
      * <p>On UNIX systems, it returns {@code "\n"}; on Microsoft
      * Windows systems it returns {@code "\r\n"}.
+     * @since 1.7
      */
     public static String lineSeparator() {
         return lineSeparator;


Thanks,

-Joe


From mike.duigou at oracle.com  Tue Aug 23 23:23:24 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 23 Aug 2011 16:23:24 -0700
Subject: JDK 8 code review request for 7082231 "Put a @since 1.7 on
	System.lineSeparator"
In-Reply-To: <4E542D2D.10103@oracle.com>
References: <4E542D2D.10103@oracle.com>
Message-ID: <AE28E0FD-DF01-45B4-95C2-137F93DA156B@oracle.com>

looks good.

On Aug 23 2011, at 15:43 , Joe Darcy wrote:

> Hello.
> 
> Please review this simple patch to fix 7082231 "Put a @since 1.7 on System.lineSeparator", which will correct an @since tag omitted by the JDK 7 fix for 6900043 "Add method to return line.separator property."
> 
> diff --git a/src/share/classes/java/lang/System.java b/src/share/classes/java/lang/System.java
> --- a/src/share/classes/java/lang/System.java
> +++ b/src/share/classes/java/lang/System.java
> @@ -632,6 +632,7 @@
>     *
>     * <p>On UNIX systems, it returns {@code "\n"}; on Microsoft
>     * Windows systems it returns {@code "\r\n"}.
> +     * @since 1.7
>     */
>    public static String lineSeparator() {
>        return lineSeparator;
> 
> 
> Thanks,
> 
> -Joe



From joe.darcy at oracle.com  Tue Aug 23 23:36:18 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 23 Aug 2011 23:36:18 +0000
Subject: hg: jdk8/tl/jdk: 7082231: Put a @since 1.7 on System.lineSeparator
Message-ID: <20110823233645.44FCF4706C@hg.openjdk.java.net>

Changeset: 440161cc9af8
Author:    darcy
Date:      2011-08-23 16:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/440161cc9af8

7082231: Put a @since 1.7 on System.lineSeparator
Reviewed-by: mduigou

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



From xueming.shen at oracle.com  Wed Aug 24 00:32:41 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 23 Aug 2011 17:32:41 -0700
Subject: Code review request 7077769: (zipfs) ZipFileSystem.writeCEN() writes
	wrong "data size" for ZIP64 extended information extra field
Message-ID: <4E5446A9.4030004@oracle.com>

The fix tires to address two issues in ZipFileSystem class

(1) The OutputStream used to write out the bits in sync() is not wrapped
by a BufferedOutputStream. Without the BufferedOutputStream wrapper,
we basically write all ZIP header tables (loc and cen) byte by byte. How
big is the impact to the performance? With the BufferedOutputStream, the
time we spend on sync/writing a Jar file in size of 64M (our rt.jar) 
improved
from 3640 ms to 1315 ms on my local machine.

(2) The writeCEN() incorrectly sets the data size of the ZIP64 extended
information extra field block.  The "data size" should be the size of the
ZIP64 data block only, should not include the 4-byte header (the ZFS.
writeCEN() accidentally includes these extra 4 bytes). It is implemented
correctly in ZipOutputStream. (Read works fine in ZipInputStream, ZipFile
and ZipFileSystem, for both the loc and cen headers).

The same change will need go into 7u2 as well.

Fix has been verified/test manually with existing test cases. Given the 
nature
of the > 4G zip data file. I'm not including an auto regression test.

Webrev is at

http://cr.openjdk.java.net/~sherman/7077769/webrev 
<http://cr.openjdk.java.net/%7Esherman/7077769/webrev/>

Thanks,
Sherman




From Alan.Bateman at oracle.com  Wed Aug 24 07:06:30 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Aug 2011 08:06:30 +0100
Subject: Code review request 7077769: (zipfs) ZipFileSystem.writeCEN()
	writes wrong "data size" for ZIP64 extended information extra field
In-Reply-To: <4E5446A9.4030004@oracle.com>
References: <4E5446A9.4030004@oracle.com>
Message-ID: <4E54A2F6.6040204@oracle.com>

Xueming Shen wrote:
> :
>
> Fix has been verified/test manually with existing test cases. Given 
> the nature
> of the > 4G zip data file. I'm not including an auto regression test.
>
> Webrev is at
>
> http://cr.openjdk.java.net/~sherman/7077769/webrev 
The zip64 fix looks okay to me. The fix to sync() is okay too although I 
would change this to use try-with-resources.

On the test, I agree an automated test might be too slow to run. 
However, as zip64 is tricky to get right then having a sanity test in 
the test tree (without a @test tag) would be useful.

-Alan


From eamonn.mcmanus at oracle.com  Wed Aug 24 07:15:59 2011
From: eamonn.mcmanus at oracle.com (Eamonn McManus)
Date: Wed, 24 Aug 2011 09:15:59 +0200
Subject: JDK 8 code review request for 7082231 "Put a @since 1.7 on
	System.lineSeparator"
In-Reply-To: <4E542D2D.10103@oracle.com>
References: <4E542D2D.10103@oracle.com>
Message-ID: <4E54A52F.3030003@oracle.com>

Looks good. But I am thinking that this shows we need a regression test 
that ensures that there are no missing @since tags, given that JDK 7 
went out without this one. I am imagining two doclets, one of which 
creates a file with a list of the signatures of every public element 
(class, method, constructor, or field), and the other of which checks 
that every public element is either listed in the file or has a @since 
tag. So we would have run the first doclet on JDK 6 and then used its 
output with the second doclet to check JDK 7. I'm probably stating the 
obvious.

?amonn


On 24/8/11 12:43 AM, Joe Darcy wrote:
> Hello.
>
> Please review this simple patch to fix 7082231 "Put a @since 1.7 on 
> System.lineSeparator", which will correct an @since tag omitted by the 
> JDK 7 fix for 6900043 "Add method to return line.separator property."
>
> diff --git a/src/share/classes/java/lang/System.java 
> b/src/share/classes/java/lang/System.java
> --- a/src/share/classes/java/lang/System.java
> +++ b/src/share/classes/java/lang/System.java
> @@ -632,6 +632,7 @@
>      *
>      * <p>On UNIX systems, it returns {@code "\n"}; on Microsoft
>      * Windows systems it returns {@code "\r\n"}.
> +     * @since 1.7
>      */
>     public static String lineSeparator() {
>         return lineSeparator;
>
>
> Thanks,
>
> -Joe


From Alan.Bateman at oracle.com  Wed Aug 24 07:54:43 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Aug 2011 08:54:43 +0100
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors to
	InternalError and VirtualMachineError
In-Reply-To: <20110822191717.9FF1347FE5@hg.openjdk.java.net>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>
Message-ID: <4E54AE42.7000904@oracle.com>


Joe, Sebastian - just noticed this now but VirtualMachineError doesn't 
specify a serialVersionUID so these new constructors will change the 
default value.

joe.darcy at oracle.com wrote:
> Changeset: c43af666d130
> Author:    darcy
> Date:      2011-08-22 12:16 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130
>
> 7080020: Add conventional constructors to InternalError and VirtualMachineError
> Reviewed-by: darcy
> Contributed-by: nsebastian.sickelmann at gmx.de
>
> ! src/share/classes/com/sun/servicetag/SunConnection.java
> ! src/share/classes/java/lang/InternalError.java
> ! src/share/classes/java/lang/VirtualMachineError.java
> ! src/share/classes/java/util/prefs/Preferences.java
> ! src/share/classes/sun/font/FontManagerFactory.java
> ! src/share/classes/sun/misc/URLClassPath.java
> ! src/share/classes/sun/reflect/MethodAccessorGenerator.java
> ! src/share/classes/sun/security/x509/X500Name.java
> ! src/share/classes/sun/tools/jconsole/ProxyClient.java
> ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
>   





From sebastian.sickelmann at gmx.de  Wed Aug 24 10:29:28 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 24 Aug 2011 12:29:28 +0200
Subject: =?US-ASCII?Q?Re=3A_hg=3A_jdk8/tl/jdk=3A_7080020=3A_Add_conventional_con?=
	=?US-ASCII?Q?structors_to=09InternalError_and_VirtualMachineError?=
In-Reply-To: <4E54AE42.7000904@oracle.com>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>
	<4E54AE42.7000904@oracle.com>
Message-ID: <f94662ce-7b32-40a3-8786-88eea01106b6@email.android.com>

I am sorry. Should have read the complete Serialization Specification. Thought that serialversionUid is only calculated on declared non transient instance fields. I will estimate old serialversionUid andere create a new Cr. Should we create Regression Tests on all serializable somehow?
-- Sebastian


Alan Bateman <Alan.Bateman at oracle.com> schrieb:

>
>Joe, Sebastian - just noticed this now but VirtualMachineError doesn't 
>specify a serialVersionUID so these new constructors will change the 
>default value.
>
>joe.darcy at oracle.com wrote:
>> Changeset: c43af666d130
>> Author:    darcy
>> Date:      2011-08-22 12:16 -0700
>> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130
>>
>> 7080020: Add conventional constructors to InternalError and VirtualMachineError
>> Reviewed-by: darcy
>> Contributed-by: nsebastian.sickelmann at gmx.de
>>
>> ! src/share/classes/com/sun/servicetag/SunConnection.java
>> ! src/share/classes/java/lang/InternalError.java
>> ! src/share/classes/java/lang/VirtualMachineError.java
>> ! src/share/classes/java/util/prefs/Preferences.java
>> ! src/share/classes/sun/font/FontManagerFactory.java
>> ! src/share/classes/sun/misc/URLClassPath.java
>> ! src/share/classes/sun/reflect/MethodAccessorGenerator.java
>> ! src/share/classes/sun/security/x509/X500Name.java
>> ! src/share/classes/sun/tools/jconsole/ProxyClient.java
>> ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
>>   
>
>
>

-- 
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.


From joe.darcy at oracle.com  Wed Aug 24 15:11:03 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 24 Aug 2011 08:11:03 -0700
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors to
	InternalError and VirtualMachineError
In-Reply-To: <4E54AE42.7000904@oracle.com>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>
	<4E54AE42.7000904@oracle.com>
Message-ID: <4E551487.8050007@oracle.com>

Hi Alan.

I did check for that point in my review :-)

The VirtualMachineError class is abstract so as long as all its 
subclasses declare a serialVersionUID, like InternalError does, I think 
we're fine.

Thanks,

-Joe

Alan Bateman wrote:
>
> Joe, Sebastian - just noticed this now but VirtualMachineError doesn't 
> specify a serialVersionUID so these new constructors will change the 
> default value.
>
> joe.darcy at oracle.com wrote:
>> Changeset: c43af666d130
>> Author:    darcy
>> Date:      2011-08-22 12:16 -0700
>> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130
>>
>> 7080020: Add conventional constructors to InternalError and 
>> VirtualMachineError
>> Reviewed-by: darcy
>> Contributed-by: nsebastian.sickelmann at gmx.de
>>
>> ! src/share/classes/com/sun/servicetag/SunConnection.java
>> ! src/share/classes/java/lang/InternalError.java
>> ! src/share/classes/java/lang/VirtualMachineError.java
>> ! src/share/classes/java/util/prefs/Preferences.java
>> ! src/share/classes/sun/font/FontManagerFactory.java
>> ! src/share/classes/sun/misc/URLClassPath.java
>> ! src/share/classes/sun/reflect/MethodAccessorGenerator.java
>> ! src/share/classes/sun/security/x509/X500Name.java
>> ! src/share/classes/sun/tools/jconsole/ProxyClient.java
>> ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
>>   
>
>
>



From daniel.smith at oracle.com  Wed Aug 24 18:10:11 2011
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 24 Aug 2011 11:10:11 -0700
Subject: Enumeration adapters in SE 8
Message-ID: <05EDC0AC-8754-4A5C-9F18-2DA29BE7743E@oracle.com>

I was pointed to some comments on core-libs about adapting Enumerations to for loops in SE 8.  (Sorry for the new thread -- I wasn't subscribed.)  It turns out lambdas + extension methods will make this very easy.

In the API:

interface Enumeration<E> extends Iterator<E> {
  boolean hasMoreElements();
  E nextElement();
  boolean hasNext() default #hasMoreElements;
  E next() default #nextElement;
  void remove() default { throw new UnsupportedOperationException(); }
}

Note that Iterable is a function type -- a thunk producing an Iterator -- and so we can express Iterables with lambdas and method references.  It's becoming clear that a for loop should provide a target type for these things, so that will probably be part of the SE 8 feature set.

With a method reference:

Hashtable<String,Object> h = ?;
for (String s : h#keys) { ? }

With a lambda:

for (String s : #{ -> path().to().enumeration() }) { ... }

My preference is to also support Iterators directly in for loops; this may or may not make it in:

for (String s : path().to().enumeration()) { ... }

?Dan



From cgdecker at gmail.com  Wed Aug 24 21:58:24 2011
From: cgdecker at gmail.com (Colin Decker)
Date: Wed, 24 Aug 2011 17:58:24 -0400
Subject: Enumeration adapters in SE 8
In-Reply-To: <CABKW8Ri_chGS2DY9eKVa0T1HeLP3TwoDuXOSpLSz-7mAJHC6kg@mail.gmail.com>
References: <05EDC0AC-8754-4A5C-9F18-2DA29BE7743E@oracle.com>
	<CABKW8Ri_chGS2DY9eKVa0T1HeLP3TwoDuXOSpLSz-7mAJHC6kg@mail.gmail.com>
Message-ID: <CAPmOpX67m+YC9VWJ8dJ0uBvpgZOYKgA-Q42dkqKycAf=YQnCEA@mail.gmail.com>

I've come across various scenarios. One example is
javax.swing.tree.DefaultMutableTreeNode. It has numerous methods that return
Enumerations, including:
- children
- depthFirstEnumeration
- breadthFirstEnumeration
- preorderEnumeration
- postorderEnumeration
- pathFromAncestorEnumeration

I've created a utility class with methods to return Iterables for each of
these types of Enumerations for convenience, but it would be much nicer to
just use a method reference.

Deque's descendingIterator() method is a more modern good candidate for
treating as an Iterable. See this question on StackOverflow:
http://stackoverflow.com/questions/3883131/idiomatic-way-to-use-for-each-loop-given-an-iterator

-- 
Colin


On Wed, Aug 24, 2011 at 5:45 PM, Ben Evans <benjamin.john.evans at gmail.com>wrote:

> Hi Dan,
>
> On Wed, Aug 24, 2011 at 7:10 PM, Dan Smith <daniel.smith at oracle.com>
> wrote:
>
> > I was pointed to some comments on core-libs about adapting Enumerations
> to
> > for loops in SE 8.  (Sorry for the new thread -- I wasn't subscribed.)
>  It
> > turns out lambdas + extension methods will make this very easy.
> >
> > In the API:
> >
> > interface Enumeration<E> extends Iterator<E> {
> >  boolean hasMoreElements();
> >  E nextElement();
> >  boolean hasNext() default #hasMoreElements;
> >  E next() default #nextElement;
> >  void remove() default { throw new UnsupportedOperationException(); }
> > }
> >
> > Note that Iterable is a function type -- a thunk producing an Iterator --
> > and so we can express Iterables with lambdas and method references.  It's
> > becoming clear that a for loop should provide a target type for these
> > things, so that will probably be part of the SE 8 feature set.
> >
> > With a method reference:
> >
> > Hashtable<String,Object> h = ?;
> > for (String s : h#keys) { ? }
> >
>
> I'm struggling to see where this might be useful. This example is obviously
> too trivial and would add nothing, but I can't see to come up with any more
> extensive example where having a method reference in this position would be
> actually useful.
>
> Can someone else provide a more compelling example for a for loop taking a
> method reference?
>
> Thanks,
>
> Ben
>
>


From brian.goetz at oracle.com  Wed Aug 24 22:26:32 2011
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 24 Aug 2011 18:26:32 -0400
Subject: Call for input -- point lambdafication
Message-ID: <4E557A98.404@oracle.com>

This is a call for proposals for "point lambdafication candidates."

Once we introduce lambda to the language, the libraries immediately 
start to look a little older.  One subgoal of Project Lambda is to 
upgrade the libraries to take better advantage of the new language 
features.  Of course, there will be still be seams between "old ways" 
and "new ways" of doing things, but we want to eliminate the most 
obvious gaps.

What I'm asking for here is examples of methods *OUTSIDE OF COLLECTIONS* 
that take advantage of lambda, that you'd be sad if they didn't show up 
in the library eventually.

Here's an example:
    BufferedReader.eachLine(Block<String> b)

I call methods like this "point lambdafications" because they should be 
stand-alone methods that don't require additional library abstractions 
-- they are just a matter of adding one method somewhere.  Usually the 
implementations are trivial.

Rules:
  - Don't reply on-list -- use the SurveyMonkey link below.  I will 
summarize and post on-list.
  - Stay away from Collections.  This is the subject of a separate 
project, and not the goal of this data-gathering exercise.
  - You can propose new SAM types if they are needed.
  - You cannot propose new non-SAM types (e.g., ReadOnlyListView); if 
your suggestion requires that, it is not a point lambdafication.
  - Include enough descriptive text to describe what the method does. 
Implementations are fine, but unless its painfully obvious what the 
implementation does, the descriptive text is required.


Proposal form: https://www.surveymonkey.com/s/6VSLZKN

I will post the results on-list during the week of Sept 5.




From lordpixel+core-libs-dev at mac.com  Thu Aug 25 00:50:07 2011
From: lordpixel+core-libs-dev at mac.com (Andrew Thompson)
Date: Wed, 24 Aug 2011 20:50:07 -0400
Subject: Enumeration adapters in SE 8
In-Reply-To: <CANiekN6X5J0Za3rn-SVWVuLMn7YZ1ZjY93fC+t+65vzVAmEbNw@mail.gmail.com>
References: <05EDC0AC-8754-4A5C-9F18-2DA29BE7743E@oracle.com>
	<CABKW8Ri_chGS2DY9eKVa0T1HeLP3TwoDuXOSpLSz-7mAJHC6kg@mail.gmail.com>
	<CAPmOpX67m+YC9VWJ8dJ0uBvpgZOYKgA-Q42dkqKycAf=YQnCEA@mail.gmail.com>
	<CANiekN6X5J0Za3rn-SVWVuLMn7YZ1ZjY93fC+t+65vzVAmEbNw@mail.gmail.com>
Message-ID: <BCB23AFD-4CBC-4A77-920D-2A86E87C9E48@mac.com>

The key advance would be the last one, unfortunately the one Dan says may not make it: allowing the for loop to take an Iterator. 

I had some legacy code in the last couple of weeks where I wanted to be able to process arbitrary sequences: arrays, iterables and iterators and I ended up copying and pasting control flow code because there's no unifying interface. 

Enumerations are nice to have. Although I can use the for loop with an array, there's no way to write a generic method to handle arrays and Iterables. Arrays that implement Iterable would be more valuable if we're talking convenience. 



On Aug 24, 2011, at 6:13 PM, Collin Fagan <collin.fagan at gmail.com> wrote:

> There was a time where it was considered best practice to return an iterator
> instead of a collection.  There are now many apis and legacy code that are
> not compatible with the for each loop.
> 
> I think even if there are only a few places in the jdk where this would
> apply it would still be convenient in the wild.
> Collin
> 
> On Wed, Aug 24, 2011 at 4:58 PM, Colin Decker <cgdecker at gmail.com> wrote:
> 
>> I've come across various scenarios. One example is
>> javax.swing.tree.DefaultMutableTreeNode. It has numerous methods that
>> return
>> Enumerations, including:
>> - children
>> - depthFirstEnumeration
>> - breadthFirstEnumeration
>> - preorderEnumeration
>> - postorderEnumeration
>> - pathFromAncestorEnumeration
>> 
>> I've created a utility class with methods to return Iterables for each of
>> these types of Enumerations for convenience, but it would be much nicer to
>> just use a method reference.
>> 
>> Deque's descendingIterator() method is a more modern good candidate for
>> treating as an Iterable. See this question on StackOverflow:
>> 
>> http://stackoverflow.com/questions/3883131/idiomatic-way-to-use-for-each-loop-given-an-iterator
>> 
>> --
>> Colin
>> 
>> 
>> On Wed, Aug 24, 2011 at 5:45 PM, Ben Evans <benjamin.john.evans at gmail.com
>>> wrote:
>> 
>>> Hi Dan,
>>> 
>>> On Wed, Aug 24, 2011 at 7:10 PM, Dan Smith <daniel.smith at oracle.com>
>>> wrote:
>>> 
>>>> I was pointed to some comments on core-libs about adapting Enumerations
>>> to
>>>> for loops in SE 8.  (Sorry for the new thread -- I wasn't subscribed.)
>>> It
>>>> turns out lambdas + extension methods will make this very easy.
>>>> 
>>>> In the API:
>>>> 
>>>> interface Enumeration<E> extends Iterator<E> {
>>>> boolean hasMoreElements();
>>>> E nextElement();
>>>> boolean hasNext() default #hasMoreElements;
>>>> E next() default #nextElement;
>>>> void remove() default { throw new UnsupportedOperationException(); }
>>>> }
>>>> 
>>>> Note that Iterable is a function type -- a thunk producing an Iterator
>> --
>>>> and so we can express Iterables with lambdas and method references.
>> It's
>>>> becoming clear that a for loop should provide a target type for these
>>>> things, so that will probably be part of the SE 8 feature set.
>>>> 
>>>> With a method reference:
>>>> 
>>>> Hashtable<String,Object> h = ?;
>>>> for (String s : h#keys) { ? }
>>>> 
>>> 
>>> I'm struggling to see where this might be useful. This example is
>> obviously
>>> too trivial and would add nothing, but I can't see to come up with any
>> more
>>> extensive example where having a method reference in this position would
>> be
>>> actually useful.
>>> 
>>> Can someone else provide a more compelling example for a for loop taking
>> a
>>> method reference?
>>> 
>>> Thanks,
>>> 
>>> Ben
>>> 
>>> 
>> 
>> 
> 


AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside

	(see you later space cowboy, you can't take the sky from me)




From weijun.wang at oracle.com  Thu Aug 25 02:41:48 2011
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 25 Aug 2011 10:41:48 +0800
Subject: Enhance toString() to return structured info, for certificate and
	probably more
Message-ID: <4E55B66C.4020008@oracle.com>

Hi All

I was talking with Xuelei on how to better display certificate info. 
There are 3 cases we can currently think of:

1. debug output
2. keytool/jarsigner output
3. Java plugin display

The 1st one is the most primitive one and can be a single string, the 
2nd is also a string but have some format and needs to localized, the 
third is a series of Swing controls.

But the contents of all 3 are the same, and hopefully can be provided in 
a single method. Each consumer can just display it in its own style, 
with no need to understand Certificate fields, OIDs, etc. It's just like 
XSLT transformation of XML files.

So what shall I do? Let toString() outputs a long string in XML or JSON?

Or, create a new method describe() or toDescription() that returns a 
UnmodifiableMap (based on a LinkedHashMap to preserve order)?

I prefer the latter because there is no need to parse the output, and at 
least in the case of certificate, since a certificate contains 
extensions, it's very easy to stuff several maps inside another one. The 
map's keys are strings, and values can be another map or a simple data 
object, say, primitive, string, or Date.

So this needs a new interface Descriptable. It can either be:

    interface sun.security.util.Descriptable;
    sun.security.x509.X509CertImpl implements Descriptable;
    sun.security.x509.Extension implements Descriptable;

or

    interface java.security.Descriptable;
    java.security.cert.X509Certificate implements Descriptable;
    java.security.cert.Extension implements Descriptable;

or if there are other people find it useful, it can be inside the 
java.util package.

What's your ideas? Do you also need such a method?

Thanks
Max


From Alan.Bateman at oracle.com  Thu Aug 25 06:28:25 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 25 Aug 2011 07:28:25 +0100
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors to
	InternalError and VirtualMachineError
In-Reply-To: <4E551487.8050007@oracle.com>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>
	<4E54AE42.7000904@oracle.com> <4E551487.8050007@oracle.com>
Message-ID: <4E55EB89.7060906@oracle.com>

Joe Darcy wrote:
> Hi Alan.
>
> I did check for that point in my review :-)
>
> The VirtualMachineError class is abstract so as long as all its 
> subclasses declare a serialVersionUID, like InternalError does, I 
> think we're fine.
We need to check the serialization protocol but I'm pretty the object 
stream class of the supertype goes into the stream too. Also I quickly 
checked an an up-to-date build of jdk8/tl and its currently unable to 
deserialize streams contain any of the virtual machine errors like 
OutOfMemoryError, StackOverflowError, etc.

-Alan.


From joe.darcy at oracle.com  Thu Aug 25 07:00:15 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 25 Aug 2011 00:00:15 -0700
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors to
	InternalError and VirtualMachineError
In-Reply-To: <4E55EB89.7060906@oracle.com>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>
	<4E54AE42.7000904@oracle.com> <4E551487.8050007@oracle.com>
	<4E55EB89.7060906@oracle.com>
Message-ID: <4E55F2FF.80108@oracle.com>

Alan Bateman wrote:
> Joe Darcy wrote:
>> Hi Alan.
>>
>> I did check for that point in my review :-)
>>
>> The VirtualMachineError class is abstract so as long as all its 
>> subclasses declare a serialVersionUID, like InternalError does, I 
>> think we're fine.
> We need to check the serialization protocol but I'm pretty the object 
> stream class of the supertype goes into the stream too. Also I quickly 
> checked an an up-to-date build of jdk8/tl and its currently unable to 
> deserialize streams contain any of the virtual machine errors like 
> OutOfMemoryError, StackOverflowError, etc.

*sigh*

Thanks for checking on this Alan; I'll prepare a changeset with the 
explicit serialVersionUID on InternalError.

-Joe



From sebastian.sickelmann at gmx.de  Thu Aug 25 08:02:25 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Thu, 25 Aug 2011 10:02:25 +0200
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors
	to	InternalError and VirtualMachineError
In-Reply-To: <4E55EB89.7060906@oracle.com>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>	<4E54AE42.7000904@oracle.com>
	<4E551487.8050007@oracle.com> <4E55EB89.7060906@oracle.com>
Message-ID: <4E560191.3020500@gmx.de>

Am 25.08.2011 08:28, schrieb Alan Bateman:
> Joe Darcy wrote:
>> Hi Alan.
>>
>> I did check for that point in my review :-)
>>
>> The VirtualMachineError class is abstract so as long as all its 
>> subclasses declare a serialVersionUID, like InternalError does, I 
>> think we're fine.
> We need to check the serialization protocol but I'm pretty the object 
> stream class of the supertype goes into the stream too. Also I quickly 
> checked an an up-to-date build of jdk8/tl and its currently unable to 
> deserialize streams contain any of the virtual machine errors like 
> OutOfMemoryError, StackOverflowError, etc.
>
> -Alan.
Hi,

I understand the problem with the missing serialVersionUID after i read 
the Object Serialization Specification completly. Even if i don't see a 
reason why the signatures of the constructors are part of the 
calculation of the default serialVersionUID.

But i got another problem. I tried to check the serialVersionUID of 
VirtualMachieneError and got always the same results for jdk1.6.0, 
openjdk7 and my freshly build openjdk8 with updated VirtualMachineError.

Am i doing something wrong? I put my output of serialver in the 
following lines.

sebastian at sebastian-laptop:/usr/lib/jvm/jdk1.6.0_25/bin$ serialver 
java.lang.VirtualMachineError
java.lang.VirtualMachineError:    static final long serialVersionUID = 
4161983926571568670L;

sebastian at sebastian-laptop:/usr/lib/jvm/java-7-openjdk/bin$ serialver 
java.lang.VirtualMachineError
java.lang.VirtualMachineError:    static final long serialVersionUID = 
4161983926571568670L;

sebastian at sebastian-laptop:~/deve/openjdk8-jdk-only/build/linux-i586/j2sdk-image/bin$ 
serialver java.lang.VirtualMachineError
java.lang.VirtualMachineError:    static final long serialVersionUID = 
4161983926571568670L;

I have build(make clean, make all, make images) the jdk-repo only. Or 
does i have to pull in the changes of my jdk8/tl/jdk clone to my 
jdk8/jdk8/jdk clone to check this?

Has someone in the past evaluated if there is a good way to do 
regression tests for serialVersionUID in jdk-sources?

-- Sebastian


From mike.skells at talk21.com  Thu Aug 25 08:19:06 2011
From: mike.skells at talk21.com (mike.skells at talk21.com)
Date: Thu, 25 Aug 2011 08:19:06 +0000
Subject: Enumeration adapters in SE 8
In-Reply-To: <BCB23AFD-4CBC-4A77-920D-2A86E87C9E48@mac.com>
References: <05EDC0AC-8754-4A5C-9F18-2DA29BE7743E@oracle.com><CABKW8Ri_chGS2DY9eKVa0T1HeLP3TwoDuXOSpLSz-7mAJHC6kg@mail.gmail.com><CAPmOpX67m+YC9VWJ8dJ0uBvpgZOYKgA-Q42dkqKycAf=YQnCEA@mail.gmail.com><CANiekN6X5J0Za3rn-SVWVuLMn7YZ1ZjY93fC+t+65vzVAmEbNw@mail.gmail.com><BCB23AFD-4CBC-4A77-920D-2A86E87C9E48@mac.com>
Message-ID: <1255060618-1314260361-cardhu_decombobulator_blackberry.rim.net-982829995-@b25.c3.bise7.blackberry>

Hi
I know this is slightly off topic but f there is a discussion on enhancing the for each loop ...

1 is there any chance that we could use ARM functionality and allow a ClosableIterator to be introduced. There are many occasions that an iterator is backed by some resource (list of lines in a file, list of rows in a database) but there is no mechanism in the foreach loop to close this implicit resource. This was one thing that C# got right in its implementation, if the iterator implements IDisposable then it is disposed. In java it may require an additional interface although I doubt that any current Iterators implement Closable

2 it would be nice if the foreach loop honoured the RandomAccess semantics but it is probably too late for that now


Regards
Mike
Sent from my BlackBerry? wireless device

-----Original Message-----
From: Andrew Thompson <lordpixel+core-libs-dev at mac.com>
Sender: core-libs-dev-bounces at openjdk.java.net
Date: Wed, 24 Aug 2011 20:50:07 
To: Collin Fagan<collin.fagan at gmail.com>
Cc: core-libs-dev at openjdk.java.net<core-libs-dev at openjdk.java.net>; lambda-dev<lambda-dev at openjdk.java.net>
Subject: Re: Enumeration adapters in SE 8

The key advance would be the last one, unfortunately the one Dan says may not make it: allowing the for loop to take an Iterator. 

I had some legacy code in the last couple of weeks where I wanted to be able to process arbitrary sequences: arrays, iterables and iterators and I ended up copying and pasting control flow code because there's no unifying interface. 

Enumerations are nice to have. Although I can use the for loop with an array, there's no way to write a generic method to handle arrays and Iterables. Arrays that implement Iterable would be more valuable if we're talking convenience. 



On Aug 24, 2011, at 6:13 PM, Collin Fagan <collin.fagan at gmail.com> wrote:

> There was a time where it was considered best practice to return an iterator
> instead of a collection.  There are now many apis and legacy code that are
> not compatible with the for each loop.
> 
> I think even if there are only a few places in the jdk where this would
> apply it would still be convenient in the wild.
> Collin
> 
> On Wed, Aug 24, 2011 at 4:58 PM, Colin Decker <cgdecker at gmail.com> wrote:
> 
>> I've come across various scenarios. One example is
>> javax.swing.tree.DefaultMutableTreeNode. It has numerous methods that
>> return
>> Enumerations, including:
>> - children
>> - depthFirstEnumeration
>> - breadthFirstEnumeration
>> - preorderEnumeration
>> - postorderEnumeration
>> - pathFromAncestorEnumeration
>> 
>> I've created a utility class with methods to return Iterables for each of
>> these types of Enumerations for convenience, but it would be much nicer to
>> just use a method reference.
>> 
>> Deque's descendingIterator() method is a more modern good candidate for
>> treating as an Iterable. See this question on StackOverflow:
>> 
>> http://stackoverflow.com/questions/3883131/idiomatic-way-to-use-for-each-loop-given-an-iterator
>> 
>> --
>> Colin
>> 
>> 
>> On Wed, Aug 24, 2011 at 5:45 PM, Ben Evans <benjamin.john.evans at gmail.com
>>> wrote:
>> 
>>> Hi Dan,
>>> 
>>> On Wed, Aug 24, 2011 at 7:10 PM, Dan Smith <daniel.smith at oracle.com>
>>> wrote:
>>> 
>>>> I was pointed to some comments on core-libs about adapting Enumerations
>>> to
>>>> for loops in SE 8.  (Sorry for the new thread -- I wasn't subscribed.)
>>> It
>>>> turns out lambdas + extension methods will make this very easy.
>>>> 
>>>> In the API:
>>>> 
>>>> interface Enumeration<E> extends Iterator<E> {
>>>> boolean hasMoreElements();
>>>> E nextElement();
>>>> boolean hasNext() default #hasMoreElements;
>>>> E next() default #nextElement;
>>>> void remove() default { throw new UnsupportedOperationException(); }
>>>> }
>>>> 
>>>> Note that Iterable is a function type -- a thunk producing an Iterator
>> --
>>>> and so we can express Iterables with lambdas and method references.
>> It's
>>>> becoming clear that a for loop should provide a target type for these
>>>> things, so that will probably be part of the SE 8 feature set.
>>>> 
>>>> With a method reference:
>>>> 
>>>> Hashtable<String,Object> h = ?;
>>>> for (String s : h#keys) { ? }
>>>> 
>>> 
>>> I'm struggling to see where this might be useful. This example is
>> obviously
>>> too trivial and would add nothing, but I can't see to come up with any
>> more
>>> extensive example where having a method reference in this position would
>> be
>>> actually useful.
>>> 
>>> Can someone else provide a more compelling example for a for loop taking
>> a
>>> method reference?
>>> 
>>> Thanks,
>>> 
>>> Ben
>>> 
>>> 
>> 
>> 
> 


AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside

	(see you later space cowboy, you can't take the sky from me)



From Alan.Bateman at oracle.com  Thu Aug 25 08:46:47 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 25 Aug 2011 09:46:47 +0100
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors
	to	InternalError and VirtualMachineError
In-Reply-To: <4E560191.3020500@gmx.de>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>	<4E54AE42.7000904@oracle.com>	<4E551487.8050007@oracle.com>
	<4E55EB89.7060906@oracle.com> <4E560191.3020500@gmx.de>
Message-ID: <4E560BF7.3040700@oracle.com>

Sebastian Sickelmann wrote:
> :
>
> I have build(make clean, make all, make images) the jdk-repo only. Or 
> does i have to pull in the changes of my jdk8/tl/jdk clone to my 
> jdk8/jdk8/jdk clone to check this?
>
> Has someone in the past evaluated if there is a good way to do 
> regression tests for serialVersionUID in jdk-sources?
To see the issue then you'll need a build of jdk8/tl rather than 
jdk8/jdk8 as the changes haven't been integrated into the master yet. We 
really need to get to the point where the entire JDK is built with 
-Xlint:serial -Werror as it's too easy to inadvertently change the SUID. 
Aside from a few specified tests, the tests in the jdk repository don't 
test serialization compatibility.

-Alan




From eamonn.mcmanus at oracle.com  Thu Aug 25 08:59:04 2011
From: eamonn.mcmanus at oracle.com (Eamonn McManus)
Date: Thu, 25 Aug 2011 10:59:04 +0200
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors to
	InternalError and VirtualMachineError
In-Reply-To: <4E55F2FF.80108@oracle.com>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>
	<4E54AE42.7000904@oracle.com> <4E551487.8050007@oracle.com>
	<4E55EB89.7060906@oracle.com> <4E55F2FF.80108@oracle.com>
Message-ID: <4E560ED8.8010504@oracle.com>

Could we perhaps have the JDK build use an annotation processor that 
requires every public class in java.* javax.* etc that is serializable 
to either declare a serialVersionUID or have 
@SuppressWarnings("serial")? The amount of grief we have had over the 
years with this would easily justify the effort.

?amonn


On 25/8/11 9:00 AM, Joe Darcy wrote:
> Alan Bateman wrote:
>> Joe Darcy wrote:
>>> Hi Alan.
>>>
>>> I did check for that point in my review :-)
>>>
>>> The VirtualMachineError class is abstract so as long as all its 
>>> subclasses declare a serialVersionUID, like InternalError does, I 
>>> think we're fine.
>> We need to check the serialization protocol but I'm pretty the object 
>> stream class of the supertype goes into the stream too. Also I 
>> quickly checked an an up-to-date build of jdk8/tl and its currently 
>> unable to deserialize streams contain any of the virtual machine 
>> errors like OutOfMemoryError, StackOverflowError, etc.
>
> *sigh*
>
> Thanks for checking on this Alan; I'll prepare a changeset with the 
> explicit serialVersionUID on InternalError.
>
> -Joe
>


From chris.hegarty at oracle.com  Thu Aug 25 15:10:09 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 25 Aug 2011 15:10:09 +0000
Subject: hg: jdk8/tl/jdk: 7044870:
	java/nio/channels/DatagramChannel/SelectWhenRefused.java failed
	on SUSE Linux 10
Message-ID: <20110825151031.89A11470EC@hg.openjdk.java.net>

Changeset: c9e78769c0da
Author:    chegar
Date:      2011-08-25 16:08 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9e78769c0da

7044870: java/nio/channels/DatagramChannel/SelectWhenRefused.java failed on SUSE Linux 10
Reviewed-by: alanb, chegar
Contributed-by: kurchi.subhra.hazra at oracle.com

! test/java/nio/channels/DatagramChannel/SelectWhenRefused.java



From joe.darcy at oracle.com  Thu Aug 25 16:01:16 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 25 Aug 2011 09:01:16 -0700
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors to
	InternalError and VirtualMachineError
In-Reply-To: <4E560ED8.8010504@oracle.com>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>
	<4E54AE42.7000904@oracle.com> <4E551487.8050007@oracle.com>
	<4E55EB89.7060906@oracle.com> <4E55F2FF.80108@oracle.com>
	<4E560ED8.8010504@oracle.com>
Message-ID: <4E5671CC.6080706@oracle.com>

Eamonn McManus wrote:
> Could we perhaps have the JDK build use an annotation processor that 
> requires every public class in java.* javax.* etc that is serializable 
> to either declare a serialVersionUID or have 
> @SuppressWarnings("serial")? The amount of grief we have had over the 
> years with this would easily justify the effort.

We could achieve that effect using the "-Xlint:serial -Werror" option to 
javac during the JDK build.

-Joe

>
> ?amonn
>
>
> On 25/8/11 9:00 AM, Joe Darcy wrote:
>> Alan Bateman wrote:
>>> Joe Darcy wrote:
>>>> Hi Alan.
>>>>
>>>> I did check for that point in my review :-)
>>>>
>>>> The VirtualMachineError class is abstract so as long as all its 
>>>> subclasses declare a serialVersionUID, like InternalError does, I 
>>>> think we're fine.
>>> We need to check the serialization protocol but I'm pretty the 
>>> object stream class of the supertype goes into the stream too. Also 
>>> I quickly checked an an up-to-date build of jdk8/tl and its 
>>> currently unable to deserialize streams contain any of the virtual 
>>> machine errors like OutOfMemoryError, StackOverflowError, etc.
>>
>> *sigh*
>>
>> Thanks for checking on this Alan; I'll prepare a changeset with the 
>> explicit serialVersionUID on InternalError.
>>
>> -Joe
>>



From joe.darcy at oracle.com  Thu Aug 25 16:37:44 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 25 Aug 2011 09:37:44 -0700
Subject: JDK 8 code review request for 7082727 VirtualMachineError should
	declare its serialVersionUID
Message-ID: <4E567A58.5090801@oracle.com>

Hello.

Please review the patch below to add an explicit serialVersionUID to 
VirtualMachineError:

    7082727 VirtualMachineError should declare its serialVersionUID
    http://cr.openjdk.java.net/~darcy/7082727.0/

Thanks,

-Joe

--- old/src/share/classes/java/lang/VirtualMachineError.java    
2011-08-25 09:35:04.000000000 -0700
+++ new/src/share/classes/java/lang/VirtualMachineError.java    
2011-08-25 09:35:03.000000000 -0700
@@ -34,6 +34,8 @@
  * @since   JDK1.0
  */
 abstract public class VirtualMachineError extends Error {
+    private static final long serialVersionUID = 4161983926571568670L;
+
     /**
      * Constructs a <code>VirtualMachineError</code> with no detail 
message.
      */



From Alan.Bateman at oracle.com  Thu Aug 25 16:40:09 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 25 Aug 2011 17:40:09 +0100
Subject: JDK 8 code review request for 7082727 VirtualMachineError should
	declare its serialVersionUID
In-Reply-To: <4E567A58.5090801@oracle.com>
References: <4E567A58.5090801@oracle.com>
Message-ID: <4E567AE9.5030301@oracle.com>

Joe Darcy wrote:
> Hello.
>
> Please review the patch below to add an explicit serialVersionUID to 
> VirtualMachineError:
>
>    7082727 VirtualMachineError should declare its serialVersionUID
>    http://cr.openjdk.java.net/~darcy/7082727.0/
>
> Thanks,
>
> -Joe
>
> --- old/src/share/classes/java/lang/VirtualMachineError.java    
> 2011-08-25 09:35:04.000000000 -0700
> +++ new/src/share/classes/java/lang/VirtualMachineError.java    
> 2011-08-25 09:35:03.000000000 -0700
> @@ -34,6 +34,8 @@
>  * @since   JDK1.0
>  */
> abstract public class VirtualMachineError extends Error {
> +    private static final long serialVersionUID = 4161983926571568670L;
> +
>     /**
>      * Constructs a <code>VirtualMachineError</code> with no detail 
> message.
>      */
>
Looks good, thanks for getting this done.

-Alan.


From joe.darcy at oracle.com  Thu Aug 25 16:43:52 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 25 Aug 2011 16:43:52 +0000
Subject: hg: jdk8/tl/jdk: 7082727: VirtualMachineError should declare its
	serialVersionUID
Message-ID: <20110825164417.3BA3F470F1@hg.openjdk.java.net>

Changeset: 624cc18a6cf9
Author:    darcy
Date:      2011-08-25 09:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624cc18a6cf9

7082727: VirtualMachineError should declare its serialVersionUID
Reviewed-by: alanb

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



From eamonn.mcmanus at oracle.com  Thu Aug 25 16:50:00 2011
From: eamonn.mcmanus at oracle.com (Eamonn McManus)
Date: Thu, 25 Aug 2011 18:50:00 +0200
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors to
	InternalError and VirtualMachineError
In-Reply-To: <4E5671CC.6080706@oracle.com>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>
	<4E54AE42.7000904@oracle.com> <4E551487.8050007@oracle.com>
	<4E55EB89.7060906@oracle.com> <4E55F2FF.80108@oracle.com>
	<4E560ED8.8010504@oracle.com> <4E5671CC.6080706@oracle.com>
Message-ID: <4E567D38.6080909@oracle.com>

Yeah, I guess so. We'd have to add @SuppressWarnings("serial") to some 
non-public classes but so what.

?amonn


On 25/8/11 6:01 PM, Joe Darcy wrote:
> Eamonn McManus wrote:
>> Could we perhaps have the JDK build use an annotation processor that 
>> requires every public class in java.* javax.* etc that is 
>> serializable to either declare a serialVersionUID or have 
>> @SuppressWarnings("serial")? The amount of grief we have had over the 
>> years with this would easily justify the effort.
>
> We could achieve that effect using the "-Xlint:serial -Werror" option 
> to javac during the JDK build.
>
> -Joe
>
>>
>> ?amonn
>>
>>
>> On 25/8/11 9:00 AM, Joe Darcy wrote:
>>> Alan Bateman wrote:
>>>> Joe Darcy wrote:
>>>>> Hi Alan.
>>>>>
>>>>> I did check for that point in my review :-)
>>>>>
>>>>> The VirtualMachineError class is abstract so as long as all its 
>>>>> subclasses declare a serialVersionUID, like InternalError does, I 
>>>>> think we're fine.
>>>> We need to check the serialization protocol but I'm pretty the 
>>>> object stream class of the supertype goes into the stream too. Also 
>>>> I quickly checked an an up-to-date build of jdk8/tl and its 
>>>> currently unable to deserialize streams contain any of the virtual 
>>>> machine errors like OutOfMemoryError, StackOverflowError, etc.
>>>
>>> *sigh*
>>>
>>> Thanks for checking on this Alan; I'll prepare a changeset with the 
>>> explicit serialVersionUID on InternalError.
>>>
>>> -Joe
>>>
>


From Lance.Andersen at oracle.com  Thu Aug 25 16:50:36 2011
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 25 Aug 2011 12:50:36 -0400
Subject: JDK 8 code review request for 7082727 VirtualMachineError should
	declare its serialVersionUID
In-Reply-To: <4E567A58.5090801@oracle.com>
References: <4E567A58.5090801@oracle.com>
Message-ID: <8D25F5D5-D545-497D-A2E6-89712DB9139F@oracle.com>

Looks good joe.
On Aug 25, 2011, at 12:37 PM, Joe Darcy wrote:

> Hello.
> 
> Please review the patch below to add an explicit serialVersionUID to VirtualMachineError:
> 
>   7082727 VirtualMachineError should declare its serialVersionUID
>   http://cr.openjdk.java.net/~darcy/7082727.0/
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/share/classes/java/lang/VirtualMachineError.java    2011-08-25 09:35:04.000000000 -0700
> +++ new/src/share/classes/java/lang/VirtualMachineError.java    2011-08-25 09:35:03.000000000 -0700
> @@ -34,6 +34,8 @@
> * @since   JDK1.0
> */
> abstract public class VirtualMachineError extends Error {
> +    private static final long serialVersionUID = 4161983926571568670L;
> +
>    /**
>     * Constructs a <code>VirtualMachineError</code> with no detail message.
>     */
> 


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



From sebastian.sickelmann at gmx.de  Thu Aug 25 17:09:36 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Thu, 25 Aug 2011 19:09:36 +0200
Subject: =?US-ASCII?Q?Re=3A_JDK_8_code_review_request_for_7082727_Virtua?=
	=?US-ASCII?Q?lMachineError_should=09declare_its_serialVersionUID?=
In-Reply-To: <4E567A58.5090801@oracle.com>
References: <4E567A58.5090801@oracle.com>
Message-ID: <dee97349-a103-4380-b42a-2da1bc184c48@email.android.com>

Looks good. 
Thanks For fixing. 
-- Sebastian


Joe Darcy <joe.darcy at oracle.com> schrieb:

>Hello.
>
>Please review the patch below to add an explicit serialVersionUID to 
>VirtualMachineError:
>
>    7082727 VirtualMachineError should declare its serialVersionUID
>    http://cr.openjdk.java.net/~darcy/7082727.0/
>
>Thanks,
>
>-Joe
>
>--- old/src/share/classes/java/lang/VirtualMachineError.java    
>2011-08-25 09:35:04.000000000 -0700
>+++ new/src/share/classes/java/lang/VirtualMachineError.java    
>2011-08-25 09:35:03.000000000 -0700
>@@ -34,6 +34,8 @@
>  * @since   JDK1.0
>  */
> abstract public class VirtualMachineError extends Error {
>+    private static final long serialVersionUID = 4161983926571568670L;
>+
>     /**
>      * Constructs a <code>VirtualMachineError</code> with no detail 
>message.
>      */
>



From xueming.shen at oracle.com  Thu Aug 25 18:28:03 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 25 Aug 2011 11:28:03 -0700
Subject: Code review request 7077769: (zipfs) ZipFileSystem.writeCEN()
	writes wrong "data size" for ZIP64 extended information extra field
In-Reply-To: <4E54A2F6.6040204@oracle.com>
References: <4E5446A9.4030004@oracle.com> <4E54A2F6.6040204@oracle.com>
Message-ID: <4E569433.3030802@oracle.com>

Alan

Webrev has been updated to

(1) use the new try(resource){}
(2) update the existing test case LargetZip to
      a) be able to add one more entry at the end of the > 4g zip via 
ZipFileSystem
      b) read through all entries inside the large zipfile, given 
zipfile's self-crc-check
          it guarantees the correctness of the zipfile. So it now goes 
through 18G+
          file read/write for one round:-)
      (you have to use -XX:-UseLoopPredicate on server vm for now to 
workaround
        the C2 loop redicate bug)

http://cr.openjdk.java.net/~sherman/7077769/webrev/

-Sherman

On 08/24/2011 12:06 AM, Alan Bateman wrote:
> Xueming Shen wrote:
>> :
>>
>> Fix has been verified/test manually with existing test cases. Given 
>> the nature
>> of the > 4G zip data file. I'm not including an auto regression test.
>>
>> Webrev is at
>>
>> http://cr.openjdk.java.net/~sherman/7077769/webrev 
> The zip64 fix looks okay to me. The fix to sync() is okay too although 
> I would change this to use try-with-resources.
>
> On the test, I agree an automated test might be too slow to run. 
> However, as zip64 is tricky to get right then having a sanity test in 
> the test tree (without a @test tag) would be useful.
>
> -Alan



From Ulf.Zibis at gmx.de  Thu Aug 25 18:23:06 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 25 Aug 2011 20:23:06 +0200
Subject: Enumeration adapters in SE 8
In-Reply-To: <1255060618-1314260361-cardhu_decombobulator_blackberry.rim.net-982829995-@b25.c3.bise7.blackberry>
References: <05EDC0AC-8754-4A5C-9F18-2DA29BE7743E@oracle.com><CABKW8Ri_chGS2DY9eKVa0T1HeLP3TwoDuXOSpLSz-7mAJHC6kg@mail.gmail.com><CAPmOpX67m+YC9VWJ8dJ0uBvpgZOYKgA-Q42dkqKycAf=YQnCEA@mail.gmail.com><CANiekN6X5J0Za3rn-SVWVuLMn7YZ1ZjY93fC+t+65vzVAmEbNw@mail.gmail.com><BCB23AFD-4CBC-4A77-920D-2A86E87C9E48@mac.com>
	<1255060618-1314260361-cardhu_decombobulator_blackberry.rim.net-982829995-@b25.c3.bise7.blackberry>
Message-ID: <4E56930A.7050103@gmx.de>

Some other candidates for Iterable:
Bug 6793773 - Let CharsetProvider implement Iterable 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6793773>
Bug 6935695 - String should implement Iterable 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6935695>

-Ulf


Am 25.08.2011 10:19, schrieb mike.skells at talk21.com:
> Hi
> I know this is slightly off topic but f there is a discussion on enhancing the for each loop ...
>
> 1 is there any chance that we could use ARM functionality and allow a ClosableIterator to be introduced. There are many occasions that an iterator is backed by some resource (list of lines in a file, list of rows in a database) but there is no mechanism in the foreach loop to close this implicit resource. This was one thing that C# got right in its implementation, if the iterator implements IDisposable then it is disposed. In java it may require an additional interface although I doubt that any current Iterators implement Closable
>
> 2 it would be nice if the foreach loop honoured the RandomAccess semantics but it is probably too late for that now
>


From ahughes at redhat.com  Thu Aug 25 20:53:34 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 25 Aug 2011 21:53:34 +0100
Subject: hg: jdk8/tl/jdk: 7082727: VirtualMachineError should declare its
	serialVersionUID
In-Reply-To: <20110825164417.3BA3F470F1@hg.openjdk.java.net>
References: <20110825164417.3BA3F470F1@hg.openjdk.java.net>
Message-ID: <20110825205333.GA9583@rivendell.middle-earth.co.uk>

On 16:43 Thu 25 Aug     , joe.darcy at oracle.com wrote:
> Changeset: 624cc18a6cf9
> Author:    darcy
> Date:      2011-08-25 09:42 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624cc18a6cf9
> 
> 7082727: VirtualMachineError should declare its serialVersionUID
> Reviewed-by: alanb
> 
> ! src/share/classes/java/lang/VirtualMachineError.java
> 

Is there a general policy on serialVersionUIDs within the JDK i.e. that they are declared?
I've seen a few warnings during builds, and I'm wondering what the correct fix is in the
majority of cases.
-- 
Andrew :)

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

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From ahughes at redhat.com  Thu Aug 25 21:01:41 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 25 Aug 2011 22:01:41 +0100
Subject: Enhance toString() to return structured info, for certificate
	and probably more
In-Reply-To: <4E55B66C.4020008@oracle.com>
References: <4E55B66C.4020008@oracle.com>
Message-ID: <20110825210141.GB9583@rivendell.middle-earth.co.uk>

On 10:41 Thu 25 Aug     , Weijun Wang wrote:
> Hi All
> 
> I was talking with Xuelei on how to better display certificate info. 
> There are 3 cases we can currently think of:
> 
> 1. debug output
> 2. keytool/jarsigner output
> 3. Java plugin display
> 
> The 1st one is the most primitive one and can be a single string, the 
> 2nd is also a string but have some format and needs to localized, the 
> third is a series of Swing controls.
> 
> But the contents of all 3 are the same, and hopefully can be provided in 
> a single method. Each consumer can just display it in its own style, 
> with no need to understand Certificate fields, OIDs, etc. It's just like 
> XSLT transformation of XML files.
> 
> So what shall I do? Let toString() outputs a long string in XML or JSON?
> 

I be against that.  It goes against the usual expectation of toString output
being (fairly) human-readable.

> Or, create a new method describe() or toDescription() that returns a 
> UnmodifiableMap (based on a LinkedHashMap to preserve order)?
> 
> I prefer the latter because there is no need to parse the output, and at 
> least in the case of certificate, since a certificate contains 
> extensions, it's very easy to stuff several maps inside another one. The 
> map's keys are strings, and values can be another map or a simple data 
> object, say, primitive, string, or Date.
> 
> So this needs a new interface Descriptable. It can either be:
> 
>     interface sun.security.util.Descriptable;
>     sun.security.x509.X509CertImpl implements Descriptable;
>     sun.security.x509.Extension implements Descriptable;
> 
> or
> 
>     interface java.security.Descriptable;
>     java.security.cert.X509Certificate implements Descriptable;
>     java.security.cert.Extension implements Descriptable;
> 
> or if there are other people find it useful, it can be inside the 
> java.util package.
> 

This sounds like a good idea to me, but would there be a standard set
of keys and values?  Especially if it's going to be part of
java.security, the keys and values should be part of the
method specification.  This becomes a harder task if it's generalised
into java.util.

BTW, it should be Describable :-)

> What's your ideas? Do you also need such a method?
> 
> Thanks
> Max

-- 
Andrew :)

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

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From sebastian.sickelmann at gmx.de  Thu Aug 25 21:48:55 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Thu, 25 Aug 2011 23:48:55 +0200
Subject: hg: jdk8/tl/jdk: 7082727: VirtualMachineError should declare
	its	serialVersionUID
In-Reply-To: <20110825205333.GA9583@rivendell.middle-earth.co.uk>
References: <20110825164417.3BA3F470F1@hg.openjdk.java.net>
	<20110825205333.GA9583@rivendell.middle-earth.co.uk>
Message-ID: <4E56C347.7050203@gmx.de>

Am 25.08.2011 22:53, schrieb Dr Andrew John Hughes:
> On 16:43 Thu 25 Aug     , joe.darcy at oracle.com wrote:
>> IChangeset: 624cc18a6cf9
>> Author:    darcy
>> Date:      2011-08-25 09:42 -0700
>> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624cc18a6cf9
>>
>> 7082727: VirtualMachineError should declare its serialVersionUID
>> Reviewed-by: alanb
>>
>> ! src/share/classes/java/lang/VirtualMachineError.java
>>
> Is there a general policy on serialVersionUIDs within the JDK i.e. that they are declared?
> I've seen a few warnings during builds, and I'm wondering what the correct fix is in the
> majority of cases.
I think that every Serialezable Class in the jdk should declare a 
serialVersionUID to achieve compatibility  between versions of the jdk.
If not at the moment the default serialVersionUID changes (not only on 
changing non-transient instance-fields as a thought) the compatibility 
will break.

And as 
http://download.oracle.com/javase/7/docs/platform/serialization/spec/class.html#4100 
specifies it breaks on "simply change (add,remove,signature-change) 
non-private constructors. Even changing a non-private method can change 
the default serialVersionUID which is a shock for me. This two 
dependencies(constructors,methods) to serialVersionUID calculation 
doen't make any sence to me.
Does someone know why?
I think that there is no way of changing this in future, isn't it?

-- Sebastian


From sebastian.sickelmann at gmx.de  Fri Aug 26 00:00:53 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 26 Aug 2011 02:00:53 +0200
Subject: Request for review Remove "private" cause in jdk exceptions
In-Reply-To: <4E56CB90.60508@gmx.de>
References: <4E525386.9000207@gmx.de>
	<4E52758D.2020208@oracle.com>	<4E56C6CC.7010305@gmx.de>
	<4E56CB90.60508@gmx.de>
Message-ID: <4E56E235.6010307@gmx.de>

Am 26.08.2011 00:24, schrieb Sebastian Sickelmann:
> Am 26.08.2011 00:03, schrieb Sebastian Sickelmann:
>> I have found more places in jdk source where an Exception has a 
>> private cause field.
>>
>> share/classes/javax/management/remote/JMXProviderException.java:    
>> private Throwable cause = null;
>> share/classes/javax/xml/crypto/KeySelectorException.java:    private 
>> Throwable cause;
>> share/classes/javax/xml/crypto/NoSuchMechanismException.java:    
>> private Throwable cause;
>> share/classes/javax/xml/crypto/MarshalException.java:    private 
>> Throwable cause;
>> share/classes/javax/xml/crypto/dsig/XMLSignatureException.java:    
>> private Throwable cause;
>> share/classes/javax/xml/crypto/dsig/TransformException.java:    
>> private Throwable cause;
>> share/classes/javax/xml/crypto/URIReferenceException.java:    private 
>> Throwable cause;
>>
>> 7081804 handles NoSuchMechanismException.
>> Is there a way to expand it to at least the xml/crypto/**/* Exceptions?
>> JMXProviderException should be fine too.
>>
>> I would create a CR for the changes to me made to change and test this.
>> Would it be good to have some utility-code in Throwable to don't 
>> introduce to much code-duplication?
>>
>> -- Sebastian
> After a very quick analysis i think i found more candidates for 
> removing private causes.
> share/classes/javax/security/sasl/SaslException.java:    private 
> Throwable _exception;
> share/classes/java/lang/reflect/UndeclaredThrowableException.java:    
> private Throwable undeclaredThrowable;
> share/classes/java/lang/reflect/InvocationTargetException.java:    
> private Throwable target;
> share/classes/java/lang/ClassNotFoundException.java:    private 
> Throwable ex;
> share/classes/com/sun/java/browser/dom/DOMAccessException.java:    
> private Throwable ex;
> share/classes/com/sun/java/browser/dom/DOMUnsupportedException.java:    private 
> Throwable ex;
> share/classes/javax/naming/NamingException.java:    protected 
> Throwable rootException = null;
> share/classes/java/rmi/RemoteException.java:    public Throwable detail;
> share/classes/java/rmi/activation/ActivationException.java:    public 
> Throwable detail;
>
> Some of them need deeper inspection. Some of them are the same as the 
> above noted Exceptions in xml/crypto package.
>
> - Sebastian
OK. Webrev is there: 
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/

Can someone review this?

-- Sebastian


From joe.darcy at oracle.com  Fri Aug 26 00:01:11 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 25 Aug 2011 17:01:11 -0700
Subject: hg: jdk8/tl/jdk: 7082727: VirtualMachineError should declare
	its serialVersionUID
In-Reply-To: <20110825205333.GA9583@rivendell.middle-earth.co.uk>
References: <20110825164417.3BA3F470F1@hg.openjdk.java.net>
	<20110825205333.GA9583@rivendell.middle-earth.co.uk>
Message-ID: <4E56E247.1090705@oracle.com>

Dr Andrew John Hughes wrote:
> On 16:43 Thu 25 Aug     , joe.darcy at oracle.com wrote:
>   
>> Changeset: 624cc18a6cf9
>> Author:    darcy
>> Date:      2011-08-25 09:42 -0700
>> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624cc18a6cf9
>>
>> 7082727: VirtualMachineError should declare its serialVersionUID
>> Reviewed-by: alanb
>>
>> ! src/share/classes/java/lang/VirtualMachineError.java
>>
>>     
>
> Is there a general policy on serialVersionUIDs within the JDK i.e. that they are declared?
> I've seen a few warnings during builds, and I'm wondering what the correct fix is in the
> majority of cases.
>   

What the policy *should* be is roughly "all serializable classes that 
are exported API should declare serialVersionUIDs."  There could be 
exceptions to this in awt (or is it swing?) where some classes are 
declared serializable but are only intended to be written and read by 
the same release as opposed to across releases.  This policy can be 
enforced by changing the build to include "javac -Xlint:serial 
-Werror".  Additionally, for the classes that are supposed to be 
serializable across platforms, the values of the serialVersionUIDs 
should be tracked too.

If a class doesn't already have a serialialVersionUID, the correct fix 
is usually to declare an explicit serialVersionUID which matches the 
computed serialVersionUID in the first platform release the class was 
introduced.

-Joe




From mike.duigou at oracle.com  Fri Aug 26 02:03:36 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 25 Aug 2011 19:03:36 -0700
Subject: Enhance toString() to return structured info,
	for certificate and probably more
In-Reply-To: <20110825210141.GB9583@rivendell.middle-earth.co.uk>
References: <4E55B66C.4020008@oracle.com>
	<20110825210141.GB9583@rivendell.middle-earth.co.uk>
Message-ID: <C9F2D223-0018-425D-B249-05E173BCA5D1@oracle.com>


On Aug 25 2011, at 14:01 , Dr Andrew John Hughes wrote:

> On 10:41 Thu 25 Aug     , Weijun Wang wrote:
>> Hi All
>> 
>> I was talking with Xuelei on how to better display certificate info. 
>> There are 3 cases we can currently think of:
>> 
>> 1. debug output
>> 2. keytool/jarsigner output
>> 3. Java plugin display
>> 
>> The 1st one is the most primitive one and can be a single string, the 
>> 2nd is also a string but have some format and needs to localized, the 
>> third is a series of Swing controls.
>> 
>> But the contents of all 3 are the same, and hopefully can be provided in 
>> a single method. Each consumer can just display it in its own style, 
>> with no need to understand Certificate fields, OIDs, etc. It's just like 
>> XSLT transformation of XML files.
>> 
>> So what shall I do? Let toString() outputs a long string in XML or JSON?
>> 
> 
> I be against that.  It goes against the usual expectation of toString output
> being (fairly) human-readable.

I agree. The format of toString() should favour debugging uses rather than machine readable. Other than for primitive types it's usually a mistake if the output of toString() meant to be machine parsed. If there needs to be machine parsable text representation then that should be on some other method.

Secondly, the toString output format, being for debugging doesn't need to display every byte of the data, in some cases such as a 4096 RSA key, the hash value of the key is generally more useful than emitting the whole key. No reasonable human comparing two traces would want to check 8192 hex bytes to see if two keys match. Making it easy by printing the key hash helps a lot.

Mike



From weijun.wang at oracle.com  Fri Aug 26 02:22:27 2011
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 26 Aug 2011 10:22:27 +0800
Subject: Enhance toString() to return structured info, for certificate
	and probably more
In-Reply-To: <C9F2D223-0018-425D-B249-05E173BCA5D1@oracle.com>
References: <4E55B66C.4020008@oracle.com>
	<20110825210141.GB9583@rivendell.middle-earth.co.uk>
	<C9F2D223-0018-425D-B249-05E173BCA5D1@oracle.com>
Message-ID: <4E570363.8070601@oracle.com>

Well, I mentioned toString() there just to make it look absurd so that I 
can promote my alternative method. :)

As for the toDescription() method, do you know if there are other cases 
it can be useful?

Thanks
Max


On 08/26/2011 10:03 AM, Mike Duigou wrote:
>
> On Aug 25 2011, at 14:01 , Dr Andrew John Hughes wrote:
>
>> On 10:41 Thu 25 Aug     , Weijun Wang wrote:
>>> Hi All
>>>
>>> I was talking with Xuelei on how to better display certificate info.
>>> There are 3 cases we can currently think of:
>>>
>>> 1. debug output
>>> 2. keytool/jarsigner output
>>> 3. Java plugin display
>>>
>>> The 1st one is the most primitive one and can be a single string, the
>>> 2nd is also a string but have some format and needs to localized, the
>>> third is a series of Swing controls.
>>>
>>> But the contents of all 3 are the same, and hopefully can be provided in
>>> a single method. Each consumer can just display it in its own style,
>>> with no need to understand Certificate fields, OIDs, etc. It's just like
>>> XSLT transformation of XML files.
>>>
>>> So what shall I do? Let toString() outputs a long string in XML or JSON?
>>>
>>
>> I be against that.  It goes against the usual expectation of toString output
>> being (fairly) human-readable.
>
> I agree. The format of toString() should favour debugging uses rather than machine readable. Other than for primitive types it's usually a mistake if the output of toString() meant to be machine parsed. If there needs to be machine parsable text representation then that should be on some other method.
>
> Secondly, the toString output format, being for debugging doesn't need to display every byte of the data, in some cases such as a 4096 RSA key, the hash value of the key is generally more useful than emitting the whole key. No reasonable human comparing two traces would want to check 8192 hex bytes to see if two keys match. Making it easy by printing the key hash helps a lot.
>
> Mike
>


From pcj at roundroom.net  Fri Aug 26 06:32:14 2011
From: pcj at roundroom.net (Peter Jones)
Date: Fri, 26 Aug 2011 02:32:14 -0400
Subject: Request for review Remove "private" cause in jdk exceptions
In-Reply-To: <4E56E235.6010307@gmx.de>
References: <4E525386.9000207@gmx.de>
	<4E52758D.2020208@oracle.com>	<4E56C6CC.7010305@gmx.de>
	<4E56CB90.60508@gmx.de> <4E56E235.6010307@gmx.de>
Message-ID: <B74C6CB1-874F-4185-AC14-A3ABDA2879A0@roundroom.net>

On Aug 25, 2011, at 8:00 PM, Sebastian Sickelmann wrote:
> Am 26.08.2011 00:24, schrieb Sebastian Sickelmann:
>> Am 26.08.2011 00:03, schrieb Sebastian Sickelmann:
>>> I have found more places in jdk source where an Exception has a private cause field.
>>> 
>>> share/classes/javax/management/remote/JMXProviderException.java:    private Throwable cause = null;
>>> share/classes/javax/xml/crypto/KeySelectorException.java:    private Throwable cause;
>>> share/classes/javax/xml/crypto/NoSuchMechanismException.java:    private Throwable cause;
>>> share/classes/javax/xml/crypto/MarshalException.java:    private Throwable cause;
>>> share/classes/javax/xml/crypto/dsig/XMLSignatureException.java:    private Throwable cause;
>>> share/classes/javax/xml/crypto/dsig/TransformException.java:    private Throwable cause;
>>> share/classes/javax/xml/crypto/URIReferenceException.java:    private Throwable cause;
>>> 
>>> 7081804 handles NoSuchMechanismException.
>>> Is there a way to expand it to at least the xml/crypto/**/* Exceptions?
>>> JMXProviderException should be fine too.
>>> 
>>> I would create a CR for the changes to me made to change and test this.
>>> Would it be good to have some utility-code in Throwable to don't introduce to much code-duplication?
>>> 
>>> -- Sebastian
>> After a very quick analysis i think i found more candidates for removing private causes.
>> share/classes/javax/security/sasl/SaslException.java:    private Throwable _exception;
>> share/classes/java/lang/reflect/UndeclaredThrowableException.java:    private Throwable undeclaredThrowable;
>> share/classes/java/lang/reflect/InvocationTargetException.java:    private Throwable target;
>> share/classes/java/lang/ClassNotFoundException.java:    private Throwable ex;
>> share/classes/com/sun/java/browser/dom/DOMAccessException.java:    private Throwable ex;
>> share/classes/com/sun/java/browser/dom/DOMUnsupportedException.java:    private Throwable ex;
>> share/classes/javax/naming/NamingException.java:    protected Throwable rootException = null;
>> share/classes/java/rmi/RemoteException.java:    public Throwable detail;
>> share/classes/java/rmi/activation/ActivationException.java:    public Throwable detail;
>> 
>> Some of them need deeper inspection. Some of them are the same as the above noted Exceptions in xml/crypto package.
>> 
>> - Sebastian
> OK. Webrev is there: http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/
> 
> Can someone review this?

Sebastian,

Public fields like RemoteException.detail, ill-advised as they may have been, cannot be removed (would break binary compatibility).

This change proposes additions to the public API (subclass interface) of java.lang.Throwable, which would need additional approval process.  Without getting into detailed design critique, the proposed protected methods seem to add subtle complexity to the subclass interface of this central class, which leads me to:

Is there a particular problem that these changes are attempting to address?  Many of these exception classes had cause-like fields prior to the addition of Throwable.cause in 1.4, and as described in their class docs, for 1.4 they were each retrofitted, with some care, to work well with the general cause APIs added to Throwable.  (Also see the doc for Throwable.getCause, which describes how subclasses can override it to take responsibility for their causes.)

These changes seem to be about implementing an alternate approach to that retrofitting, with considerably higher complexity (serialized form compatibility code) and risk, and I don't understand why-- I don't see a motivation discussed earlier on core-libs-dev?

Cheers,

-- Peter



From Alan.Bateman at oracle.com  Fri Aug 26 07:22:19 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Aug 2011 08:22:19 +0100
Subject: Request for review Remove "private" cause in jdk exceptions
In-Reply-To: <4E56E235.6010307@gmx.de>
References: <4E525386.9000207@gmx.de>	<4E52758D.2020208@oracle.com>	<4E56C6CC.7010305@gmx.de>	<4E56CB90.60508@gmx.de>
	<4E56E235.6010307@gmx.de>
Message-ID: <4E5749AB.9040705@oracle.com>

Sebastian Sickelmann wrote:
>
> OK. Webrev is there: 
> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/ 
>
>
> Can someone review this?
I think this one will require careful review and I'm not even sure that 
it's worth it. Using serialPersistentFields and overriding the 
readObject/writeObject method is the right thing for this kind of issue 
but it's bringing complexity that hardy seems worth it. There are a few 
awkward issues in here. I have to admit that I don't know, without 
checking, what the deal is with APIs that continued life as standalone 
JSRs after going into Java SE. I also suspect that some of these changes 
have subtly changed the behavior of a few of the exceptions. On 
RemoteException the patch removes a public field which we can't do. I 
think the other clean-up patches that you have posted here in the last 
week or two are good and we should move forward on them.

-Alan.


From fweimer at bfk.de  Fri Aug 26 07:26:13 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 26 Aug 2011 07:26:13 +0000
Subject: Enhance toString() to return structured info,
	for certificate and probably more
In-Reply-To: <4E55B66C.4020008@oracle.com> (Weijun Wang's message of "Thu, 25
	Aug 2011 10:41:48 +0800")
References: <4E55B66C.4020008@oracle.com>
Message-ID: <82ei084oru.fsf@mid.bfk.de>

* Weijun Wang:

> What's your ideas? Do you also need such a method?

I suspect that many applications which need to look at certificates in
detail would benefit more from an official ASN.1 decoder.  Defining yet
another data model for X.509 certificates (after ASN.1 and the current
Java API) seems a bit superfluous, IMHO.  But perhaps I misunderstood
what you meant.

-- 
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 sean.coffey at oracle.com  Fri Aug 26 09:56:21 2011
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Fri, 26 Aug 2011 09:56:21 +0000
Subject: hg: jdk8/tl/jdk: 7024697: SessionRef.dispose() should determine if
	the token referred to by the token object is still valid
Message-ID: <20110826095639.080AB47129@hg.openjdk.java.net>

Changeset: 3a13b7ab57f7
Author:    coffeys
Date:      2011-08-26 10:47 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a13b7ab57f7

7024697: SessionRef.dispose() should determine if the token referred to by the token object is still valid
Reviewed-by: valeriep

! src/share/classes/sun/security/pkcs11/Session.java
! src/share/classes/sun/security/pkcs11/Token.java



From sebastian.sickelmann at gmx.de  Fri Aug 26 10:59:45 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 26 Aug 2011 12:59:45 +0200
Subject: Request for review Remove "private" cause in jdk exceptions
In-Reply-To: <B74C6CB1-874F-4185-AC14-A3ABDA2879A0@roundroom.net>
References: <4E525386.9000207@gmx.de>
	<4E52758D.2020208@oracle.com>	<4E56C6CC.7010305@gmx.de>
	<4E56CB90.60508@gmx.de> <4E56E235.6010307@gmx.de>
	<B74C6CB1-874F-4185-AC14-A3ABDA2879A0@roundroom.net>
Message-ID: <4E577CA1.4000000@gmx.de>

Am 26.08.2011 08:32, schrieb Peter Jones:
> On Aug 25, 2011, at 8:00 PM, Sebastian Sickelmann wrote:
>> Am 26.08.2011 00:24, schrieb Sebastian Sickelmann:
>>> Am 26.08.2011 00:03, schrieb Sebastian Sickelmann:
>>>> I have found more places in jdk source where an Exception has a private cause field.
>>>>
>>>> share/classes/javax/management/remote/JMXProviderException.java:    private Throwable cause = null;
>>>> share/classes/javax/xml/crypto/KeySelectorException.java:    private Throwable cause;
>>>> share/classes/javax/xml/crypto/NoSuchMechanismException.java:    private Throwable cause;
>>>> share/classes/javax/xml/crypto/MarshalException.java:    private Throwable cause;
>>>> share/classes/javax/xml/crypto/dsig/XMLSignatureException.java:    private Throwable cause;
>>>> share/classes/javax/xml/crypto/dsig/TransformException.java:    private Throwable cause;
>>>> share/classes/javax/xml/crypto/URIReferenceException.java:    private Throwable cause;
>>>>
>>>> 7081804 handles NoSuchMechanismException.
>>>> Is there a way to expand it to at least the xml/crypto/**/* Exceptions?
>>>> JMXProviderException should be fine too.
>>>>
>>>> I would create a CR for the changes to me made to change and test this.
>>>> Would it be good to have some utility-code in Throwable to don't introduce to much code-duplication?
>>>>
>>>> -- Sebastian
>>> After a very quick analysis i think i found more candidates for removing private causes.
>>> share/classes/javax/security/sasl/SaslException.java:    private Throwable _exception;
>>> share/classes/java/lang/reflect/UndeclaredThrowableException.java:    private Throwable undeclaredThrowable;
>>> share/classes/java/lang/reflect/InvocationTargetException.java:    private Throwable target;
>>> share/classes/java/lang/ClassNotFoundException.java:    private Throwable ex;
>>> share/classes/com/sun/java/browser/dom/DOMAccessException.java:    private Throwable ex;
>>> share/classes/com/sun/java/browser/dom/DOMUnsupportedException.java:    private Throwable ex;
>>> share/classes/javax/naming/NamingException.java:    protected Throwable rootException = null;
>>> share/classes/java/rmi/RemoteException.java:    public Throwable detail;
>>> share/classes/java/rmi/activation/ActivationException.java:    public Throwable detail;
>>>
>>> Some of them need deeper inspection. Some of them are the same as the above noted Exceptions in xml/crypto package.
>>>
>>> - Sebastian
>> OK. Webrev is there: http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/
>>
>> Can someone review this?
> Sebastian,
>
> Public fields like RemoteException.detail, ill-advised as they may have been, cannot be removed (would break binary compatibility).
Sorry for that. It was more a reflex (remove "evil" public fields) than 
a real problem with this. Breaking this would breaking binary 
compatibility but can this be a real show-stopper for not fixing this? 
But you are right. Changes with binary incompatibility should be done 
really carefully.
> This change proposes additions to the public API (subclass interface) of java.lang.Throwable, which would need additional approval process.  Without getting into detailed design critique, the proposed protected methods seem to add subtle complexity to the subclass interface of this central class, which leads me to:
>
> Is there a particular problem that these changes are attempting to address?  Many of these exception classes had cause-like fields prior to the addition of Throwable.cause in 1.4, and as described in their class docs, for 1.4 they were each retrofitted, with some care, to work well with the general cause APIs added to Throwable.  (Also see the doc for Throwable.getCause, which describes how subclasses can override it to take responsibility for their causes.)
>
> These changes seem to be about implementing an alternate approach to that retrofitting, with considerably higher complexity (serialized form compatibility code) and risk, and I don't understand why-- I don't see a motivation discussed earlier on core-libs-dev?
Discussion started at core-libs-dev in another threads[1]. The 
main-reason was to chain more Exceptions together where possible. I 
changed the NoSuchMechanismException in javax.xml.crypto while try to 
chain more Exceptions that extends RuntimeException.
I just removed the field, Alan noted that this would change to 
compatibility and said that this CR should be discussed at security-dev. 
Additionally he created a bug "7081804: Remove cause field from 
javax.xml.crypto.NoSuchMechnismException"[3]

The changes for chained-exceptions in Throwable made to 
javax/xml/crypto/*Exceptions are not done so well as in the other cases 
here. So i tried to fix it like here[2].

Alternatively i could fix javax/xml/crypto by adopting the solution used 
in the other cases.

The question i have is what is the best solution that should used. 
Changing the serialization thought custom serialization or through using 
the solution used in the other cases? I think we should only have one 
solution to address this.
> Cheers,
>
> -- Peter
>
-- Sebastian

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007462.html
[2] 
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_85919cd409d1/
[3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7081804


From dalibor.topic at oracle.com  Fri Aug 26 11:05:34 2011
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 26 Aug 2011 13:05:34 +0200
Subject: Request for review Remove "private" cause in jdk exceptions
In-Reply-To: <4E577CA1.4000000@gmx.de>
References: <4E525386.9000207@gmx.de>
	<4E52758D.2020208@oracle.com>	<4E56C6CC.7010305@gmx.de>
	<4E56CB90.60508@gmx.de> <4E56E235.6010307@gmx.de>
	<B74C6CB1-874F-4185-AC14-A3ABDA2879A0@roundroom.net>
	<4E577CA1.4000000@gmx.de>
Message-ID: <4E577DFE.3030106@oracle.com>

On 8/26/11 12:59 PM, Sebastian Sickelmann wrote:
> Am 26.08.2011 08:32, schrieb Peter Jones:
>> Public fields like RemoteException.detail, ill-advised as they may have been, cannot be removed (would break binary compatibility).
> Sorry for that. It was more a reflex (remove "evil" public fields) than a real problem with this. Breaking this would breaking binary compatibility but can this be a real show-stopper for not fixing this?

Breaking binary compatibility is bad, bad, really, really bad.

cheers,
dalibor topic
-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738 <tel:+494023646738> | Mobile: +491772664192 <tel:+491772664192>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment


From sebastian.sickelmann at gmx.de  Fri Aug 26 11:15:17 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 26 Aug 2011 13:15:17 +0200
Subject: Request for review Remove "private" cause in jdk exceptions
In-Reply-To: <4E5749AB.9040705@oracle.com>
References: <4E525386.9000207@gmx.de>	<4E52758D.2020208@oracle.com>	<4E56C6CC.7010305@gmx.de>	<4E56CB90.60508@gmx.de>
	<4E56E235.6010307@gmx.de> <4E5749AB.9040705@oracle.com>
Message-ID: <4E578045.1060906@gmx.de>

Am 26.08.2011 09:22, schrieb Alan Bateman:
> Sebastian Sickelmann wrote:
>>
>> OK. Webrev is there: 
>> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/ 
>>
>>
>> Can someone review this?
> I think this one will require careful review and I'm not even sure 
> that it's worth it. Using serialPersistentFields and overriding the 
> readObject/writeObject method is the right thing for this kind of 
> issue but it's bringing complexity that hardy seems worth it. 
As Peter noted in his reply there is another solution to handle chaining 
as introduced in Throwable for Exceptions that already has an own cause 
field.
Like in InvocationTargetException [1]. The Change is much simple and 
introduces much less complexity, for the cost of one additional 
reference to the cause (which should be no problem).

> There are a few awkward issues in here. I have to admit that I don't 
> know, without checking, what the deal is with APIs that continued life 
> as standalone JSRs after going into Java SE. I also suspect that some 
> of these changes have subtly changed the behavior of a few of the 
> exceptions. On RemoteException the patch removes a public field which 
> we can't do. I think the other clean-up patches that you have posted 
> here in the last week or two are good and we should move forward on them.
I will continue on the other issues too. Thanks for reviewing/supporting 
on my CRs. (Does CR mean Change Request???)

-- Sebastian
>
> -Alan.
[1] 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/37a05a11f281/src/share/classes/java/lang/reflect/InvocationTargetException.java


From dalibor.topic at oracle.com  Fri Aug 26 11:18:50 2011
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 26 Aug 2011 13:18:50 +0200
Subject: Request for review Remove "private" cause in jdk exceptions
In-Reply-To: <4E578045.1060906@gmx.de>
References: <4E525386.9000207@gmx.de>	<4E52758D.2020208@oracle.com>	<4E56C6CC.7010305@gmx.de>	<4E56CB90.60508@gmx.de>
	<4E56E235.6010307@gmx.de> <4E5749AB.9040705@oracle.com>
	<4E578045.1060906@gmx.de>
Message-ID: <4E57811A.4070100@oracle.com>

On 8/26/11 1:15 PM, Sebastian Sickelmann wrote:
>Thanks for reviewing/supporting on my CRs. (Does CR mean Change Request???)

Yes. See http://wikis.sun.com/display/OpenJdkBuilds/JDK+Glossary+of+Terms

cheers,
dalibor topic
-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738 <tel:+494023646738> | Mobile: +491772664192 <tel:+491772664192>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment


From sebastian.sickelmann at gmx.de  Fri Aug 26 11:25:17 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 26 Aug 2011 13:25:17 +0200
Subject: Request for review Remove "private" cause in jdk exceptions
In-Reply-To: <4E577DFE.3030106@oracle.com>
References: <4E525386.9000207@gmx.de>	<4E52758D.2020208@oracle.com>	<4E56C6CC.7010305@gmx.de>	<4E56CB90.60508@gmx.de>
	<4E56E235.6010307@gmx.de>	<B74C6CB1-874F-4185-AC14-A3ABDA2879A0@roundroom.net>	<4E577CA1.4000000@gmx.de>
	<4E577DFE.3030106@oracle.com>
Message-ID: <4E57829D.6090802@gmx.de>

Am 26.08.2011 13:05, schrieb Dalibor Topic:
> On 8/26/11 12:59 PM, Sebastian Sickelmann wrote:
>> Am 26.08.2011 08:32, schrieb Peter Jones:
>>> Public fields like RemoteException.detail, ill-advised as they may have been, cannot be removed (would break binary compatibility).
>> Sorry for that. It was more a reflex (remove "evil" public fields) than a real problem with this. Breaking this would breaking binary compatibility but can this be a real show-stopper for not fixing this?
> Breaking binary compatibility is bad, bad, really, really bad.
>
> cheers,
> dalibor topic
I know that. And it wasn't my intention to break compatibility. I just 
wondered why we doesn't even worry about breaking encapsulation(public 
fields are bad too)? In Applications-development (cannot be compared 
with jdk) you wouldn't even think about it. You would break 
compatibility in the next major release and get rid of the encapsulation 
problem. Maybe you wouldn't even wait for the next major release and fix 
it in an bugfix-release, but the later cannot be an option for the jdk.

-- Sebastian


From sebastian.sickelmann at gmx.de  Fri Aug 26 19:49:47 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 26 Aug 2011 21:49:47 +0200
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors
	to	InternalError and VirtualMachineError
In-Reply-To: <4E560BF7.3040700@oracle.com>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>	<4E54AE42.7000904@oracle.com>	<4E551487.8050007@oracle.com>
	<4E55EB89.7060906@oracle.com> <4E560191.3020500@gmx.de>
	<4E560BF7.3040700@oracle.com>
Message-ID: <4E57F8DB.9080906@gmx.de>

Am 25.08.2011 10:46, schrieb Alan Bateman:
> Sebastian Sickelmann wrote:
>> :
>>
>> I have build(make clean, make all, make images) the jdk-repo only. Or 
>> does i have to pull in the changes of my jdk8/tl/jdk clone to my 
>> jdk8/jdk8/jdk clone to check this?
>>
>> Has someone in the past evaluated if there is a good way to do 
>> regression tests for serialVersionUID in jdk-sources?
> To see the issue then you'll need a build of jdk8/tl rather than 
> jdk8/jdk8 as the changes haven't been integrated into the master yet. 
I have tried both jdk8/tl/jdk and jdk8/jdk8/* (with the changes from 
jdk8/tl/jdk pulled in) an in all version it was printed the old 
serialVersionUID. But never mind, I maybe have done something wrong.
> We really need to get to the point where the entire JDK is built with 
> -Xlint:serial -Werror as it's too easy to inadvertently change the SUID.
But this only protectes for forget of defining an explicit 
serialVerionUID, not an change in it. Or do you think if there is an 
explicit serialVersionUID then the change in it would be noted while 
reviewing?
> Aside from a few specified tests, the tests in the jdk repository 
> don't test serialization compatibility.
Maybe an script that collects all serialVersionUID of the classes in JDK 
can compare it with the new ones and print it for documentation (break 
in compatibility). Or is there a real strict "don't break compatiblity 
ever" policy in jdk developement?
>
> -Alan
>
>
-- Sebastian


From sebastian.sickelmann at gmx.de  Fri Aug 26 19:57:04 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 26 Aug 2011 21:57:04 +0200
Subject: Request for review: More cause-chaining for InternalError
In-Reply-To: <4E539A1F.106@gmx.de>
References: <4E48BA0E.6090702@gmx.de>
	<4E4B1528.8060306@oracle.com>	<4E4C2BFA.40207@gmx.de>
	<4E52ABB0.1030605@oracle.com> <4E539A1F.106@gmx.de>
Message-ID: <4E57FA90.1000802@gmx.de>

Am 23.08.2011 14:16, schrieb Sebastian Sickelmann:
> Am 22.08.2011 21:19, schrieb Joe Darcy:
>> Sebastian Sickelmann wrote:
>>> Am 17.08.2011 03:11, schrieb joe.darcy at oracle.com:
>>>> Hello.
>>>>
>>>> On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote:
>>>>> Hi,
>>>>>
>>>>> some time ago, i wrote[5] with Joe and David about advancing some 
>>>>> exception-types to the 4 standard ctors.
>>>>>
>>>>> The first Exception i have looked at was InternalError and 
>>>>> now(after some struggeling with gnumake and hg) my patches for 
>>>>> reviewing are ready.
>>>>>
>>>>> I uploaded them at [4]
>>>>>
>>>>> I split the changes into 3 parts.
>>>>>
>>>>> 1. Added 2 ctors to InternalError and VirtualMachineError****[1]
>>>>> 2. Use the two ctors of InternalError****[2] (based on [1])
>>>>> 3. Chain Rootcause into InternalError**[3] (based also on [1])
>>>>>
>>>>> I think part 1 and 2 are uncritical. Part 3 is more critical 
>>>>> because it changes behavior (exception-chaining). But i don't 
>>>>> think that part 3 is unimportable, because in case of an 
>>>>> InternalError (use should not be able to recover) there shouldn't 
>>>>> be a problem with a little longer exception-chain.
>>>>>
>>>>> Is there someone who what to sponsor this or parts of it?
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/attachment.cgi?id=233
>>>>> [2] https://bugs.openjdk.java.net/attachment.cgi?id=234
>>>>> [3] https://bugs.openjdk.java.net/attachment.cgi?id=235
>>>>> [4] https://bugs.openjdk.java.net/show_bug.cgi?id=100201
>>>>> [5] 
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html 
>>>>>
>>>>
>>>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
>>>> conventional constructors to InternalError" for it.
>>>>
>>>> For adding constructors to InternalError (or VirtualMachineError), 
>>>> the push that adds the constructors should include some usage of 
>>>> them.  Therefore, at least portions of 1) and 2) above should be 
>>>> combined.  If there are easy to find usages of a cause for 
>>>> VirtualMachineError, then those should be included at the same time 
>>>> any new constructors are added there.
>>> VirtualMachineError is changed because it is the abstract super 
>>> class of InternalError so use of the VirtualMachineError ctors is 
>>> inside of the InternalError ctors
>>>>
>>>> There is some currently Oracle-internal paperwork which needs to be 
>>>> filed to make an API change; I'll file that paperwork once there is 
>>>> verification on whether updates to both InternalError and 
>>>> VirtualMachineError will be included in this round of work.  The 
>>>> paperwork needs to be approved before the change is pushed and 
>>>> typically takes a few days to be processed.
>>>>
>>> OK. That much work for just chaining up exceptions.
>>> I am happy that i needn't to do this paperwork. I hope it's virtual 
>>> paperwork. ;-)
>>>
>>> I will post the change in 2 webrevs than.
>>> One for the smaller part (Change of the InternalError itself + some 
>>> small changes "initCause usage to ctor parameter")
>>> And one for the bigger part (Chain all uses of InternalError with 
>>> the root-cause if any root-cause exists)
>>>
>>> i must rebase it again. Will post webrev url at the other thread in 
>>> short.
>>
>> Hello.
>>
>> The internal API paperwork went through; I've just pushed a changeset 
>> with the additional constructors and some usage of them to replace 
>> calls to initCause methods:
>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130
>>
>> Thanks,
>>
>> -Joe
> Thanks for commiting. My email-adress has a typo but that isn't a real 
> problem ;-)
>
> I have rebased my "additional chainings of InternalError" on your commit.
>
> The webrev is:
> http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_c43af666d130/ 
>
>
> Reviews are welcome for this too.
>
> - Sebastian
Any change to get an review/sponsorship of this?
Maybe the CR is little bit to big. Should i break it up to several 
webrevs and discuss with smaller contributor-circles (ex. 
awt-dev,security-dev,swing-dev)?

-- Sebastian


From Alan.Bateman at oracle.com  Fri Aug 26 20:17:52 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Aug 2011 21:17:52 +0100
Subject: Code review request 7077769: (zipfs) ZipFileSystem.writeCEN()
	writes wrong "data size" for ZIP64 extended information extra field
In-Reply-To: <4E569433.3030802@oracle.com>
References: <4E5446A9.4030004@oracle.com> <4E54A2F6.6040204@oracle.com>
	<4E569433.3030802@oracle.com>
Message-ID: <4E57FF70.7040502@oracle.com>

Xueming Shen wrote:
> Alan
>
> Webrev has been updated to
>
> (1) use the new try(resource){}
> (2) update the existing test case LargetZip to
>      a) be able to add one more entry at the end of the > 4g zip via 
> ZipFileSystem
>      b) read through all entries inside the large zipfile, given 
> zipfile's self-crc-check
>          it guarantees the correctness of the zipfile. So it now goes 
> through 18G+
>          file read/write for one round:-)
>      (you have to use -XX:-UseLoopPredicate on server vm for now to 
> workaround
>        the C2 loop redicate bug)
>
> http://cr.openjdk.java.net/~sherman/7077769/webrev/
Looks good. On the test I guess I would have used Files.walkFileTree in 
the update method. Also in the mkdirs implementation can be replaced 
with Files.createDirectories.

-Alan.


From joe.darcy at oracle.com  Fri Aug 26 20:37:02 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Fri, 26 Aug 2011 13:37:02 -0700
Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors
	to	InternalError and VirtualMachineError
In-Reply-To: <4E57F8DB.9080906@gmx.de>
References: <20110822191717.9FF1347FE5@hg.openjdk.java.net>	<4E54AE42.7000904@oracle.com>	<4E551487.8050007@oracle.com>	<4E55EB89.7060906@oracle.com>
	<4E560191.3020500@gmx.de>	<4E560BF7.3040700@oracle.com>
	<4E57F8DB.9080906@gmx.de>
Message-ID: <4E5803EE.8070009@oracle.com>

On 8/26/2011 12:49 PM, Sebastian Sickelmann wrote:
> Am 25.08.2011 10:46, schrieb Alan Bateman:
>> Sebastian Sickelmann wrote:
>>> :
>>>
>>> I have build(make clean, make all, make images) the jdk-repo only. 
>>> Or does i have to pull in the changes of my jdk8/tl/jdk clone to my 
>>> jdk8/jdk8/jdk clone to check this?
>>>
>>> Has someone in the past evaluated if there is a good way to do 
>>> regression tests for serialVersionUID in jdk-sources?
>> To see the issue then you'll need a build of jdk8/tl rather than 
>> jdk8/jdk8 as the changes haven't been integrated into the master yet. 
> I have tried both jdk8/tl/jdk and jdk8/jdk8/* (with the changes from 
> jdk8/tl/jdk pulled in) an in all version it was printed the old 
> serialVersionUID. But never mind, I maybe have done something wrong.
>> We really need to get to the point where the entire JDK is built with 
>> -Xlint:serial -Werror as it's too easy to inadvertently change the SUID.
> But this only protectes for forget of defining an explicit 
> serialVerionUID, not an change in it. Or do you think if there is an 
> explicit serialVersionUID then the change in it would be noted while 
> reviewing?

Yes, such a change *should* be noted during a review, but having the 
build break if the policy is broken is a sure way to get the problem 
noticed by the integrator is not the developer or reviewer!

>> Aside from a few specified tests, the tests in the jdk repository 
>> don't test serialization compatibility.
> Maybe an script that collects all serialVersionUID of the classes in 
> JDK can compare it with the new ones and print it for documentation 
> (break in compatibility). Or is there a real strict "don't break 
> compatiblity ever" policy in jdk developement?
>

Such a script would be a good idea; there would be a few subtleties to 
attend to.  Our compatibility policies for the JDK is a bit nuanced; the 
most detailed writeup of the policies is in this document:

http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy

-Joe


From sebastian.sickelmann at gmx.de  Fri Aug 26 20:45:07 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 26 Aug 2011 22:45:07 +0200
Subject: Request Review: 7080622: Remove varargs warnings from rmic
In-Reply-To: <4E4DEB78.5050808@gmx.de>
References: <4E4C449C.7050707@gmx.de>
	<4E4C4629.7060101@oracle.com>	<4E4D1D81.4090209@oracle.com>
	<4E4DEB78.5050808@gmx.de>
Message-ID: <4E5805D3.6060108@gmx.de>

Am 19.08.2011 06:50, schrieb Sebastian Sickelmann:
>
> Am 18.08.2011 16:11, schrieb Alan Bateman:
>> Mandy Chung wrote:
>>> Thumbs up from me.   Are you going to include this change with 
>>> another CR that you have a fix to be pushed?
>>>
>>> Mandy
>> I think it's best to separate this fix and so I've created the 
>> following to track it:
>>  7080622: Remove varargs warnings from rmic
>
> I updated my Patch so that it handles all varargs warnings in jdk 
> subrepo.http://oss-patches.24.eu/openjdk8/Varargs_Warning
>
> I hope that is ok because the bug Name names only rmic
>
> --Sebastian
>
>>
>> -Alan.
>>
>
I updated my webrev to fix a small failure i introduces with my initial 
CR in logging off XIconWindow.
Is there any change to rename the bug. Or should i provide 2 CRs for this?

The new webrev is here:
http://oss-patches.24.eu/openjdk8/Varargs_Warning/REBASED_ON_3a13b7ab57f7/

-- Sebastian


From sebastian.sickelmann at gmx.de  Fri Aug 26 20:51:59 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 26 Aug 2011 22:51:59 +0200
Subject: Request-Review: Remove two simple warnings in HttpsURLConnection.java
Message-ID: <4E58076F.4090500@gmx.de>

Hi,

is there someone who wants to review / support this simple warning removal?

The webrev is:
http://oss-patches.24.eu/openjdk8/Simple_Warning/

-- Sebastian*
*


From Alan.Bateman at oracle.com  Fri Aug 26 20:55:43 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Aug 2011 21:55:43 +0100
Subject: Request Review: 7080622: Remove varargs warnings from rmic
In-Reply-To: <4E5805D3.6060108@gmx.de>
References: <4E4C449C.7050707@gmx.de>
	<4E4C4629.7060101@oracle.com>	<4E4D1D81.4090209@oracle.com>
	<4E4DEB78.5050808@gmx.de> <4E5805D3.6060108@gmx.de>
Message-ID: <4E58084F.20806@oracle.com>

Sebastian Sickelmann wrote:
> I updated my webrev to fix a small failure i introduces with my 
> initial CR in logging off XIconWindow.
> Is there any change to rename the bug. Or should i provide 2 CRs for 
> this?
I changed the synopsis to simply "Remove vargs warnings" as one CR is 
sufficient for this. I was chatting with Sherman and he said he would 
help get these patches in.

-Alan.


From xueming.shen at oracle.com  Fri Aug 26 21:29:11 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 26 Aug 2011 14:29:11 -0700
Subject: Code review request 7077769: (zipfs) ZipFileSystem.writeCEN()
	writes wrong "data size" for ZIP64 extended information extra field
In-Reply-To: <4E57FF70.7040502@oracle.com>
References: <4E5446A9.4030004@oracle.com> <4E54A2F6.6040204@oracle.com>
	<4E569433.3030802@oracle.com> <4E57FF70.7040502@oracle.com>
Message-ID: <4E581027.2030604@oracle.com>

On 08/26/2011 01:17 PM, Alan Bateman wrote:
> Xueming Shen wrote:
>> Alan
>>
>> Webrev has been updated to
>>
>> (1) use the new try(resource){}
>> (2) update the existing test case LargetZip to
>>      a) be able to add one more entry at the end of the > 4g zip via 
>> ZipFileSystem
>>      b) read through all entries inside the large zipfile, given 
>> zipfile's self-crc-check
>>          it guarantees the correctness of the zipfile. So it now goes 
>> through 18G+
>>          file read/write for one round:-)
>>      (you have to use -XX:-UseLoopPredicate on server vm for now to 
>> workaround
>>        the C2 loop redicate bug)
>>
>> http://cr.openjdk.java.net/~sherman/7077769/webrev/
> Looks good. On the test I guess I would have used Files.walkFileTree 
> in the update method. Also in the mkdirs implementation can be 
> replaced with Files.createDirectories.

Webrev has been updated to use Files.walkFileTree and 
Files.createDirectories.

Thanks,
Sherman

>
> -Alan.



From alan.bateman at oracle.com  Fri Aug 26 21:26:13 2011
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 26 Aug 2011 21:26:13 +0000
Subject: hg: jdk8/tl/jdk: 7060243: (dc) Multicasting tests fail on Windows XP
	if IPv6 is enabled
Message-ID: <20110826212638.5FB2B47149@hg.openjdk.java.net>

Changeset: 6d2f09eed4e3
Author:    alanb
Date:      2011-08-26 22:24 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d2f09eed4e3

7060243: (dc) Multicasting tests fail on Windows XP if IPv6 is enabled
Reviewed-by: alanb
Contributed-by: kurchi.subhra.hazra at oracle.com

! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java



From Alan.Bateman at oracle.com  Fri Aug 26 21:39:55 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Aug 2011 22:39:55 +0100
Subject: Code review request 7077769: (zipfs) ZipFileSystem.writeCEN()
	writes wrong "data size" for ZIP64 extended information extra field
In-Reply-To: <4E581027.2030604@oracle.com>
References: <4E5446A9.4030004@oracle.com> <4E54A2F6.6040204@oracle.com>
	<4E569433.3030802@oracle.com> <4E57FF70.7040502@oracle.com>
	<4E581027.2030604@oracle.com>
Message-ID: <4E5812AB.9040105@oracle.com>

Xueming Shen wrote:
> On 08/26/2011 01:17 PM, Alan Bateman wrote:
>> Xueming Shen wrote:
>>> Alan
>>>
>>> Webrev has been updated to
>>>
>>> (1) use the new try(resource){}
>>> (2) update the existing test case LargetZip to
>>>      a) be able to add one more entry at the end of the > 4g zip via 
>>> ZipFileSystem
>>>      b) read through all entries inside the large zipfile, given 
>>> zipfile's self-crc-check
>>>          it guarantees the correctness of the zipfile. So it now 
>>> goes through 18G+
>>>          file read/write for one round:-)
>>>      (you have to use -XX:-UseLoopPredicate on server vm for now to 
>>> workaround
>>>        the C2 loop redicate bug)
>>>
>>> http://cr.openjdk.java.net/~sherman/7077769/webrev/
>> Looks good. On the test I guess I would have used Files.walkFileTree 
>> in the update method. Also in the mkdirs implementation can be 
>> replaced with Files.createDirectories.
>
> Webrev has been updated to use Files.walkFileTree and 
> Files.createDirectories.
Mostly okay to me. If you want you could remove lines 233-236 as 
walkFileTree will just invoke the visitFile method if you call it with a 
path to a file that isn't a directory. Also just noticed line 218 checks 
if the scheme is "jar" and that comparison should technically be without 
regard to case.

-Alan.


From Alan.Bateman at oracle.com  Fri Aug 26 21:45:46 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Aug 2011 22:45:46 +0100
Subject: Request-Review: Remove two simple warnings in
	HttpsURLConnection.java
In-Reply-To: <4E58076F.4090500@gmx.de>
References: <4E58076F.4090500@gmx.de>
Message-ID: <4E58140A.5080203@oracle.com>

Sebastian Sickelmann wrote:
> Hi,
>
> is there someone who wants to review / support this simple warning 
> removal?
>
> The webrev is:
> http://oss-patches.24.eu/openjdk8/Simple_Warning/
>
> -- Sebastian*
> *
This is JSSE so probably best if someone from the security area pushes 
this for Sebastian.

-Alan.


From xueming.shen at oracle.com  Fri Aug 26 22:16:50 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 26 Aug 2011 15:16:50 -0700
Subject: Request-Review: Remove two simple warnings in
	HttpsURLConnection.java
In-Reply-To: <4E58140A.5080203@oracle.com>
References: <4E58076F.4090500@gmx.de> <4E58140A.5080203@oracle.com>
Message-ID: <4E581B52.1000506@oracle.com>

On 08/26/2011 02:45 PM, Alan Bateman wrote:
> Sebastian Sickelmann wrote:
>> Hi,
>>
>> is there someone who wants to review / support this simple warning 
>> removal?
>>
>> The webrev is:
>> http://oss-patches.24.eu/openjdk8/Simple_Warning/
>>
>> -- Sebastian*
>> *
> This is JSSE so probably best if someone from the security area pushes 
> this for Sebastian.
>
> -Alan.

webrev has been updated as suggested

-Sherman


From xueming.shen at oracle.com  Fri Aug 26 22:26:09 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 26 Aug 2011 15:26:09 -0700
Subject: Request-Review: Remove two simple warnings in
	HttpsURLConnection.java
In-Reply-To: <4E581B52.1000506@oracle.com>
References: <4E58076F.4090500@gmx.de> <4E58140A.5080203@oracle.com>
	<4E581B52.1000506@oracle.com>
Message-ID: <4E581D81.8040108@oracle.com>

Please ignored this email.  My apology. Wrong click.

On 08/26/2011 03:16 PM, Xueming Shen wrote:
> On 08/26/2011 02:45 PM, Alan Bateman wrote:
>> Sebastian Sickelmann wrote:
>>> Hi,
>>>
>>> is there someone who wants to review / support this simple warning 
>>> removal?
>>>
>>> The webrev is:
>>> http://oss-patches.24.eu/openjdk8/Simple_Warning/
>>>
>>> -- Sebastian*
>>> *
>> This is JSSE so probably best if someone from the security area 
>> pushes this for Sebastian.
>>
>> -Alan.
>
> webrev has been updated as suggested
>
> -Sherman



From xueming.shen at oracle.com  Fri Aug 26 22:25:44 2011
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Fri, 26 Aug 2011 22:25:44 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20110826222610.C33384714C@hg.openjdk.java.net>

Changeset: 973d923af88c
Author:    sherman
Date:      2011-08-26 15:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/973d923af88c

7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field
Summary: fixed the wrong size when writing out the cen table for ZIP64
Reviewed-by: alanb

! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
! test/java/util/zip/LargeZip.java

Changeset: 9bd06beac455
Author:    sherman
Date:      2011-08-26 15:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bd06beac455

Merge




From xuelei.fan at oracle.com  Sat Aug 27 01:01:42 2011
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sat, 27 Aug 2011 09:01:42 +0800
Subject: Request-Review: Remove two simple warnings in
	HttpsURLConnection.java
In-Reply-To: <4E58140A.5080203@oracle.com>
References: <4E58076F.4090500@gmx.de> <4E58140A.5080203@oracle.com>
Message-ID: <4E5841F6.10908@oracle.com>

Hi Sebastian,

Thank you for your contribution on OpenJDK.

The update looks fine to me. Do you have a CR (Change Request) for this
update?

BTW, have you signed the Oracle Contribution Agreement [1]? I did not
find you name in the OpenJDK people list.

Thanks,
Xuelei

[1] http://openjdk.java.net/contribute/

On 8/27/2011 5:45 AM, Alan Bateman wrote:
> Sebastian Sickelmann wrote:
>> Hi,
>>
>> is there someone who wants to review / support this simple warning
>> removal?
>>
>> The webrev is:
>> http://oss-patches.24.eu/openjdk8/Simple_Warning/
>>
>> -- Sebastian*
>> *
> This is JSSE so probably best if someone from the security area pushes
> this for Sebastian.
> 
> -Alan.



From Alan.Bateman at oracle.com  Sat Aug 27 06:13:52 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 Aug 2011 07:13:52 +0100
Subject: Request-Review: Remove two simple warnings in
	HttpsURLConnection.java
In-Reply-To: <4E5841F6.10908@oracle.com>
References: <4E58076F.4090500@gmx.de> <4E58140A.5080203@oracle.com>
	<4E5841F6.10908@oracle.com>
Message-ID: <4E588B20.4060105@oracle.com>

Xuelei Fan wrote:
> Hi Sebastian,
>
> Thank you for your contribution on OpenJDK.
>
> The update looks fine to me. Do you have a CR (Change Request) for this
> update?
>
> BTW, have you signed the Oracle Contribution Agreement [1]? I did not
> find you name in the OpenJDK people list.
>   
I don't think there is a specific bug created for this. Sasha made great 
progress on squashing warnings but I think only got through about half 
of the security area. There are may be more general bugs created for the 
remaining areas but I would suggest just creating a specific bug for this.

He's listed in the CA signatories file and both Joe Darcy and I have 
pushed changes for him.

-Alan.


From xuelei.fan at oracle.com  Sat Aug 27 08:27:46 2011
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sat, 27 Aug 2011 16:27:46 +0800
Subject: Request-Review: Remove two simple warnings in
	HttpsURLConnection.java
In-Reply-To: <4E588B20.4060105@oracle.com>
References: <4E58076F.4090500@gmx.de> <4E58140A.5080203@oracle.com>
	<4E5841F6.10908@oracle.com> <4E588B20.4060105@oracle.com>
Message-ID: <4E58AA82.3000005@oracle.com>

On 8/27/2011 2:13 PM, Alan Bateman wrote:
> Xuelei Fan wrote:
>> Hi Sebastian,
>>
>> Thank you for your contribution on OpenJDK.
>>
>> The update looks fine to me. Do you have a CR (Change Request) for this
>> update?
>>
>> BTW, have you signed the Oracle Contribution Agreement [1]? I did not
>> find you name in the OpenJDK people list.
>>   
> I don't think there is a specific bug created for this. Sasha made great
> progress on squashing warnings but I think only got through about half
> of the security area. There are may be more general bugs created for the
> remaining areas but I would suggest just creating a specific bug for this.
> 
I will try to clear up some security warning one or two weeks later. I
will create a special CR for this one.

> He's listed in the CA signatories file and both Joe Darcy and I have
> pushed changes for him.
> 
Good, I will push the changes on behavior of Sebastian.

Thanks,
Xuelei

> -Alan.



From xuelei.fan at oracle.com  Sat Aug 27 09:18:18 2011
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Sat, 27 Aug 2011 09:18:18 +0000
Subject: hg: jdk8/tl/jdk: 7084040: Clearup warning in HttpsURLConnection
Message-ID: <20110827091835.6692D47166@hg.openjdk.java.net>

Changeset: e4729ad0d7b5
Author:    xuelei
Date:      2011-08-27 02:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4729ad0d7b5

7084040: Clearup warning in HttpsURLConnection
Reviewed-by: xuelei
Contributed-by: nsebastian.sickelmann at gmx.de

! src/share/classes/javax/net/ssl/HttpsURLConnection.java



From xuelei.fan at oracle.com  Sat Aug 27 09:22:44 2011
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sat, 27 Aug 2011 17:22:44 +0800
Subject: Request-Review: Remove two simple warnings in
	HttpsURLConnection.java
In-Reply-To: <4E58AA82.3000005@oracle.com>
References: <4E58076F.4090500@gmx.de> <4E58140A.5080203@oracle.com>
	<4E5841F6.10908@oracle.com> <4E588B20.4060105@oracle.com>
	<4E58AA82.3000005@oracle.com>
Message-ID: <4E58B764.1010404@oracle.com>

The fix was integrated into OpenJDK 8.
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4729ad0d7b5

Sebastian, thank you for the contribution.

Xuelei

On 8/27/2011 4:27 PM, Xuelei Fan wrote:
> On 8/27/2011 2:13 PM, Alan Bateman wrote:
>> Xuelei Fan wrote:
>>> Hi Sebastian,
>>>
>>> Thank you for your contribution on OpenJDK.
>>>
>>> The update looks fine to me. Do you have a CR (Change Request) for this
>>> update?
>>>
>>> BTW, have you signed the Oracle Contribution Agreement [1]? I did not
>>> find you name in the OpenJDK people list.
>>>   
>> I don't think there is a specific bug created for this. Sasha made great
>> progress on squashing warnings but I think only got through about half
>> of the security area. There are may be more general bugs created for the
>> remaining areas but I would suggest just creating a specific bug for this.
>>
> I will try to clear up some security warning one or two weeks later. I
> will create a special CR for this one.
> 
>> He's listed in the CA signatories file and both Joe Darcy and I have
>> pushed changes for him.
>>
> Good, I will push the changes on behavior of Sebastian.
> 
> Thanks,
> Xuelei
> 
>> -Alan.
> 



From alan.bateman at oracle.com  Sat Aug 27 15:13:50 2011
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 27 Aug 2011 15:13:50 +0000
Subject: hg: jdk8/tl/jdk: 7060790: (fs) FileSystem.newWatchService error
	message confusing when maximum inotify descriptors reached
Message-ID: <20110827151410.DCB4347173@hg.openjdk.java.net>

Changeset: 83add4632b49
Author:    alanb
Date:      2011-08-27 15:40 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83add4632b49

7060790: (fs) FileSystem.newWatchService error message confusing when maximum inotify descriptors reached
Reviewed-by: forax

! src/solaris/classes/sun/nio/fs/LinuxWatchService.java
! src/solaris/native/sun/nio/fs/genUnixConstants.c



From Xuelei.Fan at Oracle.Com  Sun Aug 28 00:21:29 2011
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Sun, 28 Aug 2011 08:21:29 +0800
Subject: hg: jdk8/tl/jdk: 7084040: Clearup warning in HttpsURLConnection
In-Reply-To: <20110827091835.6692D47166@hg.openjdk.java.net>
References: <20110827091835.6692D47166@hg.openjdk.java.net>
Message-ID: <AAA2DB92-E3C1-4A4C-B848-877BEBFDC31D@Oracle.Com>

Sorry that there is a typo of the email address of the contributor. The mail address should be sebastian.sickelmann at gmx.de. My apologies for my mistake.

Xuelei

On Aug 27, 2011, at 5:18 PM, xuelei.fan at oracle.com wrote:

> Changeset: e4729ad0d7b5
> Author:    xuelei
> Date:      2011-08-27 02:17 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4729ad0d7b5
> 
> 7084040: Clearup warning in HttpsURLConnection
> Reviewed-by: xuelei
> Contributed-by: nsebastian.sickelmann at gmx.de
> 
> ! src/share/classes/javax/net/ssl/HttpsURLConnection.java
> 


From ahughes at redhat.com  Sun Aug 28 04:22:23 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Sun, 28 Aug 2011 05:22:23 +0100
Subject: Request for review: More cause-chaining for InternalError
In-Reply-To: <4E539A1F.106@gmx.de>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
	<4E4C2BFA.40207@gmx.de> <4E52ABB0.1030605@oracle.com>
	<4E539A1F.106@gmx.de>
Message-ID: <20110828042223.GC31694@rivendell.middle-earth.co.uk>

On 14:16 Tue 23 Aug     , Sebastian Sickelmann wrote:
> Am 22.08.2011 21:19, schrieb Joe Darcy:
> > Sebastian Sickelmann wrote:
> >> Am 17.08.2011 03:11, schrieb joe.darcy at oracle.com:
> >>> Hello.
> >>>
> >>> On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote:
> >>>> Hi,
> >>>>
> >>>> some time ago, i wrote[5] with Joe and David about advancing some 
> >>>> exception-types to the 4 standard ctors.
> >>>>
> >>>> The first Exception i have looked at was InternalError and 
> >>>> now(after some struggeling with gnumake and hg) my patches for 
> >>>> reviewing are ready.
> >>>>
> >>>> I uploaded them at [4]
> >>>>
> >>>> I split the changes into 3 parts.
> >>>>
> >>>> 1. Added 2 ctors to InternalError and VirtualMachineError****[1]
> >>>> 2. Use the two ctors of InternalError****[2] (based on [1])
> >>>> 3. Chain Rootcause into InternalError**[3] (based also on [1])
> >>>>
> >>>> I think part 1 and 2 are uncritical. Part 3 is more critical 
> >>>> because it changes behavior (exception-chaining). But i don't think 
> >>>> that part 3 is unimportable, because in case of an InternalError 
> >>>> (use should not be able to recover) there shouldn't be a problem 
> >>>> with a little longer exception-chain.
> >>>>
> >>>> Is there someone who what to sponsor this or parts of it?
> >>>>
> >>>> [1] https://bugs.openjdk.java.net/attachment.cgi?id=233
> >>>> [2] https://bugs.openjdk.java.net/attachment.cgi?id=234
> >>>> [3] https://bugs.openjdk.java.net/attachment.cgi?id=235
> >>>> [4] https://bugs.openjdk.java.net/show_bug.cgi?id=100201
> >>>> [5] 
> >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html 
> >>>>
> >>>
> >>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
> >>> conventional constructors to InternalError" for it.
> >>>
> >>> For adding constructors to InternalError (or VirtualMachineError), 
> >>> the push that adds the constructors should include some usage of 
> >>> them.  Therefore, at least portions of 1) and 2) above should be 
> >>> combined.  If there are easy to find usages of a cause for 
> >>> VirtualMachineError, then those should be included at the same time 
> >>> any new constructors are added there.
> >> VirtualMachineError is changed because it is the abstract super class 
> >> of InternalError so use of the VirtualMachineError ctors is inside of 
> >> the InternalError ctors
> >>>
> >>> There is some currently Oracle-internal paperwork which needs to be 
> >>> filed to make an API change; I'll file that paperwork once there is 
> >>> verification on whether updates to both InternalError and 
> >>> VirtualMachineError will be included in this round of work.  The 
> >>> paperwork needs to be approved before the change is pushed and 
> >>> typically takes a few days to be processed.
> >>>
> >> OK. That much work for just chaining up exceptions.
> >> I am happy that i needn't to do this paperwork. I hope it's virtual 
> >> paperwork. ;-)
> >>
> >> I will post the change in 2 webrevs than.
> >> One for the smaller part (Change of the InternalError itself + some 
> >> small changes "initCause usage to ctor parameter")
> >> And one for the bigger part (Chain all uses of InternalError with the 
> >> root-cause if any root-cause exists)
> >>
> >> i must rebase it again. Will post webrev url at the other thread in 
> >> short.
> >
> > Hello.
> >
> > The internal API paperwork went through; I've just pushed a changeset 
> > with the additional constructors and some usage of them to replace 
> > calls to initCause methods:
> > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130
> >
> > Thanks,
> >
> > -Joe
> Thanks for commiting. My email-adress has a typo but that isn't a real 
> problem ;-)
> 
> I have rebased my "additional chainings of InternalError" on your commit.
> 
> The webrev is:
> http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_c43af666d130/
> 
> Reviews are welcome for this too.
> 

This looks fine to me; mostly trivial stuff.

> - Sebastian

-- 
Andrew :)

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

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From sebastian.sickelmann at gmx.de  Sun Aug 28 08:18:34 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Sun, 28 Aug 2011 10:18:34 +0200
Subject: Request for review: More cause-chaining for InternalError
In-Reply-To: <20110828042223.GC31694@rivendell.middle-earth.co.uk>
References: <4E48BA0E.6090702@gmx.de> <4E4B1528.8060306@oracle.com>
	<4E4C2BFA.40207@gmx.de> <4E52ABB0.1030605@oracle.com>
	<4E539A1F.106@gmx.de>
	<20110828042223.GC31694@rivendell.middle-earth.co.uk>
Message-ID: <4E59F9DA.7050605@gmx.de>

Am 28.08.2011 06:22, schrieb Dr Andrew John Hughes:
> On 14:16 Tue 23 Aug     , Sebastian Sickelmann wrote:
>>
>> I have rebased my "additional chainings of InternalError" on your commit.
>>
>> The webrev is:
>> http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_c43af666d130/
>>
>> Reviews are welcome for this too.
>>
> This looks fine to me; mostly trivial stuff.
Yes. It's more a assiduity work*, then real complex.
The only non trival stuff maybe 
***src/share/classes/java/text/DecimalFormat.java* 
<http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=assiduity&trestr=0x8001> 
[0]
in combination with src/share/classes/java/text/Format.java [1]

Is there someone who whats to sponsor this by creating a CR and pushing 
it? Or are there more reviewers needed?

How is such cleanup-work handled? I can make more assiduity work on 
this, but is it worth it? Are there drawbacks, additional to my 
mailing-list spam, by such cleanups? Chaining more aggresivly maybe 
cause CG to do later cleanup and serialized Exceptions can be more 
expensive while serializing and transfering over wire(remote-calls etc.).

-- Sebastian

*
>> - Sebastian


From Alan.Bateman at oracle.com  Sun Aug 28 10:10:33 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 28 Aug 2011 11:10:33 +0100
Subject: Request for review: More cause-chaining for InternalError
In-Reply-To: <4E59F9DA.7050605@gmx.de>
References: <4E48BA0E.6090702@gmx.de>
	<4E4B1528.8060306@oracle.com>	<4E4C2BFA.40207@gmx.de>
	<4E52ABB0.1030605@oracle.com>	<4E539A1F.106@gmx.de>	<20110828042223.GC31694@rivendell.middle-earth.co.uk>
	<4E59F9DA.7050605@gmx.de>
Message-ID: <4E5A1419.4000205@oracle.com>

Sebastian Sickelmann wrote:
> Yes. It's more a assiduity work*, then real complex.
> The only non trival stuff maybe 
> ***src/share/classes/java/text/DecimalFormat.java* 
> <http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=assiduity&trestr=0x8001> 
> [0]
> in combination with src/share/classes/java/text/Format.java [1]
>
> Is there someone who whats to sponsor this by creating a CR and 
> pushing it? Or are there more reviewers needed?
>
> How is such cleanup-work handled? I can make more assiduity work on 
> this, but is it worth it? Are there drawbacks, additional to my 
> mailing-list spam, by such cleanups? Chaining more aggresivly maybe 
> cause CG to do later cleanup and serialized Exceptions can be more 
> expensive while serializing and transfering over wire(remote-calls etc.).
>
I've created a bug for this:
7084245: Update usages of InternalError to use exception chaining

and Sherman is going to help get this pushed.

I scanned the patch and see that you've updated three of the 
java.util.concurrent classes. The usual protocol here is for the changes 
to go first into Doug Lea's upstream CVS and then we periodically pull 
the changes into OpenJDK. Chris Hegarty currently looks after this. 
Everyone involved is flexible and small changes like this aren't a major 
issue, it's really just to avoid the code diverging and also making it 
easy to merge/sync up regularly.

You've added a "TODO" to sun.java2d.pipe.LoopPipe.getStrokesSpans asking 
about the printStackTrace. Looks odd to me too but you could check on 
the 2d-dev list in case there is some reason it was put in there.

Kumar should be able to help with your question in sun.misc.Launcher.

I suspect future maintainers might be puzzled by the comment added to 
java.text.DecimalFormat.clone so I wonder if you should leave it out.

How to handle clean-up work in general is a good question, especially 
with patches that touch many areas, like this patch. My personal view is 
that it's polite to copy the mailing lists for all the areas changed so 
that the folks have at least a heads-up and a chance to comment if they 
wish. Less surprises when they are forced to re-base their in-progress 
patches for example. One reviewer for the patch is fine and there is no 
requirement that you get a reviewer from every single area.

On the exception chaining then I suspect you'll find lots of 
opportunities in the code. You probably do need to watch out for 
exceptions that have references to objects that ultimately reference the 
world but I hope they would be few. Otherwise I wouldn't be too 
concerned about making more use of exception chaining.

-Alan.


From sebastian.sickelmann at gmx.de  Sun Aug 28 19:35:58 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Sun, 28 Aug 2011 21:35:58 +0200
Subject: Request for review: 7084245: Update usages of InternalError to use
	exception chaining
Message-ID: <4E5A989E.8070103@gmx.de>

Hi, here is a webrev[1] for some cleanup that i want to integrated in 
tl-repositories.

Alan Bateman had scanned the changes and gave me some good input[3] for 
further discussion here:

The changes to java.util.concurrent should go through Doug Lea's 
upstream CVS. Alan told me that Chris Hegarty is on this topic already. 
The suggested changes for this is here[2].

I have changed some classes in awt / sun.java2d maybe someone of the 
2d-dev maillinglist can look at these changes.
I also changed some classes in java/securtiy maybe someone of 
security-dev maillinglist can look at these changes.

Let me know if there is a need to split/rebase the main-webrev[1] to 
review and/or push it individually.

Mostly the patch changes exception-chains. But there are some places 
where the patch changes behavoir:

- I removed some printstackTraces in 
sun.java2d.pipe.LoopPipe.getStrokesSpans and sun.misc.Launcher (Alan 
told me that kumar maybe want to have a look at it?).
- I changed java.text.Format.clone not to return null. I think it will 
never happen. But if so throwing an InternalError seems to be better 
than returning null and let all the extended classes crash in there 
clone Method with a NullPointerException. And so catching an Exception 
in java.text.DecimalFormat.clone is unnecessary.

-- Sebastian

[1] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_0/
[2] 
http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/
[3] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007563.html


From sebastian.sickelmann at gmx.de  Sun Aug 28 20:25:42 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Sun, 28 Aug 2011 22:25:42 +0200
Subject: Some questions on 6312085: The for/in statement should support
	Iterators/Enumerations
Message-ID: <4E5AA446.6030101@gmx.de>

Hi, i thought about what todo to enable the enhanced-for-loop for 
Iterators and Enumerations.

And it seems to me that the main problem is that the used 
Iterator/Enumeration should not be used in other places( it should be 
"private" for the loop).

As Iterable solves this through creating a new "private" Iterator for 
the Iterable(ex. List/Set/....) it is not geranteed that there are 
concurrent modifications on the Iterable. Typically the iterator solves 
this through checking for concurrent modifications.

If i see it right it should be possible to use every 
Iterator/Enumeration as a source for the enhanced-for-loop which is 
Cloneable too. The main-problem I see is that it is not as easy to pin 
out which Iterator / Enumeration i can put into the for-loop and which i 
cannot. Additionaly i think that would lead into runtime-checks and not 
compiletime-checks which would be really ugly. Let Iterator / 
Enumeration extends Cloneable isn't a good solution because there will 
be some Iterators/Enumerations that are not possible to clone. 
Addtionaly there would be some compatibility issues, ex. let 
Object.clone() do the job will not for every  case) and there maybe more 
compatibiliy issues(binary?) i don't see actually.

As i haven't found any source that brings in the Cloneable 
Iterator/Enumeration solution into account with the enhanced-for-loop it 
maybe a new idea.
Has some a good idea how to get to compiletime-checks with this solution 
and/or how to transparently give the applicationdeveloper the feedback 
he/she needs to intuitional use these?

Thanks for feedback.

-- Sebastian


From David.Holmes at oracle.com  Mon Aug 29 00:02:00 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 29 Aug 2011 10:02:00 +1000
Subject: Request for review: 7084245: Update usages of InternalError to
	use exception chaining
In-Reply-To: <4E5A989E.8070103@gmx.de>
References: <4E5A989E.8070103@gmx.de>
Message-ID: <4E5AD6F8.2080901@oracle.com>

On 29/08/2011 5:35 AM, Sebastian Sickelmann wrote:
> Hi, here is a webrev[1] for some cleanup that i want to integrated in
> tl-repositories.
>
> Alan Bateman had scanned the changes and gave me some good input[3] for
> further discussion here:
>
> The changes to java.util.concurrent should go through Doug Lea's upstream
> CVS. Alan told me that Chris Hegarty is on this topic already. The suggested
> changes for this is here[2].

These changes are somewhat pointless. We don't need to set the cause because 
it will never happen. The classes are cloneable so 
CloneNotSupportedException can not be thrown. If it is then something really 
bizarre has happened hence we throw InternalError. The site of the 
InternalError tells us why it was thrown.

David
-----

> I have changed some classes in awt / sun.java2d maybe someone of the 2d-dev
> maillinglist can look at these changes.
> I also changed some classes in java/securtiy maybe someone of security-dev
> maillinglist can look at these changes.
>
> Let me know if there is a need to split/rebase the main-webrev[1] to review
> and/or push it individually.
>
> Mostly the patch changes exception-chains. But there are some places where
> the patch changes behavoir:
>
> - I removed some printstackTraces in
> sun.java2d.pipe.LoopPipe.getStrokesSpans and sun.misc.Launcher (Alan told me
> that kumar maybe want to have a look at it?).
> - I changed java.text.Format.clone not to return null. I think it will never
> happen. But if so throwing an InternalError seems to be better than
> returning null and let all the extended classes crash in there clone Method
> with a NullPointerException. And so catching an Exception in
> java.text.DecimalFormat.clone is unnecessary.
>
> -- Sebastian
>
> [1] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_0/
> [2] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/
> [3]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007563.html


From sebastian.sickelmann at gmx.de  Mon Aug 29 07:58:53 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Mon, 29 Aug 2011 09:58:53 +0200
Subject: Request for review: 7084245: Update usages of InternalError to
	use exception chaining
In-Reply-To: <4E5AD6F8.2080901@oracle.com>
References: <4E5A989E.8070103@gmx.de> <4E5AD6F8.2080901@oracle.com>
Message-ID: <4E5B46BD.6040907@gmx.de>

Am 29.08.2011 02:02, schrieb David Holmes:
> On 29/08/2011 5:35 AM, Sebastian Sickelmann wrote:
>> Hi, here is a webrev[1] for some cleanup that i want to integrated in
>> tl-repositories.
>>
>> Alan Bateman had scanned the changes and gave me some good input[3] for
>> further discussion here:
>>
>> The changes to java.util.concurrent should go through Doug Lea's 
>> upstream
>> CVS. Alan told me that Chris Hegarty is on this topic already. The 
>> suggested
>> changes for this is here[2].
>
> These changes are somewhat pointless. We don't need to set the cause 
> because it will never happen. The classes are cloneable so 
> CloneNotSupportedException can not be thrown. If it is then something 
> really bizarre has happened hence we throw InternalError. The site of 
> the InternalError tells us why it was thrown.
>
> David
> -----
Thanks for your input. I have myself thought many times about the 
effects of these changes. It changes almost nothing, especially because 
it chains to InternalError which should not be thrown in the most cases. 
So chaining almost costs us zero runtime-costs but in really bizarre 
situations it gives slightly more information what happend.
This cleanup was the first step in a series of cleanup work i want to do 
in topic of exception-chaining. I chose it(InternalError) as the first 
step because it it has so less side-effect(longer chains, runtime 
performance while serializing and printing, later GC of causes,...) 
because it should mostly never happen. So i had the change to learn 
using the tools(mercurial, openjdk build files, webrev, contribution 
process).
The only problem i actually see with these small-changes (where nothing 
really bad/wrong is cleanuped) is the workload i generate for the 
reviewers, supporters, mailinglist-readers and if its worth doing it anyway.

So let me know if the complete cleanup of exception chaining should be 
considered to stop. It's ok if it's so. I have learned enought in using 
the tools and i can start searching for more interessting things to do. 
I only keep going because i said i will do it. It the point in time (Aug 
8) i guessed that there is much to do if I start with it. But i haven't 
imagine that's so much assiduity work.

-- Sebastian


From fweimer at bfk.de  Mon Aug 29 11:24:28 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Mon, 29 Aug 2011 11:24:28 +0000
Subject: Review request for 7020513 : Add com.sun.xml.internal to the
	"package.access" property in java.security
In-Reply-To: <4D654E60.9070106@oracle.com> (Rama Pulavarthi's message of "Wed, 
	23 Feb 2011 10:13:52 -0800")
References: <4D64558A.6040807@oracle.com> <4D64C8EF.2050101@oracle.com>
	<4D654E60.9070106@oracle.com>
Message-ID: <8239gkqx3n.fsf@mid.bfk.de>

* Rama Pulavarthi:

> Just porting the fix along with tests from Open JDK 6 workspace,
> that's why I kept the old date. Does it need to be changed? This test
> was added then following the convention of other tests. I will check
> other tests in JDK 7 to see if it needs any update.

I see that the test was dropped in the final webrev and the commit
(cfc05963734e).  Was this intentional?  The Makefile changes are still
present, though.

-- 
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 xuelei.fan at oracle.com  Mon Aug 29 12:11:03 2011
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 29 Aug 2011 05:11:03 -0700 (PDT)
Subject: Request for review: 7084245: Update usages of InternalError to
	use exception chaining
In-Reply-To: <4E5A989E.8070103@gmx.de>
References: <4E5A989E.8070103@gmx.de>
Message-ID: <4E5B81D7.1060002@oracle.com>

I reviewed the security part. In general, it looks fine. But sometimes,
from my very personal view, the exception-chain might be over used. For
example, the following code:

  try {
      md = MessageDigest.getInstance("SHA");
  } catch (NoSuchAlgorithmException nsae) {
      throw new InternalError("internal error: SHA-1 not available.");
  }

The exception message and stack is simple and easy to understand. If
using exception-chain, the message chain looks like:
   "internal error: SHA-1 not available."
   -> "SHA ... not available""

I think the information is redundant, and expose unnecessary call stack.

Exceptions thrown by a method should be defined at an abstraction level
consistent with what the method does, not necessarily with the low-level
details of how it is implemented. Please also refer to item 61, "Throw
exceptions appropriate to the abstraction", in "Effective Java 2nd Editor".

It seems that the webrev offline now, I cannot access it.

Thanks,
Xuelei

On 8/29/2011 3:35 AM, Sebastian Sickelmann wrote:
> Hi, here is a webrev[1] for some cleanup that i want to integrated in
> tl-repositories.
> 
> Alan Bateman had scanned the changes and gave me some good input[3] for
> further discussion here:
> 
> The changes to java.util.concurrent should go through Doug Lea's
> upstream CVS. Alan told me that Chris Hegarty is on this topic already.
> The suggested changes for this is here[2].
> 
> I have changed some classes in awt / sun.java2d maybe someone of the
> 2d-dev maillinglist can look at these changes.
> I also changed some classes in java/securtiy maybe someone of
> security-dev maillinglist can look at these changes.
> 
> Let me know if there is a need to split/rebase the main-webrev[1] to
> review and/or push it individually.
> 
> Mostly the patch changes exception-chains. But there are some places
> where the patch changes behavoir:
> 
> - I removed some printstackTraces in
> sun.java2d.pipe.LoopPipe.getStrokesSpans and sun.misc.Launcher (Alan
> told me that kumar maybe want to have a look at it?).
> - I changed java.text.Format.clone not to return null. I think it will
> never happen. But if so throwing an InternalError seems to be better
> than returning null and let all the extended classes crash in there
> clone Method with a NullPointerException. And so catching an Exception
> in java.text.DecimalFormat.clone is unnecessary.
> 
> -- Sebastian
> 
> [1] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_0/
> [2]
> http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/
> [3]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007563.html
> 



From xuelei.fan at oracle.com  Mon Aug 29 12:56:22 2011
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Mon, 29 Aug 2011 12:56:22 +0000
Subject: hg: jdk8/tl/jdk: 7059542: JNDI name operations should be locale
	independent
Message-ID: <20110829125644.4A6A5471D1@hg.openjdk.java.net>

Changeset: 02c2d38f4271
Author:    xuelei
Date:      2011-08-29 05:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/02c2d38f4271

7059542: JNDI name operations should be locale independent
Reviewed-by: weijun

! src/share/classes/com/sun/jndi/ldap/ClientId.java
! src/share/classes/com/sun/jndi/ldap/LdapClient.java
! src/share/classes/com/sun/jndi/ldap/LdapCtx.java
! src/share/classes/com/sun/jndi/ldap/LdapName.java
! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java
! src/share/classes/com/sun/jndi/toolkit/dir/HierMemDirCtx.java
! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java
! src/share/classes/com/sun/security/ntlm/NTLM.java
! src/share/classes/java/security/KeyRep.java
! src/share/classes/java/security/Security.java
! src/share/classes/javax/naming/NameImpl.java
! src/share/classes/javax/naming/directory/BasicAttributes.java
! src/share/classes/javax/naming/ldap/Rdn.java
! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java
! src/share/classes/sun/security/krb5/PrincipalName.java
! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
! src/share/classes/sun/security/provider/JavaKeyStore.java
! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java
! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java
! src/share/classes/sun/security/tools/KeyStoreUtil.java
! src/share/classes/sun/security/util/HostnameChecker.java
! src/share/classes/sun/security/x509/DNSName.java
! src/share/classes/sun/security/x509/RFC822Name.java
! test/javax/naming/ldap/LdapName/CompareToEqualsTests.java



From sean.mullan at oracle.com  Mon Aug 29 17:41:27 2011
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Mon, 29 Aug 2011 17:41:27 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20110829174147.1BB9F471E4@hg.openjdk.java.net>

Changeset: d1c04dac850d
Author:    mullan
Date:      2011-08-29 12:22 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1c04dac850d

7024771: "\\<>" in attribute value part of X500Principal constructor parameter makes strange effect
Reviewed-by: vinnie

! src/share/classes/sun/security/x509/AVA.java
! src/share/classes/sun/security/x509/X500Name.java
+ test/javax/security/auth/x500/X500Principal/Parse.java

Changeset: c2b4e0ea3ab9
Author:    mullan
Date:      2011-08-29 12:23 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2b4e0ea3ab9

Merge

! src/share/classes/sun/security/x509/X500Name.java



From kumar.x.srinivasan at oracle.COM  Mon Aug 29 18:04:43 2011
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Mon, 29 Aug 2011 11:04:43 -0700
Subject: Request for review: 7084245: Update usages of InternalError to
	use exception chaining
In-Reply-To: <4E5A989E.8070103@gmx.de>
References: <4E5A989E.8070103@gmx.de>
Message-ID: <4E5BD4BB.7070107@oracle.COM>

Hi,

Sorry for the delay, was on vacation...comment inlined.
> Hi, here is a webrev[1] for some cleanup that i want to integrated in 
> tl-repositories.
>
> Alan Bateman had scanned the changes and gave me some good input[3] 
> for further discussion here:
>
> The changes to java.util.concurrent should go through Doug Lea's 
> upstream CVS. Alan told me that Chris Hegarty is on this topic 
> already. The suggested changes for this is here[2].
>
> I have changed some classes in awt / sun.java2d maybe someone of the 
> 2d-dev maillinglist can look at these changes.
> I also changed some classes in java/securtiy maybe someone of 
> security-dev maillinglist can look at these changes.
>
> Let me know if there is a need to split/rebase the main-webrev[1] to 
> review and/or push it individually.
>
> Mostly the patch changes exception-chains. But there are some places 
> where the patch changes behavoir:
>
> - I removed some printstackTraces in 
> sun.java2d.pipe.LoopPipe.getStrokesSpans and sun.misc.Launcher (Alan 
> told me that kumar maybe want to have a look at it?).

The methods in question in sun.misc.Launcher are not called by the java  
launcher,
I think these were added to facilitate the JavaWebstart Launcher javaws.
Nevertheless, the changes look good to me.

Thanks
Kumar


> - I changed java.text.Format.clone not to return null. I think it will 
> never happen. But if so throwing an InternalError seems to be better 
> than returning null and let all the extended classes crash in there 
> clone Method with a NullPointerException. And so catching an Exception 
> in java.text.DecimalFormat.clone is unnecessary.
>
> -- Sebastian
>
> [1] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_0/
> [2] 
> http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/
> [3] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007563.html



From xueming.shen at oracle.com  Mon Aug 29 19:10:18 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 29 Aug 2011 12:10:18 -0700
Subject: Request for review: 7084245: Update usages of InternalError to
	use exception chaining
In-Reply-To: <4E5A989E.8070103@gmx.de>
References: <4E5A989E.8070103@gmx.de>
Message-ID: <4E5BE41A.8050000@oracle.com>

Hi Sebastian,

I will help to push the patch, if people all agreed the changes proposed.

I pulled your patch and generated the webrev at

http://cr.openjdk.java.net/~sherman/7084245/webrev

with couple changes from your original patch.

(1) Undo the changes in DecimalFormat.java and Format.java.
      while arguably your suggested change might be the correct/better 
one for
      the situation, but it's a behavior change, personally I don't 
think you want
      to change the behavior, whether it is a "better" solution (not 
just look better)
      or "bug fix",  in this kind of clean-up project. Leave that to 
separate "bug fix"
      patch, if you believe the existing code is buggy/wrong.

(2) Removed your comment and left the printStackTrace() in LoopPipe.java
      untouched. Again, that  printStackTrace() might be unintentional, 
a leftover of
      the debug version for  example, but I'm not sure. Until the 2d 
engineer that is
      the case, I would prefer to leave it un-touched.

(3) Removed the concurrent package changes from the list. As discussed 
previously
      These changes might go different path to get it, if agreed.

It appears Xuelei.Fan from security might have some options on the 
changes made
in security area. So Xuelei, do you want me to pull out the changes in 
security
area and leave that for your to deal with separately?

Personally I think it's nice to make the switch to the new chaining 
version if the
original code is "new InternalError(msg) + initCause()", in which case 
it has the
clear intention that implementation does want to expose the original 
cause of
this InternalError. But for the case of InternalError(msg) only, the 
proposed change
actually again changes the behavior/intention of the original code, in 
which it might
not be desirable to expose the original cause when throw the 
InternalError. As
suggested in the Throwable API doc, the "hiding" might be purposely, to 
separate
different levels of abstraction when throw the InternalError.

-Sherman




On 08/28/2011 12:35 PM, Sebastian Sickelmann wrote:
> Hi, here is a webrev[1] for some cleanup that i want to integrated in 
> tl-repositories.
>
> Alan Bateman had scanned the changes and gave me some good input[3] 
> for further discussion here:
>
> The changes to java.util.concurrent should go through Doug Lea's 
> upstream CVS. Alan told me that Chris Hegarty is on this topic 
> already. The suggested changes for this is here[2].
>
> I have changed some classes in awt / sun.java2d maybe someone of the 
> 2d-dev maillinglist can look at these changes.
> I also changed some classes in java/securtiy maybe someone of 
> security-dev maillinglist can look at these changes.
>
> Let me know if there is a need to split/rebase the main-webrev[1] to 
> review and/or push it individually.
>
> Mostly the patch changes exception-chains. But there are some places 
> where the patch changes behavoir:
>
> - I removed some printstackTraces in 
> sun.java2d.pipe.LoopPipe.getStrokesSpans and sun.misc.Launcher (Alan 
> told me that kumar maybe want to have a look at it?).
> - I changed java.text.Format.clone not to return null. I think it will 
> never happen. But if so throwing an InternalError seems to be better 
> than returning null and let all the extended classes crash in there 
> clone Method with a NullPointerException. And so catching an Exception 
> in java.text.DecimalFormat.clone is unnecessary.
>
> -- Sebastian
>
> [1] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_0/
> [2] 
> http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/
> [3] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007563.html



From weijun.wang at oracle.com  Tue Aug 30 02:46:54 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Tue, 30 Aug 2011 02:46:54 +0000
Subject: hg: jdk8/tl/jdk: 7083576: add javax/xml/crypto into jdk_security2
Message-ID: <20110830024704.BF422471FA@hg.openjdk.java.net>

Changeset: 6d6d75421e8a
Author:    weijun
Date:      2011-08-30 10:46 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d6d75421e8a

7083576: add javax/xml/crypto into jdk_security2
Reviewed-by: mullan

! test/Makefile
! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java



From sebastian.sickelmann at gmx.de  Tue Aug 30 05:59:54 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Tue, 30 Aug 2011 07:59:54 +0200
Subject: [OpenJDK 2D-Dev] Request for review: 7084245: Update usages of
	InternalError to use exception chaining
In-Reply-To: <1314564891.2813.8.camel@galactica>
References: <4E5A989E.8070103@gmx.de> <1314564891.2813.8.camel@galactica>
Message-ID: <4E5C7C5A.9020601@gmx.de>

Am 28.08.2011 22:54, schrieb Mario Torre:
> Il giorno dom, 28/08/2011 alle 21.35 +0200, Sebastian Sickelmann ha
> scritto:
>> Hi, here is a webrev[1] for some cleanup that i want to integrated in
>> tl-repositories.
> Hi,
Hi created a new webrev with your suggested changes at:
http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_1/
I have created some comments inline in this mail.
> The patch seems good for me (speaking in particular about the AWT/2D
> part), and I don't think it will introduce any side effects.
>
> Just a note:
>
> src/share/classes/java/lang/invoke/CallSite.java:
>
>           } catch (ReflectiveOperationException ignore) {
> -            throw new InternalError();
> +            throw new InternalError(ignore);
>           }
>
> Being a refactoring patch, I would not change the name from "ignore" to
> the more classical "e", since we are not ignoring the exception anymore.
>
> Also in src/share/classes/com/sun/servicetag/BrowserSupport.java, it
> seems to me that you can also aggregate the InvocationTargetException in
> the multi catch.
I think we should not make further aggregating on InvocationTargetException
in this patch. It changes behavoir. Which of the two places to you mean 
we can
aggregate into multi catch?
> In fact, the block could be probably rewritten to take advantage of
> ReflectiveOperationException.
>
> Same for src/share/classes/sun/misc/Launcher.java,
> src/share/classes/sun/security/util/SecurityConstants.java and
> src/share/classes/sun/tracing/dtrace/DTraceProvider.java
Changed that to ReflectiveOperationException.
> Cheers,
> Mario
>
-- Sebastian


From sebastian.sickelmann at gmx.de  Tue Aug 30 08:20:41 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Tue, 30 Aug 2011 10:20:41 +0200
Subject: Request for review: 7084245: Update usages of InternalError to
	use exception chaining
In-Reply-To: <4E5BE41A.8050000@oracle.com>
References: <4E5A989E.8070103@gmx.de> <4E5BE41A.8050000@oracle.com>
Message-ID: <4E5C9D59.3030202@gmx.de>

Am 29.08.2011 21:10, schrieb Xueming Shen:
> Hi Sebastian,
>
> I will help to push the patch, if people all agreed the changes proposed.
Thanks for supporting this.
>
> I pulled your patch and generated the webrev at
>
> http://cr.openjdk.java.net/~sherman/7084245/webrev
I already created a new webrev that handles the suggested changes of 
Mario Torre.
They sounded reasonable for me.

>
> with couple changes from your original patch.
>
> (1) Undo the changes in DecimalFormat.java and Format.java.
>      while arguably your suggested change might be the correct/better 
> one for
>      the situation, but it's a behavior change, personally I don't 
> think you want
>      to change the behavior, whether it is a "better" solution (not 
> just look better)
>      or "bug fix",  in this kind of clean-up project. Leave that to 
> separate "bug fix"
>      patch, if you believe the existing code is buggy/wrong.
Not changing this at all is not the intention of this. Even if the 
CloneNotSupportedException
cannot be thrown, chaining is what can be done to make it more clear 
what happend.
I don't think that i changed behavoir that much:
  - Returning null in Format will mostly (if not always) result in 
NullPointerException in
    the extending class.
  - DecimalFormat is the only class in jdk i found that makes it 
"correct" and catch it and throw
    an InternalError.
    If i think about how the catch in DecimalFormat maybe come into the 
codebase it must
    be that Format.clone must somehow returned null in the past. Which 
is a bizarre case,
    because it cannot happen cause Format is cloneable.
>
> (2) Removed your comment and left the printStackTrace() in LoopPipe.java
>      untouched. Again, that  printStackTrace() might be unintentional, 
> a leftover of
>      the debug version for  example, but I'm not sure. Until the 2d 
> engineer that is
>      the case, I would prefer to leave it un-touched.
>
> (3) Removed the concurrent package changes from the list. As discussed 
> previously
>      These changes might go different path to get it, if agreed.
Done a special webrev for this here:
     
http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/
>
> It appears Xuelei.Fan from security might have some options on the 
> changes made
> in security area. So Xuelei, do you want me to pull out the changes in 
> security
> area and leave that for your to deal with separately?
Xuelei.Fan gave some input for the security area. He said
<quote>
         Exceptions thrown by a method should be defined at an 
abstraction level
         consistent with what the method does, not necessarily with the 
low-level
         details of how it is implemented.
<quote/>
and i think he is totally right. But if i read it right in Throwable 
this is exactly
what the Throwable.cause is intended for.
<quote>
  * One reason that a throwable may have a cause is that the class that
  * throws it is built atop a lower layered abstraction, and an operation on
  * the upper layer fails due to a failure in the lower layer.  It would 
be bad
  * design to let the throwable thrown by the lower layer propagate 
outward, as
  * it is generally unrelated to the abstraction provided by the upper 
layer.
  * Further, doing so would tie the API of the upper layer to the details of
  * its implementation, assuming the lower layer's exception was a checked
  * exception.  Throwing a "wrapped exception" (i.e., an exception 
containing a
  * cause) allows the upper layer to communicate the details of the 
failure to
  * its caller without incurring either of these shortcomings.  It preserves
  * the flexibility to change the implementation of the upper layer without
  * changing its API (in particular, the set of exceptions thrown by its
  * methods).
<quote/>

>
> Personally I think it's nice to make the switch to the new chaining 
> version if the
> original code is "new InternalError(msg) + initCause()", in which case 
> it has the
> clear intention that implementation does want to expose the original 
> cause of
> this InternalError. But for the case of InternalError(msg) only, the 
> proposed change
> actually again changes the behavior/intention of the original code, in 
> which it might
> not be desirable to expose the original cause when throw the 
> InternalError. As
> suggested in the Throwable API doc, the "hiding" might be purposely, 
> to separate
> different levels of abstraction when throw the InternalError.
Two comments on this:
1.    You maybe haven't noticed it. "new InternalError(msg).initCause()" 
is handled in a previous patch
        http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130

2.    You share this opinion with Xuelei.Fan. I think exactly the other 
way around. That
        maybe comes from my application development background where 
intensive logging
        and long stacktraces are the only information basis you got in 
production code.
        The only reason i see to be carefully with long exception-chains 
is GC and serialization/transfer-costs
        as i have written in
        
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007562.html
        I will not say that Alan is supporting this meaning but he 
somewhat followed the idea in his follow-up.

I think we should think about it and get some more general policy when 
to chain and when not and document it
in Throwable javadoc more clearly. I cannot find the place in Throwable 
API you mentioned about hiding.

> -Sherman
-- Sebastian


From sebastian.sickelmann at gmx.de  Tue Aug 30 08:23:55 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Tue, 30 Aug 2011 10:23:55 +0200
Subject: Request for review: 7084245: Update usages of InternalError to
	use exception chaining
In-Reply-To: <4E5C9D59.3030202@gmx.de>
References: <4E5A989E.8070103@gmx.de> <4E5BE41A.8050000@oracle.com>
	<4E5C9D59.3030202@gmx.de>
Message-ID: <4E5C9E1B.4070800@gmx.de>

Sorry i have forgotten the webrev url.

http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_1/



Am 30.08.2011 10:20, schrieb Sebastian Sickelmann:
> Am 29.08.2011 21:10, schrieb Xueming Shen:
>> Hi Sebastian,
>>
>> I will help to push the patch, if people all agreed the changes 
>> proposed.
> Thanks for supporting this.
>>
>> I pulled your patch and generated the webrev at
>>
>> http://cr.openjdk.java.net/~sherman/7084245/webrev
> I already created a new webrev that handles the suggested changes of 
> Mario Torre.
> They sounded reasonable for me.
>
>>
>> with couple changes from your original patch.
>>
>> (1) Undo the changes in DecimalFormat.java and Format.java.
>>      while arguably your suggested change might be the correct/better 
>> one for
>>      the situation, but it's a behavior change, personally I don't 
>> think you want
>>      to change the behavior, whether it is a "better" solution (not 
>> just look better)
>>      or "bug fix",  in this kind of clean-up project. Leave that to 
>> separate "bug fix"
>>      patch, if you believe the existing code is buggy/wrong.
> Not changing this at all is not the intention of this. Even if the 
> CloneNotSupportedException
> cannot be thrown, chaining is what can be done to make it more clear 
> what happend.
> I don't think that i changed behavoir that much:
>  - Returning null in Format will mostly (if not always) result in 
> NullPointerException in
>    the extending class.
>  - DecimalFormat is the only class in jdk i found that makes it 
> "correct" and catch it and throw
>    an InternalError.
>    If i think about how the catch in DecimalFormat maybe come into the 
> codebase it must
>    be that Format.clone must somehow returned null in the past. Which 
> is a bizarre case,
>    because it cannot happen cause Format is cloneable.
>>
>> (2) Removed your comment and left the printStackTrace() in LoopPipe.java
>>      untouched. Again, that  printStackTrace() might be 
>> unintentional, a leftover of
>>      the debug version for  example, but I'm not sure. Until the 2d 
>> engineer that is
>>      the case, I would prefer to leave it un-touched.
>>
>> (3) Removed the concurrent package changes from the list. As 
>> discussed previously
>>      These changes might go different path to get it, if agreed.
> Done a special webrev for this here:
>     
> http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/
>>
>> It appears Xuelei.Fan from security might have some options on the 
>> changes made
>> in security area. So Xuelei, do you want me to pull out the changes 
>> in security
>> area and leave that for your to deal with separately?
> Xuelei.Fan gave some input for the security area. He said
> <quote>
>         Exceptions thrown by a method should be defined at an 
> abstraction level
>         consistent with what the method does, not necessarily with the 
> low-level
>         details of how it is implemented.
> <quote/>
> and i think he is totally right. But if i read it right in Throwable 
> this is exactly
> what the Throwable.cause is intended for.
> <quote>
>  * One reason that a throwable may have a cause is that the class that
>  * throws it is built atop a lower layered abstraction, and an 
> operation on
>  * the upper layer fails due to a failure in the lower layer.  It 
> would be bad
>  * design to let the throwable thrown by the lower layer propagate 
> outward, as
>  * it is generally unrelated to the abstraction provided by the upper 
> layer.
>  * Further, doing so would tie the API of the upper layer to the 
> details of
>  * its implementation, assuming the lower layer's exception was a checked
>  * exception.  Throwing a "wrapped exception" (i.e., an exception 
> containing a
>  * cause) allows the upper layer to communicate the details of the 
> failure to
>  * its caller without incurring either of these shortcomings.  It 
> preserves
>  * the flexibility to change the implementation of the upper layer 
> without
>  * changing its API (in particular, the set of exceptions thrown by its
>  * methods).
> <quote/>
>
>>
>> Personally I think it's nice to make the switch to the new chaining 
>> version if the
>> original code is "new InternalError(msg) + initCause()", in which 
>> case it has the
>> clear intention that implementation does want to expose the original 
>> cause of
>> this InternalError. But for the case of InternalError(msg) only, the 
>> proposed change
>> actually again changes the behavior/intention of the original code, 
>> in which it might
>> not be desirable to expose the original cause when throw the 
>> InternalError. As
>> suggested in the Throwable API doc, the "hiding" might be purposely, 
>> to separate
>> different levels of abstraction when throw the InternalError.
> Two comments on this:
> 1.    You maybe haven't noticed it. "new 
> InternalError(msg).initCause()" is handled in a previous patch
>        http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130
>
> 2.    You share this opinion with Xuelei.Fan. I think exactly the 
> other way around. That
>        maybe comes from my application development background where 
> intensive logging
>        and long stacktraces are the only information basis you got in 
> production code.
>        The only reason i see to be carefully with long 
> exception-chains is GC and serialization/transfer-costs
>        as i have written in
>        
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007562.html
>        I will not say that Alan is supporting this meaning but he 
> somewhat followed the idea in his follow-up.
>
> I think we should think about it and get some more general policy when 
> to chain and when not and document it
> in Throwable javadoc more clearly. I cannot find the place in 
> Throwable API you mentioned about hiding.
>
>> -Sherman
> -- Sebastian



From michael.x.mcmahon at oracle.com  Tue Aug 30 13:41:53 2011
From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com)
Date: Tue, 30 Aug 2011 13:41:53 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20110830134225.AFE1F47215@hg.openjdk.java.net>

Changeset: fe205518c3a7
Author:    michaelm
Date:      2011-08-30 14:40 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe205518c3a7

7084560: Crash in net.dll
Reviewed-by: chegar
Contributed-by: luchsh at linux.vnet.ibm.com

! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface_winXP.c

Changeset: ef4f24534a96
Author:    michaelm
Date:      2011-08-30 14:41 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef4f24534a96

Merge




From xueming.shen at oracle.com  Tue Aug 30 17:20:49 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 30 Aug 2011 10:20:49 -0700
Subject: Request for review: 7084245: Update usages of InternalError to
	use exception chaining
In-Reply-To: <4E5C9E1B.4070800@gmx.de>
References: <4E5A989E.8070103@gmx.de> <4E5BE41A.8050000@oracle.com>
	<4E5C9D59.3030202@gmx.de> <4E5C9E1B.4070800@gmx.de>
Message-ID: <4E5D1BF1.3010602@oracle.com>

Hi Sebastian,

On 08/30/2011 01:23 AM, Sebastian Sickelmann wrote:
> Sorry i have forgotten the webrev url.
>
> http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_1/
>
>>
>>> with couple changes from your original patch.
>>>
>>> (1) Undo the changes in DecimalFormat.java and Format.java.
>>>      while arguably your suggested change might be the 
>>> correct/better one for
>>>      the situation, but it's a behavior change, personally I don't 
>>> think you want
>>>      to change the behavior, whether it is a "better" solution (not 
>>> just look better)
>>>      or "bug fix",  in this kind of clean-up project. Leave that to 
>>> separate "bug fix"
>>>      patch, if you believe the existing code is buggy/wrong.
>> Not changing this at all is not the intention of this. Even if the 
>> CloneNotSupportedException
>> cannot be thrown, chaining is what can be done to make it more clear 
>> what happend.
>> I don't think that i changed behavoir that much:
>>  - Returning null in Format will mostly (if not always) result in 
>> NullPointerException in
>>    the extending class.
>>  - DecimalFormat is the only class in jdk i found that makes it 
>> "correct" and catch it and throw
>>    an InternalError.
>>    If i think about how the catch in DecimalFormat maybe come into 
>> the codebase it must
>>    be that Format.clone must somehow returned null in the past. Which 
>> is a bizarre case,
>>    because it cannot happen cause Format is cloneable.
>>

We now started to "discuss" whether or not the original code is correct 
or not, and if not,
how to fix it. This is exactly the reason why I think this kind of 
"cleanup" project might not
want to get involved in, especially if it involves behavior change. Get 
that done separately
if you are interested to correct that wrong behavior. In this particular 
case, the "null return"
obviously "never" really happens, I agree it's fine to do so.

>>> Personally I think it's nice to make the switch to the new chaining 
>>> version if the
>>> original code is "new InternalError(msg) + initCause()", in which 
>>> case it has the
>>> clear intention that implementation does want to expose the original 
>>> cause of
>>> this InternalError. But for the case of InternalError(msg) only, the 
>>> proposed change
>>> actually again changes the behavior/intention of the original code, 
>>> in which it might
>>> not be desirable to expose the original cause when throw the 
>>> InternalError. As
>>> suggested in the Throwable API doc, the "hiding" might be purposely, 
>>> to separate
>>> different levels of abstraction when throw the InternalError.
>>
>> Two comments on this:
>> 1.    You maybe haven't noticed it. "new 
>> InternalError(msg).initCause()" is handled in a previous patch
>>        http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130
>>
>> 2.    You share this opinion with Xuelei.Fan. I think exactly the 
>> other way around. That
>>        maybe comes from my application development background where 
>> intensive logging
>>        and long stacktraces are the only information basis you got in 
>> production code.
>>        The only reason i see to be carefully with long 
>> exception-chains is GC and serialization/transfer-costs
>>        as i have written in
>>        
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007562.html
>>        I will not say that Alan is supporting this meaning but he 
>> somewhat followed the idea in his follow-up.
Again, I'm not talking about which approach is correct, which one is 
wrong. I would leave
that to the owner of that particular area to decide, whether including 
the initial cause is
desired.
Generally I would assume if it is desired, then they can/should do so 
with initCause() at
first place (then, as I said, it's nice to make the switch to the new 
chaining version, in this
cleanup project). There are probably three possibilities why they did 
use initCause() at first
place (1) the original owner did not think the initial cause should be 
included (2) even
it should, since it doesn't matter, they did not include it (3) 
initCause() didn't even exist
when the original code was written.  Personally I think you can only do 
so if it's (2) or (3)
in a cleanup project. Given initCause() was added in 1.4, I would 
"assume/guess" most of
them are because of (3). and actually I believe most of them also belong 
to "doesn't really
matter" category.

That said, since 2d/awt, Xuelei.Fan have approved the changes in their 
areas, and Alan have
reviewed the changes as well (in which I would assume the core/lib area 
has been covered).
I will push the latest changes into the tl repository.

-Sherman





From xueming.shen at oracle.com  Tue Aug 30 17:55:43 2011
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 30 Aug 2011 10:55:43 -0700
Subject: Request for review: 7084245: Update usages of InternalError to
	use exception chaining
In-Reply-To: <4E5D1BF1.3010602@oracle.com>
References: <4E5A989E.8070103@gmx.de>
	<4E5BE41A.8050000@oracle.com>	<4E5C9D59.3030202@gmx.de>
	<4E5C9E1B.4070800@gmx.de> <4E5D1BF1.3010602@oracle.com>
Message-ID: <4E5D241F.1060200@oracle.com>

Sebastian,

src/share/classes/sun/misc/Launcher.java in new patch appears to miss a 
ending } at ln#487

-Sherman

On 08/30/2011 10:20 AM, Xueming Shen wrote:
> Hi Sebastian,
>
> On 08/30/2011 01:23 AM, Sebastian Sickelmann wrote:
>> Sorry i have forgotten the webrev url.
>>
>> http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_1/
>>
>>>
>>>> with couple changes from your original patch.
>>>>
>>>> (1) Undo the changes in DecimalFormat.java and Format.java.
>>>>      while arguably your suggested change might be the 
>>>> correct/better one for
>>>>      the situation, but it's a behavior change, personally I don't 
>>>> think you want
>>>>      to change the behavior, whether it is a "better" solution (not 
>>>> just look better)
>>>>      or "bug fix",  in this kind of clean-up project. Leave that to 
>>>> separate "bug fix"
>>>>      patch, if you believe the existing code is buggy/wrong.
>>> Not changing this at all is not the intention of this. Even if the 
>>> CloneNotSupportedException
>>> cannot be thrown, chaining is what can be done to make it more clear 
>>> what happend.
>>> I don't think that i changed behavoir that much:
>>>  - Returning null in Format will mostly (if not always) result in 
>>> NullPointerException in
>>>    the extending class.
>>>  - DecimalFormat is the only class in jdk i found that makes it 
>>> "correct" and catch it and throw
>>>    an InternalError.
>>>    If i think about how the catch in DecimalFormat maybe come into 
>>> the codebase it must
>>>    be that Format.clone must somehow returned null in the past. 
>>> Which is a bizarre case,
>>>    because it cannot happen cause Format is cloneable.
>>>
>
> We now started to "discuss" whether or not the original code is 
> correct or not, and if not,
> how to fix it. This is exactly the reason why I think this kind of 
> "cleanup" project might not
> want to get involved in, especially if it involves behavior change. 
> Get that done separately
> if you are interested to correct that wrong behavior. In this 
> particular case, the "null return"
> obviously "never" really happens, I agree it's fine to do so.
>
>>>> Personally I think it's nice to make the switch to the new chaining 
>>>> version if the
>>>> original code is "new InternalError(msg) + initCause()", in which 
>>>> case it has the
>>>> clear intention that implementation does want to expose the 
>>>> original cause of
>>>> this InternalError. But for the case of InternalError(msg) only, 
>>>> the proposed change
>>>> actually again changes the behavior/intention of the original code, 
>>>> in which it might
>>>> not be desirable to expose the original cause when throw the 
>>>> InternalError. As
>>>> suggested in the Throwable API doc, the "hiding" might be 
>>>> purposely, to separate
>>>> different levels of abstraction when throw the InternalError.
>>>
>>> Two comments on this:
>>> 1.    You maybe haven't noticed it. "new 
>>> InternalError(msg).initCause()" is handled in a previous patch
>>>        http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130
>>>
>>> 2.    You share this opinion with Xuelei.Fan. I think exactly the 
>>> other way around. That
>>>        maybe comes from my application development background where 
>>> intensive logging
>>>        and long stacktraces are the only information basis you got 
>>> in production code.
>>>        The only reason i see to be carefully with long 
>>> exception-chains is GC and serialization/transfer-costs
>>>        as i have written in
>>>        
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007562.html
>>>        I will not say that Alan is supporting this meaning but he 
>>> somewhat followed the idea in his follow-up.
> Again, I'm not talking about which approach is correct, which one is 
> wrong. I would leave
> that to the owner of that particular area to decide, whether including 
> the initial cause is
> desired.
> Generally I would assume if it is desired, then they can/should do so 
> with initCause() at
> first place (then, as I said, it's nice to make the switch to the new 
> chaining version, in this
> cleanup project). There are probably three possibilities why they did 
> use initCause() at first
> place (1) the original owner did not think the initial cause should be 
> included (2) even
> it should, since it doesn't matter, they did not include it (3) 
> initCause() didn't even exist
> when the original code was written.  Personally I think you can only 
> do so if it's (2) or (3)
> in a cleanup project. Given initCause() was added in 1.4, I would 
> "assume/guess" most of
> them are because of (3). and actually I believe most of them also 
> belong to "doesn't really
> matter" category.
>
> That said, since 2d/awt, Xuelei.Fan have approved the changes in their 
> areas, and Alan have
> reviewed the changes as well (in which I would assume the core/lib 
> area has been covered).
> I will push the latest changes into the tl repository.
>
> -Sherman
>
>
>



From xueming.shen at oracle.com  Tue Aug 30 18:38:05 2011
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Tue, 30 Aug 2011 18:38:05 +0000
Subject: hg: jdk8/tl/jdk: 7084245: Update usages of InternalError to use
	exception chaining
Message-ID: <20110830183814.F1AB147230@hg.openjdk.java.net>

Changeset: 8a51f0e24380
Author:    sherman
Date:      2011-08-30 11:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a51f0e24380

7084245: Update usages of InternalError to use exception chaining
Summary: to use new InternalError constructor with cause chainning
Reviewed-by: alanb, ksrini, xuelei, neugens
Contributed-by: sebastian.sickelmann at gmx.de

! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
! src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java
! src/share/classes/com/sun/jmx/snmp/SnmpInt.java
! src/share/classes/com/sun/jmx/snmp/SnmpNull.java
! src/share/classes/com/sun/jmx/snmp/SnmpString.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java
! src/share/classes/com/sun/servicetag/BrowserSupport.java
! src/share/classes/com/sun/servicetag/RegistrationDocument.java
! src/share/classes/java/awt/BufferCapabilities.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/GridBagConstraints.java
! src/share/classes/java/awt/ImageCapabilities.java
! src/share/classes/java/awt/Insets.java
! src/share/classes/java/awt/JobAttributes.java
! src/share/classes/java/awt/PageAttributes.java
! src/share/classes/java/awt/RenderingHints.java
! src/share/classes/java/awt/font/TextLayout.java
! src/share/classes/java/awt/geom/AffineTransform.java
! src/share/classes/java/awt/geom/CubicCurve2D.java
! src/share/classes/java/awt/geom/Dimension2D.java
! src/share/classes/java/awt/geom/Line2D.java
! src/share/classes/java/awt/geom/Point2D.java
! src/share/classes/java/awt/geom/QuadCurve2D.java
! src/share/classes/java/awt/geom/RectangularShape.java
! src/share/classes/java/awt/image/ImageFilter.java
! src/share/classes/java/awt/image/Kernel.java
! src/share/classes/java/io/ObjectStreamClass.java
! src/share/classes/java/lang/CharacterName.java
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/invoke/CallSite.java
! src/share/classes/java/lang/invoke/Invokers.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/share/classes/java/lang/invoke/MethodTypeForm.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/rmi/dgc/VMID.java
! src/share/classes/java/security/cert/CollectionCertStoreParameters.java
! src/share/classes/java/security/cert/LDAPCertStoreParameters.java
! src/share/classes/java/security/cert/PKIXCertPathChecker.java
! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java
! src/share/classes/java/security/cert/PKIXParameters.java
! src/share/classes/java/security/cert/X509CRLSelector.java
! src/share/classes/java/security/cert/X509CertSelector.java
! src/share/classes/java/text/AttributedString.java
! src/share/classes/java/text/BreakDictionary.java
! src/share/classes/java/text/BreakIterator.java
! src/share/classes/java/text/Collator.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/text/DigitList.java
! src/share/classes/java/text/Format.java
! src/share/classes/java/text/RuleBasedBreakIterator.java
! src/share/classes/java/text/StringCharacterIterator.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/BitSet.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/UUID.java
! src/share/classes/java/util/Vector.java
! src/share/classes/java/util/zip/ZipEntry.java
! src/share/classes/javax/management/openmbean/TabularDataSupport.java
! src/share/classes/javax/swing/text/ElementIterator.java
! src/share/classes/javax/swing/text/rtf/RTFReader.java
! src/share/classes/sun/dc/DuctusRenderingEngine.java
! src/share/classes/sun/font/FontLineMetrics.java
! src/share/classes/sun/font/GlyphLayout.java
! src/share/classes/sun/invoke/util/ValueConversions.java
! src/share/classes/sun/java2d/pipe/LoopPipe.java
! src/share/classes/sun/management/counter/perf/PerfDataEntry.java
! src/share/classes/sun/management/counter/perf/PerfDataType.java
! src/share/classes/sun/misc/Launcher.java
! src/share/classes/sun/misc/ProxyGenerator.java
! src/share/classes/sun/net/NetworkClient.java
! src/share/classes/sun/net/NetworkServer.java
! src/share/classes/sun/net/ftp/impl/FtpClient.java
! src/share/classes/sun/net/smtp/SmtpClient.java
! src/share/classes/sun/net/www/http/ChunkedOutputStream.java
! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
! src/share/classes/sun/net/www/protocol/https/HttpsClient.java
! src/share/classes/sun/nio/ch/Util.java
! src/share/classes/sun/reflect/UTF8.java
! src/share/classes/sun/reflect/misc/MethodUtil.java
! src/share/classes/sun/rmi/transport/LiveRef.java
! src/share/classes/sun/security/provider/SecureRandom.java
! src/share/classes/sun/security/provider/SeedGenerator.java
! src/share/classes/sun/security/provider/certpath/ForwardState.java
! src/share/classes/sun/security/provider/certpath/ReverseState.java
! src/share/classes/sun/security/provider/certpath/URICertStore.java
! src/share/classes/sun/security/util/SecurityConstants.java
! src/share/classes/sun/text/CompactByteArray.java
! src/share/classes/sun/text/normalizer/NormalizerBase.java
! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java
! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java
! src/share/classes/sun/tools/jconsole/LocalVirtualMachine.java
! src/share/classes/sun/tools/tree/Node.java
! src/share/classes/sun/tracing/dtrace/DTraceProvider.java
! src/share/classes/sun/util/calendar/CalendarDate.java
! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java
! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java
! src/solaris/classes/sun/nio/ch/InheritedChannel.java
! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java



From weijun.wang at oracle.com  Wed Aug 31 01:23:32 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Wed, 31 Aug 2011 01:23:32 +0000
Subject: hg: jdk8/tl/jdk: 7083664: test hard code of using c:/temp but this
	dir might not exist
Message-ID: <20110831012342.3169047240@hg.openjdk.java.net>

Changeset: f5120b47f93d
Author:    weijun
Date:      2011-08-31 09:22 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f5120b47f93d

7083664: test hard code of using c:/temp but this dir might not exist
Reviewed-by: xuelei, ohair

! test/lib/security/java.policy/Ext_AllPolicy.sh
! test/sun/security/tools/jarsigner/AlgOptions.sh
! test/sun/security/tools/jarsigner/PercentSign.sh
! test/sun/security/tools/jarsigner/diffend.sh
! test/sun/security/tools/jarsigner/oldsig.sh
! test/sun/security/tools/keytool/AltProviderPath.sh
! test/sun/security/tools/keytool/SecretKeyKS.sh
! test/sun/security/tools/keytool/StandardAlgName.sh
! test/sun/security/tools/keytool/i18n.sh
! test/sun/security/tools/keytool/resource.sh
! test/sun/security/tools/policytool/Alias.sh
! test/sun/security/tools/policytool/ChangeUI.sh
! test/sun/security/tools/policytool/OpenPolicy.sh
! test/sun/security/tools/policytool/SaveAs.sh
! test/sun/security/tools/policytool/UpdatePermissions.sh
! test/sun/security/tools/policytool/UsePolicy.sh
! test/sun/security/tools/policytool/i18n.sh



From maurizio.cimadamore at oracle.com  Wed Aug 31 15:16:29 2011
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 31 Aug 2011 15:16:29 +0000
Subject: hg: jdk8/tl/langtools: 2 new changesets
Message-ID: <20110831151633.4F19247260@hg.openjdk.java.net>

Changeset: b86277584776
Author:    mcimadamore
Date:      2011-08-31 16:11 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b86277584776

7085024: internal error; cannot instantiate Foo
Summary: Types.isConvertible does not handle erroneous types correctly
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/7085024/T7085024.java
+ test/tools/javac/7085024/T7085024.out

Changeset: d0257833498e
Author:    mcimadamore
Date:      2011-08-31 16:15 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d0257833498e

7079713: javac hangs when compiling a class that references a cyclically inherited class
Summary: Types.membersClosure needs to handle pathological cases of cyclic inheritance
Reviewed-by: jjg, jjh

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/7079713/TestCircularClassfile.java



From jonathan.gibbons at oracle.com  Wed Aug 31 22:39:26 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 31 Aug 2011 22:39:26 +0000
Subject: hg: jdk8/tl/langtools: 7074416: Regression: JSR199: javac doesn't
	unwrap clientcodewrapper objects
Message-ID: <20110831223928.C51BA47275@hg.openjdk.java.net>

Changeset: f85d980faaf8
Author:    jjg
Date:      2011-08-31 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f85d980faaf8

7074416: Regression: JSR199: javac doesn't unwrap clientcodewrapper objects
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java
! src/share/classes/javax/tools/JavaCompiler.java
! test/tools/javac/TryWithResources/UnusedResourcesTest.java
! test/tools/javac/diags/Example.java
! test/tools/javac/processing/errors/TestSuppression.java