Diamond conversion doesn't do very much other than to make the code shorter, by
removing redundancy. The meaning and function of the program aren't changed at
all. Given a diamond, the compiler infers type arguments based on the context.
In many cases where a variable is declared and initialized at the same
location, the type arguments in the initializer are identical to those in the
declaration. So, using diamond lets us get rid of a bit of noise.
In the example you chose the benefit is fairly small. There are other cases
where the benefit is greater, such as this one from
src/share/classes/sun/security/pkcs11/SunPKCS11.java:
- final Map<Descriptor,Integer> supportedAlgs =
- new HashMap<Descriptor,Integer>();
+ final Map<Descriptor,Integer> supportedAlgs = new HashMap<>();
The shorter initializer lets us fold things back onto a single line. Not a
really big deal, but a little nicer I think.
s'marks
On 1/13/11 7:15 PM, Xuelei Fan wrote:
Sorry, I did not look into this too much. I have a question about the
diamond conversion. Why we want to make the change like the following
code? What's the benefits?
private final static Map<BulkCipher,Boolean> availableCache =
- new HashMap<BulkCipher,Boolean>(8);
+ new HashMap<>(8);
Thanks,
Andrew
On 1/14/2011 11:02 AM, Stuart Marks wrote:
I did full clean builds of the JDK repo with -g:none, both with and
without the diamond changes. I then compared all of the .class files in
the two builds using the "cmp" command. The files were all identical,
with the exception of two version classes which I think are
auto-generated with date stamps or something. In any case all of the
.class files corresponding to .java files in my changeset were
byte-for-byte identical.
s'marks
On 1/13/11 4:41 PM, Valerie (Yu-Ching) Peng wrote:
Which particular class did you compared? Just to double check...
Thanks,
Valerie
On 01/13/11 04:15 PM, Stuart Marks wrote:
Yes, the byte codes are identical. I compiled with -g:none before and
after
the changes and the classfiles are all identical. (Even though the
bytecodes
are identical, the classfiles would differ because of changed line
number
information, which is disabled with -g:none.)
So, I assume this means that sunpkcs11.jar doesn't need to be
updated, and
that I can push this changeset without further changes?
s'marks
On 1/12/11 7:06 PM, Valerie (Yu-Ching) Peng wrote:
The changes look good to me.
BTW, I recall seeing in one of your earlier email that the byte code
is the
same w/ the usage of this diamond operator. Is this so?
If not, then we need to update the sunpkcs11.jar also.
Thanks,
Valerie
On 01/12/11 05:30 PM, Stuart Marks wrote:
Hi Valerie,
You're up next for diamond conversion. :-)
These should be pretty straightforward. Almost all changes are
variable
initializations. There's one return statement, one use of diamond in a
ternary operator (a ? b : c), and one whitespace fixup.
Webrev is here:
http://cr.openjdk.java.net/~smarks/reviews/7011998/webrev.0/
Thanks!
s'marks
