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
