Max,
Good catch to find this bug!
Some comments:
1) I don't get why salt now becomes transient. I don't see that it has
any effect on how the object is cloned and class is not Serializable.
2) You should be able to remove L128 in the new file. The cloned object
will have same value for na
Changeset: 04cf82179fa7
Author:mcimadamore
Date: 2010-04-21 12:24 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/04cf82179fa7
6730476: invalid "unchecked generic array" warning
Summary: Reifiable-ness of varargs element type should be checked after JLS3
15.12.2.8
Revie
On Apr 21, 2010, at 6:53 PM, Chris Hegarty wrote:
> Max,
>
> Good catch to find this bug!
>
> Some comments:
> 1) I don't get why salt now becomes transient. I don't see that it has
> any effect on how the object is cloned and class is not Serializable.
Reversed. I just had a habit to mark a
On 21/04/2010 12:24, Weijun Wang wrote:
On Apr 21, 2010, at 6:53 PM, Chris Hegarty wrote:
Max,
Good catch to find this bug!
Some comments:
1) I don't get why salt now becomes transient. I don't see that it has
any effect on how the object is cloned and class is not Serializable.
Reverse
Jeff I'm a little confused about the reasoning here. I was surprised to
discover that the atomic updaters allow you to perform accesses that
direct bytecode and reflection do not (perhaps I knew this when we put
them together but have since forgotten). So contrary to my expectation
that the rea
On 4/19/2010 11:23 AM, Martin Buchholz wrote:
Jeff, please review.
Yes, will do. I was caught up with other things last week. I will
try to go through and catch up with this discussion later today.
Jeff
On 4/16/2010 5:50 AM, David Holmes wrote:
Hi Doug,
approval as I'm not a subscriber.>
Doug Lea said the following on 04/16/10 21:43:
On 04/15/10 18:34, Martin Buchholz wrote:
People are using Atomic field updaters to update fields in classes
in other classloaders.
I think the policy on
Changeset: edde2f60415b
Author:weijun
Date: 2010-04-22 12:45 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/edde2f60415b
6856069: PrincipalName.clone() does not invoke super.clone()
Reviewed-by: chegar
! src/share/classes/sun/security/krb5/PrincipalName.java
+ test/sun/secur
Jeff,
I totally agree with your analysis.
I'd like to see better javadoc for java.util.concurrent.atomic
in general. I'm not sure I'm the best person to come
up with the kind of security-related javadoc we want to see here.
The key idea is that, like an instance of Unsafe,
an updater is a token
