hg: jdk7/tl/jdk: 2 new changesets
Changeset: adff75ebdc00 Author:valeriep Date: 2010-12-22 19:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/adff75ebdc00 6924489: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OPERATION_NOT_INITIALIZED Summary: Reset cipher state to un-initialized wherever necessary. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 3254c3ae63fe Author:valeriep Date: 2010-12-27 11:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3254c3ae63fe Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java
Re: review request for 7008728: diamond conversion of basic security, permission, authentication code
On 12/22/10 8:39 PM, Stuart Marks wrote: The third batch of diamond conversions in the security area. This one's for Sean. Can you review this? Webrev is here: http://cr.openjdk.java.net/~smarks/reviews/7008728/webrev.0/ src/share/classes/com/sun/security/auth/SubjectCodeSource.java [96] Looks like the converter also missed another one. I think this line should be: new LinkedList<>() : In particular, take a look at src/share/classes/javax/security/auth/Subject.java It looks like the converter might have missed a diamond opportunity at line 157. Hmmm. Let me know what you think. Yes, I agree. Everything else looks good, though I did not scan every source file looking for potential missed conversions - I only looked for missed ones if it was near the code that had differences (such as SubjectCodeSource). Also, I would be curious to know if there has been any discussion in Project Coin regarding my other comment as to whether the diamond operator improves code readability if the variable is declared elsewhere. --Sean
Re: review request for 7008713: diamond conversion of kerberos5 and security tools
On 12/22/10 9:04 PM, Stuart Marks wrote: BTW, what are we supposed to review? Besides going through the patch and making sure each change is good, the only thing I can think of is looking for lines need coinification but untouched. Made some simple greps and found none yet. A fair question. While most of the changes are mechanical, I think the main criterion is, "does this improve the code?" The diamond operator doesn't (or at least, shouldn't) change any semantics of the code, so this is all about style, readability, conciseness, etc. Using the diamond operator definitely makes the code *shorter*. Whether it's *better* doesn't necessarily follow from that. In most cases, though, using diamond is better, I think. I'd be curious if you saw any instances where you thought that it would be better not to use diamond. It's not a requirement to use diamond everywhere possible. That's one of the points of this exercise, which is to put the new language features through their paces on real code, and to see how well it works out. One instance where I think it is debatable as to whether it improves code readability is if the variable is declared somewhere else in the code. In these cases I find myself scrolling upwards or searching to find the declaration to see what type the parameters are. --Sean
Code Review Request: CR 6976118, version number tolerance in the PreMasterSecret
Hi Weijun, A simple fix for version number tolerance. webrev: http://cr.openjdk.java.net/~xuelei/6976118/webrev.00/ Thanks, Xuelei
