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
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
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 availableCache =
- new HashMap(8);
+ new HashMap<>(8);
Thanks,
Andrew
On 1/14/2011 11:02 AM, Stuart
Is there something in the source tree that needs to be modified so that
sunpkcs11.jar gets updated properly? I see this file in my build output area:
build/linux-i586/lib/ext/sunpkcs11.jar
but I presume this is created automatically by the build process, from .class
files that are built fr
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 s
If sunpkcs11.jar includes line number info (which I think yes), then it
needs to be updated. Otherwise, line numbers shown in the exception
stack info will not match the source code.
Max
On 01/14/2011 08:15 AM, Stuart Marks wrote:
Yes, the byte codes are identical. I compiled with -g:none bef
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
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 mea
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
