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
