Review request for 6927486: Deadlock in legacy Hashtable writeObject()

[Stuart Marks]

On 1/5/11 5:36 AM, Alan Bateman wrote:
> I've taken the liberty to generate a webrev from the changeset, just to make it
> a bit easier for folks to browse and review.
> http://cr.openjdk.java.net/~alanb/6927486/webrev/
>
> I don't see any issues with the changes to j.u.Hashtable. You might have seen
> Stuart Mark's changes go by recently where he changed some of the existing code
> (including java.util) to use diamond. You might want to use this in these
> changes to avoid needing to re-run the tools on this code. This would also fix
> a style issue where you've got a space between the type parameters in a few
> places.

A couple things here.

First, the changeset Alan refers to is 449dfb061fde, where I used a conversion 
tool to apply the diamond operator in a bunch of places. The tool applied 
diamond *everywhere* that the current JDK 7 compiler supports it. It's not 
clear that we actually want to use diamond everywhere that it can be used, 
however, we haven't completely decided this yet.

In Hashtable.java, diamond is used in a bunch of similar places. I'd suggest 
following the style that's there and using diamond in this case, the creation 
of an Entry object for entryStack, e.g.

     entryStack = new Entry<>(0, entry.key, entry.value, entryStack);

Second, it's not clear to me that there is a preferred style for putting spaces 
in the list of type arguments. If one looks around the code base, it's quite 
inconsistent. There does seem to be a moderate preference for not using spaces 
when the type arguments are themselves type parameters, which are typically 
single letters, e.g. Entry<K,V>. But spaces are often used when the type 
arguments are concrete types that are full words, e.g. Map<String, Boolean>. 
But this is moot if diamond is used in this case.

s'marks