review request for 7011998: diamond conversion for jgss and pkcs11

[Stuart Marks]

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
>>>>>
>>>
>