Get it! Thanks! Andrew
On 1/14/2011 2:47 PM, Stuart Marks wrote: > 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 >>>>>> >>>> >>
