From weijun.wang at oracle.com Tue Aug 2 00:02:33 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 02 Aug 2011 15:02:33 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E379640.9050105@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> Message-ID: <4E37A109.7080902@oracle.com> Hi All http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ *Attention*: please note that the jtreg mode for jdk_security3 is still RunOthervmBatch. Xuelei is now working on the JSSE tests. Once he is ready, he will change the mode to RunSamevmBatch. The code changes: * Still included in test/ProblemList.txt - JSSE tests, Xuelei is working on them - ec tests on solaris-i586, they fail even if run standalone * PKCS11/EC tests: - New Providers.setAt, to ensure provider is added to desired position: test/sun/security/pkcs11/ec/* - PKCS11Test.safeReload, to ensure shared library can be loaded again: test/sun/security/pkcs11/PKCS11Test.java test/sun/security/pkcs11/SecmodTest.java - Test using config files need to run in othervm: test/sun/security/pkcs11/Secmod/* test/sun/security/pkcs11/fips/* - Restoring provider lists: test/sun/security/ec/TestEC.java test/sun/security/pkcs11/PKCS11Test.java * Try-with-resources updates: - test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - test/sun/security/pkcs12/PKCS12SameKeyId.java - test/sun/security/tools/keytool/StartDateTest.java * Other tests still need to be in -othervm: Using special policy file: test/sun/security/provider/PolicyFile/Comparator.java AlgorithmId static field oidTable initialization: test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java * JAAS configuration restore: - test/javax/security/auth/login/LoginContext/ResetConfigModule.java * Use "localhost" as hostname, to make name resolution fast - test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java After these changes, JPRT test run (with RunSamevmBatch and no JSSE tests) shows most tests are OK. There are still intermittent failures which are PKCS11/EC provider related. Thanks Max From xuelei.fan at oracle.com Tue Aug 2 02:19:19 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 02 Aug 2011 17:19:19 +0800 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E34155E.5090700@oracle.com> References: <4E34155E.5090700@oracle.com> Message-ID: <4E37C117.2030104@oracle.com> > Please review these JNDI changes. > Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072353 > webrev: http://cr.openjdk.java.net/~mduigou/7072353/0/webrev/ Thanks for your effort to make JNDI free of compile-warning. The work is hard, I appreciate it. 1. I noticed the copyright date of a few files are unchanged, please update them before you push the changes. 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java In javax.naming.Context, Hashtable is used for context environment. In this changes, you use Hashtable. What do you think if we keep the type of K and V the same as Hashtable? I also noticed the similar inconsistency at: . com/sun/jndi/dns/DnsContext.java: 50 Hashtable environment; . com/sun/jndi/ldap/LdapCtx.java 226 Hashtable envprops = null; 3. src/share/classes/com/sun/jndi/dns/DnsContext.java What do you think if we have BaseNameClassPairEnumeration to implement the NamingEnumeration, so that we can share the code of nextElement()? class BaseNameClassPairEnumeration implements NamingEnumeration *** com/sun/jndi/ldap/Connection.java 251 } catch (ClassNotFoundException | 252 InstantiationException | 253 InvocationTargetException | 254 IllegalAccessException e) { I like this new try-catch feature! 4. com/sun/jndi/ldap/LdapCtx.java 1194 return (NamingEnumeration) 1195 new LdapBindingEnumeration(this, answer, name, cont); LdapBindingEnumeration is of type NamingEnumeration, it may be not necessary to convert to NamingEnumeration. Do you mean NamingEnumeration? return (NamingEnumeration) new LdapBindingEnumeration(this, answer, name, cont); 2244 switch (propName) { Do you want to indent this block? We usually indent a block even for switch blocks. 3017 Vector temp = (Vector)extractURLs(res.errorMessage); You may not need the conversion any more, the return value of extractURLs() has been updated to 2564 private static Vector extractURLs(String refString) 5. com/sun/jndi/ldap/LdapBindingEnumeration.java Why it is necessary to convert the return type twice (line 92)? 92 return (LdapBindingEnumeration)(NamingEnumeration) 93 refCtx.listBindings(listArg); It's great to use convariant return type. I would suggest add override tag to make it easy understood. I am only able to review a quarter of the update today, will continue tomorrow. Thanks, Xuelei From chris.hegarty at oracle.com Tue Aug 2 07:08:59 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 02 Aug 2011 14:08:59 +0000 Subject: hg: jdk8/tl/jdk: 6978200: ServerSocket.toString include "port=0" in the returned String Message-ID: <20110802140909.6A2E3478C2@hg.openjdk.java.net> Changeset: 809e8db0c142 Author: chegar Date: 2011-07-29 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/809e8db0c142 6978200: ServerSocket.toString include "port=0" in the returned String Summary: Removal of "port=0" from ServerSocket.toString method Reviewed-by: alanb, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/ServerSocket.java From Alan.Bateman at oracle.com Tue Aug 2 09:11:56 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Aug 2011 17:11:56 +0100 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E37C117.2030104@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> Message-ID: <4E3821CC.9030202@oracle.com> Xuelei Fan wrote: > : > 1. I noticed the copyright date of a few files are unchanged, please > update them before you push the changes. > This has come up a few times but I don't think it is strictly required. Kelly or one of the release engineers run a script over the forest periodically to fix up the date range. The nice thing (in my view anyway) about not changing the headers is that it avoids clutter in the patch and webrev. It also makes it a bit easier to transport patches to other releases. -Alan From Alan.Bateman at oracle.com Tue Aug 2 09:43:19 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Aug 2011 17:43:19 +0100 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E37A109.7080902@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> Message-ID: <4E382927.1070806@oracle.com> Weijun Wang wrote: > Hi All > > http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ I went through the changes to the tests and they look okay to me. It's good to see so many tests removed from the problem list and the tests updated to work in samevm or agentvm mode. Is there a bug created for the ec tests that are failing on solaris-i586? If so then it would be good to include the bugID for future edits to the problem list. Also I see you've commented out two ec tests and I wonder if these lines should be removed or uncommented. test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - no problem with your change but I notice this test using URL's getFile which isn't the right way to get to a file path. Could this be changed to using File(URI)? -Alan. From Xuelei.Fan at Oracle.Com Tue Aug 2 09:53:52 2011 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 3 Aug 2011 00:53:52 +0800 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E3821CC.9030202@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> <4E3821CC.9030202@oracle.com> Message-ID: <4128F157-7CB7-43F5-846C-6FFB5A6DEA0A@Oracle.Com> On Aug 3, 2011, at 12:11 AM, Alan Bateman wrote: > Xuelei Fan wrote: >> : >> 1. I noticed the copyright date of a few files are unchanged, please >> update them before you push the changes. >> > This has come up a few times but I don't think it is strictly required. Kelly or one of the release engineers run a script over the forest periodically to fix up the date range. It's very good. I like the way that update the header in bunch. Thanks, Xuelei > The nice thing (in my view anyway) about not changing the headers is that it avoids clutter in the patch and webrev. It also makes it a bit easier to transport patches to other releases. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20110803/e9ef1861/attachment.html From alexandre.boulgakov at oracle.com Tue Aug 2 11:44:09 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Tue, 02 Aug 2011 11:44:09 -0700 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E37C117.2030104@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> Message-ID: <4E384579.1080209@oracle.com> Thanks for reviewing! See my responses inline. I'll wait on sending another webrev until I've received the rest of your comments. -Sasha On 8/2/2011 2:19 AM, Xuelei Fan wrote: >> Please review these JNDI changes. >> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072353 >> webrev: http://cr.openjdk.java.net/~mduigou/7072353/0/webrev/ > Thanks for your effort to make JNDI free of compile-warning. The work is > hard, I appreciate it. > > 1. I noticed the copyright date of a few files are unchanged, please > update them before you push the changes. I've done that in my local copy but didn't include it in the webrev so as to not pollute it. > > 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java > In javax.naming.Context, Hashtable is used for context > environment. In this changes, you use Hashtable. > What do you think if we keep the type of K and V the same as > Hashtable? > > I also noticed the similar inconsistency at: > . com/sun/jndi/dns/DnsContext.java: > 50 Hashtable environment; > . com/sun/jndi/ldap/LdapCtx.java > 226 Hashtable envprops = null; The environment passed to the constructor is still Hashtable, so there shouldn't be any source incompatibility because of this. However, the environment is accessed within the class under the assumption that (String, Object) pairs or (Object, Object) pairs can be added. This means that the environment must be of type Hashtable or Hashtable at the time Hashtable.put is called. We can either cast it at every call site or once in the constructor. If I understand type erasure correctly, these casts will not affect the bytecode produced since the compiler is smart enough to notice we are casting a Hashtable to a Hashtable, so the only difference is in terms of readability and the number of @SuppressWarnings("unchecked") annotations thta need to be included. > > 3. src/share/classes/com/sun/jndi/dns/DnsContext.java > What do you think if we have BaseNameClassPairEnumeration to > implement the NamingEnumeration, so that we can share the code of > nextElement()? I'll change it to abstract class BaseNameClassPairEnumeration implements NamingEnumeration > > class BaseNameClassPairEnumeration implements NamingEnumeration > > *** com/sun/jndi/ldap/Connection.java > 251 } catch (ClassNotFoundException | > 252 InstantiationException | > 253 InvocationTargetException | > 254 IllegalAccessException e) { > > I like this new try-catch feature! > > 4. com/sun/jndi/ldap/LdapCtx.java > 1194 return (NamingEnumeration) > 1195 new LdapBindingEnumeration(this, answer, name, cont); > > LdapBindingEnumeration is of type NamingEnumeration, it may be not > necessary to convert to NamingEnumeration. Do you mean > NamingEnumeration? > > return (NamingEnumeration) > new LdapBindingEnumeration(this, answer, name, cont); LdapBindingEnumeration extends LdapNamingEnumeration, which implements NamingEnumeration. This means we can cast it to NamingEnumeration directly, but must go through a raw intermediate like NamingEnumeration or Object. I can change it to a double cast with (NamingEnumeration)(NamingEnumeration), if you think that would improve readability, or LdapBindingEnumeration and LdapNamingEnumeration could be refactored to implement different NamingEnumeration interfaces (like I did with NameClassPairEnumeration and BindingEnumeration in src/share/classes/com/sun/jndi/dns/DnsContext.java). > > 2244 switch (propName) { > Do you want to indent this block? We usually indent a block even for > switch blocks. Oops, didn't notice that. > > 3017 Vector temp = (Vector)extractURLs(res.errorMessage); > You may not need the conversion any more, the return value of > extractURLs() has been updated to > 2564 private static Vector extractURLs(String refString) The cast is needed to go from Vector to Vector. > > 5. com/sun/jndi/ldap/LdapBindingEnumeration.java > Why it is necessary to convert the return type twice (line 92)? > > 92 return (LdapBindingEnumeration)(NamingEnumeration) > 93 refCtx.listBindings(listArg); Again, it's due to a generic type mismatch: refCtx.listBindings(listArg) returns a NamingEnumeration but LdapBindingEnumeration implements NamingEnumeration. It'd be great if we could have variant generic interface type parameters, so NamingEnumeration could extend NamingEnumeration. > > It's great to use convariant return type. I would suggest add > override tag to make it easy understood. > > I am only able to review a quarter of the update today, will continue > tomorrow. > > Thanks, > Xuelei From alexandre.boulgakov at oracle.com Tue Aug 2 11:47:08 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Tue, 02 Aug 2011 11:47:08 -0700 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E37C117.2030104@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> Message-ID: <4E38462C.7010900@oracle.com> Thanks for reviewing! Please see my responses inline. I'll wait on sending another webrev until I've received the rest of your comments. -Sasha On 8/2/2011 2:19 AM, Xuelei Fan wrote: >> Please review these JNDI changes. >> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072353 >> webrev: http://cr.openjdk.java.net/~mduigou/7072353/0/webrev/ > Thanks for your effort to make JNDI free of compile-warning. The work is > hard, I appreciate it. > > 1. I noticed the copyright date of a few files are unchanged, please > update them before you push the changes. I've done that in my local copy but didn't include it in the webrev so as to not pollute it. > > 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java > In javax.naming.Context, Hashtable is used for context > environment. In this changes, you use Hashtable. > What do you think if we keep the type of K and V the same as > Hashtable? > > I also noticed the similar inconsistency at: > . com/sun/jndi/dns/DnsContext.java: > 50 Hashtable environment; > . com/sun/jndi/ldap/LdapCtx.java > 226 Hashtable envprops = null; The environment passed to the constructor is still Hashtable, so there shouldn't be any source incompatibility because of this. However, the environment is accessed within the class under the assumption that (String, Object) pairs or (Object, Object) pairs can be added. This means that the environment must be of type Hashtable or Hashtable at the time Hashtable.put is called. We can either cast it at every call site or once in the constructor. If I understand type erasure correctly, these casts will not affect the bytecode produced since the compiler is smart enough to notice we are casting a Hashtable to a Hashtable, so the only difference is in terms of readability and the number of @SuppressWarnings("unchecked") annotations that need to be included. > > 3. src/share/classes/com/sun/jndi/dns/DnsContext.java > What do you think if we have BaseNameClassPairEnumeration to > implement the NamingEnumeration, so that we can share the code of > nextElement()? I'll change it to abstract class BaseNameClassPairEnumeration implements NamingEnumeration > > class BaseNameClassPairEnumeration implements NamingEnumeration > > *** com/sun/jndi/ldap/Connection.java > 251 } catch (ClassNotFoundException | > 252 InstantiationException | > 253 InvocationTargetException | > 254 IllegalAccessException e) { > > I like this new try-catch feature! > > 4. com/sun/jndi/ldap/LdapCtx.java > 1194 return (NamingEnumeration) > 1195 new LdapBindingEnumeration(this, answer, name, cont); > > LdapBindingEnumeration is of type NamingEnumeration, it may be not > necessary to convert to NamingEnumeration. Do you mean > NamingEnumeration? > > return (NamingEnumeration) > new LdapBindingEnumeration(this, answer, name, cont); LdapBindingEnumeration extends LdapNamingEnumeration, which implements NamingEnumeration. This means we cannot cast it to NamingEnumeration directly, but must go through a raw intermediate like NamingEnumeration or Object. I can change it to a double cast with (NamingEnumeration)(NamingEnumeration), if you think that would improve readability, or LdapBindingEnumeration and LdapNamingEnumeration could be refactored to implement different NamingEnumeration interfaces (like I did with NameClassPairEnumeration and BindingEnumeration in src/share/classes/com/sun/jndi/dns/DnsContext.java). > > 2244 switch (propName) { > Do you want to indent this block? We usually indent a block even for > switch blocks. Oops, didn't notice that. > > 3017 Vector temp = (Vector)extractURLs(res.errorMessage); > You may not need the conversion any more, the return value of > extractURLs() has been updated to > 2564 private static Vector extractURLs(String refString) The cast is needed to go from Vector to Vector. > > 5. com/sun/jndi/ldap/LdapBindingEnumeration.java > Why it is necessary to convert the return type twice (line 92)? > > 92 return (LdapBindingEnumeration)(NamingEnumeration) > 93 refCtx.listBindings(listArg); Again, it's due to a generic type mismatch: refCtx.listBindings(listArg) returns a NamingEnumeration but LdapBindingEnumeration implements NamingEnumeration. It'd be great if we could have variant generic interface type parameters, so NamingEnumeration could extend NamingEnumeration. > > It's great to use convariant return type. I would suggest add > override tag to make it easy understood. > > I am only able to review a quarter of the update today, will continue > tomorrow. > > Thanks, > Xuelei From weijun.wang at oracle.com Tue Aug 2 20:50:52 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 03 Aug 2011 11:50:52 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E382927.1070806@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E382927.1070806@oracle.com> Message-ID: <4E38C59C.1000504@oracle.com> On 08/03/2011 12:43 AM, Alan Bateman wrote: > Weijun Wang wrote: >> Hi All >> >> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ > I went through the changes to the tests and they look okay to me. It's > good to see so many tests removed from the problem list and the tests > updated to work in samevm or agentvm mode. > > Is there a bug created for the ec tests that are failing on > solaris-i586? If so then it would be good to include the bugID for I thought there was one but I cannot find it. *Vinnie*, do you know it? > future edits to the problem list. Also I see you've commented out two ec > tests and I wonder if these lines should be removed or uncommented. I don't understand why these 2 pass now. Maybe they still fail on some platforms not in JPRT? Anyway, I just don't want to purge the lines. > > test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - no problem > with your change but I notice this test using URL's getFile which isn't > the right way to get to a file path. Could this be changed to using > File(URI)? This test is a compatibility check, see http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/4e7ad09de58b I remember there were some strange things on Windows, say, UNC, \ vs /, that made some hand-crafted URL illegal. We cannot support all of them, so just make sure the old supported ones are still supported. Thanks Max > > -Alan. > > > > > From xuelei.fan at oracle.com Tue Aug 2 21:13:13 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 03 Aug 2011 12:13:13 +0800 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E384579.1080209@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> <4E384579.1080209@oracle.com> Message-ID: <4E38CAD9.8050705@oracle.com> com/sun/jndi/toolkit/dir/SearchFilter.java 451 for (NamingEnumeration ve = attr.getAll(); 452 ve.hasMore(); 453 ) { The update is OK. But the coding style looks uncomfortable. Would you mind change it to use for-each style? . javax/naming/directory/BasicAttribute.java It's an old coding style issue, would you mind indent the lines in inner-class ValuesEnumImpl? On 8/3/2011 2:44 AM, Alexandre Boulgakov wrote: > Thanks for reviewing! See my responses inline. > > I'll wait on sending another webrev until I've received the rest of your > comments. > > -Sasha > > On 8/2/2011 2:19 AM, Xuelei Fan wrote: >>> Please review these JNDI changes. >>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072353 >>> webrev: http://cr.openjdk.java.net/~mduigou/7072353/0/webrev/ >> Thanks for your effort to make JNDI free of compile-warning. The work is >> hard, I appreciate it. >> >> 1. I noticed the copyright date of a few files are unchanged, please >> update them before you push the changes. > I've done that in my local copy but didn't include it in the webrev so > as to not pollute it. We (security team) used to update all copyright date range manually. But Alan told me that the release engineers will run a script over the forest periodically to fix up the date range. I like this way, I think we don't have to update the date range in every fix manually any more. It depends on you. >> >> 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java >> In javax.naming.Context, Hashtable is used for context >> environment. In this changes, you use Hashtable> java.lang.Object>. >> What do you think if we keep the type of K and V the same as >> Hashtable? >> >> I also noticed the similar inconsistency at: >> . com/sun/jndi/dns/DnsContext.java: >> 50 Hashtable environment; >> . com/sun/jndi/ldap/LdapCtx.java >> 226 Hashtable envprops = null; > The environment passed to the constructor is still Hashtable, so > there shouldn't be any source incompatibility because of this. However, > the environment is accessed within the class under the assumption that > (String, Object) pairs or (Object, Object) pairs can be added. This > means that the environment must be of type Hashtable or > Hashtable at the time Hashtable.put is called. We can > either cast it at every call site or once in the constructor. If I > understand type erasure correctly, these casts will not affect the > bytecode produced since the compiler is smart enough to notice we are > casting a Hashtable to a Hashtable, so the only difference is in terms > of readability and the number of @SuppressWarnings("unchecked") > annotations thta need to be included. Sounds reasonable. >> >> 3. src/share/classes/com/sun/jndi/dns/DnsContext.java >> What do you think if we have BaseNameClassPairEnumeration to >> implement the NamingEnumeration, so that we can share the code of >> nextElement()? > > I'll change it to > abstract class BaseNameClassPairEnumeration implements > NamingEnumeration > You may also want to change BaseFlatNames in com/sun/jndi/toolkit/dir/HierMemDirCtx.java with the similar style. >> >> class BaseNameClassPairEnumeration implements NamingEnumeration >> >> *** com/sun/jndi/ldap/Connection.java >> 251 } catch (ClassNotFoundException | >> 252 InstantiationException | >> 253 InvocationTargetException | >> 254 IllegalAccessException e) { >> >> I like this new try-catch feature! >> >> 4. com/sun/jndi/ldap/LdapCtx.java >> 1194 return (NamingEnumeration) >> 1195 new LdapBindingEnumeration(this, answer, name, cont); >> >> LdapBindingEnumeration is of type NamingEnumeration, it may be not >> necessary to convert to NamingEnumeration. Do you mean >> NamingEnumeration? >> >> return (NamingEnumeration) >> new LdapBindingEnumeration(this, answer, name, cont); > LdapBindingEnumeration extends LdapNamingEnumeration, which implements > NamingEnumeration. This means we can cast it to > NamingEnumeration directly, but must go through a raw > intermediate like NamingEnumeration or Object. I can change it to a > double cast with (NamingEnumeration)(NamingEnumeration), if you > think that would improve readability, or LdapBindingEnumeration and > LdapNamingEnumeration could be refactored to implement different > NamingEnumeration interfaces (like I did with > NameClassPairEnumeration and BindingEnumeration in > src/share/classes/com/sun/jndi/dns/DnsContext.java). LdapBindingEnumeration --extends--> LdapNamingEnumeration --implements --> NamingEnumeration. >From the above hierarchy, LdapBindingEnumeration is an instance of NamingEnumeration. Now you cast it to NamingEnumeration. It might work, but it looks unreasonable and risky in the first glance. The LdapNamingEnumeration and LdapBindingEnumeration is designed when using non-generic programming style. If we switch to use generic features, the inherit structure may not sound reasonable any more. You made a good update in DnsContext and HierMemDirCtx by introducing a intermediate class, BaseNameClassPairEnumeration/BaseFlatNames. Does it sound a solution to LdapBindingEnumeration and LdapNamingEnumeration? >> >> 2244 switch (propName) { >> Do you want to indent this block? We usually indent a block even for >> switch blocks. > Oops, didn't notice that. >> >> 3017 Vector temp = (Vector)extractURLs(res.errorMessage); >> You may not need the conversion any more, the return value of >> extractURLs() has been updated to >> 2564 private static Vector extractURLs(String refString) > The cast is needed to go from Vector to Vector. >> >> 5. com/sun/jndi/ldap/LdapBindingEnumeration.java >> Why it is necessary to convert the return type twice (line 92)? >> 8>> 92 return (LdapBindingEnumeration)(NamingEnumeration) >> 93 refCtx.listBindings(listArg); > Again, it's due to a generic type mismatch: refCtx.listBindings(listArg) > returns a NamingEnumeration but LdapBindingEnumeration > implements NamingEnumeration. It'd be great if we could > have variant generic interface type parameters, so > NamingEnumeration could extend NamingEnumeration. See above. Otherwise, looks fine to me. Thanks, Xuelei >> >> It's great to use convariant return type. I would suggest add >> override tag to make it easy understood. >> >> I am only able to review a quarter of the update today, will continue >> tomorrow. >> >> Thanks, >> Xuelei From ahughes at redhat.com Tue Aug 2 22:44:23 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 3 Aug 2011 06:44:23 +0100 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E3821CC.9030202@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> <4E3821CC.9030202@oracle.com> Message-ID: <20110803054423.GD31431@rivendell.middle-earth.co.uk> On 17:11 Tue 02 Aug , Alan Bateman wrote: > Xuelei Fan wrote: > > : > > 1. I noticed the copyright date of a few files are unchanged, please > > update them before you push the changes. > > > This has come up a few times but I don't think it is strictly required. > Kelly or one of the release engineers run a script over the forest > periodically to fix up the date range. The nice thing (in my view > anyway) about not changing the headers is that it avoids clutter in the > patch and webrev. It also makes it a bit easier to transport patches to > other releases. > I was thinking the same thing. Copyright header changes mixed into other patches are a nightmare as regards backporting. > -Alan > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From David.Holmes at oracle.com Wed Aug 3 00:42:21 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 03 Aug 2011 17:42:21 +1000 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E384579.1080209@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> <4E384579.1080209@oracle.com> Message-ID: <4E38FBDD.8070202@oracle.com> Alexandre Boulgakov said the following on 08/03/11 04:44: > On 8/2/2011 2:19 AM, Xuelei Fan wrote: >> 3017 Vector temp = (Vector)extractURLs(res.errorMessage); >> You may not need the conversion any more, the return value of >> extractURLs() has been updated to >> 2564 private static Vector extractURLs(String refString) > The cast is needed to go from Vector to Vector. Raw types should be avoided (here and elsewhere there are casts to raw Vector). I'm surprised (generics continue to surprise me) that despite all our advances in type-inference etc that the compiler can not tell that a Vector is-a Vector. :( Not knowing how LdapResult.referrals is used overall I'm unsure what might be a better fix but perhaps referrals could be declared as Vector and an unchecked cast to Vector added only/if where needed? Cheers, David Holmes From alexandre.boulgakov at oracle.com Wed Aug 3 11:03:29 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Wed, 03 Aug 2011 11:03:29 -0700 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E38CAD9.8050705@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> <4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com> Message-ID: <4E398D71.9030302@oracle.com> Please see my responses inline. Thanks! -Sasha On 8/2/2011 9:13 PM, Xuelei Fan wrote: > . com/sun/jndi/toolkit/dir/SearchFilter.java > 451 for (NamingEnumeration ve = attr.getAll(); > 452 ve.hasMore(); > 453 ) { > > The update is OK. But the coding style looks uncomfortable. Would you > mind change it to use for-each style? For-each only works with Iterables. There doesn't seem to be a way to get an Iterable out of an Attribute instance, so the only way to use a for-each here would be to wrap the Enumeration in an ArrayList using Collections.list(). While this might look neater, the contents of the Enumeration would have to be copied over, using time and increasing the memory footprint. Changing Attribute to implement Iterable would require a spec change, and would be beyond the scope of this fix. > > . javax/naming/directory/BasicAttribute.java > It's an old coding style issue, would you mind indent the lines in > inner-class ValuesEnumImpl? Got it. > We (security team) used to update all copyright date range manually. But > Alan told me that the release engineers will run a script over the > forest periodically to fix up the date range. I like this way, I think > we don't have to update the date range in every fix manually any more. > It depends on you. I'll keep that in mind, but I've already updated the copyright dates in my local copy. Would it be fine to include them in the next version of the webrev? Since these are just warning fixes, they probably will not be backported. > >>> 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java >>> In javax.naming.Context, Hashtable is used for context >>> environment. In this changes, you use Hashtable>> java.lang.Object>. >>> What do you think if we keep the type of K and V the same as >>> Hashtable? >>> >>> I also noticed the similar inconsistency at: >>> . com/sun/jndi/dns/DnsContext.java: >>> 50 Hashtable environment; >>> . com/sun/jndi/ldap/LdapCtx.java >>> 226 Hashtable envprops = null; >> The environment passed to the constructor is still Hashtable, so >> there shouldn't be any source incompatibility because of this. However, >> the environment is accessed within the class under the assumption that >> (String, Object) pairs or (Object, Object) pairs can be added. This >> means that the environment must be of type Hashtable or >> Hashtable at the time Hashtable.put is called. We can >> either cast it at every call site or once in the constructor. If I >> understand type erasure correctly, these casts will not affect the >> bytecode produced since the compiler is smart enough to notice we are >> casting a Hashtable to a Hashtable, so the only difference is in terms >> of readability and the number of @SuppressWarnings("unchecked") >> annotations thta need to be included. > Sounds reasonable. > >>> 3. src/share/classes/com/sun/jndi/dns/DnsContext.java >>> What do you think if we have BaseNameClassPairEnumeration to >>> implement the NamingEnumeration, so that we can share the code of >>> nextElement()? >> I'll change it to >> abstract class BaseNameClassPairEnumeration implements >> NamingEnumeration >> > You may also want to change BaseFlatNames in > com/sun/jndi/toolkit/dir/HierMemDirCtx.java with the similar style. Got it. Would it make sense to make everything except for the next() methods final, or will the compiler infer that? > LdapBindingEnumeration --extends--> LdapNamingEnumeration --implements > --> NamingEnumeration. > > From the above hierarchy, LdapBindingEnumeration is an instance of > NamingEnumeration. Now you cast it to > NamingEnumeration. It might work, but it looks unreasonable and > risky in the first glance. > > The LdapNamingEnumeration and LdapBindingEnumeration is designed when > using non-generic programming style. If we switch to use generic > features, the inherit structure may not sound reasonable any more. > > You made a good update in DnsContext and HierMemDirCtx by introducing a > intermediate class, BaseNameClassPairEnumeration/BaseFlatNames. Does it > sound a solution to LdapBindingEnumeration and LdapNamingEnumeration? Yes, I can do that. And also for LdapSearchEnumeration which extends LdapNamingEnumeration as well. > >>> 2244 switch (propName) { >>> Do you want to indent this block? We usually indent a block even for >>> switch blocks. >> Oops, didn't notice that. >>> 3017 Vector temp = (Vector)extractURLs(res.errorMessage); >>> You may not need the conversion any more, the return value of >>> extractURLs() has been updated to >>> 2564 private static Vector extractURLs(String refString) >> The cast is needed to go from Vector to Vector. >>> 5. com/sun/jndi/ldap/LdapBindingEnumeration.java >>> Why it is necessary to convert the return type twice (line 92)? >>> > 8>> 92 return (LdapBindingEnumeration)(NamingEnumeration) >>> 93 refCtx.listBindings(listArg); >> Again, it's due to a generic type mismatch: refCtx.listBindings(listArg) >> returns a NamingEnumeration but LdapBindingEnumeration >> implements NamingEnumeration. It'd be great if we could >> have variant generic interface type parameters, so >> NamingEnumeration could extend NamingEnumeration. > See above. > > Otherwise, looks fine to me. > > Thanks, > Xuelei > >>> It's great to use convariant return type. I would suggest add >>> override tag to make it easy understood. >>> >>> I am only able to review a quarter of the update today, will continue >>> tomorrow. >>> >>> Thanks, >>> Xuelei From alexandre.boulgakov at oracle.com Wed Aug 3 14:14:22 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Wed, 03 Aug 2011 14:14:22 -0700 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <1312405776.14748.25.camel@chalkhill> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> <4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com> <4E398D71.9030302@oracle.com> <1312405776.14748.25.camel@chalkhill> Message-ID: <4E39BA2E.9050405@oracle.com> Users of Iterable expect to call Iterable.iterator() multiple times, receiving a fresh iterator pointing to the beginning of the Iterable each time. This would not be possible to do with an Enumeration wrapper since Enumerations are read-once. I don't know if this is a strong enough reason not to include such a utility class, but it could certainly be confusing. -Sasha On 8/3/2011 2:09 PM, Neil Richards wrote: > On Wed, 2011-08-03 at 11:03 -0700, Alexandre Boulgakov wrote: >> Please see my responses inline. >> >> Thanks! >> -Sasha >> >> On 8/2/2011 9:13 PM, Xuelei Fan wrote: >>> . com/sun/jndi/toolkit/dir/SearchFilter.java >>> 451 for (NamingEnumeration ve = attr.getAll(); >>> 452 ve.hasMore(); >>> 453 ) { >>> >>> The update is OK. But the coding style looks uncomfortable. Would you >>> mind change it to use for-each style? >> For-each only works with Iterables. There doesn't seem to be a way to >> get an Iterable out of an Attribute instance, so the only way to use a >> for-each here would be to wrap the Enumeration in an ArrayList using >> Collections.list(). While this might look neater, the contents of the >> Enumeration would have to be copied over, using time and increasing the >> memory footprint. Changing Attribute to implement Iterable would require >> a spec change, and would be beyond the scope of this fix. > Would it be useful to have a utility object to convert an Enumeration > so it can be used in for-each constructs? - something like: > ---- > import java.util.Enumeration; > import java.util.Iterator; > > /** > * Utility class to transform an Enumeration object such that it can be used in > * the for-each construct. > */ > public class IterableEnumerationHolder implements Iterable, Iterator { > private final Enumeration e; > > public IterableEnumerationHolder(final Enumeration e) { > this.e = e; > } > > @Override > public Iterator iterator() { > return this; > } > > @Override > public boolean hasNext() { > return e.hasMoreElements(); > } > > @Override > public E next() { > return e.nextElement(); > } > > @Override > public void remove() { > throw new UnsupportedOperationException(); > } > } > ---- > > If it would, perhaps it might be considered for Java 8? > > Regards, > Neil > From valerie.peng at oracle.com Wed Aug 3 14:48:15 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 03 Aug 2011 14:48:15 -0700 Subject: code review request: 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problemThe In-Reply-To: <4E15078E.20001@oracle.com> References: <4E15078E.20001@oracle.com> Message-ID: <4E39C21F.8040605@oracle.com> The changes look good to me. Thanks, Valerie On 07/06/11 18:10, Weijun Wang wrote: > Hi Valerie > > http://cr.openjdk.java.net/~weijun/7061379/webrev.00/ > > The bug report says the TGS-REQ "asks for a KRB_NT_SRV_INST type > whereas the kdc answers with a KRB_NT_PRINCIPAL type. Thus, > equalsWithoutRealm function fails and authentication is refused". The > KDC's behavior is a little abnormal but RFC 4120 6.2 [1] does point out: > > ... The name-type SHOULD be > treated only as a hint to interpreting the meaning of a name. It is > not significant when checking for equivalence. > > So I remove the name-type check in > PrincipalName.equalsWithoutRsealm(). This also makes equals() > transitive, which is good. The hashCode() method has never been > dependent on the name-type, so there is no need to update it. > > The regression test introduced a new KDC option to set name-type for > sname in a KDC-REP to be an arbitrary value, in order to prove it is > now ignored in "checking for equivalence". > > Thanks > Max > > [1] http://tools.ietf.org/html/rfc4120#section-6.2 > > -------- Original Message -------- > *Change Request ID*: 7061379 > *Synopsis*: [Kerberos] Cross-realm authentication fails, due to > nameType problem > > > === *Description* > ============================================================ > FULL PRODUCT VERSION : > Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02, mixed mode) > > /!\ same bug with open jdk 1.7 > > ADDITIONAL OS VERSION INFORMATION : > Linux x86_64 Intel(R) Xeon(R) CPU L5520 @ 2.27GHz GNU/Linux > > EXTRA RELEVANT SYSTEM CONFIGURATION : > /!\ same bug with open jdk 1.7 > > A DESCRIPTION OF THE PROBLEM : > Authentication to remote server fails. Error doesn't appear in the > logs but the debugger points out the following error: > > KRB_AP_ERR_MODIFIED (erreur 41) Message stream modified > in sun.security.krb5.KrbKdcRep class, line 56 > > Cross-realm authentication to one remote service is processed in > sun.security.krb5.internal.CredentialsUtil class. > It consists in the obtention of a token for the krbtgt/REALM1 at REALM2 > principal. > > Function acquireServiceCreds() negotiates with the kdc, by throwing > requests and receiving responses. equalsWithoutRealm() function is > called. > > The function equalsWithoutRealm() in sun.security.krb5.PrincipalName > checks the conformity between principal asked in request and principal > obtained in response. > However, there is a type mismatch between the two krbtgt principals: > request asks for a KRB_NT_SRV_INST type whereas the kdc answers with a > KRB_NT_PRINCIPAL type. Thus, equalsWithoutRealm function fails and > authentication is refused. > > > STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : > Try to access from one realm to whatever remote 'kerberized' service. > For example: GSSAPI and JNDI for remote LDAP server. > > EXPECTED VERSUS ACTUAL BEHAVIOR : > EXPECTED - > Expected result: successful authentication with remote service access. > ACTUAL - > Error is caught but not reported in system.out, and remote > authentication fails. > > ERROR MESSAGES/STACK TRACES THAT OCCUR : > KRB_AP_ERR_MODIFIED (erreur 41) Message stream modified > in sun.security.krb5.KrbKdcRep class, line 56 > > is reached but never thrown to the logs. > > REPRODUCIBILITY : > This bug can be reproduced always. > > CUSTOMER SUBMITTED WORKAROUND : > Modifying the acquireServiceCreds() function solves the problem. But > maybe the best solution is to change the request for a cross-realm > krbtgt. > > Line 134 in CredentialsUtil.java: > > for (cTgt = ccreds, i = 0; i < realms.length;) > { > // tempService = new > ServiceName(PrincipalName.TGS_DEFAULT_SRV_NAME, > // serviceRealm, realms[i]); > if (!localRealm.equalsIgnoreCase(serviceRealm)) { //do > cross-realm authentication > if (DEBUG) { > System.out.println(">>>DEBUG: Credentails request > cross realm ticket for " + "krbtgt/" + serviceRealm + "@" + localRealm); > } > tempService = new ServiceName("krbtgt/" + serviceRealm > + "@" + realms[i]); > }else{ > tempService = new > ServiceName(PrincipalName.TGS_DEFAULT_SRV_NAME, > serviceRealm, realms[i]); > } > > if (DEBUG) > { > System.out.println(">>> Credentials > acquireServiceCreds: main loop: [" + i +"] tempService=" + tempService); > } > ... > ... > ... > > SUPPORT : > YES > From xuelei.fan at oracle.com Wed Aug 3 16:15:03 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Aug 2011 07:15:03 +0800 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E398D71.9030302@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> <4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com> <4E398D71.9030302@oracle.com> Message-ID: <4E39D677.8090107@oracle.com> On 8/4/2011 2:03 AM, Alexandre Boulgakov wrote: > Please see my responses inline. > > Thanks! > -Sasha > > On 8/2/2011 9:13 PM, Xuelei Fan wrote: >> . com/sun/jndi/toolkit/dir/SearchFilter.java >> 451 for (NamingEnumeration ve = attr.getAll(); >> 452 ve.hasMore(); >> 453 ) { >> >> The update is OK. But the coding style looks uncomfortable. Would you >> mind change it to use for-each style? > For-each only works with Iterables. There doesn't seem to be a way to > get an Iterable out of an Attribute instance, so the only way to use a > for-each here would be to wrap the Enumeration in an ArrayList using > Collections.list(). While this might look neater, the contents of the > Enumeration would have to be copied over, using time and increasing the > memory footprint. Changing Attribute to implement Iterable would require > a spec change, and would be beyond the scope of this fix. > My fault, I thought Enumeration is able to work with for-each. OK, forgot it, or if you don't mind, please append line 453 at the end of line 452. >> >> . javax/naming/directory/BasicAttribute.java >> It's an old coding style issue, would you mind indent the lines in >> inner-class ValuesEnumImpl? > Got it. >> We (security team) used to update all copyright date range manually. But >> Alan told me that the release engineers will run a script over the >> forest periodically to fix up the date range. I like this way, I think >> we don't have to update the date range in every fix manually any more. >> It depends on you. > I'll keep that in mind, but I've already updated the copyright dates in > my local copy. Would it be fine to include them in the next version of > the webrev? Sure, it's OK. > Since these are just warning fixes, they probably will not > be backported. >> >>>> 2. src/share/classes/com/sun/jndi/cosnaming/CNCtx.java >>>> In javax.naming.Context, Hashtable is used for context >>>> environment. In this changes, you use Hashtable>>> java.lang.Object>. >>>> What do you think if we keep the type of K and V the same as >>>> Hashtable? >>>> >>>> I also noticed the similar inconsistency at: >>>> . com/sun/jndi/dns/DnsContext.java: >>>> 50 Hashtable environment; >>>> . com/sun/jndi/ldap/LdapCtx.java >>>> 226 Hashtable envprops = null; >>> The environment passed to the constructor is still Hashtable, so >>> there shouldn't be any source incompatibility because of this. However, >>> the environment is accessed within the class under the assumption that >>> (String, Object) pairs or (Object, Object) pairs can be added. This >>> means that the environment must be of type Hashtable or >>> Hashtable at the time Hashtable.put is called. We can >>> either cast it at every call site or once in the constructor. If I >>> understand type erasure correctly, these casts will not affect the >>> bytecode produced since the compiler is smart enough to notice we are >>> casting a Hashtable to a Hashtable, so the only difference is in terms >>> of readability and the number of @SuppressWarnings("unchecked") >>> annotations thta need to be included. >> Sounds reasonable. >> >>>> 3. src/share/classes/com/sun/jndi/dns/DnsContext.java >>>> What do you think if we have BaseNameClassPairEnumeration to >>>> implement the NamingEnumeration, so that we can share the code of >>>> nextElement()? >>> I'll change it to >>> abstract class BaseNameClassPairEnumeration implements >>> NamingEnumeration >>> >> You may also want to change BaseFlatNames in >> com/sun/jndi/toolkit/dir/HierMemDirCtx.java with the similar style. > Got it. Would it make sense to make everything except for the next() > methods final, or will the compiler infer that? I think it's a good idea. >> LdapBindingEnumeration --extends--> LdapNamingEnumeration --implements >> --> NamingEnumeration. >> >> From the above hierarchy, LdapBindingEnumeration is an instance of >> NamingEnumeration. Now you cast it to >> NamingEnumeration. It might work, but it looks unreasonable and >> risky in the first glance. >> >> The LdapNamingEnumeration and LdapBindingEnumeration is designed when >> using non-generic programming style. If we switch to use generic >> features, the inherit structure may not sound reasonable any more. >> >> You made a good update in DnsContext and HierMemDirCtx by introducing a >> intermediate class, BaseNameClassPairEnumeration/BaseFlatNames. Does it >> sound a solution to LdapBindingEnumeration and LdapNamingEnumeration? > Yes, I can do that. And also for LdapSearchEnumeration which extends > LdapNamingEnumeration as well. Thanks. Thanks, Xuelei >> >>>> 2244 switch (propName) { >>>> Do you want to indent this block? We usually indent a block >>>> even for >>>> switch blocks. >>> Oops, didn't notice that. >>>> 3017 Vector temp = (Vector)extractURLs(res.errorMessage); >>>> You may not need the conversion any more, the return value of >>>> extractURLs() has been updated to >>>> 2564 private static Vector extractURLs(String >>>> refString) >>> The cast is needed to go from Vector to Vector. >>>> 5. com/sun/jndi/ldap/LdapBindingEnumeration.java >>>> Why it is necessary to convert the return type twice (line 92)? >>>> >> 8>> 92 return (LdapBindingEnumeration)(NamingEnumeration) >>>> 93 refCtx.listBindings(listArg); >>> Again, it's due to a generic type mismatch: refCtx.listBindings(listArg) >>> returns a NamingEnumeration but LdapBindingEnumeration >>> implements NamingEnumeration. It'd be great if we could >>> have variant generic interface type parameters, so >>> NamingEnumeration could extend >>> NamingEnumeration. >> See above. >> >> Otherwise, looks fine to me. >> >> Thanks, >> Xuelei >> >>>> It's great to use convariant return type. I would suggest add >>>> override tag to make it easy understood. >>>> >>>> I am only able to review a quarter of the update today, will continue >>>> tomorrow. >>>> >>>> Thanks, >>>> Xuelei From alexandre.boulgakov at oracle.com Wed Aug 3 16:39:08 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Wed, 03 Aug 2011 16:39:08 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror In-Reply-To: <4E30574A.8020907@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> Message-ID: <4E39DC1C.9040705@oracle.com> Ping..? -Sasha On 7/27/2011 11:22 AM, Alexandre Boulgakov wrote: > Should I just use the newest serialVersionUID for both of them? > > -Sasha > > On 7/26/2011 10:31 AM, Alexandre Boulgakov wrote: >> I just noticed that pkcs11 is not built on my machine (64-bit >> Windows) so I missed all of the warnings there. There are two mission >> serialVersionUID warnings for classes that have had different >> generated serialVersionUID's in the past. >> >> sun.security.pkcs11.P11Key.P11SecretKey >> -currently: -7828241727014329084L; >> -JDK 1.5: -897881148551545872L; >> >> sun.security.pkcs11.P11TlsPrfGenerator$1 >> -currently: -8090049519656411362L; >> -JDK 6: -3305145912345854189L; >> >> I'm not sure why the serialVersionUID changed for >> sun.security.pkcs11.P11TlsPrfGenerator$1; the code is the same, and >> the serialVersionUID for the base class javax.crypto.SecretKey hasn't >> changed. >> >> For sun.security.pkcs11.P11Key.P11SecretKey, the code is the same, >> but the base class sun.security.pkcs11.P11Key has changed. >> >> How should I go about resolving these issues? >> >> Thanks, >> Sasha >> >> On 7/20/2011 3:37 PM, Xuelei.Fan at Oracle.Com wrote: >>> >>> On Jul 21, 2011, at 1:25 AM, Alexandre >>> Boulgakov wrote: >>> >>>> This is a Netbeans warning, not generated by the compiler. The >>>> reason is that List.isEmpty() can be more efficient for some >>>> implementations. ArrayList.size() == 0 and ArrayList.isEmpty() >>>> should take the same time, so it doesn't matter for allResults, but >>>> keyTypeList is a List argument, so any implementation could be >>>> passed in. List.isEmpty() should never be slower than List.size() >>>> == 0 because AbstractCollection defines isEmpty() as size() == 0. >>>> >>>> Even if we don't get a performance improvement, it still improves >>>> readability. >>>> >>> Sounds reasonable. >>> >>> Thanks, >>> Xuelei >>> >>>> -Sasha >>>> >>>> On 7/19/2011 7:32 PM, Xuelei Fan wrote: >>>>> I was looking at the updates in sun/security/ssl. Looks fine to me. >>>>> >>>>> It's fine, but I just wonder why List.isEmpty() is preferred to >>>>> (List.size() == 0). What's the compiler warning for (List.size() >>>>> == 0)? >>>>> >>>>> src/share/classes/sun/security/ssl/X509KeyManagerImpl.java >>>>> - if (keyTypeList == null || keyTypeList.size() == 0) { >>>>> + if (keyTypeList == null || keyTypeList.isEmpty()) { >>>>> >>>>> - if (allResults == null || allResults.size() == 0) { >>>>> + if (allResults == null || allResults.isEmpty()) { >>>>> >>>>> Thanks for the cleanup. >>>>> >>>>> Thanks, >>>>> Xuelei (Andrew) Fan >>>>> >>>>> On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote: >>>>>> Hello Sean, >>>>>> >>>>>> Have you had a chance to look at this webrev? >>>>>> >>>>>> Thanks, >>>>>> Sasha >>>>>> >>>>>> On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Here's an updated webrev: >>>>>>> http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/ >>>>>>> >>>>>>> I've reexamined the @SuppressWarnings("unchecked") annotations, and >>>>>>> added comments to all of the ones I've added. I was was also >>>>>>> able to >>>>>>> remove several of them by using covariant return types on >>>>>>> sun.security.x509.*Extension.get(String) inherited from Object >>>>>>> CertAttrSet.get(String). I've also updated the consumers of >>>>>>> sun.security.x509.*Extension.get(String) to use the more specific >>>>>>> return type, removing several casts and >>>>>>> @SuppressWarnings("unchecked") >>>>>>> annotations. >>>>>>> >>>>>>> Also, please take a closer look at my changes to >>>>>>> com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry, >>>>>>> >>>>>>> final CodeSource) in >>>>>>> src/share/classes/com/sun/security/auth/PolicyFile.java lines >>>>>>> 1088-1094. The preceding comment and the behavior of >>>>>>> Subject.getPrincipals(Class) seem to be more consistent with the >>>>>>> updated version, but I wanted to make sure. >>>>>>> >>>>>>> The classes where I added serialVersionUID's are either new or have >>>>>>> the same serialVersionUID as the original implementation. >>>>>>> >>>>>>> Thanks, >>>>>>> Sasha >>>>>>> >>>>>>> On 7/18/2011 5:33 PM, Brad Wetmore wrote: >>>>>>>> (Apologies to folks without access to the older sources.) >>>>>>>> >>>>>>>> >>>>>>>> On 07/18/11 15:00, Sean Mullan wrote: >>>>>>>>> On 7/18/11 5:35 PM, Alexandre Boulgakov wrote: >>>>>>>>>> Is there an easy way to see when a class was added to the JDK? >>>>>>>>> For standard API classes, you can use the @since javadoc tag >>>>>>>>> which >>>>>>>>> will indicate >>>>>>>>> the release it was first introduced in. >>>>>>>> Standard, exported API classes. Some of the underlying support >>>>>>>> classes for API packages like java.*.* weren't always @since'd >>>>>>>> properly. >>>>>>>> >>>>>>>>> For internal classes, there is no easy way, since most don't >>>>>>>>> have an >>>>>>>>> @since tag. >>>>>>>>> I would probably write a script that checks the rt.jar of each of >>>>>>>>> the JREs that >>>>>>>>> are archived at /java/re/jdk. The pathnames should be fairly >>>>>>>>> consistent, just >>>>>>>>> the version number is different. >>>>>>>> Don't know which classes you're talking about here, but some >>>>>>>> classes >>>>>>>> started out in other jar files and eventually wound up in rt.jar. >>>>>>>> Also, some files live in files other than rt.jar. I usually go to >>>>>>>> the source when looking for something. If it's originally from >>>>>>>> JSSE/JGSS/JCE, you'll need to look on our restricted access >>>>>>>> machine. >>>>>>>> >>>>>>>> When I'm looking for something that is in the jdk/j2se >>>>>>>> workspaces, I >>>>>>>> go right to the old Codemgr data, specifically the nametable file, >>>>>>>> because many times the files you want may be in a >>>>>>>> src//classes >>>>>>>> instead of src/share/classes. >>>>>>>> >>>>>>>> % grep -i SunMSCAPI.java >>>>>>>> /5.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>> >>>>>>>> % grep -i SunMSCAPI.java >>>>>>>> /6.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>> src/windows/classes/sun/security/mscapi/SunMSCAPI.java ada8dbe4 >>>>>>>> a217f6b0 6c833bd3 d4ef32be >>>>>>>> >>>>>>>> That will usually give you a good starting point. >>>>>>>> >>>>>>>> Brad >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Depending on rt.jar or not. >>>>>>>> >>>>>>>>> Chris, do you have any other ideas? >>>>>>>>> >>>>>>>>> --Sean From xuelei.fan at oracle.com Wed Aug 3 16:49:53 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Aug 2011 07:49:53 +0800 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror In-Reply-To: <4E39DC1C.9040705@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> Message-ID: <4E39DEA1.5030100@oracle.com> Oops, I missed this. I don't think we can modify serialVersionUID value for backward compatibility. Thanks, Xuelei On 8/4/2011 7:39 AM, Alexandre Boulgakov wrote: > Ping..? > > -Sasha > > On 7/27/2011 11:22 AM, Alexandre Boulgakov wrote: >> Should I just use the newest serialVersionUID for both of them? >> >> -Sasha >> >> On 7/26/2011 10:31 AM, Alexandre Boulgakov wrote: >>> I just noticed that pkcs11 is not built on my machine (64-bit >>> Windows) so I missed all of the warnings there. There are two mission >>> serialVersionUID warnings for classes that have had different >>> generated serialVersionUID's in the past. >>> >>> sun.security.pkcs11.P11Key.P11SecretKey >>> -currently: -7828241727014329084L; >>> -JDK 1.5: -897881148551545872L; >>> >>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>> -currently: -8090049519656411362L; >>> -JDK 6: -3305145912345854189L; >>> >>> I'm not sure why the serialVersionUID changed for >>> sun.security.pkcs11.P11TlsPrfGenerator$1; the code is the same, and >>> the serialVersionUID for the base class javax.crypto.SecretKey hasn't >>> changed. >>> >>> For sun.security.pkcs11.P11Key.P11SecretKey, the code is the same, >>> but the base class sun.security.pkcs11.P11Key has changed. >>> >>> How should I go about resolving these issues? >>> >>> Thanks, >>> Sasha >>> >>> On 7/20/2011 3:37 PM, Xuelei.Fan at Oracle.Com wrote: >>>> >>>> On Jul 21, 2011, at 1:25 AM, Alexandre >>>> Boulgakov wrote: >>>> >>>>> This is a Netbeans warning, not generated by the compiler. The >>>>> reason is that List.isEmpty() can be more efficient for some >>>>> implementations. ArrayList.size() == 0 and ArrayList.isEmpty() >>>>> should take the same time, so it doesn't matter for allResults, but >>>>> keyTypeList is a List argument, so any implementation could be >>>>> passed in. List.isEmpty() should never be slower than List.size() >>>>> == 0 because AbstractCollection defines isEmpty() as size() == 0. >>>>> >>>>> Even if we don't get a performance improvement, it still improves >>>>> readability. >>>>> >>>> Sounds reasonable. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> -Sasha >>>>> >>>>> On 7/19/2011 7:32 PM, Xuelei Fan wrote: >>>>>> I was looking at the updates in sun/security/ssl. Looks fine to me. >>>>>> >>>>>> It's fine, but I just wonder why List.isEmpty() is preferred to >>>>>> (List.size() == 0). What's the compiler warning for (List.size() >>>>>> == 0)? >>>>>> >>>>>> src/share/classes/sun/security/ssl/X509KeyManagerImpl.java >>>>>> - if (keyTypeList == null || keyTypeList.size() == 0) { >>>>>> + if (keyTypeList == null || keyTypeList.isEmpty()) { >>>>>> >>>>>> - if (allResults == null || allResults.size() == 0) { >>>>>> + if (allResults == null || allResults.isEmpty()) { >>>>>> >>>>>> Thanks for the cleanup. >>>>>> >>>>>> Thanks, >>>>>> Xuelei (Andrew) Fan >>>>>> >>>>>> On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote: >>>>>>> Hello Sean, >>>>>>> >>>>>>> Have you had a chance to look at this webrev? >>>>>>> >>>>>>> Thanks, >>>>>>> Sasha >>>>>>> >>>>>>> On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Here's an updated webrev: >>>>>>>> http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/ >>>>>>>> >>>>>>>> I've reexamined the @SuppressWarnings("unchecked") annotations, and >>>>>>>> added comments to all of the ones I've added. I was was also >>>>>>>> able to >>>>>>>> remove several of them by using covariant return types on >>>>>>>> sun.security.x509.*Extension.get(String) inherited from Object >>>>>>>> CertAttrSet.get(String). I've also updated the consumers of >>>>>>>> sun.security.x509.*Extension.get(String) to use the more specific >>>>>>>> return type, removing several casts and >>>>>>>> @SuppressWarnings("unchecked") >>>>>>>> annotations. >>>>>>>> >>>>>>>> Also, please take a closer look at my changes to >>>>>>>> com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry, >>>>>>>> >>>>>>>> final CodeSource) in >>>>>>>> src/share/classes/com/sun/security/auth/PolicyFile.java lines >>>>>>>> 1088-1094. The preceding comment and the behavior of >>>>>>>> Subject.getPrincipals(Class) seem to be more consistent with the >>>>>>>> updated version, but I wanted to make sure. >>>>>>>> >>>>>>>> The classes where I added serialVersionUID's are either new or have >>>>>>>> the same serialVersionUID as the original implementation. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sasha >>>>>>>> >>>>>>>> On 7/18/2011 5:33 PM, Brad Wetmore wrote: >>>>>>>>> (Apologies to folks without access to the older sources.) >>>>>>>>> >>>>>>>>> >>>>>>>>> On 07/18/11 15:00, Sean Mullan wrote: >>>>>>>>>> On 7/18/11 5:35 PM, Alexandre Boulgakov wrote: >>>>>>>>>>> Is there an easy way to see when a class was added to the JDK? >>>>>>>>>> For standard API classes, you can use the @since javadoc tag >>>>>>>>>> which >>>>>>>>>> will indicate >>>>>>>>>> the release it was first introduced in. >>>>>>>>> Standard, exported API classes. Some of the underlying support >>>>>>>>> classes for API packages like java.*.* weren't always @since'd >>>>>>>>> properly. >>>>>>>>> >>>>>>>>>> For internal classes, there is no easy way, since most don't >>>>>>>>>> have an >>>>>>>>>> @since tag. >>>>>>>>>> I would probably write a script that checks the rt.jar of each of >>>>>>>>>> the JREs that >>>>>>>>>> are archived at /java/re/jdk. The pathnames should be fairly >>>>>>>>>> consistent, just >>>>>>>>>> the version number is different. >>>>>>>>> Don't know which classes you're talking about here, but some >>>>>>>>> classes >>>>>>>>> started out in other jar files and eventually wound up in rt.jar. >>>>>>>>> Also, some files live in files other than rt.jar. I usually go to >>>>>>>>> the source when looking for something. If it's originally from >>>>>>>>> JSSE/JGSS/JCE, you'll need to look on our restricted access >>>>>>>>> machine. >>>>>>>>> >>>>>>>>> When I'm looking for something that is in the jdk/j2se >>>>>>>>> workspaces, I >>>>>>>>> go right to the old Codemgr data, specifically the nametable file, >>>>>>>>> because many times the files you want may be in a >>>>>>>>> src//classes >>>>>>>>> instead of src/share/classes. >>>>>>>>> >>>>>>>>> % grep -i SunMSCAPI.java >>>>>>>>> /5.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>>> >>>>>>>>> % grep -i SunMSCAPI.java >>>>>>>>> /6.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>>> src/windows/classes/sun/security/mscapi/SunMSCAPI.java ada8dbe4 >>>>>>>>> a217f6b0 6c833bd3 d4ef32be >>>>>>>>> >>>>>>>>> That will usually give you a good starting point. >>>>>>>>> >>>>>>>>> Brad >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Depending on rt.jar or not. >>>>>>>>> >>>>>>>>>> Chris, do you have any other ideas? >>>>>>>>>> >>>>>>>>>> --Sean From alexandre.boulgakov at oracle.com Wed Aug 3 16:52:40 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Wed, 03 Aug 2011 16:52:40 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror In-Reply-To: <4E39DEA1.5030100@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E39DEA1.5030100@oracle.com> Message-ID: <4E39DF48.7060907@oracle.com> There is currently no serialVersionUID defined for these classes. Do you mean that we cannot add one for backwards compatibility? If so, would the best solution be to add an @SuppressWarnings("serial") annotation to these classes? Thanks, Sasha On 8/3/2011 4:49 PM, Xuelei Fan wrote: > Oops, I missed this. > > I don't think we can modify serialVersionUID value for backward > compatibility. > > Thanks, > Xuelei > > On 8/4/2011 7:39 AM, Alexandre Boulgakov wrote: >> Ping..? >> >> -Sasha >> >> On 7/27/2011 11:22 AM, Alexandre Boulgakov wrote: >>> Should I just use the newest serialVersionUID for both of them? >>> >>> -Sasha >>> >>> On 7/26/2011 10:31 AM, Alexandre Boulgakov wrote: >>>> I just noticed that pkcs11 is not built on my machine (64-bit >>>> Windows) so I missed all of the warnings there. There are two mission >>>> serialVersionUID warnings for classes that have had different >>>> generated serialVersionUID's in the past. >>>> >>>> sun.security.pkcs11.P11Key.P11SecretKey >>>> -currently: -7828241727014329084L; >>>> -JDK 1.5: -897881148551545872L; >>>> >>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>> -currently: -8090049519656411362L; >>>> -JDK 6: -3305145912345854189L; >>>> >>>> I'm not sure why the serialVersionUID changed for >>>> sun.security.pkcs11.P11TlsPrfGenerator$1; the code is the same, and >>>> the serialVersionUID for the base class javax.crypto.SecretKey hasn't >>>> changed. >>>> >>>> For sun.security.pkcs11.P11Key.P11SecretKey, the code is the same, >>>> but the base class sun.security.pkcs11.P11Key has changed. >>>> >>>> How should I go about resolving these issues? >>>> >>>> Thanks, >>>> Sasha >>>> >>>> On 7/20/2011 3:37 PM, Xuelei.Fan at Oracle.Com wrote: >>>>> On Jul 21, 2011, at 1:25 AM, Alexandre >>>>> Boulgakov wrote: >>>>> >>>>>> This is a Netbeans warning, not generated by the compiler. The >>>>>> reason is that List.isEmpty() can be more efficient for some >>>>>> implementations. ArrayList.size() == 0 and ArrayList.isEmpty() >>>>>> should take the same time, so it doesn't matter for allResults, but >>>>>> keyTypeList is a List argument, so any implementation could be >>>>>> passed in. List.isEmpty() should never be slower than List.size() >>>>>> == 0 because AbstractCollection defines isEmpty() as size() == 0. >>>>>> >>>>>> Even if we don't get a performance improvement, it still improves >>>>>> readability. >>>>>> >>>>> Sounds reasonable. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> -Sasha >>>>>> >>>>>> On 7/19/2011 7:32 PM, Xuelei Fan wrote: >>>>>>> I was looking at the updates in sun/security/ssl. Looks fine to me. >>>>>>> >>>>>>> It's fine, but I just wonder why List.isEmpty() is preferred to >>>>>>> (List.size() == 0). What's the compiler warning for (List.size() >>>>>>> == 0)? >>>>>>> >>>>>>> src/share/classes/sun/security/ssl/X509KeyManagerImpl.java >>>>>>> - if (keyTypeList == null || keyTypeList.size() == 0) { >>>>>>> + if (keyTypeList == null || keyTypeList.isEmpty()) { >>>>>>> >>>>>>> - if (allResults == null || allResults.size() == 0) { >>>>>>> + if (allResults == null || allResults.isEmpty()) { >>>>>>> >>>>>>> Thanks for the cleanup. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei (Andrew) Fan >>>>>>> >>>>>>> On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote: >>>>>>>> Hello Sean, >>>>>>>> >>>>>>>> Have you had a chance to look at this webrev? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sasha >>>>>>>> >>>>>>>> On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Here's an updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/ >>>>>>>>> >>>>>>>>> I've reexamined the @SuppressWarnings("unchecked") annotations, and >>>>>>>>> added comments to all of the ones I've added. I was was also >>>>>>>>> able to >>>>>>>>> remove several of them by using covariant return types on >>>>>>>>> sun.security.x509.*Extension.get(String) inherited from Object >>>>>>>>> CertAttrSet.get(String). I've also updated the consumers of >>>>>>>>> sun.security.x509.*Extension.get(String) to use the more specific >>>>>>>>> return type, removing several casts and >>>>>>>>> @SuppressWarnings("unchecked") >>>>>>>>> annotations. >>>>>>>>> >>>>>>>>> Also, please take a closer look at my changes to >>>>>>>>> com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry, >>>>>>>>> >>>>>>>>> final CodeSource) in >>>>>>>>> src/share/classes/com/sun/security/auth/PolicyFile.java lines >>>>>>>>> 1088-1094. The preceding comment and the behavior of >>>>>>>>> Subject.getPrincipals(Class) seem to be more consistent with the >>>>>>>>> updated version, but I wanted to make sure. >>>>>>>>> >>>>>>>>> The classes where I added serialVersionUID's are either new or have >>>>>>>>> the same serialVersionUID as the original implementation. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sasha >>>>>>>>> >>>>>>>>> On 7/18/2011 5:33 PM, Brad Wetmore wrote: >>>>>>>>>> (Apologies to folks without access to the older sources.) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 07/18/11 15:00, Sean Mullan wrote: >>>>>>>>>>> On 7/18/11 5:35 PM, Alexandre Boulgakov wrote: >>>>>>>>>>>> Is there an easy way to see when a class was added to the JDK? >>>>>>>>>>> For standard API classes, you can use the @since javadoc tag >>>>>>>>>>> which >>>>>>>>>>> will indicate >>>>>>>>>>> the release it was first introduced in. >>>>>>>>>> Standard, exported API classes. Some of the underlying support >>>>>>>>>> classes for API packages like java.*.* weren't always @since'd >>>>>>>>>> properly. >>>>>>>>>> >>>>>>>>>>> For internal classes, there is no easy way, since most don't >>>>>>>>>>> have an >>>>>>>>>>> @since tag. >>>>>>>>>>> I would probably write a script that checks the rt.jar of each of >>>>>>>>>>> the JREs that >>>>>>>>>>> are archived at /java/re/jdk. The pathnames should be fairly >>>>>>>>>>> consistent, just >>>>>>>>>>> the version number is different. >>>>>>>>>> Don't know which classes you're talking about here, but some >>>>>>>>>> classes >>>>>>>>>> started out in other jar files and eventually wound up in rt.jar. >>>>>>>>>> Also, some files live in files other than rt.jar. I usually go to >>>>>>>>>> the source when looking for something. If it's originally from >>>>>>>>>> JSSE/JGSS/JCE, you'll need to look on our restricted access >>>>>>>>>> machine. >>>>>>>>>> >>>>>>>>>> When I'm looking for something that is in the jdk/j2se >>>>>>>>>> workspaces, I >>>>>>>>>> go right to the old Codemgr data, specifically the nametable file, >>>>>>>>>> because many times the files you want may be in a >>>>>>>>>> src//classes >>>>>>>>>> instead of src/share/classes. >>>>>>>>>> >>>>>>>>>> % grep -i SunMSCAPI.java >>>>>>>>>> /5.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>>>> >>>>>>>>>> % grep -i SunMSCAPI.java >>>>>>>>>> /6.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>>>> src/windows/classes/sun/security/mscapi/SunMSCAPI.java ada8dbe4 >>>>>>>>>> a217f6b0 6c833bd3 d4ef32be >>>>>>>>>> >>>>>>>>>> That will usually give you a good starting point. >>>>>>>>>> >>>>>>>>>> Brad >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Depending on rt.jar or not. >>>>>>>>>> >>>>>>>>>>> Chris, do you have any other ideas? >>>>>>>>>>> >>>>>>>>>>> --Sean From xuelei.fan at oracle.com Wed Aug 3 17:07:00 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Aug 2011 08:07:00 +0800 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror In-Reply-To: <4E39DF48.7060907@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E39DEA1.5030100@oracle.com> <4E39DF48.7060907@oracle.com> Message-ID: <4E39E2A4.6000206@oracle.com> On 8/4/2011 7:52 AM, Alexandre Boulgakov wrote: > There is currently no serialVersionUID defined for these classes. Do you > mean that we cannot add one for backwards compatibility? My answers only apply to you latest e-mail about the serialVersionUID update in sun.security.pkcs11.P11Key.P11SecretKey and sun.security.pkcs11.P11TlsPrfGenerator$1. I think you need to use the current values unless you get an approval from PKCS11 owner. We may need to consider more for these classes without serialVersionUID, I will look at your webrev again if I can get some time today. Normally, I think if there is a new attribute in a class, it is OK to add a new serialVersionUID value. Xuelei > If so, would > the best solution be to add an @SuppressWarnings("serial") annotation to > these classes? > > Thanks, > Sasha > > On 8/3/2011 4:49 PM, Xuelei Fan wrote: >> Oops, I missed this. >> >> I don't think we can modify serialVersionUID value for backward >> compatibility. >> >> Thanks, >> Xuelei >> >> On 8/4/2011 7:39 AM, Alexandre Boulgakov wrote: >>> Ping..? >>> >>> -Sasha >>> >>> On 7/27/2011 11:22 AM, Alexandre Boulgakov wrote: >>>> Should I just use the newest serialVersionUID for both of them? >>>> >>>> -Sasha >>>> >>>> On 7/26/2011 10:31 AM, Alexandre Boulgakov wrote: >>>>> I just noticed that pkcs11 is not built on my machine (64-bit >>>>> Windows) so I missed all of the warnings there. There are two mission >>>>> serialVersionUID warnings for classes that have had different >>>>> generated serialVersionUID's in the past. >>>>> >>>>> sun.security.pkcs11.P11Key.P11SecretKey >>>>> -currently: -7828241727014329084L; >>>>> -JDK 1.5: -897881148551545872L; >>>>> >>>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>>> -currently: -8090049519656411362L; >>>>> -JDK 6: -3305145912345854189L; >>>>> >>>>> I'm not sure why the serialVersionUID changed for >>>>> sun.security.pkcs11.P11TlsPrfGenerator$1; the code is the same, and >>>>> the serialVersionUID for the base class javax.crypto.SecretKey hasn't >>>>> changed. >>>>> >>>>> For sun.security.pkcs11.P11Key.P11SecretKey, the code is the same, >>>>> but the base class sun.security.pkcs11.P11Key has changed. >>>>> >>>>> How should I go about resolving these issues? >>>>> >>>>> Thanks, >>>>> Sasha >>>>> >>>>> On 7/20/2011 3:37 PM, Xuelei.Fan at Oracle.Com wrote: >>>>>> On Jul 21, 2011, at 1:25 AM, Alexandre >>>>>> Boulgakov wrote: >>>>>> >>>>>>> This is a Netbeans warning, not generated by the compiler. The >>>>>>> reason is that List.isEmpty() can be more efficient for some >>>>>>> implementations. ArrayList.size() == 0 and ArrayList.isEmpty() >>>>>>> should take the same time, so it doesn't matter for allResults, but >>>>>>> keyTypeList is a List argument, so any implementation could be >>>>>>> passed in. List.isEmpty() should never be slower than List.size() >>>>>>> == 0 because AbstractCollection defines isEmpty() as size() == 0. >>>>>>> >>>>>>> Even if we don't get a performance improvement, it still improves >>>>>>> readability. >>>>>>> >>>>>> Sounds reasonable. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>>> -Sasha >>>>>>> >>>>>>> On 7/19/2011 7:32 PM, Xuelei Fan wrote: >>>>>>>> I was looking at the updates in sun/security/ssl. Looks fine to >>>>>>>> me. >>>>>>>> >>>>>>>> It's fine, but I just wonder why List.isEmpty() is preferred to >>>>>>>> (List.size() == 0). What's the compiler warning for (List.size() >>>>>>>> == 0)? >>>>>>>> >>>>>>>> src/share/classes/sun/security/ssl/X509KeyManagerImpl.java >>>>>>>> - if (keyTypeList == null || keyTypeList.size() == 0) { >>>>>>>> + if (keyTypeList == null || keyTypeList.isEmpty()) { >>>>>>>> >>>>>>>> - if (allResults == null || allResults.size() == 0) { >>>>>>>> + if (allResults == null || allResults.isEmpty()) { >>>>>>>> >>>>>>>> Thanks for the cleanup. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei (Andrew) Fan >>>>>>>> >>>>>>>> On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote: >>>>>>>>> Hello Sean, >>>>>>>>> >>>>>>>>> Have you had a chance to look at this webrev? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sasha >>>>>>>>> >>>>>>>>> On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Here's an updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/ >>>>>>>>>> >>>>>>>>>> I've reexamined the @SuppressWarnings("unchecked") >>>>>>>>>> annotations, and >>>>>>>>>> added comments to all of the ones I've added. I was was also >>>>>>>>>> able to >>>>>>>>>> remove several of them by using covariant return types on >>>>>>>>>> sun.security.x509.*Extension.get(String) inherited from Object >>>>>>>>>> CertAttrSet.get(String). I've also updated the consumers of >>>>>>>>>> sun.security.x509.*Extension.get(String) to use the more specific >>>>>>>>>> return type, removing several casts and >>>>>>>>>> @SuppressWarnings("unchecked") >>>>>>>>>> annotations. >>>>>>>>>> >>>>>>>>>> Also, please take a closer look at my changes to >>>>>>>>>> com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> final CodeSource) in >>>>>>>>>> src/share/classes/com/sun/security/auth/PolicyFile.java lines >>>>>>>>>> 1088-1094. The preceding comment and the behavior of >>>>>>>>>> Subject.getPrincipals(Class) seem to be more consistent >>>>>>>>>> with the >>>>>>>>>> updated version, but I wanted to make sure. >>>>>>>>>> >>>>>>>>>> The classes where I added serialVersionUID's are either new or >>>>>>>>>> have >>>>>>>>>> the same serialVersionUID as the original implementation. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sasha >>>>>>>>>> >>>>>>>>>> On 7/18/2011 5:33 PM, Brad Wetmore wrote: >>>>>>>>>>> (Apologies to folks without access to the older sources.) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 07/18/11 15:00, Sean Mullan wrote: >>>>>>>>>>>> On 7/18/11 5:35 PM, Alexandre Boulgakov wrote: >>>>>>>>>>>>> Is there an easy way to see when a class was added to the JDK? >>>>>>>>>>>> For standard API classes, you can use the @since javadoc tag >>>>>>>>>>>> which >>>>>>>>>>>> will indicate >>>>>>>>>>>> the release it was first introduced in. >>>>>>>>>>> Standard, exported API classes. Some of the underlying support >>>>>>>>>>> classes for API packages like java.*.* weren't always @since'd >>>>>>>>>>> properly. >>>>>>>>>>> >>>>>>>>>>>> For internal classes, there is no easy way, since most don't >>>>>>>>>>>> have an >>>>>>>>>>>> @since tag. >>>>>>>>>>>> I would probably write a script that checks the rt.jar of >>>>>>>>>>>> each of >>>>>>>>>>>> the JREs that >>>>>>>>>>>> are archived at /java/re/jdk. The pathnames should be fairly >>>>>>>>>>>> consistent, just >>>>>>>>>>>> the version number is different. >>>>>>>>>>> Don't know which classes you're talking about here, but some >>>>>>>>>>> classes >>>>>>>>>>> started out in other jar files and eventually wound up in >>>>>>>>>>> rt.jar. >>>>>>>>>>> Also, some files live in files other than rt.jar. I usually >>>>>>>>>>> go to >>>>>>>>>>> the source when looking for something. If it's originally from >>>>>>>>>>> JSSE/JGSS/JCE, you'll need to look on our restricted access >>>>>>>>>>> machine. >>>>>>>>>>> >>>>>>>>>>> When I'm looking for something that is in the jdk/j2se >>>>>>>>>>> workspaces, I >>>>>>>>>>> go right to the old Codemgr data, specifically the nametable >>>>>>>>>>> file, >>>>>>>>>>> because many times the files you want may be in a >>>>>>>>>>> src//classes >>>>>>>>>>> instead of src/share/classes. >>>>>>>>>>> >>>>>>>>>>> % grep -i SunMSCAPI.java >>>>>>>>>>> /5.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>>>>> >>>>>>>>>>> % grep -i SunMSCAPI.java >>>>>>>>>>> /6.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>>>>> src/windows/classes/sun/security/mscapi/SunMSCAPI.java ada8dbe4 >>>>>>>>>>> a217f6b0 6c833bd3 d4ef32be >>>>>>>>>>> >>>>>>>>>>> That will usually give you a good starting point. >>>>>>>>>>> >>>>>>>>>>> Brad >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Depending on rt.jar or not. >>>>>>>>>>> >>>>>>>>>>>> Chris, do you have any other ideas? >>>>>>>>>>>> >>>>>>>>>>>> --Sean From alexandre.boulgakov at oracle.com Wed Aug 3 17:10:24 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Wed, 03 Aug 2011 17:10:24 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror In-Reply-To: <4E39E2A4.6000206@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E39DEA1.5030100@oracle.com> <4E39DF48.7060907@oracle.com> <4E39E2A4.6000206@oracle.com> Message-ID: <4E39E370.3020205@oracle.com> Those were the ones I was talking about- the serialVersionUIDs I mentioned were the ones generated by serialver.exe. The webrev doesn't have any of the pkcs11 changes yet (including the added serialVersionUIDs). I'll wait for Brad's or Valerie's response. Thanks, Sasha On 8/3/2011 5:07 PM, Xuelei Fan wrote: > On 8/4/2011 7:52 AM, Alexandre Boulgakov wrote: >> There is currently no serialVersionUID defined for these classes. Do you >> mean that we cannot add one for backwards compatibility? > My answers only apply to you latest e-mail about the serialVersionUID > update in sun.security.pkcs11.P11Key.P11SecretKey and > sun.security.pkcs11.P11TlsPrfGenerator$1. I think you need to use the > current values unless you get an approval from PKCS11 owner. > > We may need to consider more for these classes without serialVersionUID, > I will look at your webrev again if I can get some time today. Normally, > I think if there is a new attribute in a class, it is OK to add a new > serialVersionUID value. > > Xuelei > >> If so, would >> the best solution be to add an @SuppressWarnings("serial") annotation to >> these classes? >> >> Thanks, >> Sasha >> >> On 8/3/2011 4:49 PM, Xuelei Fan wrote: >>> Oops, I missed this. >>> >>> I don't think we can modify serialVersionUID value for backward >>> compatibility. >>> >>> Thanks, >>> Xuelei >>> >>> On 8/4/2011 7:39 AM, Alexandre Boulgakov wrote: >>>> Ping..? >>>> >>>> -Sasha >>>> >>>> On 7/27/2011 11:22 AM, Alexandre Boulgakov wrote: >>>>> Should I just use the newest serialVersionUID for both of them? >>>>> >>>>> -Sasha >>>>> >>>>> On 7/26/2011 10:31 AM, Alexandre Boulgakov wrote: >>>>>> I just noticed that pkcs11 is not built on my machine (64-bit >>>>>> Windows) so I missed all of the warnings there. There are two mission >>>>>> serialVersionUID warnings for classes that have had different >>>>>> generated serialVersionUID's in the past. >>>>>> >>>>>> sun.security.pkcs11.P11Key.P11SecretKey >>>>>> -currently: -7828241727014329084L; >>>>>> -JDK 1.5: -897881148551545872L; >>>>>> >>>>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>>>> -currently: -8090049519656411362L; >>>>>> -JDK 6: -3305145912345854189L; >>>>>> >>>>>> I'm not sure why the serialVersionUID changed for >>>>>> sun.security.pkcs11.P11TlsPrfGenerator$1; the code is the same, and >>>>>> the serialVersionUID for the base class javax.crypto.SecretKey hasn't >>>>>> changed. >>>>>> >>>>>> For sun.security.pkcs11.P11Key.P11SecretKey, the code is the same, >>>>>> but the base class sun.security.pkcs11.P11Key has changed. >>>>>> >>>>>> How should I go about resolving these issues? >>>>>> >>>>>> Thanks, >>>>>> Sasha >>>>>> >>>>>> On 7/20/2011 3:37 PM, Xuelei.Fan at Oracle.Com wrote: >>>>>>> On Jul 21, 2011, at 1:25 AM, Alexandre >>>>>>> Boulgakov wrote: >>>>>>> >>>>>>>> This is a Netbeans warning, not generated by the compiler. The >>>>>>>> reason is that List.isEmpty() can be more efficient for some >>>>>>>> implementations. ArrayList.size() == 0 and ArrayList.isEmpty() >>>>>>>> should take the same time, so it doesn't matter for allResults, but >>>>>>>> keyTypeList is a List argument, so any implementation could be >>>>>>>> passed in. List.isEmpty() should never be slower than List.size() >>>>>>>> == 0 because AbstractCollection defines isEmpty() as size() == 0. >>>>>>>> >>>>>>>> Even if we don't get a performance improvement, it still improves >>>>>>>> readability. >>>>>>>> >>>>>>> Sounds reasonable. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>>> -Sasha >>>>>>>> >>>>>>>> On 7/19/2011 7:32 PM, Xuelei Fan wrote: >>>>>>>>> I was looking at the updates in sun/security/ssl. Looks fine to >>>>>>>>> me. >>>>>>>>> >>>>>>>>> It's fine, but I just wonder why List.isEmpty() is preferred to >>>>>>>>> (List.size() == 0). What's the compiler warning for (List.size() >>>>>>>>> == 0)? >>>>>>>>> >>>>>>>>> src/share/classes/sun/security/ssl/X509KeyManagerImpl.java >>>>>>>>> - if (keyTypeList == null || keyTypeList.size() == 0) { >>>>>>>>> + if (keyTypeList == null || keyTypeList.isEmpty()) { >>>>>>>>> >>>>>>>>> - if (allResults == null || allResults.size() == 0) { >>>>>>>>> + if (allResults == null || allResults.isEmpty()) { >>>>>>>>> >>>>>>>>> Thanks for the cleanup. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei (Andrew) Fan >>>>>>>>> >>>>>>>>> On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote: >>>>>>>>>> Hello Sean, >>>>>>>>>> >>>>>>>>>> Have you had a chance to look at this webrev? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sasha >>>>>>>>>> >>>>>>>>>> On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Here's an updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/ >>>>>>>>>>> >>>>>>>>>>> I've reexamined the @SuppressWarnings("unchecked") >>>>>>>>>>> annotations, and >>>>>>>>>>> added comments to all of the ones I've added. I was was also >>>>>>>>>>> able to >>>>>>>>>>> remove several of them by using covariant return types on >>>>>>>>>>> sun.security.x509.*Extension.get(String) inherited from Object >>>>>>>>>>> CertAttrSet.get(String). I've also updated the consumers of >>>>>>>>>>> sun.security.x509.*Extension.get(String) to use the more specific >>>>>>>>>>> return type, removing several casts and >>>>>>>>>>> @SuppressWarnings("unchecked") >>>>>>>>>>> annotations. >>>>>>>>>>> >>>>>>>>>>> Also, please take a closer look at my changes to >>>>>>>>>>> com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> final CodeSource) in >>>>>>>>>>> src/share/classes/com/sun/security/auth/PolicyFile.java lines >>>>>>>>>>> 1088-1094. The preceding comment and the behavior of >>>>>>>>>>> Subject.getPrincipals(Class) seem to be more consistent >>>>>>>>>>> with the >>>>>>>>>>> updated version, but I wanted to make sure. >>>>>>>>>>> >>>>>>>>>>> The classes where I added serialVersionUID's are either new or >>>>>>>>>>> have >>>>>>>>>>> the same serialVersionUID as the original implementation. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sasha >>>>>>>>>>> >>>>>>>>>>> On 7/18/2011 5:33 PM, Brad Wetmore wrote: >>>>>>>>>>>> (Apologies to folks without access to the older sources.) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 07/18/11 15:00, Sean Mullan wrote: >>>>>>>>>>>>> On 7/18/11 5:35 PM, Alexandre Boulgakov wrote: >>>>>>>>>>>>>> Is there an easy way to see when a class was added to the JDK? >>>>>>>>>>>>> For standard API classes, you can use the @since javadoc tag >>>>>>>>>>>>> which >>>>>>>>>>>>> will indicate >>>>>>>>>>>>> the release it was first introduced in. >>>>>>>>>>>> Standard, exported API classes. Some of the underlying support >>>>>>>>>>>> classes for API packages like java.*.* weren't always @since'd >>>>>>>>>>>> properly. >>>>>>>>>>>> >>>>>>>>>>>>> For internal classes, there is no easy way, since most don't >>>>>>>>>>>>> have an >>>>>>>>>>>>> @since tag. >>>>>>>>>>>>> I would probably write a script that checks the rt.jar of >>>>>>>>>>>>> each of >>>>>>>>>>>>> the JREs that >>>>>>>>>>>>> are archived at /java/re/jdk. The pathnames should be fairly >>>>>>>>>>>>> consistent, just >>>>>>>>>>>>> the version number is different. >>>>>>>>>>>> Don't know which classes you're talking about here, but some >>>>>>>>>>>> classes >>>>>>>>>>>> started out in other jar files and eventually wound up in >>>>>>>>>>>> rt.jar. >>>>>>>>>>>> Also, some files live in files other than rt.jar. I usually >>>>>>>>>>>> go to >>>>>>>>>>>> the source when looking for something. If it's originally from >>>>>>>>>>>> JSSE/JGSS/JCE, you'll need to look on our restricted access >>>>>>>>>>>> machine. >>>>>>>>>>>> >>>>>>>>>>>> When I'm looking for something that is in the jdk/j2se >>>>>>>>>>>> workspaces, I >>>>>>>>>>>> go right to the old Codemgr data, specifically the nametable >>>>>>>>>>>> file, >>>>>>>>>>>> because many times the files you want may be in a >>>>>>>>>>>> src//classes >>>>>>>>>>>> instead of src/share/classes. >>>>>>>>>>>> >>>>>>>>>>>> % grep -i SunMSCAPI.java >>>>>>>>>>>> /5.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>>>>>> >>>>>>>>>>>> % grep -i SunMSCAPI.java >>>>>>>>>>>> /6.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>>>>>> src/windows/classes/sun/security/mscapi/SunMSCAPI.java ada8dbe4 >>>>>>>>>>>> a217f6b0 6c833bd3 d4ef32be >>>>>>>>>>>> >>>>>>>>>>>> That will usually give you a good starting point. >>>>>>>>>>>> >>>>>>>>>>>> Brad >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Depending on rt.jar or not. >>>>>>>>>>>> >>>>>>>>>>>>> Chris, do you have any other ideas? >>>>>>>>>>>>> >>>>>>>>>>>>> --Sean From weijun.wang at oracle.com Wed Aug 3 18:23:07 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 04 Aug 2011 09:23:07 +0800 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror In-Reply-To: <4E39E370.3020205@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E39DEA1.5030100@oracle.com> <4E39DF48.7060907@oracle.com> <4E39E2A4.6000206@oracle.com> <4E39E370.3020205@oracle.com> Message-ID: <4E39F47B.3020503@oracle.com> My 2 cents: @SuppressWarnings("serial") is never a good idea. There will still be a serialver automatically computed and you won't be able to control it. Will the code changes go to jdk8 only? If so, I guess you should use the value calculated from jdk7 codes. If the values on jdk6 and jdk7 are already different, sorry, that means there is already a compatibility problem made and you won't be able to fix it. We can now only make sure jdk7 and jdk8 are compatible. Ultimately you can write small test to see if serialized form from one version can be accepted by another version. Thanks Max On 08/04/2011 08:10 AM, Alexandre Boulgakov wrote: > Those were the ones I was talking about- the serialVersionUIDs I > mentioned were the ones generated by serialver.exe. The webrev doesn't > have any of the pkcs11 changes yet (including the added serialVersionUIDs). > > I'll wait for Brad's or Valerie's response. > > Thanks, > Sasha > > On 8/3/2011 5:07 PM, Xuelei Fan wrote: >> On 8/4/2011 7:52 AM, Alexandre Boulgakov wrote: >>> There is currently no serialVersionUID defined for these classes. Do you >>> mean that we cannot add one for backwards compatibility? >> My answers only apply to you latest e-mail about the serialVersionUID >> update in sun.security.pkcs11.P11Key.P11SecretKey and >> sun.security.pkcs11.P11TlsPrfGenerator$1. I think you need to use the >> current values unless you get an approval from PKCS11 owner. >> >> We may need to consider more for these classes without serialVersionUID, >> I will look at your webrev again if I can get some time today. Normally, >> I think if there is a new attribute in a class, it is OK to add a new >> serialVersionUID value. >> >> Xuelei >> >>> If so, would >>> the best solution be to add an @SuppressWarnings("serial") annotation to >>> these classes? >>> >>> Thanks, >>> Sasha >>> >>> On 8/3/2011 4:49 PM, Xuelei Fan wrote: >>>> Oops, I missed this. >>>> >>>> I don't think we can modify serialVersionUID value for backward >>>> compatibility. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/4/2011 7:39 AM, Alexandre Boulgakov wrote: >>>>> Ping..? >>>>> >>>>> -Sasha >>>>> >>>>> On 7/27/2011 11:22 AM, Alexandre Boulgakov wrote: >>>>>> Should I just use the newest serialVersionUID for both of them? >>>>>> >>>>>> -Sasha >>>>>> >>>>>> On 7/26/2011 10:31 AM, Alexandre Boulgakov wrote: >>>>>>> I just noticed that pkcs11 is not built on my machine (64-bit >>>>>>> Windows) so I missed all of the warnings there. There are two >>>>>>> mission >>>>>>> serialVersionUID warnings for classes that have had different >>>>>>> generated serialVersionUID's in the past. >>>>>>> >>>>>>> sun.security.pkcs11.P11Key.P11SecretKey >>>>>>> -currently: -7828241727014329084L; >>>>>>> -JDK 1.5: -897881148551545872L; >>>>>>> >>>>>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>>>>> -currently: -8090049519656411362L; >>>>>>> -JDK 6: -3305145912345854189L; >>>>>>> >>>>>>> I'm not sure why the serialVersionUID changed for >>>>>>> sun.security.pkcs11.P11TlsPrfGenerator$1; the code is the same, and >>>>>>> the serialVersionUID for the base class javax.crypto.SecretKey >>>>>>> hasn't >>>>>>> changed. >>>>>>> >>>>>>> For sun.security.pkcs11.P11Key.P11SecretKey, the code is the same, >>>>>>> but the base class sun.security.pkcs11.P11Key has changed. >>>>>>> >>>>>>> How should I go about resolving these issues? >>>>>>> >>>>>>> Thanks, >>>>>>> Sasha >>>>>>> >>>>>>> On 7/20/2011 3:37 PM, Xuelei.Fan at Oracle.Com wrote: >>>>>>>> On Jul 21, 2011, at 1:25 AM, Alexandre >>>>>>>> Boulgakov wrote: >>>>>>>> >>>>>>>>> This is a Netbeans warning, not generated by the compiler. The >>>>>>>>> reason is that List.isEmpty() can be more efficient for some >>>>>>>>> implementations. ArrayList.size() == 0 and ArrayList.isEmpty() >>>>>>>>> should take the same time, so it doesn't matter for allResults, >>>>>>>>> but >>>>>>>>> keyTypeList is a List argument, so any implementation could be >>>>>>>>> passed in. List.isEmpty() should never be slower than List.size() >>>>>>>>> == 0 because AbstractCollection defines isEmpty() as size() == 0. >>>>>>>>> >>>>>>>>> Even if we don't get a performance improvement, it still improves >>>>>>>>> readability. >>>>>>>>> >>>>>>>> Sounds reasonable. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>>> -Sasha >>>>>>>>> >>>>>>>>> On 7/19/2011 7:32 PM, Xuelei Fan wrote: >>>>>>>>>> I was looking at the updates in sun/security/ssl. Looks fine to >>>>>>>>>> me. >>>>>>>>>> >>>>>>>>>> It's fine, but I just wonder why List.isEmpty() is preferred to >>>>>>>>>> (List.size() == 0). What's the compiler warning for (List.size() >>>>>>>>>> == 0)? >>>>>>>>>> >>>>>>>>>> src/share/classes/sun/security/ssl/X509KeyManagerImpl.java >>>>>>>>>> - if (keyTypeList == null || keyTypeList.size() == 0) { >>>>>>>>>> + if (keyTypeList == null || keyTypeList.isEmpty()) { >>>>>>>>>> >>>>>>>>>> - if (allResults == null || allResults.size() == 0) { >>>>>>>>>> + if (allResults == null || allResults.isEmpty()) { >>>>>>>>>> >>>>>>>>>> Thanks for the cleanup. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei (Andrew) Fan >>>>>>>>>> >>>>>>>>>> On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote: >>>>>>>>>>> Hello Sean, >>>>>>>>>>> >>>>>>>>>>> Have you had a chance to look at this webrev? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sasha >>>>>>>>>>> >>>>>>>>>>> On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Here's an updated webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/ >>>>>>>>>>>> >>>>>>>>>>>> I've reexamined the @SuppressWarnings("unchecked") >>>>>>>>>>>> annotations, and >>>>>>>>>>>> added comments to all of the ones I've added. I was was also >>>>>>>>>>>> able to >>>>>>>>>>>> remove several of them by using covariant return types on >>>>>>>>>>>> sun.security.x509.*Extension.get(String) inherited from Object >>>>>>>>>>>> CertAttrSet.get(String). I've also updated the consumers of >>>>>>>>>>>> sun.security.x509.*Extension.get(String) to use the more >>>>>>>>>>>> specific >>>>>>>>>>>> return type, removing several casts and >>>>>>>>>>>> @SuppressWarnings("unchecked") >>>>>>>>>>>> annotations. >>>>>>>>>>>> >>>>>>>>>>>> Also, please take a closer look at my changes to >>>>>>>>>>>> com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> final CodeSource) in >>>>>>>>>>>> src/share/classes/com/sun/security/auth/PolicyFile.java lines >>>>>>>>>>>> 1088-1094. The preceding comment and the behavior of >>>>>>>>>>>> Subject.getPrincipals(Class) seem to be more consistent >>>>>>>>>>>> with the >>>>>>>>>>>> updated version, but I wanted to make sure. >>>>>>>>>>>> >>>>>>>>>>>> The classes where I added serialVersionUID's are either new or >>>>>>>>>>>> have >>>>>>>>>>>> the same serialVersionUID as the original implementation. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Sasha >>>>>>>>>>>> >>>>>>>>>>>> On 7/18/2011 5:33 PM, Brad Wetmore wrote: >>>>>>>>>>>>> (Apologies to folks without access to the older sources.) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/18/11 15:00, Sean Mullan wrote: >>>>>>>>>>>>>> On 7/18/11 5:35 PM, Alexandre Boulgakov wrote: >>>>>>>>>>>>>>> Is there an easy way to see when a class was added to the >>>>>>>>>>>>>>> JDK? >>>>>>>>>>>>>> For standard API classes, you can use the @since javadoc tag >>>>>>>>>>>>>> which >>>>>>>>>>>>>> will indicate >>>>>>>>>>>>>> the release it was first introduced in. >>>>>>>>>>>>> Standard, exported API classes. Some of the underlying support >>>>>>>>>>>>> classes for API packages like java.*.* weren't always @since'd >>>>>>>>>>>>> properly. >>>>>>>>>>>>> >>>>>>>>>>>>>> For internal classes, there is no easy way, since most don't >>>>>>>>>>>>>> have an >>>>>>>>>>>>>> @since tag. >>>>>>>>>>>>>> I would probably write a script that checks the rt.jar of >>>>>>>>>>>>>> each of >>>>>>>>>>>>>> the JREs that >>>>>>>>>>>>>> are archived at /java/re/jdk. The pathnames should be fairly >>>>>>>>>>>>>> consistent, just >>>>>>>>>>>>>> the version number is different. >>>>>>>>>>>>> Don't know which classes you're talking about here, but some >>>>>>>>>>>>> classes >>>>>>>>>>>>> started out in other jar files and eventually wound up in >>>>>>>>>>>>> rt.jar. >>>>>>>>>>>>> Also, some files live in files other than rt.jar. I usually >>>>>>>>>>>>> go to >>>>>>>>>>>>> the source when looking for something. If it's originally from >>>>>>>>>>>>> JSSE/JGSS/JCE, you'll need to look on our restricted access >>>>>>>>>>>>> machine. >>>>>>>>>>>>> >>>>>>>>>>>>> When I'm looking for something that is in the jdk/j2se >>>>>>>>>>>>> workspaces, I >>>>>>>>>>>>> go right to the old Codemgr data, specifically the nametable >>>>>>>>>>>>> file, >>>>>>>>>>>>> because many times the files you want may be in a >>>>>>>>>>>>> src//classes >>>>>>>>>>>>> instead of src/share/classes. >>>>>>>>>>>>> >>>>>>>>>>>>> % grep -i SunMSCAPI.java >>>>>>>>>>>>> /5.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>>>>>>> >>>>>>>>>>>>> % grep -i SunMSCAPI.java >>>>>>>>>>>>> /6.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>>>>>>>>> src/windows/classes/sun/security/mscapi/SunMSCAPI.java >>>>>>>>>>>>> ada8dbe4 >>>>>>>>>>>>> a217f6b0 6c833bd3 d4ef32be >>>>>>>>>>>>> >>>>>>>>>>>>> That will usually give you a good starting point. >>>>>>>>>>>>> >>>>>>>>>>>>> Brad >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Depending on rt.jar or not. >>>>>>>>>>>>> >>>>>>>>>>>>>> Chris, do you have any other ideas? >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Sean From xuelei.fan at oracle.com Wed Aug 3 19:11:29 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Aug 2011 10:11:29 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E38C59C.1000504@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E382927.1070806@oracle.com> <4E38C59C.1000504@oracle.com> Message-ID: <4E39FFD1.2040204@oracle.com> test/javax/security/auth/login/LoginContext/ResetConfigModule.java You removed the "run" tag, and "build" tag is the last tag. It seems that the test will only run building, but not run the class.main(). I got the strange behavior when I run some tests with build tag with jtreg 4.1 b03. Did you come into the same issue? Thanks, Xuelei On 8/3/2011 11:50 AM, Weijun Wang wrote: > > > On 08/03/2011 12:43 AM, Alan Bateman wrote: >> Weijun Wang wrote: >>> Hi All >>> >>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >> I went through the changes to the tests and they look okay to me. It's >> good to see so many tests removed from the problem list and the tests >> updated to work in samevm or agentvm mode. >> >> Is there a bug created for the ec tests that are failing on >> solaris-i586? If so then it would be good to include the bugID for > > I thought there was one but I cannot find it. *Vinnie*, do you know it? > >> future edits to the problem list. Also I see you've commented out two ec >> tests and I wonder if these lines should be removed or uncommented. > > I don't understand why these 2 pass now. Maybe they still fail on some > platforms not in JPRT? Anyway, I just don't want to purge the lines. > >> >> test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - no problem >> with your change but I notice this test using URL's getFile which isn't >> the right way to get to a file path. Could this be changed to using >> File(URI)? > > This test is a compatibility check, see > > http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/4e7ad09de58b > > I remember there were some strange things on Windows, say, UNC, \ vs /, > that made some hand-crafted URL illegal. We cannot support all of them, > so just make sure the old supported ones are still supported. > > Thanks > Max > >> >> -Alan. >> >> >> >> >> From weijun.wang at oracle.com Wed Aug 3 19:24:44 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 04 Aug 2011 10:24:44 +0800 Subject: final inner class not final (was Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror) In-Reply-To: <4E39DC1C.9040705@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> Message-ID: <4E3A02EC.4030901@oracle.com> > serialVersionUID warnings for classes that have had different > generated serialVersionUID's in the past. >>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>> -currently: -8090049519656411362L; >>> -JDK 6: -3305145912345854189L; I find out the reason: Since 6u11, a final inner class is *not* final anymore. $ cat A4.java import java.lang.reflect.Modifier; public class A4 { public static void main(String[] args) throws Exception { Class c = Class.forName(args[0]); System.out.println(c.getModifiers() & Modifier.FINAL); } } $ java A4 java.lang.String 16 $ java A4 'sun.security.pkcs11.P11TlsPrfGenerator$1' 0 getModifiers() is a native method, and calls JVM_GetClassModifiers. Is this an intended change? FYI, the class is defined as private static final SecretKey NULL_KEY = new SecretKey() { .... in http://hg.openjdk.java.net/jdk8/tl/jdk/file/809e8db0c142/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java, line 100. Thanks Max From weijun.wang at oracle.com Wed Aug 3 19:34:18 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 04 Aug 2011 10:34:18 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E39FFD1.2040204@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E382927.1070806@oracle.com> <4E38C59C.1000504@oracle.com> <4E39FFD1.2040204@oracle.com> Message-ID: <4E3A052A.7030405@oracle.com> Oh, that's true. I'll add it back. Why did I remove it at the first place? Thanks Max On 08/04/2011 10:11 AM, Xuelei Fan wrote: > . test/javax/security/auth/login/LoginContext/ResetConfigModule.java > > You removed the "run" tag, and "build" tag is the last tag. It seems > that the test will only run building, but not run the class.main(). I > got the strange behavior when I run some tests with build tag with jtreg > 4.1 b03. Did you come into the same issue? > > Thanks, > Xuelei > > On 8/3/2011 11:50 AM, Weijun Wang wrote: >> >> >> On 08/03/2011 12:43 AM, Alan Bateman wrote: >>> Weijun Wang wrote: >>>> Hi All >>>> >>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>> I went through the changes to the tests and they look okay to me. It's >>> good to see so many tests removed from the problem list and the tests >>> updated to work in samevm or agentvm mode. >>> >>> Is there a bug created for the ec tests that are failing on >>> solaris-i586? If so then it would be good to include the bugID for >> >> I thought there was one but I cannot find it. *Vinnie*, do you know it? >> >>> future edits to the problem list. Also I see you've commented out two ec >>> tests and I wonder if these lines should be removed or uncommented. >> >> I don't understand why these 2 pass now. Maybe they still fail on some >> platforms not in JPRT? Anyway, I just don't want to purge the lines. >> >>> >>> test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - no problem >>> with your change but I notice this test using URL's getFile which isn't >>> the right way to get to a file path. Could this be changed to using >>> File(URI)? >> >> This test is a compatibility check, see >> >> http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/4e7ad09de58b >> >> I remember there were some strange things on Windows, say, UNC, \ vs /, >> that made some hand-crafted URL illegal. We cannot support all of them, >> so just make sure the old supported ones are still supported. >> >> Thanks >> Max >> >>> >>> -Alan. >>> >>> >>> >>> >>> > From xuelei.fan at oracle.com Wed Aug 3 19:38:09 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Aug 2011 10:38:09 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E3A052A.7030405@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E382927.1070806@oracle.com> <4E38C59C.1000504@oracle.com> <4E39FFD1.2040204@oracle.com> <4E3A052A.7030405@oracle.com> Message-ID: <4E3A0611.2020308@oracle.com> On 8/4/2011 10:34 AM, Weijun Wang wrote: > Oh, that's true. > > I'll add it back. Why did I remove it at the first place? > You may not have to add it back, the library tag may help to build the dependent classes. Maybe, we have some incorrect understand of the "build" tag. Xuelei > Thanks > Max > > On 08/04/2011 10:11 AM, Xuelei Fan wrote: >> . test/javax/security/auth/login/LoginContext/ResetConfigModule.java >> >> You removed the "run" tag, and "build" tag is the last tag. It seems >> that the test will only run building, but not run the class.main(). I >> got the strange behavior when I run some tests with build tag with jtreg >> 4.1 b03. Did you come into the same issue? >> >> Thanks, >> Xuelei >> >> On 8/3/2011 11:50 AM, Weijun Wang wrote: >>> >>> >>> On 08/03/2011 12:43 AM, Alan Bateman wrote: >>>> Weijun Wang wrote: >>>>> Hi All >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>>> I went through the changes to the tests and they look okay to me. It's >>>> good to see so many tests removed from the problem list and the tests >>>> updated to work in samevm or agentvm mode. >>>> >>>> Is there a bug created for the ec tests that are failing on >>>> solaris-i586? If so then it would be good to include the bugID for >>> >>> I thought there was one but I cannot find it. *Vinnie*, do you know it? >>> >>>> future edits to the problem list. Also I see you've commented out >>>> two ec >>>> tests and I wonder if these lines should be removed or uncommented. >>> >>> I don't understand why these 2 pass now. Maybe they still fail on some >>> platforms not in JPRT? Anyway, I just don't want to purge the lines. >>> >>>> >>>> test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - no >>>> problem >>>> with your change but I notice this test using URL's getFile which isn't >>>> the right way to get to a file path. Could this be changed to using >>>> File(URI)? >>> >>> This test is a compatibility check, see >>> >>> http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/4e7ad09de58b >>> >>> I remember there were some strange things on Windows, say, UNC, \ vs /, >>> that made some hand-crafted URL illegal. We cannot support all of them, >>> so just make sure the old supported ones are still supported. >>> >>> Thanks >>> Max >>> >>>> >>>> -Alan. >>>> >>>> >>>> >>>> >>>> >> From xuelei.fan at oracle.com Wed Aug 3 21:05:49 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Aug 2011 12:05:49 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E37A109.7080902@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> Message-ID: <4E3A1A9D.9010804@oracle.com> > - JSSE tests, Xuelei is working on them It may be a bad news for the purpose to quicken the testing run time. Most of the JSSE test may not be able to under samevm/agentvm mode. 1. JSSE does not support dynamic system properties For performance tuning and synchronization, JSSE does not support dynamic system properties of: "java.protocol.handler.pkgs" "javax.net.ssl.keyStore" "javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore" "javax.net.ssl.trustStorePassword" The JSSE default implementation will use these properties when initializing the static objects, and then any changes to these properties will be ignored in the same VM. There are around 90 of all 170+ JSSE regression tests depends on system properties. 2. JSSE caches TLS sessions, as will result in unexpected reuse of TLS sessions in samevm/agentvm mode. There are a lot of tests using the default SSL/TLS context, which will the same TLS session cache. There are only a very very few tests could be updated to run in samevm mode. Because samevm-safe in JSSE tests will result in unnecessary complex, and the performance improvement is very little, I would suggest tun all JSSE tests at othervm mode. What do you think? Max, if we can get an agree, would you please update the Makefile to run JSSE in othervm mode in your fix? So that we don't have to fill a new CR. Thanks, Xuelei On 8/2/2011 3:02 PM, Weijun Wang wrote: > Hi All > > http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ > > *Attention*: please note that the jtreg mode for jdk_security3 is still > RunOthervmBatch. Xuelei is now working on the JSSE tests. Once he is > ready, he will change the mode to RunSamevmBatch. > > The code changes: > > * Still included in test/ProblemList.txt > > - JSSE tests, Xuelei is working on them > - ec tests on solaris-i586, they fail even if run standalone > > * PKCS11/EC tests: > > - New Providers.setAt, to ensure provider is added to desired position: > test/sun/security/pkcs11/ec/* > > - PKCS11Test.safeReload, to ensure shared library can be loaded again: > test/sun/security/pkcs11/PKCS11Test.java > test/sun/security/pkcs11/SecmodTest.java > > - Test using config files need to run in othervm: > test/sun/security/pkcs11/Secmod/* > test/sun/security/pkcs11/fips/* > > - Restoring provider lists: > test/sun/security/ec/TestEC.java > test/sun/security/pkcs11/PKCS11Test.java > > * Try-with-resources updates: > > - test/com/sun/security/auth/login/ConfigFile/IllegalURL.java > - test/sun/security/pkcs12/PKCS12SameKeyId.java > - test/sun/security/tools/keytool/StartDateTest.java > > * Other tests still need to be in -othervm: > > Using special policy file: > test/sun/security/provider/PolicyFile/Comparator.java > AlgorithmId static field oidTable initialization: > test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java > > * JAAS configuration restore: > > - test/javax/security/auth/login/LoginContext/ResetConfigModule.java > > * Use "localhost" as hostname, to make name resolution fast > > - test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java > > > After these changes, JPRT test run (with RunSamevmBatch and no JSSE > tests) shows most tests are OK. There are still intermittent failures > which are PKCS11/EC provider related. > > Thanks > Max From weijun.wang at oracle.com Thu Aug 4 02:06:38 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 04 Aug 2011 17:06:38 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E3A1A9D.9010804@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E3A1A9D.9010804@oracle.com> Message-ID: <4E3A611E.8030304@oracle.com> > Max, if we can get an agree, would you please update the Makefile to > run JSSE in othervm mode in your fix? So that we don't have to fill > a new CR. There are two ways to do this: 1. Add "@run main/othervm" to all JSSE tests. This means a lot of code changes, but I can automate it. 2. Create new test set for JSSE. This is what I had done before in http://cr.openjdk.java.net/~weijun/7055363/webrev.00/ many changes to Makefile, jprt.properties and jprt.properties in the parent repo. I'd choose #1. What's your opinion? BTW, you mentioned HTTPS and JNDI codes. If they are not inside sun/security, I won't touch them this time. Also, at least I know tests inside test/closed/sun/security/ssl/java/security/KeyStore can run in samevm. Can you give a whitelist? Thanks Max On 08/04/2011 12:05 PM, Xuelei Fan wrote: >> - JSSE tests, Xuelei is working on them > It may be a bad news for the purpose to quicken the testing run > time. Most of the JSSE test may not be able to under samevm/agentvm > mode. > > 1. JSSE does not support dynamic system properties For performance > tuning and synchronization, JSSE does not support dynamic system > properties of: "java.protocol.handler.pkgs" "javax.net.ssl.keyStore" > "javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore" > "javax.net.ssl.trustStorePassword" > > The JSSE default implementation will use these properties when > initializing the static objects, and then any changes to these > properties will be ignored in the same VM. > > There are around 90 of all 170+ JSSE regression tests depends on > system properties. > > 2. JSSE caches TLS sessions, as will result in unexpected reuse of > TLS sessions in samevm/agentvm mode. There are a lot of tests using > the default SSL/TLS context, which will the same TLS session cache. > > There are only a very very few tests could be updated to run in > samevm mode. Because samevm-safe in JSSE tests will result in > unnecessary complex, and the performance improvement is very little, > I would suggest tun all JSSE tests at othervm mode. > > What do you think? > > Max, if we can get an agree, would you please update the Makefile to > run JSSE in othervm mode in your fix? So that we don't have to fill > a new CR. > > Thanks, Xuelei > > On 8/2/2011 3:02 PM, Weijun Wang wrote: >> Hi All >> >> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >> >> *Attention*: please note that the jtreg mode for jdk_security3 is >> still RunOthervmBatch. Xuelei is now working on the JSSE tests. >> Once he is ready, he will change the mode to RunSamevmBatch. >> >> The code changes: >> >> * Still included in test/ProblemList.txt >> >> - JSSE tests, Xuelei is working on them - ec tests on solaris-i586, >> they fail even if run standalone >> >> * PKCS11/EC tests: >> >> - New Providers.setAt, to ensure provider is added to desired >> position: test/sun/security/pkcs11/ec/* >> >> - PKCS11Test.safeReload, to ensure shared library can be loaded >> again: test/sun/security/pkcs11/PKCS11Test.java >> test/sun/security/pkcs11/SecmodTest.java >> >> - Test using config files need to run in othervm: >> test/sun/security/pkcs11/Secmod/* test/sun/security/pkcs11/fips/* >> >> - Restoring provider lists: test/sun/security/ec/TestEC.java >> test/sun/security/pkcs11/PKCS11Test.java >> >> * Try-with-resources updates: >> >> - test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - >> test/sun/security/pkcs12/PKCS12SameKeyId.java - >> test/sun/security/tools/keytool/StartDateTest.java >> >> * Other tests still need to be in -othervm: >> >> Using special policy file: >> test/sun/security/provider/PolicyFile/Comparator.java AlgorithmId >> static field oidTable initialization: >> test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java >> >> * JAAS configuration restore: >> >> - >> test/javax/security/auth/login/LoginContext/ResetConfigModule.java >> >> * Use "localhost" as hostname, to make name resolution fast >> >> - test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java >> >> >> After these changes, JPRT test run (with RunSamevmBatch and no >> JSSE tests) shows most tests are OK. There are still intermittent >> failures which are PKCS11/EC provider related. >> >> Thanks Max > From kelly.ohair at oracle.com Thu Aug 4 02:30:10 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 4 Aug 2011 11:30:10 +0200 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E3A611E.8030304@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E3A1A9D.9010804@oracle.com> <4E3A611E.8030304@oracle.com> Message-ID: <6FE553A7-0C00-4096-BD39-788BBD9B6F56@oracle.com> On Aug 4, 2011, at 11:06 AM, Weijun Wang wrote: >> Max, if we can get an agree, would you please update the Makefile to >> run JSSE in othervm mode in your fix? So that we don't have to fill >> a new CR. > > There are two ways to do this: > > 1. Add "@run main/othervm" to all JSSE tests. This means a lot of code changes, but I can automate it. > > 2. Create new test set for JSSE. This is what I had done before in > > http://cr.openjdk.java.net/~weijun/7055363/webrev.00/ > > many changes to Makefile, jprt.properties and jprt.properties in the parent repo. > > I'd choose #1. What's your opinion? Just a comment from the peanut gallery... ;^) I think #1 is the way to go. One thing we wanted people to be able to do is just cd to the test directory and run 'jtreg -samevm' or 'jtreg -agentvm' and by changing the test itself, this can work. If at some point later someone fixes the test or is able to make it work with samevm, they can remove the main/othervm. If you do it with the Makefile, you only fixed it for when people use the Makefile or with JPRT. -kto > > BTW, you mentioned HTTPS and JNDI codes. If they are not inside sun/security, I won't touch them this time. Also, at least I know tests inside test/closed/sun/security/ssl/java/security/KeyStore can run in samevm. Can you give a whitelist? > > Thanks > Max > > > On 08/04/2011 12:05 PM, Xuelei Fan wrote: >>> - JSSE tests, Xuelei is working on them >> It may be a bad news for the purpose to quicken the testing run >> time. Most of the JSSE test may not be able to under samevm/agentvm >> mode. >> >> 1. JSSE does not support dynamic system properties For performance >> tuning and synchronization, JSSE does not support dynamic system >> properties of: "java.protocol.handler.pkgs" "javax.net.ssl.keyStore" >> "javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore" >> "javax.net.ssl.trustStorePassword" >> >> The JSSE default implementation will use these properties when >> initializing the static objects, and then any changes to these >> properties will be ignored in the same VM. >> >> There are around 90 of all 170+ JSSE regression tests depends on >> system properties. >> >> 2. JSSE caches TLS sessions, as will result in unexpected reuse of >> TLS sessions in samevm/agentvm mode. There are a lot of tests using >> the default SSL/TLS context, which will the same TLS session cache. >> >> There are only a very very few tests could be updated to run in >> samevm mode. Because samevm-safe in JSSE tests will result in >> unnecessary complex, and the performance improvement is very little, >> I would suggest tun all JSSE tests at othervm mode. >> >> What do you think? >> >> Max, if we can get an agree, would you please update the Makefile to >> run JSSE in othervm mode in your fix? So that we don't have to fill >> a new CR. >> >> Thanks, Xuelei >> >> On 8/2/2011 3:02 PM, Weijun Wang wrote: >>> Hi All >>> >>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>> >>> *Attention*: please note that the jtreg mode for jdk_security3 is >>> still RunOthervmBatch. Xuelei is now working on the JSSE tests. >>> Once he is ready, he will change the mode to RunSamevmBatch. >>> >>> The code changes: >>> >>> * Still included in test/ProblemList.txt >>> >>> - JSSE tests, Xuelei is working on them - ec tests on solaris-i586, >>> they fail even if run standalone >>> >>> * PKCS11/EC tests: >>> >>> - New Providers.setAt, to ensure provider is added to desired >>> position: test/sun/security/pkcs11/ec/* >>> >>> - PKCS11Test.safeReload, to ensure shared library can be loaded >>> again: test/sun/security/pkcs11/PKCS11Test.java >>> test/sun/security/pkcs11/SecmodTest.java >>> >>> - Test using config files need to run in othervm: >>> test/sun/security/pkcs11/Secmod/* test/sun/security/pkcs11/fips/* >>> >>> - Restoring provider lists: test/sun/security/ec/TestEC.java >>> test/sun/security/pkcs11/PKCS11Test.java >>> >>> * Try-with-resources updates: >>> >>> - test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - >>> test/sun/security/pkcs12/PKCS12SameKeyId.java - >>> test/sun/security/tools/keytool/StartDateTest.java >>> >>> * Other tests still need to be in -othervm: >>> >>> Using special policy file: >>> test/sun/security/provider/PolicyFile/Comparator.java AlgorithmId >>> static field oidTable initialization: >>> test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java >>> >>> * JAAS configuration restore: >>> >>> - >>> test/javax/security/auth/login/LoginContext/ResetConfigModule.java >>> >>> * Use "localhost" as hostname, to make name resolution fast >>> >>> - test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java >>> >>> >>> After these changes, JPRT test run (with RunSamevmBatch and no >>> JSSE tests) shows most tests are OK. There are still intermittent >>> failures which are PKCS11/EC provider related. >>> >>> Thanks Max >> From xuelei.fan at oracle.com Thu Aug 4 02:50:04 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Aug 2011 17:50:04 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <6FE553A7-0C00-4096-BD39-788BBD9B6F56@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E3A1A9D.9010804@oracle.com> <4E3A611E.8030304@oracle.com> <6FE553A7-0C00-4096-BD39-788BBD9B6F56@oracle.com> Message-ID: <4E3A6B4C.7010704@oracle.com> Good point. I will update the test files. Even we have to make update to JSSE tests, I would evaluate every tests, and won't add "othervm" tag to those samevm safe tests. 170+ files, need some more time. >> ... at least I know tests inside test/closed/ >> sun/security/ssl/java/security/KeyStore can run >> in samevm. Can you give a whitelist? >> The tests won't try to establish a TLS/SSL connection, so they are safe. Thanks, Xuelei On 8/4/2011 5:30 PM, Kelly O'Hair wrote: > > On Aug 4, 2011, at 11:06 AM, Weijun Wang wrote: > >>> Max, if we can get an agree, would you please update the Makefile to >>> run JSSE in othervm mode in your fix? So that we don't have to fill >>> a new CR. >> >> There are two ways to do this: >> >> 1. Add "@run main/othervm" to all JSSE tests. This means a lot of code changes, but I can automate it. >> >> 2. Create new test set for JSSE. This is what I had done before in >> >> http://cr.openjdk.java.net/~weijun/7055363/webrev.00/ >> >> many changes to Makefile, jprt.properties and jprt.properties in the parent repo. >> >> I'd choose #1. What's your opinion? > > Just a comment from the peanut gallery... ;^) > > I think #1 is the way to go. > > One thing we wanted people to be able to do is just cd to the test directory and run 'jtreg -samevm' or 'jtreg -agentvm' > and by changing the test itself, this can work. If at some point later someone fixes the test or is able to > make it work with samevm, they can remove the main/othervm. > If you do it with the Makefile, you only fixed it for when people use the Makefile or with JPRT. > > -kto > >> >> BTW, you mentioned HTTPS and JNDI codes. If they are not inside sun/security, I won't touch them this time. Also, at least I know tests inside test/closed/sun/security/ssl/java/security/KeyStore can run in samevm. Can you give a whitelist? >> >> Thanks >> Max >> >> >> On 08/04/2011 12:05 PM, Xuelei Fan wrote: >>>> - JSSE tests, Xuelei is working on them >>> It may be a bad news for the purpose to quicken the testing run >>> time. Most of the JSSE test may not be able to under samevm/agentvm >>> mode. >>> >>> 1. JSSE does not support dynamic system properties For performance >>> tuning and synchronization, JSSE does not support dynamic system >>> properties of: "java.protocol.handler.pkgs" "javax.net.ssl.keyStore" >>> "javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore" >>> "javax.net.ssl.trustStorePassword" >>> >>> The JSSE default implementation will use these properties when >>> initializing the static objects, and then any changes to these >>> properties will be ignored in the same VM. >>> >>> There are around 90 of all 170+ JSSE regression tests depends on >>> system properties. >>> >>> 2. JSSE caches TLS sessions, as will result in unexpected reuse of >>> TLS sessions in samevm/agentvm mode. There are a lot of tests using >>> the default SSL/TLS context, which will the same TLS session cache. >>> >>> There are only a very very few tests could be updated to run in >>> samevm mode. Because samevm-safe in JSSE tests will result in >>> unnecessary complex, and the performance improvement is very little, >>> I would suggest tun all JSSE tests at othervm mode. >>> >>> What do you think? >>> >>> Max, if we can get an agree, would you please update the Makefile to >>> run JSSE in othervm mode in your fix? So that we don't have to fill >>> a new CR. >>> >>> Thanks, Xuelei >>> >>> On 8/2/2011 3:02 PM, Weijun Wang wrote: >>>> Hi All >>>> >>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>>> >>>> *Attention*: please note that the jtreg mode for jdk_security3 is >>>> still RunOthervmBatch. Xuelei is now working on the JSSE tests. >>>> Once he is ready, he will change the mode to RunSamevmBatch. >>>> >>>> The code changes: >>>> >>>> * Still included in test/ProblemList.txt >>>> >>>> - JSSE tests, Xuelei is working on them - ec tests on solaris-i586, >>>> they fail even if run standalone >>>> >>>> * PKCS11/EC tests: >>>> >>>> - New Providers.setAt, to ensure provider is added to desired >>>> position: test/sun/security/pkcs11/ec/* >>>> >>>> - PKCS11Test.safeReload, to ensure shared library can be loaded >>>> again: test/sun/security/pkcs11/PKCS11Test.java >>>> test/sun/security/pkcs11/SecmodTest.java >>>> >>>> - Test using config files need to run in othervm: >>>> test/sun/security/pkcs11/Secmod/* test/sun/security/pkcs11/fips/* >>>> >>>> - Restoring provider lists: test/sun/security/ec/TestEC.java >>>> test/sun/security/pkcs11/PKCS11Test.java >>>> >>>> * Try-with-resources updates: >>>> >>>> - test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - >>>> test/sun/security/pkcs12/PKCS12SameKeyId.java - >>>> test/sun/security/tools/keytool/StartDateTest.java >>>> >>>> * Other tests still need to be in -othervm: >>>> >>>> Using special policy file: >>>> test/sun/security/provider/PolicyFile/Comparator.java AlgorithmId >>>> static field oidTable initialization: >>>> test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java >>>> >>>> * JAAS configuration restore: >>>> >>>> - >>>> test/javax/security/auth/login/LoginContext/ResetConfigModule.java >>>> >>>> * Use "localhost" as hostname, to make name resolution fast >>>> >>>> - test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java >>>> >>>> >>>> After these changes, JPRT test run (with RunSamevmBatch and no >>>> JSSE tests) shows most tests are OK. There are still intermittent >>>> failures which are PKCS11/EC provider related. >>>> >>>> Thanks Max >>> > From weijun.wang at oracle.com Thu Aug 4 02:58:42 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 04 Aug 2011 17:58:42 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E3A6B4C.7010704@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E3A1A9D.9010804@oracle.com> <4E3A611E.8030304@oracle.com> <6FE553A7-0C00-4096-BD39-788BBD9B6F56@oracle.com> <4E3A6B4C.7010704@oracle.com> Message-ID: <4E3A6D52.1020806@oracle.com> On 08/04/2011 05:50 PM, Xuelei Fan wrote: > Good point. I will update the test files. Even we have to make update to > JSSE tests, I would evaluate every tests, and won't add "othervm" tag to > those samevm safe tests. 170+ files, need some more time. So you will add the tag? How long will you use? If less than a week, I can wait after you're finished and update the Makefile to call RunasSamevmBatch. Otherwise, I'll push my changeset first and keep RunasOthervmBatch, and in your changeset you change it to RunasSamevmBatch. Thanks Max > >>> ... at least I know tests inside test/closed/ >>> sun/security/ssl/java/security/KeyStore can run >>> in samevm. Can you give a whitelist? >>> > The tests won't try to establish a TLS/SSL connection, so they are safe. > > Thanks, > Xuelei > > On 8/4/2011 5:30 PM, Kelly O'Hair wrote: >> >> On Aug 4, 2011, at 11:06 AM, Weijun Wang wrote: >> >>>> Max, if we can get an agree, would you please update the Makefile to >>>> run JSSE in othervm mode in your fix? So that we don't have to fill >>>> a new CR. >>> >>> There are two ways to do this: >>> >>> 1. Add "@run main/othervm" to all JSSE tests. This means a lot of code changes, but I can automate it. >>> >>> 2. Create new test set for JSSE. This is what I had done before in >>> >>> http://cr.openjdk.java.net/~weijun/7055363/webrev.00/ >>> >>> many changes to Makefile, jprt.properties and jprt.properties in the parent repo. >>> >>> I'd choose #1. What's your opinion? >> >> Just a comment from the peanut gallery... ;^) >> >> I think #1 is the way to go. >> >> One thing we wanted people to be able to do is just cd to the test directory and run 'jtreg -samevm' or 'jtreg -agentvm' >> and by changing the test itself, this can work. If at some point later someone fixes the test or is able to >> make it work with samevm, they can remove the main/othervm. >> If you do it with the Makefile, you only fixed it for when people use the Makefile or with JPRT. >> >> -kto >> >>> >>> BTW, you mentioned HTTPS and JNDI codes. If they are not inside sun/security, I won't touch them this time. Also, at least I know tests inside test/closed/sun/security/ssl/java/security/KeyStore can run in samevm. Can you give a whitelist? >>> >>> Thanks >>> Max >>> >>> >>> On 08/04/2011 12:05 PM, Xuelei Fan wrote: >>>>> - JSSE tests, Xuelei is working on them >>>> It may be a bad news for the purpose to quicken the testing run >>>> time. Most of the JSSE test may not be able to under samevm/agentvm >>>> mode. >>>> >>>> 1. JSSE does not support dynamic system properties For performance >>>> tuning and synchronization, JSSE does not support dynamic system >>>> properties of: "java.protocol.handler.pkgs" "javax.net.ssl.keyStore" >>>> "javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore" >>>> "javax.net.ssl.trustStorePassword" >>>> >>>> The JSSE default implementation will use these properties when >>>> initializing the static objects, and then any changes to these >>>> properties will be ignored in the same VM. >>>> >>>> There are around 90 of all 170+ JSSE regression tests depends on >>>> system properties. >>>> >>>> 2. JSSE caches TLS sessions, as will result in unexpected reuse of >>>> TLS sessions in samevm/agentvm mode. There are a lot of tests using >>>> the default SSL/TLS context, which will the same TLS session cache. >>>> >>>> There are only a very very few tests could be updated to run in >>>> samevm mode. Because samevm-safe in JSSE tests will result in >>>> unnecessary complex, and the performance improvement is very little, >>>> I would suggest tun all JSSE tests at othervm mode. >>>> >>>> What do you think? >>>> >>>> Max, if we can get an agree, would you please update the Makefile to >>>> run JSSE in othervm mode in your fix? So that we don't have to fill >>>> a new CR. >>>> >>>> Thanks, Xuelei >>>> >>>> On 8/2/2011 3:02 PM, Weijun Wang wrote: >>>>> Hi All >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>>>> >>>>> *Attention*: please note that the jtreg mode for jdk_security3 is >>>>> still RunOthervmBatch. Xuelei is now working on the JSSE tests. >>>>> Once he is ready, he will change the mode to RunSamevmBatch. >>>>> >>>>> The code changes: >>>>> >>>>> * Still included in test/ProblemList.txt >>>>> >>>>> - JSSE tests, Xuelei is working on them - ec tests on solaris-i586, >>>>> they fail even if run standalone >>>>> >>>>> * PKCS11/EC tests: >>>>> >>>>> - New Providers.setAt, to ensure provider is added to desired >>>>> position: test/sun/security/pkcs11/ec/* >>>>> >>>>> - PKCS11Test.safeReload, to ensure shared library can be loaded >>>>> again: test/sun/security/pkcs11/PKCS11Test.java >>>>> test/sun/security/pkcs11/SecmodTest.java >>>>> >>>>> - Test using config files need to run in othervm: >>>>> test/sun/security/pkcs11/Secmod/* test/sun/security/pkcs11/fips/* >>>>> >>>>> - Restoring provider lists: test/sun/security/ec/TestEC.java >>>>> test/sun/security/pkcs11/PKCS11Test.java >>>>> >>>>> * Try-with-resources updates: >>>>> >>>>> - test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - >>>>> test/sun/security/pkcs12/PKCS12SameKeyId.java - >>>>> test/sun/security/tools/keytool/StartDateTest.java >>>>> >>>>> * Other tests still need to be in -othervm: >>>>> >>>>> Using special policy file: >>>>> test/sun/security/provider/PolicyFile/Comparator.java AlgorithmId >>>>> static field oidTable initialization: >>>>> test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java >>>>> >>>>> * JAAS configuration restore: >>>>> >>>>> - >>>>> test/javax/security/auth/login/LoginContext/ResetConfigModule.java >>>>> >>>>> * Use "localhost" as hostname, to make name resolution fast >>>>> >>>>> - test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java >>>>> >>>>> >>>>> After these changes, JPRT test run (with RunSamevmBatch and no >>>>> JSSE tests) shows most tests are OK. There are still intermittent >>>>> failures which are PKCS11/EC provider related. >>>>> >>>>> Thanks Max >>>> >> > From xuelei.fan at oracle.com Thu Aug 4 03:01:49 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Aug 2011 18:01:49 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E3A6D52.1020806@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E3A1A9D.9010804@oracle.com> <4E3A611E.8030304@oracle.com> <6FE553A7-0C00-4096-BD39-788BBD9B6F56@oracle.com> <4E3A6B4C.7010704@oracle.com> <4E3A6D52.1020806@oracle.com> Message-ID: <4E3A6E0D.9030409@oracle.com> On 8/4/2011 5:58 PM, Weijun Wang wrote: > > > On 08/04/2011 05:50 PM, Xuelei Fan wrote: >> Good point. I will update the test files. Even we have to make update to >> JSSE tests, I would evaluate every tests, and won't add "othervm" tag to >> those samevm safe tests. 170+ files, need some more time. > > So you will add the tag? How long will you use? Should be able to finish the update in the end of next week. I have updated 20+ files. Xuelei > If less than a week, I > can wait after you're finished and update the Makefile to call > RunasSamevmBatch. Otherwise, I'll push my changeset first and keep > RunasOthervmBatch, and in your changeset you change it to RunasSamevmBatch. > > Thanks > Max > >> >>>> ... at least I know tests inside test/closed/ >>>> sun/security/ssl/java/security/KeyStore can run >>>> in samevm. Can you give a whitelist? >>>> >> The tests won't try to establish a TLS/SSL connection, so they are safe. >> >> Thanks, >> Xuelei >> >> On 8/4/2011 5:30 PM, Kelly O'Hair wrote: >>> >>> On Aug 4, 2011, at 11:06 AM, Weijun Wang wrote: >>> >>>>> Max, if we can get an agree, would you please update the Makefile to >>>>> run JSSE in othervm mode in your fix? So that we don't have to fill >>>>> a new CR. >>>> >>>> There are two ways to do this: >>>> >>>> 1. Add "@run main/othervm" to all JSSE tests. This means a lot of >>>> code changes, but I can automate it. >>>> >>>> 2. Create new test set for JSSE. This is what I had done before in >>>> >>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.00/ >>>> >>>> many changes to Makefile, jprt.properties and jprt.properties in the >>>> parent repo. >>>> >>>> I'd choose #1. What's your opinion? >>> >>> Just a comment from the peanut gallery... ;^) >>> >>> I think #1 is the way to go. >>> >>> One thing we wanted people to be able to do is just cd to the test >>> directory and run 'jtreg -samevm' or 'jtreg -agentvm' >>> and by changing the test itself, this can work. If at some point >>> later someone fixes the test or is able to >>> make it work with samevm, they can remove the main/othervm. >>> If you do it with the Makefile, you only fixed it for when people use >>> the Makefile or with JPRT. >>> >>> -kto >>> >>>> >>>> BTW, you mentioned HTTPS and JNDI codes. If they are not inside >>>> sun/security, I won't touch them this time. Also, at least I know >>>> tests inside test/closed/sun/security/ssl/java/security/KeyStore can >>>> run in samevm. Can you give a whitelist? >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 08/04/2011 12:05 PM, Xuelei Fan wrote: >>>>>> - JSSE tests, Xuelei is working on them >>>>> It may be a bad news for the purpose to quicken the testing run >>>>> time. Most of the JSSE test may not be able to under samevm/agentvm >>>>> mode. >>>>> >>>>> 1. JSSE does not support dynamic system properties For performance >>>>> tuning and synchronization, JSSE does not support dynamic system >>>>> properties of: "java.protocol.handler.pkgs" "javax.net.ssl.keyStore" >>>>> "javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore" >>>>> "javax.net.ssl.trustStorePassword" >>>>> >>>>> The JSSE default implementation will use these properties when >>>>> initializing the static objects, and then any changes to these >>>>> properties will be ignored in the same VM. >>>>> >>>>> There are around 90 of all 170+ JSSE regression tests depends on >>>>> system properties. >>>>> >>>>> 2. JSSE caches TLS sessions, as will result in unexpected reuse of >>>>> TLS sessions in samevm/agentvm mode. There are a lot of tests using >>>>> the default SSL/TLS context, which will the same TLS session cache. >>>>> >>>>> There are only a very very few tests could be updated to run in >>>>> samevm mode. Because samevm-safe in JSSE tests will result in >>>>> unnecessary complex, and the performance improvement is very little, >>>>> I would suggest tun all JSSE tests at othervm mode. >>>>> >>>>> What do you think? >>>>> >>>>> Max, if we can get an agree, would you please update the Makefile to >>>>> run JSSE in othervm mode in your fix? So that we don't have to fill >>>>> a new CR. >>>>> >>>>> Thanks, Xuelei >>>>> >>>>> On 8/2/2011 3:02 PM, Weijun Wang wrote: >>>>>> Hi All >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>>>>> >>>>>> *Attention*: please note that the jtreg mode for jdk_security3 is >>>>>> still RunOthervmBatch. Xuelei is now working on the JSSE tests. >>>>>> Once he is ready, he will change the mode to RunSamevmBatch. >>>>>> >>>>>> The code changes: >>>>>> >>>>>> * Still included in test/ProblemList.txt >>>>>> >>>>>> - JSSE tests, Xuelei is working on them - ec tests on solaris-i586, >>>>>> they fail even if run standalone >>>>>> >>>>>> * PKCS11/EC tests: >>>>>> >>>>>> - New Providers.setAt, to ensure provider is added to desired >>>>>> position: test/sun/security/pkcs11/ec/* >>>>>> >>>>>> - PKCS11Test.safeReload, to ensure shared library can be loaded >>>>>> again: test/sun/security/pkcs11/PKCS11Test.java >>>>>> test/sun/security/pkcs11/SecmodTest.java >>>>>> >>>>>> - Test using config files need to run in othervm: >>>>>> test/sun/security/pkcs11/Secmod/* test/sun/security/pkcs11/fips/* >>>>>> >>>>>> - Restoring provider lists: test/sun/security/ec/TestEC.java >>>>>> test/sun/security/pkcs11/PKCS11Test.java >>>>>> >>>>>> * Try-with-resources updates: >>>>>> >>>>>> - test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - >>>>>> test/sun/security/pkcs12/PKCS12SameKeyId.java - >>>>>> test/sun/security/tools/keytool/StartDateTest.java >>>>>> >>>>>> * Other tests still need to be in -othervm: >>>>>> >>>>>> Using special policy file: >>>>>> test/sun/security/provider/PolicyFile/Comparator.java AlgorithmId >>>>>> static field oidTable initialization: >>>>>> test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java >>>>>> >>>>>> * JAAS configuration restore: >>>>>> >>>>>> - >>>>>> test/javax/security/auth/login/LoginContext/ResetConfigModule.java >>>>>> >>>>>> * Use "localhost" as hostname, to make name resolution fast >>>>>> >>>>>> - test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java >>>>>> >>>>>> >>>>>> After these changes, JPRT test run (with RunSamevmBatch and no >>>>>> JSSE tests) shows most tests are OK. There are still intermittent >>>>>> failures which are PKCS11/EC provider related. >>>>>> >>>>>> Thanks Max >>>>> >>> >> From weijun.wang at oracle.com Thu Aug 4 03:03:44 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 04 Aug 2011 18:03:44 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E3A6E0D.9030409@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E3A1A9D.9010804@oracle.com> <4E3A611E.8030304@oracle.com> <6FE553A7-0C00-4096-BD39-788BBD9B6F56@oracle.com> <4E3A6B4C.7010704@oracle.com> <4E3A6D52.1020806@oracle.com> <4E3A6E0D.9030409@oracle.com> Message-ID: <4E3A6E80.5070402@oracle.com> I'll wait then. Plus I can try running the final result. -Max On 08/04/2011 06:01 PM, Xuelei Fan wrote: > On 8/4/2011 5:58 PM, Weijun Wang wrote: >> >> >> On 08/04/2011 05:50 PM, Xuelei Fan wrote: >>> Good point. I will update the test files. Even we have to make update to >>> JSSE tests, I would evaluate every tests, and won't add "othervm" tag to >>> those samevm safe tests. 170+ files, need some more time. >> >> So you will add the tag? How long will you use? > Should be able to finish the update in the end of next week. I have > updated 20+ files. > > Xuelei > >> If less than a week, I >> can wait after you're finished and update the Makefile to call >> RunasSamevmBatch. Otherwise, I'll push my changeset first and keep >> RunasOthervmBatch, and in your changeset you change it to RunasSamevmBatch. >> >> Thanks >> Max >> >>> >>>>> ... at least I know tests inside test/closed/ >>>>> sun/security/ssl/java/security/KeyStore can run >>>>> in samevm. Can you give a whitelist? >>>>> >>> The tests won't try to establish a TLS/SSL connection, so they are safe. >>> >>> Thanks, >>> Xuelei >>> >>> On 8/4/2011 5:30 PM, Kelly O'Hair wrote: >>>> >>>> On Aug 4, 2011, at 11:06 AM, Weijun Wang wrote: >>>> >>>>>> Max, if we can get an agree, would you please update the Makefile to >>>>>> run JSSE in othervm mode in your fix? So that we don't have to fill >>>>>> a new CR. >>>>> >>>>> There are two ways to do this: >>>>> >>>>> 1. Add "@run main/othervm" to all JSSE tests. This means a lot of >>>>> code changes, but I can automate it. >>>>> >>>>> 2. Create new test set for JSSE. This is what I had done before in >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.00/ >>>>> >>>>> many changes to Makefile, jprt.properties and jprt.properties in the >>>>> parent repo. >>>>> >>>>> I'd choose #1. What's your opinion? >>>> >>>> Just a comment from the peanut gallery... ;^) >>>> >>>> I think #1 is the way to go. >>>> >>>> One thing we wanted people to be able to do is just cd to the test >>>> directory and run 'jtreg -samevm' or 'jtreg -agentvm' >>>> and by changing the test itself, this can work. If at some point >>>> later someone fixes the test or is able to >>>> make it work with samevm, they can remove the main/othervm. >>>> If you do it with the Makefile, you only fixed it for when people use >>>> the Makefile or with JPRT. >>>> >>>> -kto >>>> >>>>> >>>>> BTW, you mentioned HTTPS and JNDI codes. If they are not inside >>>>> sun/security, I won't touch them this time. Also, at least I know >>>>> tests inside test/closed/sun/security/ssl/java/security/KeyStore can >>>>> run in samevm. Can you give a whitelist? >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 08/04/2011 12:05 PM, Xuelei Fan wrote: >>>>>>> - JSSE tests, Xuelei is working on them >>>>>> It may be a bad news for the purpose to quicken the testing run >>>>>> time. Most of the JSSE test may not be able to under samevm/agentvm >>>>>> mode. >>>>>> >>>>>> 1. JSSE does not support dynamic system properties For performance >>>>>> tuning and synchronization, JSSE does not support dynamic system >>>>>> properties of: "java.protocol.handler.pkgs" "javax.net.ssl.keyStore" >>>>>> "javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore" >>>>>> "javax.net.ssl.trustStorePassword" >>>>>> >>>>>> The JSSE default implementation will use these properties when >>>>>> initializing the static objects, and then any changes to these >>>>>> properties will be ignored in the same VM. >>>>>> >>>>>> There are around 90 of all 170+ JSSE regression tests depends on >>>>>> system properties. >>>>>> >>>>>> 2. JSSE caches TLS sessions, as will result in unexpected reuse of >>>>>> TLS sessions in samevm/agentvm mode. There are a lot of tests using >>>>>> the default SSL/TLS context, which will the same TLS session cache. >>>>>> >>>>>> There are only a very very few tests could be updated to run in >>>>>> samevm mode. Because samevm-safe in JSSE tests will result in >>>>>> unnecessary complex, and the performance improvement is very little, >>>>>> I would suggest tun all JSSE tests at othervm mode. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Max, if we can get an agree, would you please update the Makefile to >>>>>> run JSSE in othervm mode in your fix? So that we don't have to fill >>>>>> a new CR. >>>>>> >>>>>> Thanks, Xuelei >>>>>> >>>>>> On 8/2/2011 3:02 PM, Weijun Wang wrote: >>>>>>> Hi All >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>>>>>> >>>>>>> *Attention*: please note that the jtreg mode for jdk_security3 is >>>>>>> still RunOthervmBatch. Xuelei is now working on the JSSE tests. >>>>>>> Once he is ready, he will change the mode to RunSamevmBatch. >>>>>>> >>>>>>> The code changes: >>>>>>> >>>>>>> * Still included in test/ProblemList.txt >>>>>>> >>>>>>> - JSSE tests, Xuelei is working on them - ec tests on solaris-i586, >>>>>>> they fail even if run standalone >>>>>>> >>>>>>> * PKCS11/EC tests: >>>>>>> >>>>>>> - New Providers.setAt, to ensure provider is added to desired >>>>>>> position: test/sun/security/pkcs11/ec/* >>>>>>> >>>>>>> - PKCS11Test.safeReload, to ensure shared library can be loaded >>>>>>> again: test/sun/security/pkcs11/PKCS11Test.java >>>>>>> test/sun/security/pkcs11/SecmodTest.java >>>>>>> >>>>>>> - Test using config files need to run in othervm: >>>>>>> test/sun/security/pkcs11/Secmod/* test/sun/security/pkcs11/fips/* >>>>>>> >>>>>>> - Restoring provider lists: test/sun/security/ec/TestEC.java >>>>>>> test/sun/security/pkcs11/PKCS11Test.java >>>>>>> >>>>>>> * Try-with-resources updates: >>>>>>> >>>>>>> - test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - >>>>>>> test/sun/security/pkcs12/PKCS12SameKeyId.java - >>>>>>> test/sun/security/tools/keytool/StartDateTest.java >>>>>>> >>>>>>> * Other tests still need to be in -othervm: >>>>>>> >>>>>>> Using special policy file: >>>>>>> test/sun/security/provider/PolicyFile/Comparator.java AlgorithmId >>>>>>> static field oidTable initialization: >>>>>>> test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java >>>>>>> >>>>>>> * JAAS configuration restore: >>>>>>> >>>>>>> - >>>>>>> test/javax/security/auth/login/LoginContext/ResetConfigModule.java >>>>>>> >>>>>>> * Use "localhost" as hostname, to make name resolution fast >>>>>>> >>>>>>> - test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java >>>>>>> >>>>>>> >>>>>>> After these changes, JPRT test run (with RunSamevmBatch and no >>>>>>> JSSE tests) shows most tests are OK. There are still intermittent >>>>>>> failures which are PKCS11/EC provider related. >>>>>>> >>>>>>> Thanks Max >>>>>> >>>> >>> > From weijun.wang at oracle.com Thu Aug 4 03:19:29 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 04 Aug 2011 10:19:29 +0000 Subject: hg: jdk8/tl/jdk: 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem Message-ID: <20110804101955.C941C4792B@hg.openjdk.java.net> Changeset: e68db408d08c Author: weijun Date: 2011-08-04 18:18 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e68db408d08c 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/PrincipalName.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/PrincipalNameEquals.java From Alan.Bateman at oracle.com Thu Aug 4 03:32:40 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Aug 2011 11:32:40 +0100 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E3A611E.8030304@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E3A1A9D.9010804@oracle.com> <4E3A611E.8030304@oracle.com> Message-ID: <4E3A7548.2030101@oracle.com> Weijun Wang wrote: > > There are two ways to do this: > > 1. Add "@run main/othervm" to all JSSE tests. This means a lot of code > changes, but I can automate it. > > 2. Create new test set for JSSE. This is what I had done before in > > http://cr.openjdk.java.net/~weijun/7055363/webrev.00/ > > many changes to Makefile, jprt.properties and jprt.properties in the > parent repo. > > I'd choose #1. What's your opinion? > It's a pity to have so many tests running in othervm mode but I agree that #1 is the way to do this. As Kelly says we want to be able to allow folks to "jtreg -agentvm" and ultimately they should be able to specify the top-level test directory and all tests should pass. -Alan From mike.duigou at oracle.com Thu Aug 4 09:17:50 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 04 Aug 2011 16:17:50 +0000 Subject: hg: jdk8/tl/jdk: 7073296: Executable.equalParamTypes() incorrectly returns true when the number of params differs. Message-ID: <20110804161801.09D1A47938@hg.openjdk.java.net> Changeset: 565555e89034 Author: mduigou Date: 2011-08-04 08:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/565555e89034 7073296: Executable.equalParamTypes() incorrectly returns true when the number of params differs. Reviewed-by: alanb, darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Executable.java + test/java/lang/reflect/Constructor/Equals.java From joe.darcy at oracle.com Thu Aug 4 11:17:07 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 04 Aug 2011 18:17:07 +0000 Subject: hg: jdk8/tl/langtools: 7071246: Enclosing string literal in parenthesis in switch-case crashes javac Message-ID: <20110804181712.289234793D@hg.openjdk.java.net> Changeset: 64b9b7ae3366 Author: darcy Date: 2011-08-04 11:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64b9b7ae3366 7071246: Enclosing string literal in parenthesis in switch-case crashes javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/StringsInSwitch/StringSwitches.java From neil.richards at ngmr.net Wed Aug 3 14:09:36 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 03 Aug 2011 22:09:36 +0100 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E398D71.9030302@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> <4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com> <4E398D71.9030302@oracle.com> Message-ID: <1312405776.14748.25.camel@chalkhill> On Wed, 2011-08-03 at 11:03 -0700, Alexandre Boulgakov wrote: > Please see my responses inline. > > Thanks! > -Sasha > > On 8/2/2011 9:13 PM, Xuelei Fan wrote: > > . com/sun/jndi/toolkit/dir/SearchFilter.java > > 451 for (NamingEnumeration ve = attr.getAll(); > > 452 ve.hasMore(); > > 453 ) { > > > > The update is OK. But the coding style looks uncomfortable. Would you > > mind change it to use for-each style? > For-each only works with Iterables. There doesn't seem to be a way to > get an Iterable out of an Attribute instance, so the only way to use a > for-each here would be to wrap the Enumeration in an ArrayList using > Collections.list(). While this might look neater, the contents of the > Enumeration would have to be copied over, using time and increasing the > memory footprint. Changing Attribute to implement Iterable would require > a spec change, and would be beyond the scope of this fix. Would it be useful to have a utility object to convert an Enumeration so it can be used in for-each constructs? - something like: ---- import java.util.Enumeration; import java.util.Iterator; /** * Utility class to transform an Enumeration object such that it can be used in * the for-each construct. */ public class IterableEnumerationHolder implements Iterable, Iterator { private final Enumeration e; public IterableEnumerationHolder(final Enumeration e) { this.e = e; } @Override public Iterator iterator() { return this; } @Override public boolean hasNext() { return e.hasMoreElements(); } @Override public E next() { return e.nextElement(); } @Override public void remove() { throw new UnsupportedOperationException(); } } ---- If it would, perhaps it might be considered for Java 8? Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From cgdecker at gmail.com Thu Aug 4 09:17:16 2011 From: cgdecker at gmail.com (Colin Decker) Date: Thu, 4 Aug 2011 12:17:16 -0400 Subject: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror] In-Reply-To: <4E39BA2E.9050405@oracle.com> References: <4E34155E.5090700@oracle.com> <4E37C117.2030104@oracle.com> <4E384579.1080209@oracle.com> <4E38CAD9.8050705@oracle.com> <4E398D71.9030302@oracle.com> <1312405776.14748.25.camel@chalkhill> <4E39BA2E.9050405@oracle.com> Message-ID: One better way to handle this in Java 8 would be to have a utility method that takes a Supplier> SAM argument (with a no-arg method that returns an Enumeration) and returns an Iterable that gets a new Enumeration from the supplier each time iterator() is called. It could then be used with method references: Iterable iterable = Util.enumerationIterable(#object.getEnumeration); -- Colin On Wed, Aug 3, 2011 at 5:14 PM, Alexandre Boulgakov < alexandre.boulgakov at oracle.com> wrote: > Users of Iterable expect to call Iterable.iterator() multiple times, > receiving a fresh iterator pointing to the beginning of the Iterable each > time. This would not be possible to do with an Enumeration wrapper since > Enumerations are read-once. > > I don't know if this is a strong enough reason not to include such a > utility class, but it could certainly be confusing. > > -Sasha > > > On 8/3/2011 2:09 PM, Neil Richards wrote: > >> On Wed, 2011-08-03 at 11:03 -0700, Alexandre Boulgakov wrote: >> >>> Please see my responses inline. >>> >>> Thanks! >>> -Sasha >>> >>> On 8/2/2011 9:13 PM, Xuelei Fan wrote: >>> >>>> . com/sun/jndi/toolkit/dir/**SearchFilter.java >>>> 451 for (NamingEnumeration ve = attr.getAll(); >>>> 452 ve.hasMore(); >>>> 453 ) { >>>> >>>> The update is OK. But the coding style looks uncomfortable. Would you >>>> mind change it to use for-each style? >>>> >>> For-each only works with Iterables. There doesn't seem to be a way to >>> get an Iterable out of an Attribute instance, so the only way to use a >>> for-each here would be to wrap the Enumeration in an ArrayList using >>> Collections.list(). While this might look neater, the contents of the >>> Enumeration would have to be copied over, using time and increasing the >>> memory footprint. Changing Attribute to implement Iterable would require >>> a spec change, and would be beyond the scope of this fix. >>> >> Would it be useful to have a utility object to convert an Enumeration >> so it can be used in for-each constructs? - something like: >> ---- >> import java.util.Enumeration; >> import java.util.Iterator; >> >> /** >> * Utility class to transform an Enumeration object such that it >> can be used in >> * the for-each construct. >> */ >> public class IterableEnumerationHolder implements Iterable, >> Iterator { >> private final Enumeration e; >> >> public IterableEnumerationHolder(**final Enumeration e) { >> this.e = e; >> } >> >> @Override >> public Iterator iterator() { >> return this; >> } >> >> @Override >> public boolean hasNext() { >> return e.hasMoreElements(); >> } >> >> @Override >> public E next() { >> return e.nextElement(); >> } >> >> @Override >> public void remove() { >> throw new UnsupportedOperationException(**); >> } >> } >> ---- >> >> If it would, perhaps it might be considered for Java 8? >> >> Regards, >> Neil >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20110804/d06c644c/attachment.html From tom.rodriguez at oracle.com Thu Aug 4 11:29:00 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 4 Aug 2011 11:29:00 -0700 Subject: final inner class not final (was Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror) In-Reply-To: <4E3A02EC.4030901@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E3A02EC.4030901@oracle.com> Message-ID: I think that's a javac issue. The inner class has an attribute which describes the access flags that the VM should report and that changed in _11. Here it is in _10. Attr(#25) { // InnerClasses [] { // InnerClasses #4 #0 #0 24; } } // end InnerClasses and here's _11: Attr(#25) { // InnerClasses [] { // InnerClasses #4 #0 #0 8; } } // end InnerClasses tom On Aug 3, 2011, at 7:24 PM, Weijun Wang wrote: >> serialVersionUID warnings for classes that have had different >> generated serialVersionUID's in the past. >>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>> -currently: -8090049519656411362L; >>>> -JDK 6: -3305145912345854189L; > > I find out the reason: > > Since 6u11, a final inner class is *not* final anymore. > > $ cat A4.java > import java.lang.reflect.Modifier; > public class A4 { > public static void main(String[] args) throws Exception { > Class c = Class.forName(args[0]); > System.out.println(c.getModifiers() & Modifier.FINAL); > } > } > $ java A4 java.lang.String > 16 > $ java A4 'sun.security.pkcs11.P11TlsPrfGenerator$1' > 0 > > getModifiers() is a native method, and calls JVM_GetClassModifiers. Is this an intended change? > > FYI, the class is defined as > > private static final SecretKey NULL_KEY = new SecretKey() { > .... > > in http://hg.openjdk.java.net/jdk8/tl/jdk/file/809e8db0c142/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java, line 100. > > > Thanks > Max From David.Holmes at oracle.com Thu Aug 4 18:54:14 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 05 Aug 2011 11:54:14 +1000 Subject: final inner class not final (was Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror) In-Reply-To: <4E3A02EC.4030901@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E3A02EC.4030901@oracle.com> Message-ID: <4E3B4D46.3000606@oracle.com> Max, See 6520152. For backward compatability anonymous inner classes don't have the ACC_FINAL bit set. David Weijun Wang said the following on 08/04/11 12:24: >> serialVersionUID warnings for classes that have had different >> generated serialVersionUID's in the past. >>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>> -currently: -8090049519656411362L; >>>> -JDK 6: -3305145912345854189L; > > I find out the reason: > > Since 6u11, a final inner class is *not* final anymore. > > $ cat A4.java > import java.lang.reflect.Modifier; > public class A4 { > public static void main(String[] args) throws Exception { > Class c = Class.forName(args[0]); > System.out.println(c.getModifiers() & Modifier.FINAL); > } > } > $ java A4 java.lang.String > 16 > $ java A4 'sun.security.pkcs11.P11TlsPrfGenerator$1' > 0 > > getModifiers() is a native method, and calls JVM_GetClassModifiers. Is > this an intended change? > > FYI, the class is defined as > > private static final SecretKey NULL_KEY = new SecretKey() { > .... > > in > http://hg.openjdk.java.net/jdk8/tl/jdk/file/809e8db0c142/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java, > line 100. > > > Thanks > Max From David.Holmes at oracle.com Thu Aug 4 19:07:58 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 05 Aug 2011 12:07:58 +1000 Subject: final inner class not final (was Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror) In-Reply-To: References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E3A02EC.4030901@oracle.com> Message-ID: <4E3B507E.5020200@oracle.com> Interesting - 6520152 was fixed in 6u4, so it would appear that this got turned on again at some stage and then off again in 6u11. Though I don't see a bug fix in 6u11 that would cover this. David Tom Rodriguez said the following on 08/05/11 04:29: > I think that's a javac issue. The inner class has an attribute which describes the access flags that the VM should report and that changed in _11. Here it is in _10. > > Attr(#25) { // InnerClasses > [] { // InnerClasses > #4 #0 #0 24; > } > } // end InnerClasses > > and here's _11: > > Attr(#25) { // InnerClasses > [] { // InnerClasses > #4 #0 #0 8; > } > } // end InnerClasses > > tom > > On Aug 3, 2011, at 7:24 PM, Weijun Wang wrote: > >>> serialVersionUID warnings for classes that have had different >>> generated serialVersionUID's in the past. >>>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>>> -currently: -8090049519656411362L; >>>>> -JDK 6: -3305145912345854189L; >> I find out the reason: >> >> Since 6u11, a final inner class is *not* final anymore. >> >> $ cat A4.java >> import java.lang.reflect.Modifier; >> public class A4 { >> public static void main(String[] args) throws Exception { >> Class c = Class.forName(args[0]); >> System.out.println(c.getModifiers() & Modifier.FINAL); >> } >> } >> $ java A4 java.lang.String >> 16 >> $ java A4 'sun.security.pkcs11.P11TlsPrfGenerator$1' >> 0 >> >> getModifiers() is a native method, and calls JVM_GetClassModifiers. Is this an intended change? >> >> FYI, the class is defined as >> >> private static final SecretKey NULL_KEY = new SecretKey() { >> .... >> >> in http://hg.openjdk.java.net/jdk8/tl/jdk/file/809e8db0c142/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java, line 100. >> >> >> Thanks >> Max > From weijun.wang at oracle.com Thu Aug 4 20:00:53 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 05 Aug 2011 11:00:53 +0800 Subject: final inner class not final (was Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror) In-Reply-To: <4E3B507E.5020200@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E3A02EC.4030901@oracle.com> <4E3B507E.5020200@oracle.com> Message-ID: <4E3B5CE5.8020604@oracle.com> No, it isn't that complicated. Take another class sun.security.jca.ProviderList$1 for example: 6-b54: 1151354171352296389L 6-b55: -8369942687198303343L (6219964) 6u3-latest: -8369942687198303343L 6u4-latest: 1151354171352296389L (6520152) So the times are connect. sun.security.pkcs11.P11TlsPrfGenerator$1 is a JCE class which is inside the ext/sunpkcs11.jar. Most likely that jar was only compiled using the new javac from 6u11. Thanks Max On 08/05/2011 10:07 AM, David Holmes wrote: > Interesting - 6520152 was fixed in 6u4, so it would appear that this got > turned on again at some stage and then off again in 6u11. Though I don't > see a bug fix in 6u11 that would cover this. > > David > > Tom Rodriguez said the following on 08/05/11 04:29: >> I think that's a javac issue. The inner class has an attribute which >> describes the access flags that the VM should report and that changed >> in _11. Here it is in _10. >> >> Attr(#25) { // InnerClasses >> [] { // InnerClasses >> #4 #0 #0 24; >> } >> } // end InnerClasses >> >> and here's _11: >> >> Attr(#25) { // InnerClasses >> [] { // InnerClasses >> #4 #0 #0 8; >> } >> } // end InnerClasses >> >> tom >> >> On Aug 3, 2011, at 7:24 PM, Weijun Wang wrote: >> >>>> serialVersionUID warnings for classes that have had different >>>> generated serialVersionUID's in the past. >>>>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>>>> -currently: -8090049519656411362L; >>>>>> -JDK 6: -3305145912345854189L; >>> I find out the reason: >>> >>> Since 6u11, a final inner class is *not* final anymore. >>> >>> $ cat A4.java >>> import java.lang.reflect.Modifier; >>> public class A4 { >>> public static void main(String[] args) throws Exception { >>> Class c = Class.forName(args[0]); >>> System.out.println(c.getModifiers() & Modifier.FINAL); >>> } >>> } >>> $ java A4 java.lang.String >>> 16 >>> $ java A4 'sun.security.pkcs11.P11TlsPrfGenerator$1' >>> 0 >>> >>> getModifiers() is a native method, and calls JVM_GetClassModifiers. >>> Is this an intended change? >>> >>> FYI, the class is defined as >>> >>> private static final SecretKey NULL_KEY = new SecretKey() { >>> .... >>> >>> in >>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/809e8db0c142/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java, >>> line 100. >>> >>> >>> Thanks >>> Max >> From xuelei.fan at oracle.com Fri Aug 5 03:09:48 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 05 Aug 2011 18:09:48 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E3A6E80.5070402@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E3A1A9D.9010804@oracle.com> <4E3A611E.8030304@oracle.com> <6FE553A7-0C00-4096-BD39-788BBD9B6F56@oracle.com> <4E3A6B4C.7010704@oracle.com> <4E3A6D52.1020806@oracle.com> <4E3A6E0D.9030409@oracle.com> <4E3A6E80.5070402@oracle.com> Message-ID: <4E3BC16C.6050304@oracle.com> Hi Max, I finished the update. It looks good in my testing. We may be able to join the effort in one CR. What do you think? I addressed the following issues in the update: 1. reserve and restore security properties, java.security.Security Security.setProperty Security.getProperty 2. reserve and restore default HostnameVerifier and SSLSocketFactory of javax.net.ssl.HttpsURLConnection HttpsURLConnection.setDefaultHostnameVerifier(HostnameVerifier v) HttpsURLConnection.getDefaultHostnameVerifier() HttpsURLConnection.setDefaultSSLSocketFactory(SSLSocketFactory sf) HttpsURLConnection.getDefaultSSLSocketFactory() 3. reserve and restore default java.net.CookieHandler and java.net.ResponseCache CookieHandler.setDefault CookieHandler.getDefault ResponseCache.setDefault ResponseCache.getDefault 4. reserve and restore system scope of java.security.IdentityScope IdentityScope.setSystemScope IdentityScope.getSystemScope 5. reserve and restore identity policy of java.security.Policy Policy.getPolicy Policy.setPolicy 6. security provider manage, java.security.Security Security.insertProviderAt Security.addProvider Security.removeProvider Security.getProviders 7. handle special system properties, "java.protocol.handler.pkgs" "javax.net.ssl.keyStore" "javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore" "javax.net.ssl.trustStorePassword" JSSE does not support above dynamic system properties. For every test that needs to set any property of above, need to run in othervm mode. 8. reserve and restore default java.net.ssl.SSLContext SSLContext.setDefault(SSLContext context) SSLContext.getDefault() Thanks, Xuelei On 8/4/2011 6:03 PM, Weijun Wang wrote: > I'll wait then. Plus I can try running the final result. > > -Max > > On 08/04/2011 06:01 PM, Xuelei Fan wrote: >> On 8/4/2011 5:58 PM, Weijun Wang wrote: >>> >>> >>> On 08/04/2011 05:50 PM, Xuelei Fan wrote: >>>> Good point. I will update the test files. Even we have to make >>>> update to >>>> JSSE tests, I would evaluate every tests, and won't add "othervm" >>>> tag to >>>> those samevm safe tests. 170+ files, need some more time. >>> >>> So you will add the tag? How long will you use? >> Should be able to finish the update in the end of next week. I have >> updated 20+ files. >> >> Xuelei >> >>> If less than a week, I >>> can wait after you're finished and update the Makefile to call >>> RunasSamevmBatch. Otherwise, I'll push my changeset first and keep >>> RunasOthervmBatch, and in your changeset you change it to >>> RunasSamevmBatch. >>> >>> Thanks >>> Max >>> >>>> >>>>>> ... at least I know tests inside test/closed/ >>>>>> sun/security/ssl/java/security/KeyStore can run >>>>>> in samevm. Can you give a whitelist? >>>>>> >>>> The tests won't try to establish a TLS/SSL connection, so they are >>>> safe. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/4/2011 5:30 PM, Kelly O'Hair wrote: >>>>> >>>>> On Aug 4, 2011, at 11:06 AM, Weijun Wang wrote: >>>>> >>>>>>> Max, if we can get an agree, would you please update the Makefile to >>>>>>> run JSSE in othervm mode in your fix? So that we don't have to fill >>>>>>> a new CR. >>>>>> >>>>>> There are two ways to do this: >>>>>> >>>>>> 1. Add "@run main/othervm" to all JSSE tests. This means a lot of >>>>>> code changes, but I can automate it. >>>>>> >>>>>> 2. Create new test set for JSSE. This is what I had done before in >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.00/ >>>>>> >>>>>> many changes to Makefile, jprt.properties and jprt.properties in the >>>>>> parent repo. >>>>>> >>>>>> I'd choose #1. What's your opinion? >>>>> >>>>> Just a comment from the peanut gallery... ;^) >>>>> >>>>> I think #1 is the way to go. >>>>> >>>>> One thing we wanted people to be able to do is just cd to the test >>>>> directory and run 'jtreg -samevm' or 'jtreg -agentvm' >>>>> and by changing the test itself, this can work. If at some point >>>>> later someone fixes the test or is able to >>>>> make it work with samevm, they can remove the main/othervm. >>>>> If you do it with the Makefile, you only fixed it for when people use >>>>> the Makefile or with JPRT. >>>>> >>>>> -kto >>>>> >>>>>> >>>>>> BTW, you mentioned HTTPS and JNDI codes. If they are not inside >>>>>> sun/security, I won't touch them this time. Also, at least I know >>>>>> tests inside test/closed/sun/security/ssl/java/security/KeyStore can >>>>>> run in samevm. Can you give a whitelist? >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> On 08/04/2011 12:05 PM, Xuelei Fan wrote: >>>>>>>> - JSSE tests, Xuelei is working on them >>>>>>> It may be a bad news for the purpose to quicken the testing run >>>>>>> time. Most of the JSSE test may not be able to under samevm/agentvm >>>>>>> mode. >>>>>>> >>>>>>> 1. JSSE does not support dynamic system properties For performance >>>>>>> tuning and synchronization, JSSE does not support dynamic system >>>>>>> properties of: "java.protocol.handler.pkgs" "javax.net.ssl.keyStore" >>>>>>> "javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore" >>>>>>> "javax.net.ssl.trustStorePassword" >>>>>>> >>>>>>> The JSSE default implementation will use these properties when >>>>>>> initializing the static objects, and then any changes to these >>>>>>> properties will be ignored in the same VM. >>>>>>> >>>>>>> There are around 90 of all 170+ JSSE regression tests depends on >>>>>>> system properties. >>>>>>> >>>>>>> 2. JSSE caches TLS sessions, as will result in unexpected reuse of >>>>>>> TLS sessions in samevm/agentvm mode. There are a lot of tests using >>>>>>> the default SSL/TLS context, which will the same TLS session cache. >>>>>>> >>>>>>> There are only a very very few tests could be updated to run in >>>>>>> samevm mode. Because samevm-safe in JSSE tests will result in >>>>>>> unnecessary complex, and the performance improvement is very little, >>>>>>> I would suggest tun all JSSE tests at othervm mode. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> Max, if we can get an agree, would you please update the Makefile to >>>>>>> run JSSE in othervm mode in your fix? So that we don't have to fill >>>>>>> a new CR. >>>>>>> >>>>>>> Thanks, Xuelei >>>>>>> >>>>>>> On 8/2/2011 3:02 PM, Weijun Wang wrote: >>>>>>>> Hi All >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>>>>>>> >>>>>>>> *Attention*: please note that the jtreg mode for jdk_security3 is >>>>>>>> still RunOthervmBatch. Xuelei is now working on the JSSE tests. >>>>>>>> Once he is ready, he will change the mode to RunSamevmBatch. >>>>>>>> >>>>>>>> The code changes: >>>>>>>> >>>>>>>> * Still included in test/ProblemList.txt >>>>>>>> >>>>>>>> - JSSE tests, Xuelei is working on them - ec tests on solaris-i586, >>>>>>>> they fail even if run standalone >>>>>>>> >>>>>>>> * PKCS11/EC tests: >>>>>>>> >>>>>>>> - New Providers.setAt, to ensure provider is added to desired >>>>>>>> position: test/sun/security/pkcs11/ec/* >>>>>>>> >>>>>>>> - PKCS11Test.safeReload, to ensure shared library can be loaded >>>>>>>> again: test/sun/security/pkcs11/PKCS11Test.java >>>>>>>> test/sun/security/pkcs11/SecmodTest.java >>>>>>>> >>>>>>>> - Test using config files need to run in othervm: >>>>>>>> test/sun/security/pkcs11/Secmod/* test/sun/security/pkcs11/fips/* >>>>>>>> >>>>>>>> - Restoring provider lists: test/sun/security/ec/TestEC.java >>>>>>>> test/sun/security/pkcs11/PKCS11Test.java >>>>>>>> >>>>>>>> * Try-with-resources updates: >>>>>>>> >>>>>>>> - test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - >>>>>>>> test/sun/security/pkcs12/PKCS12SameKeyId.java - >>>>>>>> test/sun/security/tools/keytool/StartDateTest.java >>>>>>>> >>>>>>>> * Other tests still need to be in -othervm: >>>>>>>> >>>>>>>> Using special policy file: >>>>>>>> test/sun/security/provider/PolicyFile/Comparator.java AlgorithmId >>>>>>>> static field oidTable initialization: >>>>>>>> test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java >>>>>>>> >>>>>>>> * JAAS configuration restore: >>>>>>>> >>>>>>>> - >>>>>>>> test/javax/security/auth/login/LoginContext/ResetConfigModule.java >>>>>>>> >>>>>>>> * Use "localhost" as hostname, to make name resolution fast >>>>>>>> >>>>>>>> - test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java >>>>>>>> >>>>>>>> >>>>>>>> After these changes, JPRT test run (with RunSamevmBatch and no >>>>>>>> JSSE tests) shows most tests are OK. There are still intermittent >>>>>>>> failures which are PKCS11/EC provider related. >>>>>>>> >>>>>>>> Thanks Max >>>>>>> >>>>> >>>> >> From weijun.wang at oracle.com Fri Aug 5 03:14:34 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 05 Aug 2011 18:14:34 +0800 Subject: 2nd round code review request: 7055363: jdk_security3 cleanup In-Reply-To: <4E3BC16C.6050304@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E3A1A9D.9010804@oracle.com> <4E3A611E.8030304@oracle.com> <6FE553A7-0C00-4096-BD39-788BBD9B6F56@oracle.com> <4E3A6B4C.7010704@oracle.com> <4E3A6D52.1020806@oracle.com> <4E3A6E0D.9030409@oracle.com> <4E3A6E80.5070402@oracle.com> <4E3BC16C.6050304@oracle.com> Message-ID: <4E3BC28A.6090400@oracle.com> On 08/05/2011 06:09 PM, Xuelei Fan wrote: > Hi Max, > > I finished the update. It looks good in my testing. We may be able to > join the effort in one CR. What do you think? It's up to you. If you want to make it a single changeset, just send the patch to me. Thanks Max > > I addressed the following issues in the update: > > 1. reserve and restore security properties, java.security.Security > Security.setProperty > Security.getProperty > > 2. reserve and restore default HostnameVerifier and SSLSocketFactory of > javax.net.ssl.HttpsURLConnection > HttpsURLConnection.setDefaultHostnameVerifier(HostnameVerifier v) > HttpsURLConnection.getDefaultHostnameVerifier() > HttpsURLConnection.setDefaultSSLSocketFactory(SSLSocketFactory sf) > HttpsURLConnection.getDefaultSSLSocketFactory() > > 3. reserve and restore default java.net.CookieHandler and > java.net.ResponseCache > CookieHandler.setDefault > CookieHandler.getDefault > ResponseCache.setDefault > ResponseCache.getDefault > > 4. reserve and restore system scope of java.security.IdentityScope > IdentityScope.setSystemScope > IdentityScope.getSystemScope > > 5. reserve and restore identity policy of java.security.Policy > Policy.getPolicy > Policy.setPolicy > > 6. security provider manage, java.security.Security > Security.insertProviderAt > Security.addProvider > Security.removeProvider > Security.getProviders > > 7. handle special system properties, > "java.protocol.handler.pkgs" > "javax.net.ssl.keyStore" > "javax.net.ssl.keyStorePassword" > "javax.net.ssl.trustStore" > "javax.net.ssl.trustStorePassword" > > JSSE does not support above dynamic system properties. For every test > that needs to set any property of above, need to run in othervm mode. > > 8. reserve and restore default java.net.ssl.SSLContext > SSLContext.setDefault(SSLContext context) > SSLContext.getDefault() > > > Thanks, > Xuelei > > On 8/4/2011 6:03 PM, Weijun Wang wrote: >> I'll wait then. Plus I can try running the final result. >> >> -Max >> >> On 08/04/2011 06:01 PM, Xuelei Fan wrote: >>> On 8/4/2011 5:58 PM, Weijun Wang wrote: >>>> >>>> >>>> On 08/04/2011 05:50 PM, Xuelei Fan wrote: >>>>> Good point. I will update the test files. Even we have to make >>>>> update to >>>>> JSSE tests, I would evaluate every tests, and won't add "othervm" >>>>> tag to >>>>> those samevm safe tests. 170+ files, need some more time. >>>> >>>> So you will add the tag? How long will you use? >>> Should be able to finish the update in the end of next week. I have >>> updated 20+ files. >>> >>> Xuelei >>> >>>> If less than a week, I >>>> can wait after you're finished and update the Makefile to call >>>> RunasSamevmBatch. Otherwise, I'll push my changeset first and keep >>>> RunasOthervmBatch, and in your changeset you change it to >>>> RunasSamevmBatch. >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>>>> ... at least I know tests inside test/closed/ >>>>>>> sun/security/ssl/java/security/KeyStore can run >>>>>>> in samevm. Can you give a whitelist? >>>>>>> >>>>> The tests won't try to establish a TLS/SSL connection, so they are >>>>> safe. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 8/4/2011 5:30 PM, Kelly O'Hair wrote: >>>>>> >>>>>> On Aug 4, 2011, at 11:06 AM, Weijun Wang wrote: >>>>>> >>>>>>>> Max, if we can get an agree, would you please update the Makefile to >>>>>>>> run JSSE in othervm mode in your fix? So that we don't have to fill >>>>>>>> a new CR. >>>>>>> >>>>>>> There are two ways to do this: >>>>>>> >>>>>>> 1. Add "@run main/othervm" to all JSSE tests. This means a lot of >>>>>>> code changes, but I can automate it. >>>>>>> >>>>>>> 2. Create new test set for JSSE. This is what I had done before in >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.00/ >>>>>>> >>>>>>> many changes to Makefile, jprt.properties and jprt.properties in the >>>>>>> parent repo. >>>>>>> >>>>>>> I'd choose #1. What's your opinion? >>>>>> >>>>>> Just a comment from the peanut gallery... ;^) >>>>>> >>>>>> I think #1 is the way to go. >>>>>> >>>>>> One thing we wanted people to be able to do is just cd to the test >>>>>> directory and run 'jtreg -samevm' or 'jtreg -agentvm' >>>>>> and by changing the test itself, this can work. If at some point >>>>>> later someone fixes the test or is able to >>>>>> make it work with samevm, they can remove the main/othervm. >>>>>> If you do it with the Makefile, you only fixed it for when people use >>>>>> the Makefile or with JPRT. >>>>>> >>>>>> -kto >>>>>> >>>>>>> >>>>>>> BTW, you mentioned HTTPS and JNDI codes. If they are not inside >>>>>>> sun/security, I won't touch them this time. Also, at least I know >>>>>>> tests inside test/closed/sun/security/ssl/java/security/KeyStore can >>>>>>> run in samevm. Can you give a whitelist? >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> On 08/04/2011 12:05 PM, Xuelei Fan wrote: >>>>>>>>> - JSSE tests, Xuelei is working on them >>>>>>>> It may be a bad news for the purpose to quicken the testing run >>>>>>>> time. Most of the JSSE test may not be able to under samevm/agentvm >>>>>>>> mode. >>>>>>>> >>>>>>>> 1. JSSE does not support dynamic system properties For performance >>>>>>>> tuning and synchronization, JSSE does not support dynamic system >>>>>>>> properties of: "java.protocol.handler.pkgs" "javax.net.ssl.keyStore" >>>>>>>> "javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore" >>>>>>>> "javax.net.ssl.trustStorePassword" >>>>>>>> >>>>>>>> The JSSE default implementation will use these properties when >>>>>>>> initializing the static objects, and then any changes to these >>>>>>>> properties will be ignored in the same VM. >>>>>>>> >>>>>>>> There are around 90 of all 170+ JSSE regression tests depends on >>>>>>>> system properties. >>>>>>>> >>>>>>>> 2. JSSE caches TLS sessions, as will result in unexpected reuse of >>>>>>>> TLS sessions in samevm/agentvm mode. There are a lot of tests using >>>>>>>> the default SSL/TLS context, which will the same TLS session cache. >>>>>>>> >>>>>>>> There are only a very very few tests could be updated to run in >>>>>>>> samevm mode. Because samevm-safe in JSSE tests will result in >>>>>>>> unnecessary complex, and the performance improvement is very little, >>>>>>>> I would suggest tun all JSSE tests at othervm mode. >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Max, if we can get an agree, would you please update the Makefile to >>>>>>>> run JSSE in othervm mode in your fix? So that we don't have to fill >>>>>>>> a new CR. >>>>>>>> >>>>>>>> Thanks, Xuelei >>>>>>>> >>>>>>>> On 8/2/2011 3:02 PM, Weijun Wang wrote: >>>>>>>>> Hi All >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>>>>>>>> >>>>>>>>> *Attention*: please note that the jtreg mode for jdk_security3 is >>>>>>>>> still RunOthervmBatch. Xuelei is now working on the JSSE tests. >>>>>>>>> Once he is ready, he will change the mode to RunSamevmBatch. >>>>>>>>> >>>>>>>>> The code changes: >>>>>>>>> >>>>>>>>> * Still included in test/ProblemList.txt >>>>>>>>> >>>>>>>>> - JSSE tests, Xuelei is working on them - ec tests on solaris-i586, >>>>>>>>> they fail even if run standalone >>>>>>>>> >>>>>>>>> * PKCS11/EC tests: >>>>>>>>> >>>>>>>>> - New Providers.setAt, to ensure provider is added to desired >>>>>>>>> position: test/sun/security/pkcs11/ec/* >>>>>>>>> >>>>>>>>> - PKCS11Test.safeReload, to ensure shared library can be loaded >>>>>>>>> again: test/sun/security/pkcs11/PKCS11Test.java >>>>>>>>> test/sun/security/pkcs11/SecmodTest.java >>>>>>>>> >>>>>>>>> - Test using config files need to run in othervm: >>>>>>>>> test/sun/security/pkcs11/Secmod/* test/sun/security/pkcs11/fips/* >>>>>>>>> >>>>>>>>> - Restoring provider lists: test/sun/security/ec/TestEC.java >>>>>>>>> test/sun/security/pkcs11/PKCS11Test.java >>>>>>>>> >>>>>>>>> * Try-with-resources updates: >>>>>>>>> >>>>>>>>> - test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - >>>>>>>>> test/sun/security/pkcs12/PKCS12SameKeyId.java - >>>>>>>>> test/sun/security/tools/keytool/StartDateTest.java >>>>>>>>> >>>>>>>>> * Other tests still need to be in -othervm: >>>>>>>>> >>>>>>>>> Using special policy file: >>>>>>>>> test/sun/security/provider/PolicyFile/Comparator.java AlgorithmId >>>>>>>>> static field oidTable initialization: >>>>>>>>> test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java >>>>>>>>> >>>>>>>>> * JAAS configuration restore: >>>>>>>>> >>>>>>>>> - >>>>>>>>> test/javax/security/auth/login/LoginContext/ResetConfigModule.java >>>>>>>>> >>>>>>>>> * Use "localhost" as hostname, to make name resolution fast >>>>>>>>> >>>>>>>>> - test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java >>>>>>>>> >>>>>>>>> >>>>>>>>> After these changes, JPRT test run (with RunSamevmBatch and no >>>>>>>>> JSSE tests) shows most tests are OK. There are still intermittent >>>>>>>>> failures which are PKCS11/EC provider related. >>>>>>>>> >>>>>>>>> Thanks Max >>>>>>>> >>>>>> >>>>> >>> > From jonathan.gibbons at oracle.com Fri Aug 5 15:58:29 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 05 Aug 2011 22:58:29 +0000 Subject: hg: jdk8/tl/langtools: 7074189: some javac tests fail with latest jtreg 4.1 b03 Message-ID: <20110805225832.1F8B547984@hg.openjdk.java.net> Changeset: c0d5f93af048 Author: jjg Date: 2011-08-05 15:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c0d5f93af048 7074189: some javac tests fail with latest jtreg 4.1 b03 Reviewed-by: darcy + test/tools/javac/lib/CompileFail.java ! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/tools/javac/processing/errors/TestReturnCode.java ! test/tools/javac/warnings/Serial.java From kumar.x.srinivasan at oracle.com Sat Aug 6 14:18:55 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 06 Aug 2011 21:18:55 +0000 Subject: hg: jdk8/tl/langtools: 7064544: (javadoc) miscellaneous fixes requested by netbeans Message-ID: <20110806211858.32160479B5@hg.openjdk.java.net> Changeset: e9f118c2bd3c Author: ksrini Date: 2011-08-05 19:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e9f118c2bd3c 7064544: (javadoc) miscellaneous fixes requested by netbeans Summary: Contributed by netbeans team, modified to suit by the langtools team. Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testLinkTaglet/pkg/C.java From joe.darcy at oracle.com Sat Aug 6 14:37:19 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 06 Aug 2011 21:37:19 +0000 Subject: hg: jdk8/tl/jdk: 7075098: Remove unused fdlibm files Message-ID: <20110806213742.31439479B6@hg.openjdk.java.net> Changeset: b9fffbe98230 Author: darcy Date: 2011-08-06 14:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b9fffbe98230 7075098: Remove unused fdlibm files Reviewed-by: alanb, mduigou ! make/java/fdlibm/FILES_c.gmk ! src/share/native/java/lang/fdlibm/include/fdlibm.h ! src/share/native/java/lang/fdlibm/include/jfdlibm.h - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c From weijun.wang at oracle.com Sat Aug 6 20:19:35 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 07 Aug 2011 11:19:35 +0800 Subject: One new change (was Re: 2nd round code review request: 7055363: jdk_security3 cleanup) In-Reply-To: <4E3A0611.2020308@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E382927.1070806@oracle.com> <4E38C59C.1000504@oracle.com> <4E39FFD1.2040204@oracle.com> <4E3A052A.7030405@oracle.com> <4E3A0611.2020308@oracle.com> Message-ID: <4E3E0447.8060703@oracle.com> On 08/04/2011 10:38 AM, Xuelei Fan wrote: > On 8/4/2011 10:34 AM, Weijun Wang wrote: >> Oh, that's true. >> >> I'll add it back. Why did I remove it at the first place? >> > You may not have to add it back, the library tag may help to build the > dependent classes. Maybe, we have some incorrect understand of the > "build" tag. A @build is needed here. The ResetModule file is loaded as a JAAS configuration provider. The class is not directly referenced in the test and will not be automatically compiled. In fact, JAAS uses the thread context class loader to load a Configuration provider, so even if ResetModule is built, it still cannot be loaded. I've update the test with a dirty hack: --- a/test/javax/security/auth/login/LoginContext/ResetConfigModule.java +++ b/test/javax/security/auth/login/LoginContext/ResetConfigModule.java @@ -25,7 +25,6 @@ * @test * @bug 4633622 * @summary bug in LoginContext when Configuration is subclassed - * * @build ResetConfigModule ResetModule * @run main ResetConfigModule */ @@ -40,32 +39,40 @@ public static void main(String[] args) throws Exception { + Thread.currentThread().setContextClassLoader( + ResetConfigModule.class.getClassLoader()); Please confirm this is OK. Or, do you have a better solution? BTW, I've asked about this in another mail but no reply yet: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007286.html Thanks Max > > Xuelei > >> Thanks >> Max >> >> On 08/04/2011 10:11 AM, Xuelei Fan wrote: >>> . test/javax/security/auth/login/LoginContext/ResetConfigModule.java >>> >>> You removed the "run" tag, and "build" tag is the last tag. It seems >>> that the test will only run building, but not run the class.main(). I >>> got the strange behavior when I run some tests with build tag with jtreg >>> 4.1 b03. Did you come into the same issue? >>> >>> Thanks, >>> Xuelei >>> >>> On 8/3/2011 11:50 AM, Weijun Wang wrote: >>>> >>>> >>>> On 08/03/2011 12:43 AM, Alan Bateman wrote: >>>>> Weijun Wang wrote: >>>>>> Hi All >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>>>> I went through the changes to the tests and they look okay to me. It's >>>>> good to see so many tests removed from the problem list and the tests >>>>> updated to work in samevm or agentvm mode. >>>>> >>>>> Is there a bug created for the ec tests that are failing on >>>>> solaris-i586? If so then it would be good to include the bugID for >>>> >>>> I thought there was one but I cannot find it. *Vinnie*, do you know it? >>>> >>>>> future edits to the problem list. Also I see you've commented out >>>>> two ec >>>>> tests and I wonder if these lines should be removed or uncommented. >>>> >>>> I don't understand why these 2 pass now. Maybe they still fail on some >>>> platforms not in JPRT? Anyway, I just don't want to purge the lines. >>>> >>>>> >>>>> test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - no >>>>> problem >>>>> with your change but I notice this test using URL's getFile which isn't >>>>> the right way to get to a file path. Could this be changed to using >>>>> File(URI)? >>>> >>>> This test is a compatibility check, see >>>> >>>> http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/4e7ad09de58b >>>> >>>> I remember there were some strange things on Windows, say, UNC, \ vs /, >>>> that made some hand-crafted URL illegal. We cannot support all of them, >>>> so just make sure the old supported ones are still supported. >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>> -Alan. >>>>> >>>>> >>>>> >>>>> >>>>> >>> > From xuelei.fan at oracle.com Sun Aug 7 06:34:03 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 07 Aug 2011 21:34:03 +0800 Subject: One new change (was Re: 2nd round code review request: 7055363: jdk_security3 cleanup) In-Reply-To: <4E3E0447.8060703@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E382927.1070806@oracle.com> <4E38C59C.1000504@oracle.com> <4E39FFD1.2040204@oracle.com> <4E3A052A.7030405@oracle.com> <4E3A0611.2020308@oracle.com> <4E3E0447.8060703@oracle.com> Message-ID: <4E3E944B.8080100@oracle.com> No better solution. The update sounds fine to me. Xuelei On 8/7/2011 11:19 AM, Weijun Wang wrote: > > > On 08/04/2011 10:38 AM, Xuelei Fan wrote: >> On 8/4/2011 10:34 AM, Weijun Wang wrote: >>> Oh, that's true. >>> >>> I'll add it back. Why did I remove it at the first place? >>> >> You may not have to add it back, the library tag may help to build the >> dependent classes. Maybe, we have some incorrect understand of the >> "build" tag. > > A @build is needed here. The ResetModule file is loaded as a JAAS > configuration provider. The class is not directly referenced in the test > and will not be automatically compiled. > > In fact, JAAS uses the thread context class loader to load a > Configuration provider, so even if ResetModule is built, it still cannot > be loaded. > > I've update the test with a dirty hack: > > --- a/test/javax/security/auth/login/LoginContext/ResetConfigModule.java > +++ b/test/javax/security/auth/login/LoginContext/ResetConfigModule.java > @@ -25,7 +25,6 @@ > * @test > * @bug 4633622 > * @summary bug in LoginContext when Configuration is subclassed > - * > * @build ResetConfigModule ResetModule > * @run main ResetConfigModule > */ > @@ -40,32 +39,40 @@ > > public static void main(String[] args) throws Exception { > > + Thread.currentThread().setContextClassLoader( > + ResetConfigModule.class.getClassLoader()); > > Please confirm this is OK. Or, do you have a better solution? > > BTW, I've asked about this in another mail but no reply yet: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007286.html > > > Thanks > Max > >> >> Xuelei >> >>> Thanks >>> Max >>> >>> On 08/04/2011 10:11 AM, Xuelei Fan wrote: >>>> . test/javax/security/auth/login/LoginContext/ResetConfigModule.java >>>> >>>> You removed the "run" tag, and "build" tag is the last tag. It seems >>>> that the test will only run building, but not run the class.main(). I >>>> got the strange behavior when I run some tests with build tag with >>>> jtreg >>>> 4.1 b03. Did you come into the same issue? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/3/2011 11:50 AM, Weijun Wang wrote: >>>>> >>>>> >>>>> On 08/03/2011 12:43 AM, Alan Bateman wrote: >>>>>> Weijun Wang wrote: >>>>>>> Hi All >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/7055363/webrev.01/ >>>>>> I went through the changes to the tests and they look okay to me. >>>>>> It's >>>>>> good to see so many tests removed from the problem list and the tests >>>>>> updated to work in samevm or agentvm mode. >>>>>> >>>>>> Is there a bug created for the ec tests that are failing on >>>>>> solaris-i586? If so then it would be good to include the bugID for >>>>> >>>>> I thought there was one but I cannot find it. *Vinnie*, do you know >>>>> it? >>>>> >>>>>> future edits to the problem list. Also I see you've commented out >>>>>> two ec >>>>>> tests and I wonder if these lines should be removed or uncommented. >>>>> >>>>> I don't understand why these 2 pass now. Maybe they still fail on some >>>>> platforms not in JPRT? Anyway, I just don't want to purge the lines. >>>>> >>>>>> >>>>>> test/com/sun/security/auth/login/ConfigFile/IllegalURL.java - no >>>>>> problem >>>>>> with your change but I notice this test using URL's getFile which >>>>>> isn't >>>>>> the right way to get to a file path. Could this be changed to using >>>>>> File(URI)? >>>>> >>>>> This test is a compatibility check, see >>>>> >>>>> http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/4e7ad09de58b >>>>> >>>>> I remember there were some strange things on Windows, say, UNC, \ >>>>> vs /, >>>>> that made some hand-crafted URL illegal. We cannot support all of >>>>> them, >>>>> so just make sure the old supported ones are still supported. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> >>>>>> -Alan. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From Alan.Bateman at oracle.com Sun Aug 7 15:04:20 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 07 Aug 2011 23:04:20 +0100 Subject: One new change (was Re: 2nd round code review request: 7055363: jdk_security3 cleanup) In-Reply-To: <4E3E0447.8060703@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E382927.1070806@oracle.com> <4E38C59C.1000504@oracle.com> <4E39FFD1.2040204@oracle.com> <4E3A052A.7030405@oracle.com> <4E3A0611.2020308@oracle.com> <4E3E0447.8060703@oracle.com> Message-ID: <4E3F0BE4.2010200@oracle.com> Weijun Wang wrote: > : > > > + Thread.currentThread().setContextClassLoader( > + ResetConfigModule.class.getClassLoader()); > > Please confirm this is OK. Or, do you have a better solution? Will the thread context class loader be restored too? With jtreg in -samevm or -agentvm mode then the test classes are loaded by a class loader that jtreg creates for the test so I assume the above could lead to issues in subsequent tests that make use of the thread context class loader. -Alan. From weijun.wang at oracle.com Sun Aug 7 16:48:51 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 08 Aug 2011 07:48:51 +0800 Subject: One new change (was Re: 2nd round code review request: 7055363: jdk_security3 cleanup) In-Reply-To: <4E3F0BE4.2010200@oracle.com> References: <4E3131A1.2000009@oracle.com> <4E379640.9050105@oracle.com> <4E37A109.7080902@oracle.com> <4E382927.1070806@oracle.com> <4E38C59C.1000504@oracle.com> <4E39FFD1.2040204@oracle.com> <4E3A052A.7030405@oracle.com> <4E3A0611.2020308@oracle.com> <4E3E0447.8060703@oracle.com> <4E3F0BE4.2010200@oracle.com> Message-ID: <4E3F2463.9080407@oracle.com> Correct. I'll restore it. Thanks Max On 08/08/2011 06:04 AM, Alan Bateman wrote: > Weijun Wang wrote: >> : >> >> >> + Thread.currentThread().setContextClassLoader( >> + ResetConfigModule.class.getClassLoader()); >> >> Please confirm this is OK. Or, do you have a better solution? > Will the thread context class loader be restored too? With jtreg in > -samevm or -agentvm mode then the test classes are loaded by a class > loader that jtreg creates for the test so I assume the above could lead > to issues in subsequent tests that make use of the thread context class > loader. > > -Alan. > From lana.steuck at oracle.com Sun Aug 7 17:20:34 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 08 Aug 2011 00:20:34 +0000 Subject: hg: jdk8/tl/jdk: 27 new changesets Message-ID: <20110808002500.E045C479F3@hg.openjdk.java.net> Changeset: 6444b0a364d7 Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6444b0a364d7 7054590: (JSR-292) MethodHandleProxies.asInterfaceInstance() accepts private/protected nested interfaces Summary: fix non-compliant logic in MethodHandleProxies, fix invalid private classes in MethodHandlesTest Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 5f3cd0cbad56 Author: jrose Date: 2011-07-13 01:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f3cd0cbad56 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: bfc5ec581c48 Author: jrose Date: 2011-07-16 15:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfc5ec581c48 7058630: JSR 292 method handle proxy violates contract for Object methods Reviewed-by: never, twisti ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 668edf27e9c7 Author: jrose Date: 2011-07-16 15:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/668edf27e9c7 7058651: JSR 292 unit tests need a refresh Summary: Enhancements to unit tests. Reviewed-by: never, twisti ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/RicochetTest.java + test/java/lang/invoke/ThrowExceptionsTest.java Changeset: b42029cd1744 Author: jrose Date: 2011-07-16 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b42029cd1744 6983728: JSR 292 remove argument count limitations Summary: Remove workarounds and limitations from before 6939861. Reviewed-by: never ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/FilterGeneric.java - src/share/classes/java/lang/invoke/FilterOneArgument.java - src/share/classes/java/lang/invoke/FromGeneric.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java - src/share/classes/java/lang/invoke/SpreadGeneric.java - src/share/classes/java/lang/invoke/ToGeneric.java Changeset: 74598b748a57 Author: lana Date: 2011-07-01 12:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74598b748a57 Merge Changeset: 0a00216a858c Author: lana Date: 2011-07-07 19:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a00216a858c Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: 77d5cc943286 Author: prr Date: 2011-07-19 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77d5cc943286 7068471: NPE in sun.font.FontConfigManager.getFontConfigFont() when libfontconfig.so is not installed Reviewed-by: jgodinez, prr Contributed-by: spoole at linux.vnet.ibm.com ! src/solaris/classes/sun/font/FontConfigManager.java Changeset: ae05aa9ede7b Author: bae Date: 2011-07-20 16:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae05aa9ede7b 7044285: 64 bit VM crashes in Java_sun_java2d_loops_MaskFill_MaskFill Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h Changeset: 40d0dea5d0fc Author: neugens Date: 2011-07-26 21:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40d0dea5d0fc 7070155: A small refactoring patch for the abstract RenderingEngine. Summary: Simplify code by using ReflectiveOperationException instead of 3 ignored catch blocks Reviewed-by: prr ! src/share/classes/sun/java2d/pipe/RenderingEngine.java Changeset: 0795f0dacfec Author: bagiras Date: 2011-07-11 15:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0795f0dacfec 7050935: closed/java/awt/Choice/WheelEventsConsumed/WheelEventsConsumed.html fails on win32 Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp + test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java Changeset: acea32663757 Author: peytoia Date: 2011-07-12 08:00 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acea32663757 7042148: closed/java/awt/font/TextLayout/CheckLayoutLTR.java failed Reviewed-by: okutsu ! src/share/classes/sun/text/bidi/BidiBase.java + test/java/text/Bidi/Bug7042148.java Changeset: 75ee78eb7322 Author: peytoia Date: 2011-07-12 08:46 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75ee78eb7322 7051769: java.text.Bidi.toString() output is wrong Reviewed-by: okutsu ! src/share/classes/sun/text/bidi/BidiBase.java + test/java/text/Bidi/Bug7051769.java Changeset: 6bc0e1709d97 Author: lana Date: 2011-07-11 16:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6bc0e1709d97 Merge Changeset: cce5659427bb Author: rupashka Date: 2011-07-12 11:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cce5659427bb 7019963: The goto parent directory button doesn't operate in JFileChooser Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Changeset: 5c22624d193e Author: rupashka Date: 2011-07-15 14:43 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c22624d193e 4909150: WindowsTreeUI can cause NullPointerException occasionally Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java Changeset: 6ee24f03760d Author: serb Date: 2011-07-15 19:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ee24f03760d 7043679: Wrong class name is used in Java_sun_awt_windows_WPrinterJob_initIDs Reviewed-by: dav, art ! src/windows/native/sun/windows/awt_PrintJob.cpp Changeset: c90a43ebf8fd Author: serb Date: 2011-07-15 19:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c90a43ebf8fd 7043815: AWT-XAWT - AWT-EventQueue-0 deadlock. Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java Changeset: 252f71b26b23 Author: serb Date: 2011-07-15 19:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/252f71b26b23 6596915: JCK-runtime-6a/tests/api/java_awt/Component/index.html tesPaintAll fails Reviewed-by: art, dcherepanov, anthony ! src/solaris/classes/sun/awt/X11/XButtonPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XLabelPeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuWindow.java ! src/solaris/classes/sun/awt/X11/XPanelPeer.java ! src/solaris/classes/sun/awt/X11/XRepaintArea.java ! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java ! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/solaris/classes/sun/awt/X11/XWarningWindow.java ! src/solaris/classes/sun/awt/X11/XWindow.java + test/java/awt/Component/PaintAll/PaintAll.java Changeset: 3ed58dbad819 Author: serb Date: 2011-07-15 19:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ed58dbad819 6642728: Use reflection to access ScrollPane's private method from within sun.awt package Reviewed-by: art, anthony ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/native/sun/windows/awt_ScrollPane.cpp Changeset: 9c642ae9a543 Author: serb Date: 2011-07-15 19:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c642ae9a543 4717864: setFont() does not update Fonts of Menus already on screen Reviewed-by: art, bagiras ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/native/sun/windows/awt_Menu.cpp ! src/windows/native/sun/windows/awt_Menu.h ! src/windows/native/sun/windows/awt_MenuBar.cpp ! src/windows/native/sun/windows/awt_MenuBar.h ! src/windows/native/sun/windows/awt_MenuItem.cpp ! src/windows/native/sun/windows/awt_MenuItem.h Changeset: 3ac81907aa7d Author: rupashka Date: 2011-07-18 17:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ac81907aa7d 6509273: Password in JPasswordField gets Printed in clear text Reviewed-by: alexp ! src/share/classes/sun/swing/text/TextComponentPrintable.java Changeset: c05b36e4749e Author: rupashka Date: 2011-07-18 18:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c05b36e4749e 7031941: Use generificated JComboBox and JList in core libraries Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/OptionComboBoxModel.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/sun/swing/FilePane.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: 190b11164876 Author: lana Date: 2011-07-27 22:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/190b11164876 Merge Changeset: 996547848b00 Author: lana Date: 2011-08-01 17:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/996547848b00 Merge Changeset: 3f3a59423a7e Author: lana Date: 2011-08-05 16:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f3a59423a7e Merge - src/share/classes/java/lang/invoke/FilterGeneric.java - src/share/classes/java/lang/invoke/FilterOneArgument.java - src/share/classes/java/lang/invoke/FromGeneric.java - src/share/classes/java/lang/invoke/SpreadGeneric.java - src/share/classes/java/lang/invoke/ToGeneric.java Changeset: a5f825ef8587 Author: lana Date: 2011-08-07 17:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5f825ef8587 Merge - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c From lana.steuck at oracle.com Sun Aug 7 17:19:35 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 08 Aug 2011 00:19:35 +0000 Subject: hg: jdk8/tl/hotspot: 82 new changesets Message-ID: <20110808002207.D3432479F1@hg.openjdk.java.net> Changeset: 2b27ef5c2173 Author: kvn Date: 2011-05-20 12:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b27ef5c2173 7046096: SEGV IN C2 WITH 6U25 Summary: Missing fail flag set in strings concatenation code. Reviewed-by: never ! src/share/vm/opto/stringopts.cpp Changeset: cfbca4d74a61 Author: jcoomes Date: 2011-05-20 22:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cfbca4d74a61 Merge Changeset: 789d04408ca3 Author: kvn Date: 2011-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/789d04408ca3 7045693: java/util/EnumSet/EnumSetBash.java still failing intermittently Summary: New limit for unrolled loop should be set only for zero trip guard and loop iteration test. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: b55f5bd7ec66 Author: kvn Date: 2011-05-21 13:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b55f5bd7ec66 7045506: assert(!can_reshape || !new_phi) failed: for igvn new phi should be hooked Summary: Replace the assert in PhiNode::Ideal with check to avoid transformation of new phi. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp Changeset: 7523488edce5 Author: kvn Date: 2011-05-24 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7523488edce5 7047300: VM crashes with assert(_base == InstPtr) failed: Not an object pointer Summary: The code incorrectly used is_instptr() instead of is_oopptr() to get const_oop. Reviewed-by: never ! src/share/vm/opto/output.cpp Changeset: ccf072cdba91 Author: iveresov Date: 2011-05-24 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ccf072cdba91 7046893: LP64 problem with double_quadword in c1_LIRAssembler_x86.cpp Summary: Fixed invalid casts in address computation Reviewed-by: kvn, never Contributed-by: thomas.salter at unisys.com ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 28a9fe9534ea Author: kvn Date: 2011-05-24 20:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28a9fe9534ea 7048030: is_scavengable changes causing compiler to embed more constants Summary: ciObject::can_be_constant() and should_be_constant() should use is_perm() instead of !is_scavengable() Reviewed-by: never, jrose ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp Changeset: 7db2b9499c36 Author: never Date: 2011-05-25 16:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7db2b9499c36 7046732: JSR 292 assert(result == cpce->f1()) failed: expected result for assembly code Reviewed-by: kvn, iveresov, jrose ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: c7c81f18c834 Author: kvn Date: 2011-05-25 21:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c7c81f18c834 7048332: Cadd_cmpLTMask doesn't handle 64-bit tmp register properly Summary: Use ins_encode %{ %} form to encode cadd_cmpLTMask() instruction and remove unused code. Reviewed-by: never ! src/cpu/x86/vm/x86_64.ad + test/compiler/7048332/Test7048332.java Changeset: 28263a73ebfb Author: iveresov Date: 2011-05-26 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28263a73ebfb 7047491: C1: registers saved incorrectly when calling checkcast_arraycopy stub Summary: Save and restore the argument registers around the call to checkcast_arraycopy Reviewed-by: never, roland ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 5ac411b3b8fc Author: never Date: 2011-05-26 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ac411b3b8fc 7047961: JSR 292 MethodHandleWalk swap args doesn't handle T_LONG and T_DOUBLE properly Reviewed-by: kvn, jrose ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp Changeset: c76c13577460 Author: never Date: 2011-05-26 16:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c76c13577460 Merge Changeset: b2cb497dec28 Author: kvn Date: 2011-05-27 12:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2cb497dec28 7047069: Array can dynamically change size when assigned to an object field Summary: Fix initialization of a newly-allocated array with arraycopy Reviewed-by: never ! src/share/vm/opto/library_call.cpp + test/compiler/7047069/Test7047069.java Changeset: 33e2b8f1d466 Author: kvn Date: 2011-05-31 10:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/33e2b8f1d466 6956668: misbehavior of XOR operator (^) with int Summary: optimize cmp_ne(xor(X,1),0) to cmp_eq(X,0) only for boolean values X. Reviewed-by: never ! src/share/vm/opto/subnode.cpp + test/compiler/6956668/Test6956668.java Changeset: 60b8287df30e Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/60b8287df30e 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Delegate invokedynamic linkage errors to MethodHandleNatives.raiseException. Reviewed-by: never ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: a93146d0e4be Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a93146d0e4be 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM Summary: change the default setting of the flag AllowInvokeGeneric to false Reviewed-by: never ! src/share/vm/runtime/globals.hpp Changeset: 537a4053b0f9 Author: ysr Date: 2011-05-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/537a4053b0f9 7042740: CMS: assert(n> q) failed: Looping at: ... blockOffsetTable.cpp:557 Summary: Do a one-step look-ahead, when sweeping free or garbage blocks, to avoid overstepping sweep limit, which may become a non-block-boundary because of a heap expansion delta coalescing with a previously co-terminal free block. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/blockOffsetTable.cpp Changeset: f153114134c8 Author: jcoomes Date: 2011-06-07 13:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f153114134c8 Merge Changeset: d3b9f2be46ab Author: coleenp Date: 2011-05-21 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d3b9f2be46ab 7033141: assert(has_cp_cache(i)) failed: oob Summary: Unrewrite bytecodes for OOM error allocating the constant pool cache. Reviewed-by: dcubed, acorn, never ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 9dd6c4ba364f Author: coleenp Date: 2011-06-02 14:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9dd6c4ba364f 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 Summary: Removed extra change from another bug fix that caused this regression Reviewed-by: phh, dcubed, kvn, kamg, never ! src/share/vm/oops/methodOop.cpp Changeset: 96c891ebe56a Author: coleenp Date: 2011-06-02 21:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/96c891ebe56a Merge ! src/share/vm/prims/methodHandleWalk.cpp Changeset: ae1d716e395c Author: dsamersoff Date: 2011-06-09 01:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae1d716e395c Merge Changeset: f918d6096e23 Author: never Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f918d6096e23 7050554: JSR 292 - need optimization for selectAlternative Reviewed-by: kvn, jrose ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp Changeset: cba7b5c2d53f Author: never Date: 2011-06-03 22:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cba7b5c2d53f 7045514: SPARC assembly code for JSR 292 ricochet frames Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp + src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/registerMap_sparc.hpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 642c68c75db9 Author: kvn Date: 2011-06-04 10:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/642c68c75db9 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity Summary: Mark all associated (same box and obj) lock and unlock nodes for elimination if some of them marked already. Reviewed-by: iveresov, never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp Changeset: 5cf771a79037 Author: jrose Date: 2011-06-08 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5cf771a79037 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp Reviewed-by: never, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/code/pcDesc.cpp Changeset: c8f2186acf6d Author: twisti Date: 2011-06-14 12:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8f2186acf6d 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops Reviewed-by: iveresov, never ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: f8c9417e3571 Author: never Date: 2011-06-14 14:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f8c9417e3571 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters Reviewed-by: twisti, kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp Changeset: e2ce15aa3daf Author: never Date: 2011-06-14 15:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2ce15aa3daf Merge Changeset: cfcf2ba8f3eb Author: never Date: 2011-06-15 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cfcf2ba8f3eb Merge ! src/share/vm/prims/methodHandleWalk.cpp Changeset: e2af886d540b Author: trims Date: 2011-07-01 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2af886d540b 7061691: Fork HS21 to HS22 - renumber Minor and build numbers of JVM Summary: Update the Minor and Build numbers for HS22 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1e3493ac2d11 Author: ysr Date: 2011-05-27 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e3493ac2d11 7048342: CMS: eob == _limit || fc->isFree() failed: Only a free chunk should allow us to cross over the limit Summary: The freeness bit was being cleared in debug code when it shouldn't have been. Also removed unused FreeChunk methods linkAfterNonNull and clearPrev. Reviewed-by: brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp Changeset: 5c0a3c1858b1 Author: ysr Date: 2011-06-02 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c0a3c1858b1 7048782: CMS: assert(last_chunk_index_to_check<= last_chunk_index) failed: parCardTableModRefBS.cpp:359 Summary: The LNC array is sized before the start of a scavenge, while the heap may expand during a scavenge. With CMS, the last block of an arbitrary suffice of the LNC array may expand due to coalition with the expansion delta. We now take care not to attempt access past the end of the LNC array. LNC array code will be cleaned up and suitably encapsulated as part of the forthcoming performance RFE 7043675. Reviewed-by: brutisso ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp Changeset: e66f38dd58a9 Author: ysr Date: 2011-06-08 08:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e66f38dd58a9 Merge Changeset: 053d84a76d3d Author: tonyp Date: 2011-06-08 15:31 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/053d84a76d3d 7032531: G1: enhance GC logging to include more accurate eden / survivor size transitions Summary: This changeset extends the logging information generated by +PrintGCDetails to also print out separate size transitions for the eden, survivors, and old regions. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: ae5b2f1dcf12 Author: tonyp Date: 2011-06-08 21:48 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae5b2f1dcf12 7045662: G1: OopsInHeapRegionClosure::set_region() should not be virtual Summary: make the method non-virtual, remove five unused closures, and fix a couple of copyright typos. Reviewed-by: stefank, johnc, poonam ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: c3f1170908be Author: tonyp Date: 2011-06-10 13:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3f1170908be 7045330: G1: Simplify/fix the HeapRegionSeq class 7042285: G1: native memory leak during humongous object allocation 6804436: G1: heap region indices should be size_t Summary: A series of fixes and improvements to the HeapRegionSeq class: a) replace the _regions growable array with a standard C array, b) avoid de-allocating / re-allocating HeapRegion instances when the heap shrinks / grows (fix for 7042285), c) introduce fast method to map address to HeapRegion via a "biased" array pointer, d) embed the _hrs object in G1CollectedHeap, instead of pointing to it via an indirection, e) assume that all the regions added to the HeapRegionSeq instance are contiguous, f) replace int's with size_t's for indexes (and expand that to HeapRegion as part of 6804436), g) remove unnecessary / unused methods, h) rename a couple of fields (_alloc_search_start and _seq_bottom), i) fix iterate_from() not to always start from index 0 irrespective of the region passed to it, j) add a verification method to check the HeapRegionSeq assumptions, k) always call the wrappers for _hrs.iterate(), _hrs_length(), and _hrs.at() from G1CollectedHeap, not those methods di rectly, and l) unify the code that expands the sequence (by either re-using or creating a new HeapRegion) and make it robust wrt to a HeapRegion allocation failing. Reviewed-by: stefank, johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp Changeset: 2a241e764894 Author: minqi Date: 2011-06-10 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2a241e764894 6941923: RFE: Handling large log files produced by long running Java Applications Summary: supply optinal flags to realize gc log rotation Reviewed-by: ysr, jwilhelm ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/gc/6941923/test6941923.sh Changeset: 42df21744b50 Author: minqi Date: 2011-06-10 15:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42df21744b50 Merge Changeset: ef2d1b8f2dd4 Author: ysr Date: 2011-06-13 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef2d1b8f2dd4 7051430: CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit Summary: It turns out that there is no need to explicitly stop CMS since the JVM is taken down at a terminal safepoint during which CMS threads are (terminally) inactive. This will need to be revised if and when we evolve in the future to a point where we allow JVM reincarnation in the same process, but those changes will be much more sweeping than just terminating CMS threads. The unused ::stop() methods will be removed in a separate CR. Also include in this CR is the fix for a small typo in the spelling of UseGCLogFileRotation in a message in arguments.cpp, brought to our attention by Rainer Jung and reviewed by minqi. Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 74cd10898bea Author: brutisso Date: 2011-06-13 13:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/74cd10898bea 6918185: Remove unused code for lost card-marking optimization in BacktraceBuilder Summary: Removed dead code Reviewed-by: ysr, coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp Changeset: 842b840e67db Author: tonyp Date: 2011-06-14 10:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/842b840e67db 7046558: G1: concurrent marking optimizations Summary: Some optimizations to improve the concurrent marking phase: specialize the main oop closure, make sure a few methods in the fast path are properly inlined, a few more bits and pieces, and some cosmetic fixes. Reviewed-by: stefank, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp + src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/utilities/bitMap.hpp Changeset: 6747fd0512e0 Author: johnc Date: 2011-06-14 11:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6747fd0512e0 7004681: G1: Extend marking verification to Full GCs Summary: Perform a heap verification after the first phase of G1's full GC using objects' mark words to determine liveness. The third parameter of the heap verification routines, which was used in G1 to determine which marking bitmap to use in liveness calculations, has been changed from a boolean to an enum with values defined for using the mark word, and the 'prev' and 'next' bitmaps. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp Changeset: 5130fa1b24f1 Author: johnc Date: 2011-06-15 10:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5130fa1b24f1 7045751: G1: +ExplicitGCInvokesConcurrent causes excessive single region evacuation pauses Summary: When ExplicitGCInvokesConcurrent is enabled, do not perform an evacuation pause if a marking cycle is already in progress and block the requesting thread until the marking cycle completes. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c9ca3f51cf41 Author: tonyp Date: 2011-06-16 15:51 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9ca3f51cf41 6994322: Remove the is_tlab and is_noref / is_large_noref parameters from the CollectedHeap Summary: Remove two unused parameters from the mem_allocate() method and update its uses accordingly. Reviewed-by: stefank, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/oops/typeArrayKlass.cpp Changeset: f75137faa7fe Author: ysr Date: 2011-06-20 09:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f75137faa7fe 6916968: CMS: freeList.cpp:304 assert(_allocation_stats.prevSweep() + ..., "Conservation Principle") Summary: Fix assert and adjust demand volume computation by adding missing factor. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp Changeset: 23d434c6290d Author: tonyp Date: 2011-06-20 22:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23d434c6290d 7055073: G1: code cleanup in the concurrentMark.* files Summary: Only cosmetic changes to make the concurrentMark.* more consistent, code-style-wise, with the rest of the codebase. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp Changeset: e8b0b0392037 Author: tonyp Date: 2011-06-21 15:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8b0b0392037 7046182: G1: remove unnecessary iterations over the collection set Summary: Remove two unnecessary iterations over the collection set which are supposed to prepare the RSet's of the CSet regions for parallel iterations (we'll make sure this is done incrementally). I'll piggyback on this CR the removal of the G1_REM_SET_LOGGING code. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 5f6f2615433a Author: tonyp Date: 2011-06-24 12:38 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f6f2615433a 7049999: G1: Make the G1PrintHeapRegions output consistent and complete Summary: Extend and make more consistent the output from the G1PrintHeapRegions flag. Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp + src/share/vm/gc_implementation/g1/g1HRPrinter.cpp + src/share/vm/gc_implementation/g1/g1HRPrinter.hpp Changeset: 04760e41b01e Author: brutisso Date: 2011-06-28 14:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04760e41b01e 7016112: CMS: crash during promotion testing Summary: Also reviewed by mikael.gerdin at oracle.com; stdlib:qsort() does byte-by-byte swapping on Windows. This leads to pointer shearing. Fix is to implement a quicksort that does full pointer updates. Reviewed-by: never, coleenp, ysr ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp + src/share/vm/utilities/quickSort.cpp + src/share/vm/utilities/quickSort.hpp Changeset: 4bf3cbef0b3e Author: jcoomes Date: 2011-07-06 08:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4bf3cbef0b3e Merge ! src/share/vm/oops/methodOop.cpp ! src/share/vm/runtime/globals.hpp Changeset: d83ac25d0304 Author: never Date: 2011-06-16 13:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d83ac25d0304 7055355: JSR 292: crash while throwing WrongMethodTypeException Reviewed-by: jrose, twisti, bdelsart ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: aacaff365100 Author: kvn Date: 2011-06-20 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aacaff365100 7052494: Eclipse test fails on JDK 7 b142 Summary: Keep 'ne' test in Counted loop when we can't guarantee during compilation that init < limit. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp + test/compiler/7052494/Test7052494.java Changeset: de6a837d75cf Author: never Date: 2011-06-21 09:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de6a837d75cf 7056380: VM crashes with SIGSEGV in compiled code Summary: code was using andq reg, imm instead of addq addr, imm Reviewed-by: kvn, jrose, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_64.ad Changeset: aabf25fa3f05 Author: never Date: 2011-06-22 14:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aabf25fa3f05 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb Summary: don't skip receiver when GC'ing compiled invokedynamic callsites Reviewed-by: twisti, kvn, jrose ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp Changeset: ddd894528dbc Author: jrose Date: 2011-06-23 17:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ddd894528dbc 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path Reviewed-by: never ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 498c6cf70f7e Author: kvn Date: 2011-06-28 14:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/498c6cf70f7e 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM Summary: parseClassFile() incorrectly uses nonstatic_oop_map_size() method instead of nonstatic_oop_map_count(). Reviewed-by: never Contributed-by: Krystal Mok ! src/share/vm/classfile/classFileParser.cpp Changeset: 6ae7a1561b53 Author: kvn Date: 2011-06-28 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6ae7a1561b53 6990015: Incorrect Icache line size is used for 64 bit x86 Summary: correct Icache::line_size for x64 and add verification code into vm_version_x86. Reviewed-by: never, phh ! src/cpu/x86/vm/icache_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: e3cbc9ddd434 Author: kvn Date: 2011-06-28 15:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3cbc9ddd434 7044738: Loop unroll optimization causes incorrect result Summary: take into account memory dependencies when clonning nodes in clone_up_backedge_goo(). Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp + test/compiler/7044738/Test7044738.java + test/compiler/7046096/Test7046096.java Changeset: 7889bbcc7f88 Author: kvn Date: 2011-06-28 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7889bbcc7f88 7047954: VM crashes with assert(is_Mem()) failed Summary: cast constant array ptrs to bottom Reviewed-by: never ! src/share/vm/opto/compile.cpp Changeset: 6f6e91603a45 Author: iveresov Date: 2011-07-01 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f6e91603a45 7058689: Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods Summary: Take into account current state of profiling before believing that existing higher level versions are valid Reviewed-by: kvn, never ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: 2c359f27615c Author: iveresov Date: 2011-07-01 10:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c359f27615c 7057120: Tiered: Allow C1 to inline methods with loops Summary: Recompile the enclosing methods without inlining of the method that has OSRed to level 4 or recompile the enclosing method at level 4. Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp Changeset: 15559220ce79 Author: never Date: 2011-07-05 16:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15559220ce79 6478991: C1 NullCheckEliminator yields incorrect exceptions Reviewed-by: twisti, iveresov ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/6478991/NullCheckTest.java Changeset: fe240d87c6ec Author: never Date: 2011-07-06 09:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe240d87c6ec 7061101: adlc should complain about mixing block and expression forms of ins_encode Reviewed-by: kvn ! src/share/vm/adlc/adlparse.cpp Changeset: 3e23978ea0c3 Author: never Date: 2011-07-06 18:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3e23978ea0c3 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes Summary: do explicit lookup emulating old LD_LIBRARY_PATH search Reviewed-by: kvn, jrose ! src/share/tools/hsdis/README ! src/share/vm/compiler/disassembler.cpp Changeset: b16582d6c7db Author: kvn Date: 2011-07-07 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b16582d6c7db Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp Changeset: 7d9e451f5416 Author: jcoomes Date: 2011-07-06 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d9e451f5416 7061187: need some includes for arm/ppc Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/atomic.cpp Changeset: eb94b7226b7a Author: jcoomes Date: 2011-07-06 12:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eb94b7226b7a 7061192: option handling adjustments for oracle and embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 65dba8692db7 Author: jcoomes Date: 2011-07-06 12:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65dba8692db7 7061197: ThreadLocalStorage sp map table should be optional Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.hpp Changeset: 48048b59a551 Author: jcoomes Date: 2011-07-06 12:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48048b59a551 7061204: clean the chunk table synchronously in embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: bf6481e5f96d Author: jcoomes Date: 2011-07-06 13:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf6481e5f96d 7061225: os::print_cpu_info() should support os-specific data Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 8a4fc2990229 Author: jcoomes Date: 2011-07-07 15:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a4fc2990229 7053189: remove some unnecessary platform-dependent includes Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp Changeset: b0b8491925fe Author: jcoomes Date: 2011-07-11 14:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b0b8491925fe 7061212: use o/s low memory notification in embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os/linux/vm/os_linux.cpp Changeset: 0defeba52583 Author: jcoomes Date: 2011-07-12 16:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0defeba52583 Merge Changeset: faa472957b38 Author: kvn Date: 2011-07-08 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/faa472957b38 7059034: Use movxtod/movdtox on T4 Summary: Use new VIS3 mov instructions on T4 for move data between general and float registers. Reviewed-by: never, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/runtime/globals.hpp Changeset: 263247c478c5 Author: iveresov Date: 2011-07-08 15:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/263247c478c5 7058510: multinewarray with 6 dimensions uncommon traps in server compiler Summary: Pass arguments to runtime via java array for arrays with > 5 dimensions Reviewed-by: never, kvn, jrose, pbk ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: 1f4f4ae84625 Author: kvn Date: 2011-07-13 10:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f4f4ae84625 Merge ! src/share/vm/runtime/globals.hpp Changeset: 3fbb609d9e96 Author: kvn Date: 2011-07-14 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3fbb609d9e96 7067288: compiler regression test Test7052494 timeouts with client VM Summary: Test is modified to reduce number of iterations in test5() and test6(). Reviewed-by: never, iveresov ! test/compiler/7052494/Test7052494.java Changeset: 341a57af9b0a Author: never Date: 2011-07-15 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/341a57af9b0a 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods Summary: check for single stepping when dispatching invokes from method handles Reviewed-by: coleenp, twisti, kvn, dsamersoff ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp + test/compiler/6990212/Test6990212.java Changeset: 968305b802ee Author: trims Date: 2011-07-23 01:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/968305b802ee Merge Changeset: 8e5d4aa73a8c Author: trims Date: 2011-07-22 23:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8e5d4aa73a8c 7069176: Update the JDK version numbers in Hotspot for JDK 8 Summary: Change JDK_MINOR_VER and JDK_PREVIOUS_VERSION to reflect JDK8 values Reviewed-by: jcoomes ! make/hotspot_version Changeset: 0cc8a70952c3 Author: trims Date: 2011-07-22 23:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0cc8a70952c3 7070061: Adjust Hotspot make/jprt.properties for new JDK8 settings Summary: Fix so the JPRT can build with -release jdk8 now Reviewed-by: ohair ! make/jprt.properties From xuelei.fan at oracle.com Sun Aug 7 20:43:57 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 08 Aug 2011 11:43:57 +0800 Subject: Code review request: 7063647, jsse/runtime, To use synchronized map in key manager Message-ID: <4E3F5B7D.5000209@oracle.com> webrev: http://cr.openjdk.java.net/~xuelei/7063647/webrev.00/ SunX509KeyManagerImpl should be multiple thread safe, need to synchronize cached map: private Map credentialsMap; private Map serverAliasCache; Thanks, Xuelei From alan.bateman at oracle.com Mon Aug 8 05:43:01 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 08 Aug 2011 12:43:01 +0000 Subject: hg: jdk8/tl/jdk: 7076215: (jli) jdk/src/share/bin/jli_util.h should include function prototypes for str functions Message-ID: <20110808124324.2AF9C47A11@hg.openjdk.java.net> Changeset: 94934ebbb654 Author: alanb Date: 2011-08-08 13:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94934ebbb654 7076215: (jli) jdk/src/share/bin/jli_util.h should include function prototypes for str functions Reviewed-by: alanb Contributed-by: neil.richards at ngmr.net ! src/share/bin/jli_util.h From joe.darcy at oracle.com Mon Aug 8 09:08:11 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 08 Aug 2011 16:08:11 +0000 Subject: hg: jdk8/tl/jdk: 6380161: (reflect) Exception from newInstance() not chained to cause. Message-ID: <20110808160821.684DE47A19@hg.openjdk.java.net> Changeset: d4ab25d65adb Author: darcy Date: 2011-08-08 09:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4ab25d65adb 6380161: (reflect) Exception from newInstance() not chained to cause. Reviewed-by: dholmes, lancea, forax ! src/share/classes/java/lang/Class.java From mandy.chung at oracle.com Mon Aug 8 16:28:41 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 08 Aug 2011 23:28:41 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110808232918.C481B47A2D@hg.openjdk.java.net> Changeset: 0f1b4b3bc833 Author: mchung Date: 2011-08-08 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f1b4b3bc833 7036518: TEST_BUG: add cygwin support to test/java/nio/charset/coders/CheckSJISMappingProp.sh 7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh Reviewed-by: sherman ! test/demo/zipfs/basic.sh ! test/java/nio/charset/coders/CheckSJISMappingProp.sh Changeset: 39498fc31d63 Author: mchung Date: 2011-08-08 16:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39498fc31d63 7012365: TEST_BUG: test/java/nio/charset/spi/basic.sh can be run with Cygwin Reviewed-by: darcy ! test/java/nio/charset/spi/basic.sh From bradford.wetmore at oracle.com Mon Aug 8 17:03:26 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 08 Aug 2011 17:03:26 -0700 Subject: Code review request: 7063647, jsse/runtime, To use synchronized map in key manager In-Reply-To: <4E3F5B7D.5000209@oracle.com> References: <4E3F5B7D.5000209@oracle.com> Message-ID: <4E40794E.2050900@oracle.com> Why do you need the "syncronchized (credentialsMap)" at line 344? Aren't all writes done during the constructor init? Otherwise, looks ok. Brad On 8/7/2011 8:43 PM, Xuelei Fan wrote: > webrev: http://cr.openjdk.java.net/~xuelei/7063647/webrev.00/ > > SunX509KeyManagerImpl should be multiple thread safe, need to > synchronize cached map: > private Map credentialsMap; > private Map serverAliasCache; > > Thanks, > Xuelei From xuelei.fan at oracle.com Mon Aug 8 17:58:50 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 09 Aug 2011 08:58:50 +0800 Subject: Code review request: 7063647, jsse/runtime, To use synchronized map in key manager In-Reply-To: <4E40794E.2050900@oracle.com> References: <4E3F5B7D.5000209@oracle.com> <4E40794E.2050900@oracle.com> Message-ID: <4E40864A.4060903@oracle.com> On 8/9/2011 8:03 AM, Brad Wetmore wrote: > Why do you need the "syncronchized (credentialsMap)" at line 344? Aren't > all writes done during the constructor init? > The credentialsMap.entrySet() returns the reference of the backed/internal set, the iteration of the set is not thread safe. The Collections.synchronizedMap specification requires: ------------------ It is imperative that the user manually synchronize on the returned map when iterating over any of its collection views: Map m = Collections.synchronizedMap(new HashMap()); ... Set s = m.keySet(); // Needn't be in synchronized block ... synchronized (m) { // Synchronizing on m, not s! Iterator i = s.iterator(); // Must be in synchronized block while (i.hasNext()) foo(i.next()); } Failure to follow this advice may result in non-deterministic behavior. ------------------ Thanks for the code review. Xuelei > Otherwise, looks ok. > > Brad > > > On 8/7/2011 8:43 PM, Xuelei Fan wrote: >> webrev: http://cr.openjdk.java.net/~xuelei/7063647/webrev.00/ >> >> SunX509KeyManagerImpl should be multiple thread safe, need to >> synchronize cached map: >> private Map credentialsMap; >> private Map serverAliasCache; >> >> Thanks, >> Xuelei From chris.hegarty at oracle.com Tue Aug 9 08:40:42 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 09 Aug 2011 15:40:42 +0000 Subject: hg: jdk8/tl/jdk: 7073295: TEST_BUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win) Message-ID: <20110809154108.32B0647A55@hg.openjdk.java.net> Changeset: 26fe74aa48ef Author: chegar Date: 2011-08-09 16:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26fe74aa48ef 7073295: TEST_BUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win) Reviewed-by: mchung ! test/java/lang/instrument/ManifestTest.sh From chris.hegarty at oracle.com Tue Aug 9 09:00:41 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 09 Aug 2011 16:00:41 +0000 Subject: hg: jdk8/tl/jdk: 7076756: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup in Cygwin Message-ID: <20110809160051.5F3A647A58@hg.openjdk.java.net> Changeset: cf203f293b4e Author: chegar Date: 2011-08-09 16:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf203f293b4e 7076756: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails to cleanup in Cygwin Reviewed-by: alanb, dcubed ! test/com/sun/jdi/ShellScaffold.sh From weijun.wang at oracle.com Wed Aug 10 03:00:32 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Aug 2011 18:00:32 +0800 Subject: code review request: 7076415: sun/security/krb5/runNameEquals.sh failed on sles 10 Message-ID: <4E4256C0.4000709@oracle.com> Hi Valerie/Xuelei Webrev at http://cr.openjdk.java.net/~weijun/7076415/webrev.00/ The test fails when running the native JGSS provider on a sles (SUSE Linux Enterprise Server) machine throwing: Exception in thread "main" GSSException: Invalid name provided (Mechanism level: Hostname cannot be canonicalized) at sun.security.jgss.wrapper.GSSLibStub.importName(Native Method) I've seen this before but cannot find an old CR for it. The method called is gssManager.createName("service at host",...) This "host" is not the name of a real host. On most systems, either hostname canonicalization is not performed, or there is a fallback mechanism, the method does not report any error and the test succeeds. However, on this sles machine, an exception is thrown. I don't have any control on the native GSS's importName method, so I can only try my best to provide a name it can resolve. The only such name I can think of is "localhost". The test currently uses 2 GSSName, "service at host" and "service at host2". Since I can only find one good hostname, I update it to same host with different service names, i.e. "service at localhost" and "service2 at localhost". Hopefully this still matches the purpose of the test. The original author is Xuelei. I can reproduce the failure on the failed machine, and it succeeds after the code change. Just submitted a JPRT job. Thanks Max From xuelei.fan at oracle.com Wed Aug 10 04:24:01 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 10 Aug 2011 19:24:01 +0800 Subject: code review request: 7076415: sun/security/krb5/runNameEquals.sh failed on sles 10 In-Reply-To: <4E4256C0.4000709@oracle.com> References: <4E4256C0.4000709@oracle.com> Message-ID: <4E426A51.3090006@oracle.com> Is it necessary to enable debug log in runNameEquals.sh? Otherwise, looks fine to me. Xuelei On 8/10/2011 6:00 PM, Weijun Wang wrote: > Hi Valerie/Xuelei > > Webrev at http://cr.openjdk.java.net/~weijun/7076415/webrev.00/ > > The test fails when running the native JGSS provider on a sles (SUSE > Linux Enterprise Server) machine throwing: > > Exception in thread "main" GSSException: Invalid name provided > (Mechanism level: Hostname cannot be canonicalized) > at sun.security.jgss.wrapper.GSSLibStub.importName(Native Method) > > I've seen this before but cannot find an old CR for it. The method > called is > > gssManager.createName("service at host",...) > > This "host" is not the name of a real host. On most systems, either > hostname canonicalization is not performed, or there is a fallback > mechanism, the method does not report any error and the test succeeds. > However, on this sles machine, an exception is thrown. > > I don't have any control on the native GSS's importName method, so I can > only try my best to provide a name it can resolve. The only such name I > can think of is "localhost". > > The test currently uses 2 GSSName, "service at host" and "service at host2". > Since I can only find one good hostname, I update it to same host with > different service names, i.e. "service at localhost" and > "service2 at localhost". Hopefully this still matches the purpose of the > test. The original author is Xuelei. > > I can reproduce the failure on the failed machine, and it succeeds after > the code change. > > Just submitted a JPRT job. > > Thanks > Max From weijun.wang at oracle.com Wed Aug 10 04:30:03 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Aug 2011 19:30:03 +0800 Subject: code review request: 7076415: sun/security/krb5/runNameEquals.sh failed on sles 10 In-Reply-To: <4E426A51.3090006@oracle.com> References: <4E4256C0.4000709@oracle.com> <4E426A51.3090006@oracle.com> Message-ID: <4E426BBB.1010300@oracle.com> On 08/10/2011 07:24 PM, Xuelei Fan wrote: > Is it necessary to enable debug log in runNameEquals.sh? Not really, I will remove it. Thanks Max > > Otherwise, looks fine to me. > > Xuelei > > On 8/10/2011 6:00 PM, Weijun Wang wrote: >> Hi Valerie/Xuelei >> >> Webrev at http://cr.openjdk.java.net/~weijun/7076415/webrev.00/ >> >> The test fails when running the native JGSS provider on a sles (SUSE >> Linux Enterprise Server) machine throwing: >> >> Exception in thread "main" GSSException: Invalid name provided >> (Mechanism level: Hostname cannot be canonicalized) >> at sun.security.jgss.wrapper.GSSLibStub.importName(Native Method) >> >> I've seen this before but cannot find an old CR for it. The method >> called is >> >> gssManager.createName("service at host",...) >> >> This "host" is not the name of a real host. On most systems, either >> hostname canonicalization is not performed, or there is a fallback >> mechanism, the method does not report any error and the test succeeds. >> However, on this sles machine, an exception is thrown. >> >> I don't have any control on the native GSS's importName method, so I can >> only try my best to provide a name it can resolve. The only such name I >> can think of is "localhost". >> >> The test currently uses 2 GSSName, "service at host" and "service at host2". >> Since I can only find one good hostname, I update it to same host with >> different service names, i.e. "service at localhost" and >> "service2 at localhost". Hopefully this still matches the purpose of the >> test. The original author is Xuelei. >> >> I can reproduce the failure on the failed machine, and it succeeds after >> the code change. >> >> Just submitted a JPRT job. >> >> Thanks >> Max > From chris.hegarty at oracle.com Wed Aug 10 04:32:02 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 10 Aug 2011 11:32:02 +0000 Subject: hg: jdk8/tl/jdk: 7076523: TEST_BUG: test/java/net/NetworkInterface/NetParamsTest.java can fail with NPE Message-ID: <20110810113223.B96B047A8D@hg.openjdk.java.net> Changeset: af15e902cf08 Author: chegar Date: 2011-08-10 12:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af15e902cf08 7076523: TEST_BUG: test/java/net/NetworkInterface/NetParamsTest.java can fail with NPE Reviewed-by: alanb ! test/java/net/NetworkInterface/NetParamsTest.java From lance.andersen at oracle.com Wed Aug 10 13:25:05 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Wed, 10 Aug 2011 20:25:05 +0000 Subject: hg: jdk8/tl/jdk: 7077451: SerialLob, SerialClob have the wrong checks for setStream methods Message-ID: <20110810202515.3906547AA7@hg.openjdk.java.net> Changeset: 7676670d1e97 Author: lancea Date: 2011-08-10 16:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7676670d1e97 7077451: SerialLob, SerialClob have the wrong checks for setStream methods Reviewed-by: alanb Contributed-by: Patrick Reinhart ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java + test/javax/sql/rowset/serial/SerialBlob/SetBinaryStream.java + test/javax/sql/rowset/serial/SerialClob/SetAsciiStream.java + test/javax/sql/rowset/serial/SerialClob/SetCharacterStream.java From jonathan.gibbons at oracle.com Wed Aug 10 14:09:18 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 10 Aug 2011 21:09:18 +0000 Subject: hg: jdk8/tl/jdk: 7072353: JNDI libraries do not build with javac -Xlint:all -Werror Message-ID: <20110810210928.54A6E47AAC@hg.openjdk.java.net> Changeset: 18329abcdb7c Author: jjg Date: 2011-08-10 13:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18329abcdb7c 7072353: JNDI libraries do not build with javac -Xlint:all -Werror Reviewed-by: xuelei Contributed-by: alexandre.boulgakov at oracle.com ! make/com/sun/jndi/Makefile ! make/javax/others/Makefile ! src/share/classes/com/sun/jndi/cosnaming/CNBindingEnumeration.java ! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java ! src/share/classes/com/sun/jndi/cosnaming/CNNameParser.java ! src/share/classes/com/sun/jndi/cosnaming/ExceptionMapper.java ! src/share/classes/com/sun/jndi/cosnaming/IiopUrl.java ! src/share/classes/com/sun/jndi/dns/DnsClient.java ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/dns/DnsContextFactory.java ! src/share/classes/com/sun/jndi/dns/DnsName.java ! src/share/classes/com/sun/jndi/dns/NameNode.java ! src/share/classes/com/sun/jndi/dns/Resolver.java ! src/share/classes/com/sun/jndi/dns/ResourceRecords.java ! src/share/classes/com/sun/jndi/dns/ZoneNode.java + src/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java ! src/share/classes/com/sun/jndi/ldap/Ber.java ! src/share/classes/com/sun/jndi/ldap/ClientId.java ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/DigestClientId.java ! src/share/classes/com/sun/jndi/ldap/EventQueue.java ! src/share/classes/com/sun/jndi/ldap/EventSupport.java ! src/share/classes/com/sun/jndi/ldap/LdapAttribute.java ! src/share/classes/com/sun/jndi/ldap/LdapBindingEnumeration.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java ! src/share/classes/com/sun/jndi/ldap/LdapEntry.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/ldap/LdapNamingEnumeration.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/jndi/ldap/LdapReferralContext.java ! src/share/classes/com/sun/jndi/ldap/LdapReferralException.java ! src/share/classes/com/sun/jndi/ldap/LdapResult.java ! src/share/classes/com/sun/jndi/ldap/LdapSchemaCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java ! src/share/classes/com/sun/jndi/ldap/LdapSearchEnumeration.java ! src/share/classes/com/sun/jndi/ldap/NamingEventNotifier.java ! src/share/classes/com/sun/jndi/ldap/NotifierArgs.java ! src/share/classes/com/sun/jndi/ldap/Obj.java ! src/share/classes/com/sun/jndi/ldap/ReferralEnumeration.java ! src/share/classes/com/sun/jndi/ldap/ServiceLocator.java ! src/share/classes/com/sun/jndi/ldap/SimpleClientId.java ! src/share/classes/com/sun/jndi/ldap/UnsolicitedResponseImpl.java ! src/share/classes/com/sun/jndi/ldap/VersionHelper.java ! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java ! src/share/classes/com/sun/jndi/ldap/pool/Connections.java ! src/share/classes/com/sun/jndi/ldap/pool/ConnectionsWeakRef.java ! src/share/classes/com/sun/jndi/ldap/pool/Pool.java ! src/share/classes/com/sun/jndi/ldap/pool/PoolCleaner.java ! src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java ! src/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java ! src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java ! src/share/classes/com/sun/jndi/rmi/registry/RegistryContextFactory.java ! src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java ! src/share/classes/com/sun/jndi/toolkit/ctx/AtomicContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/AtomicDirContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/ComponentContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/ComponentDirContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeDirContext.java ! src/share/classes/com/sun/jndi/toolkit/dir/ContainmentFilter.java ! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java ! src/share/classes/com/sun/jndi/toolkit/dir/DirSearch.java ! src/share/classes/com/sun/jndi/toolkit/dir/HierMemDirCtx.java ! src/share/classes/com/sun/jndi/toolkit/dir/LazySearchEnumerationImpl.java ! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java ! src/share/classes/com/sun/jndi/toolkit/url/GenericURLDirContext.java ! src/share/classes/com/sun/jndi/url/dns/dnsURLContext.java ! src/share/classes/com/sun/jndi/url/dns/dnsURLContextFactory.java ! src/share/classes/com/sun/jndi/url/iiop/iiopURLContext.java ! src/share/classes/com/sun/jndi/url/iiop/iiopURLContextFactory.java ! src/share/classes/com/sun/jndi/url/ldap/ldapURLContext.java ! src/share/classes/com/sun/jndi/url/ldap/ldapURLContextFactory.java ! src/share/classes/com/sun/jndi/url/rmi/rmiURLContext.java ! src/share/classes/com/sun/jndi/url/rmi/rmiURLContextFactory.java ! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/share/classes/com/sun/naming/internal/NamedWeakReference.java ! src/share/classes/com/sun/naming/internal/ResourceManager.java ! src/share/classes/com/sun/naming/internal/VersionHelper.java ! src/share/classes/com/sun/naming/internal/VersionHelper12.java ! src/share/classes/javax/naming/CompositeName.java ! src/share/classes/javax/naming/CompoundName.java ! src/share/classes/javax/naming/InitialContext.java ! src/share/classes/javax/naming/NameImpl.java ! src/share/classes/javax/naming/Reference.java ! src/share/classes/javax/naming/directory/BasicAttribute.java ! src/share/classes/javax/naming/directory/BasicAttributes.java ! src/share/classes/javax/naming/ldap/InitialLdapContext.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/naming/ldap/Rfc2253Parser.java ! src/share/classes/javax/naming/ldap/StartTlsRequest.java ! src/share/classes/javax/naming/spi/ContinuationContext.java ! src/share/classes/javax/naming/spi/ContinuationDirContext.java ! src/share/classes/javax/naming/spi/DirectoryManager.java ! src/share/classes/javax/naming/spi/NamingManager.java From alexandre.boulgakov at oracle.com Wed Aug 10 16:07:53 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Wed, 10 Aug 2011 16:07:53 -0700 (PDT) Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror Message-ID: Here's an updated webrev: http://cr.openjdk.java.net/~mduigou/7064075/3/webrev/ I've fixed build warnings in the pkcs11 files (make/sun/security/pkcs11/Makefile and src/share/classes/sun/security/pkcs11/*.java). Please review these changes to pkcs11. (The changes in the other files have already been reviewed in this thread.) I would really appreciate a quick review since my internship is almost over - I am leaving next week - and I wanted to get this changeset in before I leave. Thanks, Sasha On 7/26/2011 10:31 AM, Alexandre Boulgakov wrote: I just noticed that pkcs11 is not built on my machine (64-bit Windows) so I missed all of the warnings there. Thanks, Sasha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20110810/d999d951/attachment.html From xuelei.fan at oracle.com Wed Aug 10 19:51:23 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 11 Aug 2011 10:51:23 +0800 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror In-Reply-To: References: Message-ID: <4E4343AB.4060608@oracle.com> On 8/11/2011 7:07 AM, Alexandre Boulgakov wrote: > Here's an updated webrev: > http://cr.openjdk.java.net/~mduigou/7064075/3/webrev/ > > I've fixed build warnings in the pkcs11 files > (make/sun/security/pkcs11/Makefile and > src/share/classes/sun/security/pkcs11/*.java). > > Please review these changes to pkcs11. (The changes in the other files > have already been reviewed in this thread.) > I only looked at PKCS11 changes this time. Looks fine to me. Thanks, Xuelei > I would really appreciate a quick review since my internship is almost > over - I am leaving next week - and I wanted to get this changeset in > before I leave. > > Thanks, > Sasha > > On 7/26/2011 10:31 AM, Alexandre Boulgakov wrote: > > I just noticed that pkcs11 is not built on my machine (64-bit > Windows) so I missed all of the warnings there. > > Thanks, > Sasha From sean.coffey at oracle.com Thu Aug 11 04:41:36 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 11 Aug 2011 11:41:36 +0000 Subject: hg: jdk8/tl/jdk: 7047325: Internal API to improve management of direct buffers Message-ID: <20110811114200.656D047ACD@hg.openjdk.java.net> Changeset: ddcb874581eb Author: coffeys Date: 2011-08-11 12:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddcb874581eb 7047325: Internal API to improve management of direct buffers Reviewed-by: alanb, mduigou ! make/com/oracle/Makefile - make/com/oracle/net/Makefile ! make/common/Release.gmk ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/sun/misc/JavaNioAccess.java ! src/share/classes/sun/nio/ch/DirectBuffer.java From jonathan.gibbons at oracle.com Thu Aug 11 13:45:18 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 11 Aug 2011 20:45:18 +0000 Subject: hg: jdk8/tl/jdk: 7077672: jdk8_tl nightly fail in step-2 build on 8/10/11 Message-ID: <20110811204536.D221847AE7@hg.openjdk.java.net> Changeset: 79bd5691d85f Author: jjg Date: 2011-08-11 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79bd5691d85f 7077672: jdk8_tl nightly fail in step-2 build on 8/10/11 Reviewed-by: mchung, jjg Contributed-by: alexandre.boulgakov at oracle.com ! src/share/classes/com/sun/jndi/ldap/Obj.java ! src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java From xuelei.fan at oracle.com Thu Aug 11 18:24:03 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 12 Aug 2011 09:24:03 +0800 Subject: Code review request: 7063647, jsse/runtime, To use synchronized map in key manager In-Reply-To: <4E40864A.4060903@oracle.com> References: <4E3F5B7D.5000209@oracle.com> <4E40794E.2050900@oracle.com> <4E40864A.4060903@oracle.com> Message-ID: <4E4480B3.3050008@oracle.com> Since the all writes done during the constructor, we don't need to use synchronized map for credentialsMap. The HashMap.iterator() is thread-safe for read-only HashMap. new webrev: http://cr.openjdk.java.net/~xuelei/7063647/webrev.01/ Xuelei On 8/9/2011 8:58 AM, Xuelei Fan wrote: > On 8/9/2011 8:03 AM, Brad Wetmore wrote: >> Why do you need the "syncronchized (credentialsMap)" at line 344? Aren't >> all writes done during the constructor init? >> > The credentialsMap.entrySet() returns the reference of the > backed/internal set, the iteration of the set is not thread safe. The > Collections.synchronizedMap specification requires: > ------------------ > It is imperative that the user manually synchronize on the returned map > when iterating over any of its collection views: > > Map m = Collections.synchronizedMap(new HashMap()); > ... > Set s = m.keySet(); // Needn't be in synchronized block > ... > synchronized (m) { // Synchronizing on m, not s! > Iterator i = s.iterator(); // Must be in synchronized block > while (i.hasNext()) > foo(i.next()); > } > > > Failure to follow this advice may result in non-deterministic behavior. > ------------------ > > Thanks for the code review. > > Xuelei > >> Otherwise, looks ok. >> >> Brad >> >> >> On 8/7/2011 8:43 PM, Xuelei Fan wrote: >>> webrev: http://cr.openjdk.java.net/~xuelei/7063647/webrev.00/ >>> >>> SunX509KeyManagerImpl should be multiple thread safe, need to >>> synchronize cached map: >>> private Map credentialsMap; >>> private Map serverAliasCache; >>> >>> Thanks, >>> Xuelei > From weijun.wang at oracle.com Thu Aug 11 20:23:51 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 12 Aug 2011 03:23:51 +0000 Subject: hg: jdk8/tl/jdk: 7076415: sun/security/krb5/runNameEquals.sh failed on sles 10 Message-ID: <20110812032401.2A32D47AFA@hg.openjdk.java.net> Changeset: 4574445f35ac Author: weijun Date: 2011-08-12 11:20 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4574445f35ac 7076415: sun/security/krb5/runNameEquals.sh failed on sles 10 Reviewed-by: xuelei ! test/sun/security/krb5/Krb5NameEquals.java From weijun.wang at oracle.com Thu Aug 11 21:27:31 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 12 Aug 2011 04:27:31 +0000 Subject: hg: jdk8/tl/jdk: 7055363: jdk_security3 test target cleanup Message-ID: <20110812042741.0F97947AFD@hg.openjdk.java.net> Changeset: cb83fe13af98 Author: weijun Date: 2011-08-12 12:26 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb83fe13af98 7055363: jdk_security3 test target cleanup Reviewed-by: alanb, xuelei ! test/Makefile ! test/ProblemList.txt ! test/com/sun/security/auth/login/ConfigFile/IllegalURL.java + test/java/security/testlibrary/Providers.java ! test/javax/security/auth/login/LoginContext/ResetConfigModule.java ! test/sun/security/ec/TestEC.java ! test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java ! test/sun/security/pkcs11/PKCS11Test.java ! test/sun/security/pkcs11/Secmod/AddPrivateKey.java ! test/sun/security/pkcs11/Secmod/AddTrustedCert.java ! test/sun/security/pkcs11/Secmod/Crypto.java ! test/sun/security/pkcs11/Secmod/GetPrivateKey.java ! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java ! test/sun/security/pkcs11/Secmod/TrustAnchors.java ! test/sun/security/pkcs11/SecmodTest.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDSA.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java ! test/sun/security/pkcs11/fips/TrustManagerTest.java ! test/sun/security/pkcs11/rsa/TestCACerts.java ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/provider/PolicyFile/Comparator.java ! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/ClientHelloRead.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ProtocolVersion/HttpsProtocols.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyAuthTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ServerIdentityTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java ! test/sun/security/ssl/javax/net/ssl/Fix5070632.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ComURLNulls.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/JavaxURLNulls.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/KeyManagerTrustManager.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java ! test/sun/security/ssl/javax/net/ssl/SSLServerSocket/DefaultSSLServSocketFac.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java ! test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java ! test/sun/security/ssl/sanity/pluggability/CheckSockFacExport1.java ! test/sun/security/ssl/sanity/pluggability/CheckSockFacExport2.java ! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/RetryHttps.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHTTPSConnection.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java ! test/sun/security/ssl/templates/SSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java From weijun.wang at oracle.com Fri Aug 12 06:05:21 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 12 Aug 2011 13:05:21 +0000 Subject: hg: jdk8/tl/jdk: 7078355: sun/net/www/protocol/file/DirPermissionDenied.sh leaves garbage on some linux systems Message-ID: <20110812130539.86C6547B18@hg.openjdk.java.net> Changeset: e533c13df9ad Author: weijun Date: 2011-08-12 21:04 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e533c13df9ad 7078355: sun/net/www/protocol/file/DirPermissionDenied.sh leaves garbage on some linux systems Reviewed-by: chegar ! test/sun/net/www/protocol/file/DirPermissionDenied.sh From joe.darcy at oracle.com Fri Aug 12 13:37:51 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 12 Aug 2011 20:37:51 +0000 Subject: hg: jdk8/tl/jdk: 4900206: Include worst-case rounding tests for Math library functions Message-ID: <20110812203812.09B1647B2A@hg.openjdk.java.net> Changeset: 8f962aca221e Author: darcy Date: 2011-08-12 13:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f962aca221e 4900206: Include worst-case rounding tests for Math library functions Reviewed-by: alanb ! test/java/lang/Math/Tests.java + test/java/lang/Math/WorstCaseTests.java From stuart.marks at oracle.com Fri Aug 12 14:55:03 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 12 Aug 2011 21:55:03 +0000 Subject: hg: jdk8/tl/jdk: 7076526: add test MemoryMXBean/CollectionUsageThreshold to the problem list Message-ID: <20110812215514.64F1347B2F@hg.openjdk.java.net> Changeset: 3f66f9ca1ba5 Author: smarks Date: 2011-08-12 14:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f66f9ca1ba5 7076526: add test MemoryMXBean/CollectionUsageThreshold to the problem list Reviewed-by: weijun, alanb ! test/ProblemList.txt From weijun.wang at oracle.com Sat Aug 13 04:36:31 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 13 Aug 2011 19:36:31 +0800 Subject: code review request: 7078816: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure Message-ID: <4E4661BF.9090900@oracle.com> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078816 webrev: http://cr.openjdk.java.net/~weijun/7078816/webrev.00/ Description: The test calls javac to compile a java source file, but the class's parent class is not in the same directory, and compilation fails. The SecretKeysBasic class is a sub class of PKCS11Test which is in another directory, and javac has not included that directory into classpath. I also remove the version check of Solaris OS into the initial uname check, otherwise, if token "nss" already fails but token "solaris" finds version not matched, it will exit 0. I also open up the test to all OSes. Two questions: 1. Is it really necessary to define $CP to be /bin/cp on Solaris/Linux and /usr/bin/cp on Cygwin? 2. For Solaris. there is case "${OS_VERSION}" in 5.1* ) SOFTTOKEN_DIR=${TESTCLASSES} export SOFTTOKEN_DIR TOKENS="nss solaris" ;; * ) Where is this $SOFTTOKEN_DIR used? Is it necessary? I didn't find reference to it in either test or source. *Alan*: Can you try this fix on your solaris-x64 machine where the original test failed? Thanks Max From Alan.Bateman at oracle.com Sat Aug 13 09:42:55 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 13 Aug 2011 17:42:55 +0100 Subject: code review request: 7078816: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure In-Reply-To: <4E4661BF.9090900@oracle.com> References: <4E4661BF.9090900@oracle.com> Message-ID: <4E46A98F.1090202@oracle.com> Weijun Wang wrote: > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078816 > webrev: http://cr.openjdk.java.net/~weijun/7078816/webrev.00/ > > Description: > The test calls javac to compile a java source file, but the class's > parent class is not in the same directory, and compilation fails. > > The SecretKeysBasic class is a sub class of PKCS11Test which is in > another directory, and javac has not included that directory into > classpath. > > I also remove the version check of Solaris OS into the initial uname > check, otherwise, if token "nss" already fails but token "solaris" > finds version not matched, it will exit 0. > > I also open up the test to all OSes. > > Two questions: > > 1. Is it really necessary to define $CP to be /bin/cp on Solaris/Linux > and /usr/bin/cp on Cygwin? > > 2. For Solaris. there is > > case "${OS_VERSION}" in > 5.1* ) > SOFTTOKEN_DIR=${TESTCLASSES} > export SOFTTOKEN_DIR > TOKENS="nss solaris" > ;; > * ) > > Where is this $SOFTTOKEN_DIR used? Is it necessary? I didn't find > reference to it in either test or source. > > *Alan*: Can you try this fix on your solaris-x64 machine where the > original test failed? I grabbed the patch from your webrev and the tests is now passing for me - thanks. I can't say if SOFTTOKEN_DIR is needed or not but it looks like it is used by pkcs11_softtoken.so. One thing I see in the test is that TESTJAVA is no longer set when running interactively. I guess you could default it to "java" so that it runs the JDK on the PATH. Alternatively the test could fail if not set (there are examples of both approaches in the test tree). -Alan. From weijun.wang at oracle.com Sun Aug 14 04:21:16 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 14 Aug 2011 19:21:16 +0800 Subject: code review request: 7078816: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure In-Reply-To: <4E46A98F.1090202@oracle.com> References: <4E4661BF.9090900@oracle.com> <4E46A98F.1090202@oracle.com> Message-ID: <4E47AFAC.2080209@oracle.com> On 08/14/2011 12:42 AM, Alan Bateman wrote: > Weijun Wang wrote: >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078816 >> webrev: http://cr.openjdk.java.net/~weijun/7078816/webrev.00/ >> >> Description: >> The test calls javac to compile a java source file, but the class's >> parent class is not in the same directory, and compilation fails. >> >> The SecretKeysBasic class is a sub class of PKCS11Test which is in >> another directory, and javac has not included that directory into >> classpath. >> >> I also remove the version check of Solaris OS into the initial uname >> check, otherwise, if token "nss" already fails but token "solaris" >> finds version not matched, it will exit 0. >> >> I also open up the test to all OSes. >> >> Two questions: >> >> 1. Is it really necessary to define $CP to be /bin/cp on Solaris/Linux >> and /usr/bin/cp on Cygwin? >> >> 2. For Solaris. there is >> >> case "${OS_VERSION}" in >> 5.1* ) >> SOFTTOKEN_DIR=${TESTCLASSES} >> export SOFTTOKEN_DIR >> TOKENS="nss solaris" >> ;; >> * ) >> >> Where is this $SOFTTOKEN_DIR used? Is it necessary? I didn't find >> reference to it in either test or source. >> >> *Alan*: Can you try this fix on your solaris-x64 machine where the >> original test failed? > I grabbed the patch from your webrev and the tests is now passing for me > - thanks. > > I can't say if SOFTTOKEN_DIR is needed or not but it looks like it is > used by pkcs11_softtoken.so. I believe so. Googling the word shows some doc on it. > > One thing I see in the test is that TESTJAVA is no longer set when > running interactively. I guess you could default it to "java" so that it > runs the JDK on the PATH. Alternatively the test could fail if not set > (there are examples of both approaches in the test tree). I normally use if [ "${TESTJAVA}" = "" ] ; then JAVAC_CMD=`which javac` TESTJAVA=`dirname $JAVAC_CMD`/.. fi to find out the default JDK. Is this OK? Thanks Max > > -Alan. > > > From Alan.Bateman at oracle.com Sun Aug 14 12:23:17 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 14 Aug 2011 20:23:17 +0100 Subject: code review request: 7078816: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure In-Reply-To: <4E47AFAC.2080209@oracle.com> References: <4E4661BF.9090900@oracle.com> <4E46A98F.1090202@oracle.com> <4E47AFAC.2080209@oracle.com> Message-ID: <4E4820A5.4080208@oracle.com> Weijun Wang wrote: > > I normally use > > if [ "${TESTJAVA}" = "" ] ; then > JAVAC_CMD=`which javac` > TESTJAVA=`dirname $JAVAC_CMD`/.. > fi > > to find out the default JDK. Is this OK? Seems reasonable to me. -Alan. From weijun.wang at oracle.com Sun Aug 14 19:40:38 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 15 Aug 2011 10:40:38 +0800 Subject: Fwd: CR 7079144 Created, P4 java/classes_secu concise_jarsigner.sh test often fails on solaris Message-ID: <4E488726.7000600@oracle.com> Hi Xuelei Can you take a look at this small fix? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7079144 7079144: concise_jarsigner.sh test often fails on solaris Webrev: http://cr.openjdk.java.net/~weijun/7079144/webrev.00/ Description: concise_jarsigner.sh calls keytool -genkeypair a lot, and due to a known DSA bug on solaris, it's quite likely to fail. Since the test can work with any keypair generator algorithm, we can use another keyalg instead of the default DSA. I change the DSA -keyalg to RSA, and to make the test run faster, choose -keysize as 512. It passes JPRT run on all product platforms. Thanks Max From weijun.wang at oracle.com Sun Aug 14 19:43:29 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 15 Aug 2011 02:43:29 +0000 Subject: hg: jdk8/tl/jdk: 7078816: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure Message-ID: <20110815024347.3805347BA1@hg.openjdk.java.net> Changeset: b759d1a55cd4 Author: weijun Date: 2011-08-15 10:42 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b759d1a55cd4 7078816: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure Reviewed-by: alanb ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh From xuelei.fan at oracle.com Sun Aug 14 20:06:51 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 15 Aug 2011 11:06:51 +0800 Subject: Fwd: CR 7079144 Created, P4 java/classes_secu concise_jarsigner.sh test often fails on solaris In-Reply-To: <4E488726.7000600@oracle.com> References: <4E488726.7000600@oracle.com> Message-ID: <4E488D4B.7030305@oracle.com> Looks fine. I would suggest you add a comment about the keysize, so that when the keysize is not available (for example, disabled by default), we don't need to hesitate to update it to 1024 or more. Thanks, Xuelei On 8/15/2011 10:40 AM, Weijun Wang wrote: > Hi Xuelei > > Can you take a look at this small fix? > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7079144 > 7079144: concise_jarsigner.sh test often fails on solaris > > Webrev: http://cr.openjdk.java.net/~weijun/7079144/webrev.00/ > > Description: > > concise_jarsigner.sh calls keytool -genkeypair a lot, and due to > a known DSA bug on solaris, it's quite likely to fail. Since the > test can work with any keypair generator algorithm, we can use > another keyalg instead of the default DSA. > > I change the DSA -keyalg to RSA, and to make the test run faster, choose > -keysize as 512. > > It passes JPRT run on all product platforms. > > Thanks > Max > From weijun.wang at oracle.com Sun Aug 14 20:28:54 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 15 Aug 2011 11:28:54 +0800 Subject: Fwd: Re: Code review request: 7063647, jsse/runtime, To use synchronized map in key manager In-Reply-To: <4E488DCD.1060600@oracle.com> References: <4E4480B3.3050008@oracle.com> <4E471B80.6030509@oracle.com> <4E4885F4.2080809@oracle.com> <4E488C4A.9060809@oracle.com> <4E488DCD.1060600@oracle.com> Message-ID: <4E489276.20406@oracle.com> So you mean you don't really care if the serverAliasCache.put(*,*) method would be executed twice for the same keyType, because the value will always be the same and there will be no harm made. Right? If so, I'm fine with the code change. [ I add CC back, otherwise no one can prove you get a yes for the code review ] -Max On 08/15/2011 11:09 AM, Xuelei Fan wrote: > On 8/15/2011 11:02 AM, Xuelei Fan wrote: >> On 8/15/2011 10:35 AM, Weijun Wang wrote: >>> I'm not sure what action on serverAliasCache you want to protect. >>> >>> For example, >>> >>> 260 aliases = serverAliasCache.get(keyType); >>> 261 if (aliases == null) { >>> 262 aliases = getServerAliases(keyType, issuers); >>> 263 // Cache the result (positive and negative lookups) >>> 264 if (aliases == null) { >>> 265 aliases = STRING0; >>> 266 } >>> 267 serverAliasCache.put(keyType, aliases); >>> 268 } >>> >>> Here it's still possible that two threads run at the same time and both >>> going into lines 262. Is this what you want to see? >>> >> Not exactly, I want to ensure that when one thread works on line 260, >> another thread does not work on 267. >> > The logic of line 262 is a little strange that it will always return the > same value. So I don't worried about it. > > Andrew > >> Thanks, >> Andrew >> >>> Thanks >>> Max >>> >>> >>> On 08/14/2011 08:49 AM, Xuelei Fan wrote: >>>> Max, >>>> >>>> Are you available to review this simple fix? >>>> >>>> Thanks, >>>> Andrew >>>> >>>> -------- Original Message -------- >>>> Subject: Re: Code review request: 7063647, jsse/runtime, To use >>>> synchronized map in key manager >>>> Date: Fri, 12 Aug 2011 09:24:03 +0800 >>>> From: Xuelei Fan >>>> To: Brad Wetmore >>>> CC: OpenJDK >>>> >>>> Since the all writes done during the constructor, we don't need to use >>>> synchronized map for credentialsMap. The HashMap.iterator() is >>>> thread-safe for read-only HashMap. >>>> >>>> new webrev: http://cr.openjdk.java.net/~xuelei/7063647/webrev.01/ >>>> >>>> Xuelei >>>> >>>> On 8/9/2011 8:58 AM, Xuelei Fan wrote: >>>>> On 8/9/2011 8:03 AM, Brad Wetmore wrote: >>>>>> Why do you need the "syncronchized (credentialsMap)" at line 344? >>>>>> Aren't >>>>>> all writes done during the constructor init? >>>>>> >>>>> The credentialsMap.entrySet() returns the reference of the >>>>> backed/internal set, the iteration of the set is not thread safe. The >>>>> Collections.synchronizedMap specification requires: >>>>> ------------------ >>>>> It is imperative that the user manually synchronize on the returned map >>>>> when iterating over any of its collection views: >>>>> >>>>> Map m = Collections.synchronizedMap(new HashMap()); >>>>> ... >>>>> Set s = m.keySet(); // Needn't be in synchronized block >>>>> ... >>>>> synchronized (m) { // Synchronizing on m, not s! >>>>> Iterator i = s.iterator(); // Must be in synchronized block >>>>> while (i.hasNext()) >>>>> foo(i.next()); >>>>> } >>>>> >>>>> >>>>> Failure to follow this advice may result in non-deterministic behavior. >>>>> ------------------ >>>>> >>>>> Thanks for the code review. >>>>> >>>>> Xuelei >>>>> >>>>>> Otherwise, looks ok. >>>>>> >>>>>> Brad >>>>>> >>>>>> >>>>>> On 8/7/2011 8:43 PM, Xuelei Fan wrote: >>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7063647/webrev.00/ >>>>>>> >>>>>>> SunX509KeyManagerImpl should be multiple thread safe, need to >>>>>>> synchronize cached map: >>>>>>> private Map credentialsMap; >>>>>>> private Map serverAliasCache; >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>> >>>> >> > From xuelei.fan at oracle.com Sun Aug 14 20:32:28 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 15 Aug 2011 11:32:28 +0800 Subject: Fwd: Re: Code review request: 7063647, jsse/runtime, To use synchronized map in key manager In-Reply-To: <4E489276.20406@oracle.com> References: <4E4480B3.3050008@oracle.com> <4E471B80.6030509@oracle.com> <4E4885F4.2080809@oracle.com> <4E488C4A.9060809@oracle.com> <4E488DCD.1060600@oracle.com> <4E489276.20406@oracle.com> Message-ID: <4E48934C.2050409@oracle.com> On 8/15/2011 11:28 AM, Weijun Wang wrote: > So you mean you don't really care if the serverAliasCache.put(*,*) > method would be executed twice for the same keyType, because the value > will always be the same and there will be no harm made. Right? > Yes. I don't want to synchronize the get/put block because of performance and potential deadlock issues. Once the alias is out into the cache, line 262~267 will not be executed any more. > If so, I'm fine with the code change. > Thanks for the code review. Xuelei (Andrew) > [ I add CC back, otherwise no one can prove you get a yes for the code > review ] > > -Max > > > On 08/15/2011 11:09 AM, Xuelei Fan wrote: >> On 8/15/2011 11:02 AM, Xuelei Fan wrote: >>> On 8/15/2011 10:35 AM, Weijun Wang wrote: >>>> I'm not sure what action on serverAliasCache you want to protect. >>>> >>>> For example, >>>> >>>> 260 aliases = serverAliasCache.get(keyType); >>>> 261 if (aliases == null) { >>>> 262 aliases = getServerAliases(keyType, issuers); >>>> 263 // Cache the result (positive and negative >>>> lookups) >>>> 264 if (aliases == null) { >>>> 265 aliases = STRING0; >>>> 266 } >>>> 267 serverAliasCache.put(keyType, aliases); >>>> 268 } >>>> >>>> Here it's still possible that two threads run at the same time and both >>>> going into lines 262. Is this what you want to see? >>>> >>> Not exactly, I want to ensure that when one thread works on line 260, >>> another thread does not work on 267. >>> >> The logic of line 262 is a little strange that it will always return the >> same value. So I don't worried about it. >> >> Andrew >> >>> Thanks, >>> Andrew >>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 08/14/2011 08:49 AM, Xuelei Fan wrote: >>>>> Max, >>>>> >>>>> Are you available to review this simple fix? >>>>> >>>>> Thanks, >>>>> Andrew >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: Code review request: 7063647, jsse/runtime, To use >>>>> synchronized map in key manager >>>>> Date: Fri, 12 Aug 2011 09:24:03 +0800 >>>>> From: Xuelei Fan >>>>> To: Brad Wetmore >>>>> CC: OpenJDK >>>>> >>>>> Since the all writes done during the constructor, we don't need to use >>>>> synchronized map for credentialsMap. The HashMap.iterator() is >>>>> thread-safe for read-only HashMap. >>>>> >>>>> new webrev: http://cr.openjdk.java.net/~xuelei/7063647/webrev.01/ >>>>> >>>>> Xuelei >>>>> >>>>> On 8/9/2011 8:58 AM, Xuelei Fan wrote: >>>>>> On 8/9/2011 8:03 AM, Brad Wetmore wrote: >>>>>>> Why do you need the "syncronchized (credentialsMap)" at line 344? >>>>>>> Aren't >>>>>>> all writes done during the constructor init? >>>>>>> >>>>>> The credentialsMap.entrySet() returns the reference of the >>>>>> backed/internal set, the iteration of the set is not thread safe. The >>>>>> Collections.synchronizedMap specification requires: >>>>>> ------------------ >>>>>> It is imperative that the user manually synchronize on the >>>>>> returned map >>>>>> when iterating over any of its collection views: >>>>>> >>>>>> Map m = Collections.synchronizedMap(new HashMap()); >>>>>> ... >>>>>> Set s = m.keySet(); // Needn't be in synchronized block >>>>>> ... >>>>>> synchronized (m) { // Synchronizing on m, not s! >>>>>> Iterator i = s.iterator(); // Must be in synchronized block >>>>>> while (i.hasNext()) >>>>>> foo(i.next()); >>>>>> } >>>>>> >>>>>> >>>>>> Failure to follow this advice may result in non-deterministic >>>>>> behavior. >>>>>> ------------------ >>>>>> >>>>>> Thanks for the code review. >>>>>> >>>>>> Xuelei >>>>>> >>>>>>> Otherwise, looks ok. >>>>>>> >>>>>>> Brad >>>>>>> >>>>>>> >>>>>>> On 8/7/2011 8:43 PM, Xuelei Fan wrote: >>>>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7063647/webrev.00/ >>>>>>>> >>>>>>>> SunX509KeyManagerImpl should be multiple thread safe, need to >>>>>>>> synchronize cached map: >>>>>>>> private Map credentialsMap; >>>>>>>> private Map serverAliasCache; >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>> >>>>> >>> >> From weijun.wang at oracle.com Sun Aug 14 20:43:39 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 15 Aug 2011 03:43:39 +0000 Subject: hg: jdk8/tl/jdk: 7079144: concise_jarsigner.sh test often fails on solaris Message-ID: <20110815034349.2E59D47BA4@hg.openjdk.java.net> Changeset: 4af32446555d Author: weijun Date: 2011-08-15 11:43 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4af32446555d 7079144: concise_jarsigner.sh test often fails on solaris Reviewed-by: xuelei ! test/sun/security/tools/jarsigner/concise_jarsigner.sh From xuelei.fan at oracle.com Mon Aug 15 00:31:16 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 15 Aug 2011 07:31:16 +0000 Subject: hg: jdk8/tl/jdk: 7063647: To use synchronized map in key manager Message-ID: <20110815073126.0CF0E47BAD@hg.openjdk.java.net> Changeset: b07cf6cbb62a Author: xuelei Date: 2011-08-15 00:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b07cf6cbb62a 7063647: To use synchronized map in key manager Reviewed-by: wetmore, weijun ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java From joe.darcy at oracle.com Mon Aug 15 12:57:23 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 15 Aug 2011 19:57:23 +0000 Subject: hg: jdk8/tl/jdk: 4850225: Integer.getInteger() : Bad reference to getProperty? Message-ID: <20110815195733.4E65947BCD@hg.openjdk.java.net> Changeset: 6e9ed747d0ca Author: darcy Date: 2011-08-15 12:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e9ed747d0ca 4850225: Integer.getInteger() : Bad reference to getProperty? Reviewed-by: lancea ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java From jonathan.gibbons at oracle.com Mon Aug 15 14:31:35 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 15 Aug 2011 21:31:35 +0000 Subject: hg: jdk8/tl/jdk: 7064075: Security libraries don't build with javac -Xlint:all, -deprecation -Werror Message-ID: <20110815213145.F2CA047BD5@hg.openjdk.java.net> Changeset: afb6f2370cd3 Author: jjg Date: 2011-08-15 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/afb6f2370cd3 7064075: Security libraries don't build with javac -Xlint:all,-deprecation -Werror Reviewed-by: xuelei, mullan Contributed-by: alexandre.boulgakov at oracle.com ! make/com/sun/crypto/provider/Makefile ! make/com/sun/security/Makefile ! make/java/security/Makefile ! make/javax/crypto/Makefile ! make/sun/security/Makefile ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! make/sun/security/pkcs11/Makefile ! src/share/classes/com/sun/crypto/provider/AESCrypt.java ! src/share/classes/com/sun/crypto/provider/AESParameters.java ! src/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java ! src/share/classes/com/sun/crypto/provider/BlowfishParameters.java ! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESCrypt.java ! src/share/classes/com/sun/crypto/provider/DESKey.java ! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESParameters.java ! src/share/classes/com/sun/crypto/provider/DESedeKey.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESedeParameters.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/DHParameters.java ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/com/sun/crypto/provider/DHPublicKey.java ! src/share/classes/com/sun/crypto/provider/EncryptedPrivateKeyInfo.java ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBEKey.java ! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/share/classes/com/sun/crypto/provider/PBEParameters.java ! src/share/classes/com/sun/crypto/provider/PBKDF2HmacSHA1Factory.java ! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java ! src/share/classes/com/sun/crypto/provider/PCBC.java ! src/share/classes/com/sun/crypto/provider/RC2Cipher.java ! src/share/classes/com/sun/crypto/provider/RC2Parameters.java ! src/share/classes/com/sun/crypto/provider/RSACipher.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/SubjectCodeSource.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java ! src/share/classes/com/sun/security/ntlm/NTLMException.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/com/sun/security/sasl/util/PolicyUtils.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/UnresolvedPermissionCollection.java ! src/share/classes/java/security/cert/CertificateRevokedException.java ! src/share/classes/java/security/cert/X509CRLSelector.java ! src/share/classes/java/security/cert/X509CertSelector.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CryptoAllPermission.java ! src/share/classes/javax/crypto/CryptoPermission.java ! src/share/classes/javax/crypto/CryptoPermissions.java ! src/share/classes/javax/crypto/CryptoPolicyParser.java ! src/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java ! src/share/classes/javax/crypto/JarVerifier.java ! src/share/classes/javax/crypto/JceSecurity.java ! src/share/classes/javax/crypto/JceSecurityManager.java ! src/share/classes/javax/crypto/KeyAgreement.java ! src/share/classes/javax/crypto/KeyGenerator.java ! src/share/classes/javax/crypto/Mac.java ! src/share/classes/javax/crypto/SealedObject.java ! src/share/classes/javax/crypto/SecretKeyFactory.java ! src/share/classes/javax/crypto/SecretKeyFactorySpi.java ! src/share/classes/javax/crypto/spec/DESKeySpec.java ! src/share/classes/javax/crypto/spec/DESedeKeySpec.java ! src/share/classes/javax/crypto/spec/IvParameterSpec.java ! src/share/classes/javax/crypto/spec/PBEKeySpec.java ! src/share/classes/javax/crypto/spec/PBEParameterSpec.java ! src/share/classes/javax/crypto/spec/PSource.java ! src/share/classes/javax/crypto/spec/RC2ParameterSpec.java ! src/share/classes/javax/crypto/spec/RC5ParameterSpec.java ! src/share/classes/javax/crypto/spec/SecretKeySpec.java ! src/share/classes/sun/security/acl/AclEntryImpl.java ! src/share/classes/sun/security/action/PutAllAction.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyFactory.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/jca/GetInstance.java ! src/share/classes/sun/security/jca/ProviderList.java ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/jgss/GSSUtil.java ! src/share/classes/sun/security/jgss/krb5/CipherHelper.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/krb5/MessageToken.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/wrapper/NativeGSSFactory.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/classes/sun/security/krb5/Checksum.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KrbServiceLocator.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/pkcs/ContentInfo.java ! src/share/classes/sun/security/pkcs/PKCS10.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/PKCS8Key.java ! src/share/classes/sun/security/pkcs/PKCS9Attribute.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyFactory.java ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java ! src/share/classes/sun/security/pkcs11/P11Util.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/classes/sun/security/pkcs11/wrapper/Functions.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11RuntimeException.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/provider/DSAKeyFactory.java ! src/share/classes/sun/security/provider/DSAParameters.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/certpath/AdaptableX509CertSelector.java ! src/share/classes/sun/security/provider/certpath/Builder.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/IndexedCollectionCertStore.java ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/PolicyChecker.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/Vertex.java ! src/share/classes/sun/security/provider/certpath/X509CertPath.java ! src/share/classes/sun/security/rsa/RSAKeyFactory.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/timestamp/HttpTimestamper.java ! src/share/classes/sun/security/timestamp/TSResponse.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/util/Cache.java ! src/share/classes/sun/security/util/ManifestDigester.java ! src/share/classes/sun/security/util/Password.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/x509/AVA.java ! src/share/classes/sun/security/x509/AccessDescription.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/share/classes/sun/security/x509/AuthorityInfoAccessExtension.java ! src/share/classes/sun/security/x509/CRLDistributionPointsExtension.java ! src/share/classes/sun/security/x509/CRLExtensions.java ! src/share/classes/sun/security/x509/CRLNumberExtension.java ! src/share/classes/sun/security/x509/CRLReasonCodeExtension.java ! src/share/classes/sun/security/x509/CertAndKeyGen.java ! src/share/classes/sun/security/x509/CertificateAlgorithmId.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/CertificateIssuerExtension.java ! src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java ! src/share/classes/sun/security/x509/CertificatePoliciesExtension.java ! src/share/classes/sun/security/x509/CertificatePolicyId.java ! src/share/classes/sun/security/x509/CertificateSerialNumber.java ! src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java ! src/share/classes/sun/security/x509/CertificateValidity.java ! src/share/classes/sun/security/x509/CertificateVersion.java ! src/share/classes/sun/security/x509/CertificateX509Key.java ! src/share/classes/sun/security/x509/ExtendedKeyUsageExtension.java ! src/share/classes/sun/security/x509/Extension.java ! src/share/classes/sun/security/x509/InhibitAnyPolicyExtension.java ! src/share/classes/sun/security/x509/InvalidityDateExtension.java ! src/share/classes/sun/security/x509/IssuerAlternativeNameExtension.java ! src/share/classes/sun/security/x509/KeyUsageExtension.java ! src/share/classes/sun/security/x509/NameConstraintsExtension.java ! src/share/classes/sun/security/x509/NetscapeCertTypeExtension.java ! src/share/classes/sun/security/x509/OIDMap.java ! src/share/classes/sun/security/x509/OIDName.java ! src/share/classes/sun/security/x509/OtherName.java ! src/share/classes/sun/security/x509/PolicyConstraintsExtension.java ! src/share/classes/sun/security/x509/PolicyInformation.java ! src/share/classes/sun/security/x509/PolicyMappingsExtension.java ! src/share/classes/sun/security/x509/PrivateKeyUsageExtension.java ! src/share/classes/sun/security/x509/RDN.java ! src/share/classes/sun/security/x509/SubjectAlternativeNameExtension.java ! src/share/classes/sun/security/x509/SubjectInfoAccessExtension.java ! src/share/classes/sun/security/x509/SubjectKeyIdentifierExtension.java ! src/share/classes/sun/security/x509/X500Name.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java ! src/share/classes/sun/security/x509/X509Key.java ! src/windows/classes/sun/security/mscapi/KeyStore.java ! src/windows/classes/sun/security/mscapi/PRNG.java ! src/windows/classes/sun/security/mscapi/RSAPrivateKey.java ! src/windows/classes/sun/security/mscapi/RSAPublicKey.java ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java From bradford.wetmore at oracle.com Mon Aug 15 17:21:24 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 15 Aug 2011 17:21:24 -0700 Subject: code review request: 7078816: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure In-Reply-To: <4E46A98F.1090202@oracle.com> References: <4E4661BF.9090900@oracle.com> <4E46A98F.1090202@oracle.com> Message-ID: <4E49B804.2000207@oracle.com> SOFTTOKEN_DIR is used to override the default token directory location. (Usually $HOME). Brad On 8/13/2011 9:42 AM, Alan Bateman wrote: > Weijun Wang wrote: >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078816 >> webrev: http://cr.openjdk.java.net/~weijun/7078816/webrev.00/ >> >> Description: >> The test calls javac to compile a java source file, but the class's >> parent class is not in the same directory, and compilation fails. >> >> The SecretKeysBasic class is a sub class of PKCS11Test which is in >> another directory, and javac has not included that directory into >> classpath. >> >> I also remove the version check of Solaris OS into the initial uname >> check, otherwise, if token "nss" already fails but token "solaris" >> finds version not matched, it will exit 0. >> >> I also open up the test to all OSes. >> >> Two questions: >> >> 1. Is it really necessary to define $CP to be /bin/cp on Solaris/Linux >> and /usr/bin/cp on Cygwin? >> >> 2. For Solaris. there is >> >> case "${OS_VERSION}" in >> 5.1* ) >> SOFTTOKEN_DIR=${TESTCLASSES} >> export SOFTTOKEN_DIR >> TOKENS="nss solaris" >> ;; >> * ) >> >> Where is this $SOFTTOKEN_DIR used? Is it necessary? I didn't find >> reference to it in either test or source. >> >> *Alan*: Can you try this fix on your solaris-x64 machine where the >> original test failed? > I grabbed the patch from your webrev and the tests is now passing for me > - thanks. > > I can't say if SOFTTOKEN_DIR is needed or not but it looks like it is > used by pkcs11_softtoken.so. > > One thing I see in the test is that TESTJAVA is no longer set when > running interactively. I guess you could default it to "java" so that it > runs the JDK on the PATH. Alternatively the test could fail if not set > (there are examples of both approaches in the test tree). > > -Alan. > > > From weijun.wang at oracle.com Mon Aug 15 17:53:42 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 16 Aug 2011 00:53:42 +0000 Subject: hg: jdk8/tl/jdk: 7079204: add several security and networking tests to problems list Message-ID: <20110816005353.2695847BDE@hg.openjdk.java.net> Changeset: dd218ad64d5c Author: weijun Date: 2011-08-16 08:53 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd218ad64d5c 7079204: add several security and networking tests to problems list Reviewed-by: smarks ! test/ProblemList.txt From naoto.sato at oracle.com Wed Aug 17 11:10:16 2011 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 17 Aug 2011 18:10:16 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110817181050.4D8BB47C69@hg.openjdk.java.net> Changeset: c3a8d5feee94 Author: naoto Date: 2011-08-17 11:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3a8d5feee94 7073906: Locale.getDefault() returns wrong Locale for Java SE 7 Reviewed-by: okutsu ! src/windows/native/java/lang/java_props_md.c Changeset: f59c83f515e6 Author: naoto Date: 2011-08-17 11:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f59c83f515e6 7079486: Locale.getDisplayScript() (no args) does not honor default DISPLAY locale Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleCategory.java ! test/java/util/Locale/LocaleCategory.sh From jonathan.gibbons at oracle.com Wed Aug 17 12:11:07 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 17 Aug 2011 19:11:07 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110817191127.0FDE947C6C@hg.openjdk.java.net> Changeset: f4fe826b8034 Author: jjg Date: 2011-08-17 05:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4fe826b8034 7079606: tl nightly build failure due to incomplete generification Reviewed-by: jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/com/sun/security/Makefile Changeset: 259b2536d11c Author: jjg Date: 2011-08-17 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/259b2536d11c Merge From jonathan.gibbons at oracle.com Wed Aug 17 12:12:52 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 17 Aug 2011 19:12:52 +0000 Subject: hg: jdk8/tl/jdk: 7077389: Reflection classes do not build with javac -Xlint:all -Werror Message-ID: <20110817191302.1AC1247C6D@hg.openjdk.java.net> Changeset: e59aad6ed600 Author: jjg Date: 2011-08-15 17:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e59aad6ed600 7077389: Reflection classes do not build with javac -Xlint:all -Werror Reviewed-by: darcy Contributed-by: alexandre.boulgakov at oracle.com ! make/java/java/Makefile ! src/share/classes/java/lang/reflect/Array.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java ! src/share/classes/sun/reflect/ClassDefiner.java ! src/share/classes/sun/reflect/ConstantPool.java ! src/share/classes/sun/reflect/Label.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java ! src/share/classes/sun/reflect/Reflection.java ! src/share/classes/sun/reflect/ReflectionFactory.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/annotation/EnumConstantNotPresentExceptionProxy.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java ! src/share/classes/sun/reflect/generics/scope/AbstractScope.java ! src/share/classes/sun/reflect/generics/scope/ConstructorScope.java ! src/share/classes/sun/reflect/generics/tree/ClassSignature.java ! src/share/classes/sun/reflect/generics/tree/MethodTypeSignature.java From xueming.shen at oracle.com Wed Aug 17 14:05:55 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 17 Aug 2011 21:05:55 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110817210614.B652147C73@hg.openjdk.java.net> Changeset: 2961329a6774 Author: sherman Date: 2011-08-17 14:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2961329a6774 6237353: Remove sun.io package from j2se binary Summary: Removed sun.io package and related test cases Reviewed-by: alanb ! make/java/sun_nio/FILES_java.gmk ! make/java/sun_nio/Makefile ! make/sun/nio/cs/FILES_java.gmk ! make/tools/CharsetMapping/SingleByte-X.java.template - src/share/classes/sun/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/IBM33722.java ! src/share/classes/sun/nio/cs/ext/IBM964.java ! src/share/classes/sun/nio/cs/ext/ISCII91.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/TestCp834_SBCS.java - test/sun/nio/cs/TestISCII91.java Changeset: 07ad16388170 Author: sherman Date: 2011-08-17 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07ad16388170 Merge From xueming.shen at oracle.com Wed Aug 17 15:05:47 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 17 Aug 2011 22:05:47 +0000 Subject: hg: jdk8/tl/jdk: 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) Message-ID: <20110817220558.C539D47C77@hg.openjdk.java.net> Changeset: 11cc9c2e0431 Author: sherman Date: 2011-08-17 15:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11cc9c2e0431 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) Summary: Added the @since 1.7 tag Reviewed-by: mduigou, forax ! src/share/classes/java/util/regex/Matcher.java From bradford.wetmore at oracle.com Wed Aug 17 20:37:23 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 17 Aug 2011 20:37:23 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E271031.1060202@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E26471F.2000802@oracle.com> <4E271031.1060202@oracle.com> Message-ID: <4E4C88F3.6050300@oracle.com> This is a little late, but catching up on a bunch of back email. Why did you add: +JAVAC_MAX_WARNINGS = false in places like: +JAVAC_MAX_WARNINGS=false +JAVAC_LINT_OPTIONS=-Xlint:all,-deprecation +JAVAC_WARNINGS_FATAL=true The default is false (NOP) already: jdk/make/common/shared/Defs-java.gmk ifeq ($(JAVAC_MAX_WARNINGS), true) JAVAC_LINT_OPTIONS += -Xlint:all endif Just seems like additional overhead for the maintainer to understand, instead of just the two lines. Brad On 7/20/2011 10:28 AM, Alexandre Boulgakov wrote: > "JAVAC_MAX_WARNINGS = true" is the same as "JAVAC_LINT_OPTIONS = > -Xlint:all", so the only warnings being ignored are deprecation warnings. > > -Sasha > > On 7/19/2011 8:10 PM, Xuelei Fan wrote: >> About the makefile. In some makefiles, you added: >> >> JAVAC_MAX_WARNINGS = false >> JAVAC_LINT_OPTIONS = -Xlint:all,-deprecation >> JAVAC_WARNINGS_FATAL = true >> >> But some others, the more strict rules are applied: >> JAVAC_MAX_WARNINGS = true >> JAVAC_WARNINGS_FATAL = true >> >> What's the underlying warnings that we cannot always use the following >> options: >> JAVAC_MAX_WARNINGS = true >> JAVAC_WARNINGS_FATAL = true >> >> >> Thanks, >> Xuelei (Andrew) >> >> On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote: >>> Hello Sean, >>> >>> Have you had a chance to look at this webrev? >>> >>> Thanks, >>> Sasha >>> >>> On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote: >>>> Hello, >>>> >>>> Here's an updated webrev: >>>> http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/ >>>> >>>> I've reexamined the @SuppressWarnings("unchecked") annotations, and >>>> added comments to all of the ones I've added. I was was also able to >>>> remove several of them by using covariant return types on >>>> sun.security.x509.*Extension.get(String) inherited from Object >>>> CertAttrSet.get(String). I've also updated the consumers of >>>> sun.security.x509.*Extension.get(String) to use the more specific >>>> return type, removing several casts and @SuppressWarnings("unchecked") >>>> annotations. >>>> >>>> Also, please take a closer look at my changes to >>>> com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry, >>>> >>>> final CodeSource) in >>>> src/share/classes/com/sun/security/auth/PolicyFile.java lines >>>> 1088-1094. The preceding comment and the behavior of >>>> Subject.getPrincipals(Class) seem to be more consistent with the >>>> updated version, but I wanted to make sure. >>>> >>>> The classes where I added serialVersionUID's are either new or have >>>> the same serialVersionUID as the original implementation. >>>> >>>> Thanks, >>>> Sasha >>>> >>>> On 7/18/2011 5:33 PM, Brad Wetmore wrote: >>>>> (Apologies to folks without access to the older sources.) >>>>> >>>>> >>>>> On 07/18/11 15:00, Sean Mullan wrote: >>>>>> On 7/18/11 5:35 PM, Alexandre Boulgakov wrote: >>>>>>> Is there an easy way to see when a class was added to the JDK? >>>>>> For standard API classes, you can use the @since javadoc tag which >>>>>> will indicate >>>>>> the release it was first introduced in. >>>>> Standard, exported API classes. Some of the underlying support >>>>> classes for API packages like java.*.* weren't always @since'd >>>>> properly. >>>>> >>>>>> For internal classes, there is no easy way, since most don't have an >>>>>> @since tag. >>>>>> I would probably write a script that checks the rt.jar of each of >>>>>> the JREs that >>>>>> are archived at /java/re/jdk. The pathnames should be fairly >>>>>> consistent, just >>>>>> the version number is different. >>>>> Don't know which classes you're talking about here, but some classes >>>>> started out in other jar files and eventually wound up in rt.jar. >>>>> Also, some files live in files other than rt.jar. I usually go to >>>>> the source when looking for something. If it's originally from >>>>> JSSE/JGSS/JCE, you'll need to look on our restricted access machine. >>>>> >>>>> When I'm looking for something that is in the jdk/j2se workspaces, I >>>>> go right to the old Codemgr data, specifically the nametable file, >>>>> because many times the files you want may be in a src//classes >>>>> instead of src/share/classes. >>>>> >>>>> % grep -i SunMSCAPI.java >>>>> /5.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>> >>>>> % grep -i SunMSCAPI.java >>>>> /6.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>> src/windows/classes/sun/security/mscapi/SunMSCAPI.java ada8dbe4 >>>>> a217f6b0 6c833bd3 d4ef32be >>>>> >>>>> That will usually give you a good starting point. >>>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>> >>>>> Depending on rt.jar or not. >>>>> >>>>>> Chris, do you have any other ideas? >>>>>> >>>>>> --Sean From lana.steuck at oracle.com Wed Aug 17 23:07:56 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 18 Aug 2011 06:07:56 +0000 Subject: hg: jdk8/tl/jdk: 7 new changesets Message-ID: <20110818060904.5F79447CC5@hg.openjdk.java.net> Changeset: 34fdcdb70d20 Author: rupashka Date: 2011-07-28 18:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34fdcdb70d20 6995769: occasion NPE thrown from SwingUtilities.computeIntersection() Reviewed-by: alexp ! src/share/classes/javax/swing/RepaintManager.java Changeset: 86098b3f7789 Author: rupashka Date: 2011-07-28 18:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86098b3f7789 7071166: LayoutStyle.getPreferredGap() - IAE is expected but not thrown Reviewed-by: peterz ! src/share/classes/sun/swing/DefaultLayoutStyle.java + test/javax/swing/GroupLayout/7071166/bug7071166.java Changeset: 0ce1f0b21446 Author: serb Date: 2011-08-01 17:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ce1f0b21446 7068060: closed/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java failed on windows Reviewed-by: art, dcherepanov + test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java Changeset: 854e74d8d956 Author: rupashka Date: 2011-08-03 16:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/854e74d8d956 7072328: Sun URL in the MetalLookAndFeel.getLayoutStyle() specification should be replaced with Oracle one Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java Changeset: 634c2a492cf5 Author: lana Date: 2011-08-05 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/634c2a492cf5 Merge - src/share/classes/java/lang/invoke/FilterGeneric.java - src/share/classes/java/lang/invoke/FilterOneArgument.java - src/share/classes/java/lang/invoke/FromGeneric.java - src/share/classes/java/lang/invoke/SpreadGeneric.java - src/share/classes/java/lang/invoke/ToGeneric.java Changeset: 2cdbbc4a6359 Author: lana Date: 2011-08-09 17:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cdbbc4a6359 Merge - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c Changeset: 7d8927b76d68 Author: lana Date: 2011-08-17 22:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d8927b76d68 Merge From alan.bateman at oracle.com Thu Aug 18 08:54:11 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 18 Aug 2011 15:54:11 +0000 Subject: hg: jdk8/tl/jdk: 7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails Message-ID: <20110818155435.84FEE47D09@hg.openjdk.java.net> Changeset: 759aa847dcaf Author: alanb Date: 2011-08-18 16:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/759aa847dcaf 7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails Reviewed-by: forax, mduigou ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/FilterOutputStream.java ! src/share/classes/java/lang/AutoCloseable.java + test/java/io/etc/FailingFlushAndClose.java ! test/java/lang/ProcessBuilder/Basic.java From alexandre.boulgakov at oracle.com Thu Aug 18 11:21:35 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Thu, 18 Aug 2011 11:21:35 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E4C88F3.6050300@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E26471F.2000802@oracle.com> <4E271031.1060202@oracle.com> <4E4C88F3.6050300@oracle.com> Message-ID: <4E4D582F.3030704@oracle.com> This is actually a complicated question. If a user sets JAVAC_MAX_WARNINGS=true globally, there are two things we can do: We can listen to the user and exit with an error the moment one of these files comes along (in this case, we know there will be [deprecation] warnings), or we can ignore the user's request for the particular makefile by resetting JAVAC_MAX_WARNINGS=false. I went with the latter simply because it allows for a full build with "make JAVAC_MAX_WARNINGS=true", which makes for easy bookkeeping. -Sasha On 8/17/2011 8:37 PM, Brad Wetmore wrote: > This is a little late, but catching up on a bunch of back email. > > Why did you add: > > +JAVAC_MAX_WARNINGS = false > > in places like: > > +JAVAC_MAX_WARNINGS=false > +JAVAC_LINT_OPTIONS=-Xlint:all,-deprecation > +JAVAC_WARNINGS_FATAL=true > > The default is false (NOP) already: > > jdk/make/common/shared/Defs-java.gmk > > ifeq ($(JAVAC_MAX_WARNINGS), true) > JAVAC_LINT_OPTIONS += -Xlint:all > endif > > Just seems like additional overhead for the maintainer to understand, > instead of just the two lines. > > Brad > > > > > On 7/20/2011 10:28 AM, Alexandre Boulgakov wrote: >> "JAVAC_MAX_WARNINGS = true" is the same as "JAVAC_LINT_OPTIONS = >> -Xlint:all", so the only warnings being ignored are deprecation >> warnings. >> >> -Sasha >> >> On 7/19/2011 8:10 PM, Xuelei Fan wrote: >>> About the makefile. In some makefiles, you added: >>> >>> JAVAC_MAX_WARNINGS = false >>> JAVAC_LINT_OPTIONS = -Xlint:all,-deprecation >>> JAVAC_WARNINGS_FATAL = true >>> >>> But some others, the more strict rules are applied: >>> JAVAC_MAX_WARNINGS = true >>> JAVAC_WARNINGS_FATAL = true >>> >>> What's the underlying warnings that we cannot always use the following >>> options: >>> JAVAC_MAX_WARNINGS = true >>> JAVAC_WARNINGS_FATAL = true >>> >>> >>> Thanks, >>> Xuelei (Andrew) >>> >>> On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote: >>>> Hello Sean, >>>> >>>> Have you had a chance to look at this webrev? >>>> >>>> Thanks, >>>> Sasha >>>> >>>> On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote: >>>>> Hello, >>>>> >>>>> Here's an updated webrev: >>>>> http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/ >>>>> >>>>> I've reexamined the @SuppressWarnings("unchecked") annotations, and >>>>> added comments to all of the ones I've added. I was was also able to >>>>> remove several of them by using covariant return types on >>>>> sun.security.x509.*Extension.get(String) inherited from Object >>>>> CertAttrSet.get(String). I've also updated the consumers of >>>>> sun.security.x509.*Extension.get(String) to use the more specific >>>>> return type, removing several casts and >>>>> @SuppressWarnings("unchecked") >>>>> annotations. >>>>> >>>>> Also, please take a closer look at my changes to >>>>> com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry, >>>>> >>>>> >>>>> final CodeSource) in >>>>> src/share/classes/com/sun/security/auth/PolicyFile.java lines >>>>> 1088-1094. The preceding comment and the behavior of >>>>> Subject.getPrincipals(Class) seem to be more consistent with the >>>>> updated version, but I wanted to make sure. >>>>> >>>>> The classes where I added serialVersionUID's are either new or have >>>>> the same serialVersionUID as the original implementation. >>>>> >>>>> Thanks, >>>>> Sasha >>>>> >>>>> On 7/18/2011 5:33 PM, Brad Wetmore wrote: >>>>>> (Apologies to folks without access to the older sources.) >>>>>> >>>>>> >>>>>> On 07/18/11 15:00, Sean Mullan wrote: >>>>>>> On 7/18/11 5:35 PM, Alexandre Boulgakov wrote: >>>>>>>> Is there an easy way to see when a class was added to the JDK? >>>>>>> For standard API classes, you can use the @since javadoc tag which >>>>>>> will indicate >>>>>>> the release it was first introduced in. >>>>>> Standard, exported API classes. Some of the underlying support >>>>>> classes for API packages like java.*.* weren't always @since'd >>>>>> properly. >>>>>> >>>>>>> For internal classes, there is no easy way, since most don't >>>>>>> have an >>>>>>> @since tag. >>>>>>> I would probably write a script that checks the rt.jar of each of >>>>>>> the JREs that >>>>>>> are archived at /java/re/jdk. The pathnames should be fairly >>>>>>> consistent, just >>>>>>> the version number is different. >>>>>> Don't know which classes you're talking about here, but some classes >>>>>> started out in other jar files and eventually wound up in rt.jar. >>>>>> Also, some files live in files other than rt.jar. I usually go to >>>>>> the source when looking for something. If it's originally from >>>>>> JSSE/JGSS/JCE, you'll need to look on our restricted access machine. >>>>>> >>>>>> When I'm looking for something that is in the jdk/j2se workspaces, I >>>>>> go right to the old Codemgr data, specifically the nametable file, >>>>>> because many times the files you want may be in a src//classes >>>>>> instead of src/share/classes. >>>>>> >>>>>> % grep -i SunMSCAPI.java >>>>>> /5.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>> >>>>>> % grep -i SunMSCAPI.java >>>>>> /6.0/latest/ws/j2se/Codemgr_wsdata/nametable >>>>>> src/windows/classes/sun/security/mscapi/SunMSCAPI.java ada8dbe4 >>>>>> a217f6b0 6c833bd3 d4ef32be >>>>>> >>>>>> That will usually give you a good starting point. >>>>>> >>>>>> Brad >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Depending on rt.jar or not. >>>>>> >>>>>>> Chris, do you have any other ideas? >>>>>>> >>>>>>> --Sean From weijun.wang at oracle.com Thu Aug 18 22:43:33 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 19 Aug 2011 05:43:33 +0000 Subject: hg: jdk8/tl/jdk: 7043847: NTML impl of SaslServer throws UnsupportedOperationException from (un)wrap method; ... Message-ID: <20110819054352.194BE47DBF@hg.openjdk.java.net> Changeset: 55952703809f Author: weijun Date: 2011-08-19 13:42 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55952703809f 7043847: NTML impl of SaslServer throws UnsupportedOperationException from (un)wrap method 7043860: NTML impl of SaslServer doesn't throw ISE from getAuthorizationID() method 7043882: NTML impl of SaslServer doesn't throw ISE from getNegotiatedProperty() method 7043938: NTML impl of SaslClientFactory throws NPE instead of SaslException 7043959: NTML impl of SaslClientFactory throws NPE for null CallBackHandler instance Reviewed-by: vinnie ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLMException.java ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java + test/com/sun/security/sasl/ntlm/Conformance.java From chris.hegarty at oracle.com Fri Aug 19 02:56:45 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 19 Aug 2011 09:56:45 +0000 Subject: hg: jdk8/tl/jdk: 7025938: Add bitmap mime type to content-types.properties Message-ID: <20110819095709.84ABF47DDC@hg.openjdk.java.net> Changeset: 46b53f80ab0a Author: chegar Date: 2011-08-19 10:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46b53f80ab0a 7025938: Add bitmap mime type to content-types.properties Reviewed-by: chegar, alanb, michaelm Contributed-by: lvjing at linux.vnet.ibm.com ! src/solaris/lib/content-types.properties ! src/windows/lib/content-types.properties From joe.darcy at oracle.com Fri Aug 19 17:42:47 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 20 Aug 2011 00:42:47 +0000 Subject: hg: jdk8/tl/jdk: 4748706: typos in java.util.Observable documentation Message-ID: <20110820004257.3A94E47E7A@hg.openjdk.java.net> Changeset: 8018d541a7b2 Author: darcy Date: 2011-08-19 17:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8018d541a7b2 4748706: typos in java.util.Observable documentation Reviewed-by: iris ! src/share/classes/java/util/Observable.java From alan.bateman at oracle.com Mon Aug 22 03:41:52 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 22 Aug 2011 10:41:52 +0000 Subject: hg: jdk8/tl/jdk: 7081796: (ch) rawtype warning in sun.nio.ch.InheritedChannel Message-ID: <20110822104215.F3F9F47FCD@hg.openjdk.java.net> Changeset: b3425b50bc36 Author: alanb Date: 2011-08-22 11:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3425b50bc36 7081796: (ch) rawtype warning in sun.nio.ch.InheritedChannel Reviewed-by: chegar ! src/solaris/classes/sun/nio/ch/InheritedChannel.java From xuelei.fan at oracle.com Mon Aug 22 04:10:32 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 22 Aug 2011 19:10:32 +0800 Subject: code review request: 7081817, java/classes_secu, test/sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java failing Message-ID: <4E523928.70706@oracle.com> Simple fix, no webrev. % hg diff src/share/classes/sun/security/provider/certpath/X509CertPath.java --- a/src/share/classes/sun/security/provider/certpath/X509CertPath.java +++ b/src/share/classes/sun/security/provider/certpath/X509CertPath.java @@ -105,7 +105,13 @@ super("X.509"); // Ensure that the List contains only X509Certificates - for (Certificate obj : certs) { + // + // Note; The certs parameter is not necessarily to be of Certificate + // for some old code. For compatibility, to make sure the exception + // is CertificateException, rather than ClassCastException, please + // don't use + // for (Certificate obj : certs) + for (Object obj : certs) if (obj instanceof X509Certificate == false) { throw new CertificateException ("List is not all X509Certificates: " Thanks, Xuelei From Alan.Bateman at oracle.com Mon Aug 22 04:31:05 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Aug 2011 12:31:05 +0100 Subject: code review request: 7081817, java/classes_secu, test/sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java failing In-Reply-To: <4E523928.70706@oracle.com> References: <4E523928.70706@oracle.com> Message-ID: <4E523DF9.2070500@oracle.com> Xuelei Fan wrote: > Simple fix, no webrev. > > % hg diff src/share/classes/sun/security/provider/certpath/X509CertPath.java > --- a/src/share/classes/sun/security/provider/certpath/X509CertPath.java > +++ b/src/share/classes/sun/security/provider/certpath/X509CertPath.java > @@ -105,7 +105,13 @@ > super("X.509"); > > // Ensure that the List contains only X509Certificates > - for (Certificate obj : certs) { > + // > + // Note; The certs parameter is not necessarily to be of Certificate > + // for some old code. For compatibility, to make sure the exception > + // is CertificateException, rather than ClassCastException, please > + // don't use > + // for (Certificate obj : certs) > + for (Object obj : certs) > if (obj instanceof X509Certificate == false) { > throw new CertificateException > ("List is not all X509Certificates: " > > The fix looks okay to me. I'm not sure that the note is really needed as it's clear from the code (and the javadoc) that CertificateException is what is intended for this case. -Alan. From weijun.wang at oracle.com Mon Aug 22 04:38:02 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Aug 2011 19:38:02 +0800 Subject: code review request: 7081817, java/classes_secu, test/sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java failing In-Reply-To: <4E523DF9.2070500@oracle.com> References: <4E523928.70706@oracle.com> <4E523DF9.2070500@oracle.com> Message-ID: <4E523F9A.3010407@oracle.com> On 08/22/2011 07:31 PM, Alan Bateman wrote: > Xuelei Fan wrote: >> Simple fix, no webrev. >> >> % hg diff >> src/share/classes/sun/security/provider/certpath/X509CertPath.java >> --- a/src/share/classes/sun/security/provider/certpath/X509CertPath.java >> +++ b/src/share/classes/sun/security/provider/certpath/X509CertPath.java >> @@ -105,7 +105,13 @@ >> super("X.509"); >> >> // Ensure that the List contains only X509Certificates >> - for (Certificate obj : certs) { >> + // >> + // Note; The certs parameter is not necessarily to be of Certificate >> + // for some old code. For compatibility, to make sure the exception >> + // is CertificateException, rather than ClassCastException, please >> + // don't use >> + // for (Certificate obj : certs) >> + for (Object obj : certs) for (Object obj : certs) { ^ >> if (obj instanceof X509Certificate == false) { >> throw new CertificateException >> ("List is not all X509Certificates: " >> > The fix looks okay to me. I'm not sure that the note is really needed as > it's clear from the code (and the javadoc) that CertificateException is > what is intended for this case. The note is needed, otherwise it won't be changed last time. Thanks Max > > -Alan. From Alan.Bateman at oracle.com Mon Aug 22 04:43:16 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Aug 2011 12:43:16 +0100 Subject: code review request: 7081817, java/classes_secu, test/sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java failing In-Reply-To: <4E523F9A.3010407@oracle.com> References: <4E523928.70706@oracle.com> <4E523DF9.2070500@oracle.com> <4E523F9A.3010407@oracle.com> Message-ID: <4E5240D4.8080104@oracle.com> Weijun Wang wrote: > > The note is needed, otherwise it won't be changed last time. I assume it was because the tests weren't run :-) From sebastian.sickelmann at gmx.de Mon Aug 22 06:03:02 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 22 Aug 2011 15:03:02 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException Message-ID: <4E525386.9000207@gmx.de> Hi, while making some change for using exception-chaining on RuntimeException in more cases, i found that javax.xml.crypto.NoSuchMechnismException had a private cause field that isn't necessary since throwable can handle it. But just removing isn't that simple as Alan pointed out[1]. First of all i thought just changing the serialversionUID was the right solution, but Alan disagreed and i actually think that too. Unfortunatly Alan doen't had the time to explain it in detail, but i think that we must search for a solution that doen't break backward serialization compatability. I created a webrev for my suggested change here: http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2/ In a following post Alan writes that this should best be discussed here. What is the hg repository for patches in this mailinglist? I don't see any security-dev related repository for openjdk8 in http://hg.openjdk.java.net/ the patch is based on *** *jdk8/tl/jdk maybe i should rebase it onto another repository. Another problem i have is testing. I think we should add some test for this. But got no real clue how to do it right. I tested it manually with the source here[2] and the files in here[3]. The files are created with an openjdk7 build(Unfortunatly i think with an quite old private build) and with an openjdk8(with my patches to NoSuchMechanismException). I tested it manually with my openjdk 7 and 8 build and in both cases the serialized objects could be loaded correctly in all cases. What is the best way to test this automatically. I thought about checking if the newly created openjdk8 serialization is binary equal to the jdk7 output, but it isn't because of some unavoidable changes (ex. jdk8 has the custom-serialization-bit) Alan mentioned that it may be ok to embed some serialized-objects as byte[] in testcode. I will try to create a jtreg for this. Hope to be back on this soon. In the meantime it would be great to have someone reviewed the webrev. @core-libs-dev: I crosspost it to core-libs-dev because the thread started there. So the interessted parties can move over to security-dev archive[4] -- Sebastian [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007462.html [2] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/SeriallizeTest.java [3] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/ [4] http://mail.openjdk.java.net/pipermail/security-dev/2011-August/thread.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20110822/3d971cbd/attachment.html From chris.hegarty at oracle.com Mon Aug 22 06:10:33 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 22 Aug 2011 13:10:33 +0000 Subject: hg: jdk8/tl/jdk: 7023713: HttpCookie.domainMatches("hostname.local", "hostname") should return true Message-ID: <20110822131044.950FF47FD3@hg.openjdk.java.net> Changeset: 5c1f90dd0405 Author: chegar Date: 2011-08-22 14:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c1f90dd0405 7023713: HttpCookie.domainMatches("hostname.local", "hostname") should return true Reviewed-by: chegar Contributed-by: zhouyx at linux.vnet.ibm.com ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java From xuelei.fan at oracle.com Mon Aug 22 06:32:20 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 22 Aug 2011 21:32:20 +0800 Subject: code review request: 7081817, java/classes_secu, test/sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java failing In-Reply-To: <4E5240D4.8080104@oracle.com> References: <4E523928.70706@oracle.com> <4E523DF9.2070500@oracle.com> <4E523F9A.3010407@oracle.com> <4E5240D4.8080104@oracle.com> Message-ID: <4E525A64.7080604@oracle.com> On 8/22/2011 7:43 PM, Alan Bateman wrote: > Weijun Wang wrote: >> >> The note is needed, otherwise it won't be changed last time. > I assume it was because the tests weren't run :-) I would like to have the comments because it is not intuitively clear why we cannot use Certificate class. Most of the time, we think the compiler will help to check the type, this case is special. Thanks for the quick review. Xuelei From Alan.Bateman at oracle.com Mon Aug 22 07:38:35 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Aug 2011 15:38:35 +0100 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E525386.9000207@gmx.de> References: <4E525386.9000207@gmx.de> Message-ID: <4E5269EB.5040308@oracle.com> Sebastian Sickelmann wrote: > : > > In a following post Alan writes that this should best be discussed > here. What is the hg repository for patches in this mailinglist? I > don't see any security-dev related repository for openjdk8 in > http://hg.openjdk.java.net/ the patch is based on *** > *jdk8/tl/jdk maybe i should > rebase it onto another repository. Security changes are also pushed to jdk8/tl/jdk, it's just a different mailing list for this area. -Alan. From alan.bateman at oracle.com Mon Aug 22 08:06:25 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 22 Aug 2011 15:06:25 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110822150645.EE18247FD9@hg.openjdk.java.net> Changeset: fd07a2b7bf4d Author: alanb Date: 2011-08-22 16:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fd07a2b7bf4d 7081813: ProblemList.txt updates (8/2011) Reviewed-by: weijun, mchung ! test/ProblemList.txt ! test/java/io/IOException/LastErrorString.java Changeset: 605ea77f2e6f Author: alanb Date: 2011-08-22 16:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/605ea77f2e6f Merge From sean.mullan at oracle.com Mon Aug 22 08:28:13 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 22 Aug 2011 11:28:13 -0400 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E525386.9000207@gmx.de> References: <4E525386.9000207@gmx.de> Message-ID: <4E52758D.2020208@oracle.com> (dropping core-libs-dev) On 8/22/11 9:03 AM, Sebastian Sickelmann wrote: > Hi, > > while making some change for using exception-chaining on RuntimeException in > more cases, i found that javax.xml.crypto.NoSuchMechnismException had a private > cause field that isn't necessary since throwable can handle it. But just > removing isn't that simple as Alan pointed out[1]. The history behind this is that this API is part of JSR 105. JSR 105 was released independently of Java SE as a "standalone JSR" and later integrated into Java SE 6 as part of the platform JSR. Thus as I understand, all JSR 105 API changes need to first go through a maintenance revision of JSR 105. JSR 105 was designed to be used by applications using JDK 1.2 and up, thus there are no API dependencies on any releases later than that. Therefore, this class (and other exception classes in JSR 105) included their own methods to capture the cause. I've been aware of this issue for a little while but I did not have the cycles to analyze it thoroughly so I am glad you are looking into it. I think you will find the same issue in the other Exception classes in the javax.xml.crypto package and its subpackages. Have you looked at those yet? I am not sure if removing the 3 overloaded methods qualifies as an API change. If so, it would first require it go through a maintenance JSR. I will need to ask someone else about that and get back to you. > First of all i thought just changing the serialversionUID was the right > solution, but Alan disagreed and i actually think that too. Unfortunatly Alan > doen't had the time to explain it in detail, but i think that we must search for > a solution that doen't break backward serialization compatability. > > I created a webrev for my suggested change here: > http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2/ > > In a following post Alan writes that this should best be discussed here. What is > the hg repository for patches in this mailinglist? I don't see any security-dev > related repository for openjdk8 in http://hg.openjdk.java.net/ the patch is > based on *** *jdk8/tl/jdk maybe i > should rebase it onto another repository. > > Another problem i have is testing. I think we should add some test for this. But > got no real clue how to do it right. I tested it manually with the source > here[2] and the files in here[3]. > > The files are created with an openjdk7 build(Unfortunatly i think with an quite > old private build) and with an openjdk8(with my patches to > NoSuchMechanismException). I tested it manually with my openjdk 7 and 8 build > and in both cases the serialized objects could be loaded correctly in all cases. > > What is the best way to test this automatically. I thought about checking if the > newly created openjdk8 serialization is binary equal to the jdk7 output, but it > isn't because of some unavoidable changes (ex. jdk8 has the > custom-serialization-bit) > > Alan mentioned that it may be ok to embed some serialized-objects as byte[] in > testcode. Yes, that is probably the best solution. I remember I had created some tests for this a while back. I'll see if I can find them. > I will try to create a jtreg for this. Hope to be back on this soon. In the > meantime it would be great to have someone reviewed the webrev. I am pretty busy but will try to find some cycles to review it more carefully in the next couple of days. --Sean > > @core-libs-dev: I crosspost it to core-libs-dev because the thread started > there. So the interessted parties can move over to security-dev archive[4] > > -- Sebastian > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007462.html > [2] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/SeriallizeTest.java > [3] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/ > [4] http://mail.openjdk.java.net/pipermail/security-dev/2011-August/thread.html From joe.darcy at oracle.com Mon Aug 22 12:16:58 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 22 Aug 2011 19:16:58 +0000 Subject: hg: jdk8/tl/jdk: 7080020: Add conventional constructors to InternalError and VirtualMachineError Message-ID: <20110822191717.9FF1347FE5@hg.openjdk.java.net> Changeset: c43af666d130 Author: darcy Date: 2011-08-22 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130 7080020: Add conventional constructors to InternalError and VirtualMachineError Reviewed-by: darcy Contributed-by: nsebastian.sickelmann at gmx.de ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/java/lang/InternalError.java ! src/share/classes/java/lang/VirtualMachineError.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/sun/font/FontManagerFactory.java ! src/share/classes/sun/misc/URLClassPath.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/classes/sun/security/x509/X500Name.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java From joe.darcy at oracle.com Mon Aug 22 17:13:40 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 23 Aug 2011 00:13:40 +0000 Subject: hg: jdk8/tl/jdk: 6476261: (reflect) GenericSignatureFormatError When signature includes nested inner classes; ... Message-ID: <20110823001350.8555147FF3@hg.openjdk.java.net> Changeset: b1f99f9c2879 Author: darcy Date: 2011-08-22 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1f99f9c2879 6476261: (reflect) GenericSignatureFormatError When signature includes nested inner classes 6832374: (reflect) malformed signature can cause parser to go into infinite loop 7052898: (reflect) SignatureParser will accept strings outside of the grammar Summary: Various signature parsing fixes; additional review by sonali.goel at oracle.com Reviewed-by: alanb ! src/share/classes/sun/reflect/generics/parser/SignatureParser.java ! test/java/lang/reflect/Generics/Probe.java + test/java/lang/reflect/Generics/SignatureTest.java + test/java/lang/reflect/Generics/TestBadSignatures.java From joe.darcy at oracle.com Mon Aug 22 17:34:46 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 23 Aug 2011 00:34:46 +0000 Subject: hg: jdk8/tl/jdk: 7080038: (ann) Serializable types in sun.reflect.annotation do not declare serialVersionUIDs Message-ID: <20110823003457.AF30C47FF6@hg.openjdk.java.net> Changeset: 71e353aba896 Author: darcy Date: 2011-08-22 17:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71e353aba896 7080038: (ann) Serializable types in sun.reflect.annotation do not declare serialVersionUIDs Reviewed-by: alanb ! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! src/share/classes/sun/reflect/annotation/AnnotationTypeMismatchExceptionProxy.java ! src/share/classes/sun/reflect/annotation/EnumConstantNotPresentExceptionProxy.java ! src/share/classes/sun/reflect/annotation/TypeNotPresentExceptionProxy.java From xuelei.fan at oracle.com Mon Aug 22 18:23:09 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 23 Aug 2011 01:23:09 +0000 Subject: hg: jdk8/tl/jdk: 7081817: test/sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java failing Message-ID: <20110823012319.B160447FFB@hg.openjdk.java.net> Changeset: 21f4d2d96191 Author: xuelei Date: 2011-08-22 18:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21f4d2d96191 7081817: test/sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java failing Reviewed-by: alanb, weijun ! src/share/classes/sun/security/provider/certpath/X509CertPath.java From mandy.chung at oracle.com Tue Aug 23 10:36:29 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 23 Aug 2011 17:36:29 +0000 Subject: hg: jdk8/tl/jdk: 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may return null Message-ID: <20110823173654.5A11347033@hg.openjdk.java.net> Changeset: 4e53fc6bcac0 Author: mchung Date: 2011-08-23 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e53fc6bcac0 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may return null Reviewed-by: alanb Contributed-by: spoole at uk.ibm.com ! src/share/classes/sun/management/ManagementFactoryHelper.java + test/java/lang/management/ManagementFactory/GetObjectName.java From sebastian.sickelmann at gmx.de Tue Aug 23 14:15:32 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 23 Aug 2011 23:15:32 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E52758D.2020208@oracle.com> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> Message-ID: <4E541874.5040009@gmx.de> Am 22.08.2011 17:28, schrieb Sean Mullan: > (dropping core-libs-dev) > > On 8/22/11 9:03 AM, Sebastian Sickelmann wrote: >> Hi, >> >> while making some change for using exception-chaining on RuntimeException in >> more cases, i found that javax.xml.crypto.NoSuchMechnismException had a private >> cause field that isn't necessary since throwable can handle it. But just >> removing isn't that simple as Alan pointed out[1]. > The history behind this is that this API is part of JSR 105. JSR 105 was > released independently of Java SE as a "standalone JSR" and later integrated > into Java SE 6 as part of the platform JSR. Thus as I understand, all JSR 105 > API changes need to first go through a maintenance revision of JSR 105. > > JSR 105 was designed to be used by applications using JDK 1.2 and up, thus there > are no API dependencies on any releases later than that. Therefore, this class > (and other exception classes in JSR 105) included their own methods to capture > the cause. > > I've been aware of this issue for a little while but I did not have the cycles > to analyze it thoroughly so I am glad you are looking into it. > > I think you will find the same issue in the other Exception classes in the > javax.xml.crypto package and its subpackages. Have you looked at those yet? Yes. It is also in: dsig/XMLSignatureException.java: private Throwable cause; dsig/TransformException.java: private Throwable cause; KeySelectorException.java: private Throwable cause; MarshalException.java: private Throwable cause; URIReferenceException.java: private Throwable cause; > I am not sure if removing the 3 overloaded methods qualifies as an API change. > If so, it would first require it go through a maintenance JSR. I will need to > ask someone else about that and get back to you. I don't think that it is an api change. It should at least be source compatible. I will make a check if its is binary compatible, too. Then there shouldn't be any problem isn't it? >> First of all i thought just changing the serialversionUID was the right >> solution, but Alan disagreed and i actually think that too. Unfortunatly Alan >> doen't had the time to explain it in detail, but i think that we must search for >> a solution that doen't break backward serialization compatability. >> >> I created a webrev for my suggested change here: >> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2/ >> >> In a following post Alan writes that this should best be discussed here. What is >> the hg repository for patches in this mailinglist? I don't see any security-dev >> related repository for openjdk8 in http://hg.openjdk.java.net/ the patch is >> based on ****jdk8/tl/jdk maybe i >> should rebase it onto another repository. >> >> Another problem i have is testing. I think we should add some test for this. But >> got no real clue how to do it right. I tested it manually with the source >> here[2] and the files in here[3]. >> >> The files are created with an openjdk7 build(Unfortunatly i think with an quite >> old private build) and with an openjdk8(with my patches to >> NoSuchMechanismException). I tested it manually with my openjdk 7 and 8 build >> and in both cases the serialized objects could be loaded correctly in all cases. >> >> What is the best way to test this automatically. I thought about checking if the >> newly created openjdk8 serialization is binary equal to the jdk7 output, but it >> isn't because of some unavoidable changes (ex. jdk8 has the >> custom-serialization-bit) >> >> Alan mentioned that it may be ok to embed some serialized-objects as byte[] in >> testcode. > Yes, that is probably the best solution. I remember I had created some tests for > this a while back. I'll see if I can find them. > >> I will try to create a jtreg for this. Hope to be back on this soon. In the >> meantime it would be great to have someone reviewed the webrev. > I am pretty busy but will try to find some cycles to review it more carefully in > the next couple of days. No Problem, i will prepare the tests. Thanks for taking the time. > --Sean -- Sebastian From joe.darcy at oracle.com Tue Aug 23 16:36:18 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 23 Aug 2011 23:36:18 +0000 Subject: hg: jdk8/tl/jdk: 7082231: Put a @since 1.7 on System.lineSeparator Message-ID: <20110823233645.44FCF4706C@hg.openjdk.java.net> Changeset: 440161cc9af8 Author: darcy Date: 2011-08-23 16:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/440161cc9af8 7082231: Put a @since 1.7 on System.lineSeparator Reviewed-by: mduigou ! src/share/classes/java/lang/System.java From sebastian.sickelmann at gmx.de Tue Aug 23 23:58:13 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Wed, 24 Aug 2011 08:58:13 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E52758D.2020208@oracle.com> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> Message-ID: <4E54A105.1040204@gmx.de> Hi, i have created a new webrev for the first raw version of the tests. It is avaiable here[1]. Why i put in some dumps and not the binary version of the files or byte[] in source? Because we cannot/should not integrate this testcase in jdk7 and so we cannot test backward-compatibility. So i want add some comments in the dumps to show and explain the difference. Next steps: Expand to other Exceptions in javax/xml/crypto and comment the testsource better. -- Sebastian [1] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_85919cd409d1/ From weijun.wang at oracle.com Wed Aug 24 19:41:48 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Aug 2011 10:41:48 +0800 Subject: Enhance toString() to return structured info, for certificate and probably more Message-ID: <4E55B66C.4020008@oracle.com> Hi All I was talking with Xuelei on how to better display certificate info. There are 3 cases we can currently think of: 1. debug output 2. keytool/jarsigner output 3. Java plugin display The 1st one is the most primitive one and can be a single string, the 2nd is also a string but have some format and needs to localized, the third is a series of Swing controls. But the contents of all 3 are the same, and hopefully can be provided in a single method. Each consumer can just display it in its own style, with no need to understand Certificate fields, OIDs, etc. It's just like XSLT transformation of XML files. So what shall I do? Let toString() outputs a long string in XML or JSON? Or, create a new method describe() or toDescription() that returns a UnmodifiableMap (based on a LinkedHashMap to preserve order)? I prefer the latter because there is no need to parse the output, and at least in the case of certificate, since a certificate contains extensions, it's very easy to stuff several maps inside another one. The map's keys are strings, and values can be another map or a simple data object, say, primitive, string, or Date. So this needs a new interface Descriptable. It can either be: interface sun.security.util.Descriptable; sun.security.x509.X509CertImpl implements Descriptable; sun.security.x509.Extension implements Descriptable; or interface java.security.Descriptable; java.security.cert.X509Certificate implements Descriptable; java.security.cert.Extension implements Descriptable; or if there are other people find it useful, it can be inside the java.util package. What's your ideas? Do you also need such a method? Thanks Max From sean.coffey at oracle.com Thu Aug 25 06:45:25 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 25 Aug 2011 14:45:25 +0100 Subject: Code review request for 7024697 Message-ID: <4E5651F5.6020901@oracle.com> This is a forward port of http://bugs.sun.com/view_bug.do?bug_id=7024697 to jdk 7 & 8 releases. Code change is identical to that made in jdk6. http://cr.openjdk.java.net/~coffeys/webrev.7024697/ regards, Sean. From chris.hegarty at oracle.com Thu Aug 25 08:10:09 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 25 Aug 2011 15:10:09 +0000 Subject: hg: jdk8/tl/jdk: 7044870: java/nio/channels/DatagramChannel/SelectWhenRefused.java failed on SUSE Linux 10 Message-ID: <20110825151031.89A11470EC@hg.openjdk.java.net> Changeset: c9e78769c0da Author: chegar Date: 2011-08-25 16:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9e78769c0da 7044870: java/nio/channels/DatagramChannel/SelectWhenRefused.java failed on SUSE Linux 10 Reviewed-by: alanb, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! test/java/nio/channels/DatagramChannel/SelectWhenRefused.java From joe.darcy at oracle.com Thu Aug 25 09:43:52 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 25 Aug 2011 16:43:52 +0000 Subject: hg: jdk8/tl/jdk: 7082727: VirtualMachineError should declare its serialVersionUID Message-ID: <20110825164417.3BA3F470F1@hg.openjdk.java.net> Changeset: 624cc18a6cf9 Author: darcy Date: 2011-08-25 09:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624cc18a6cf9 7082727: VirtualMachineError should declare its serialVersionUID Reviewed-by: alanb ! src/share/classes/java/lang/VirtualMachineError.java From valerie.peng at oracle.com Thu Aug 25 10:58:54 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 25 Aug 2011 10:58:54 -0700 Subject: Code review request for 7024697 In-Reply-To: <4E5651F5.6020901@oracle.com> References: <4E5651F5.6020901@oracle.com> Message-ID: <4E568D5E.6030508@oracle.com> Looks fine. Thanks, Valerie On 08/25/11 06:45, Se?n Coffey wrote: > This is a forward port of http://bugs.sun.com/view_bug.do?bug_id=7024697 > to jdk 7 & 8 releases. > > Code change is identical to that made in jdk6. > > http://cr.openjdk.java.net/~coffeys/webrev.7024697/ > > regards, > Sean. > > From ahughes at redhat.com Thu Aug 25 14:01:41 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 25 Aug 2011 22:01:41 +0100 Subject: Enhance toString() to return structured info, for certificate and probably more In-Reply-To: <4E55B66C.4020008@oracle.com> References: <4E55B66C.4020008@oracle.com> Message-ID: <20110825210141.GB9583@rivendell.middle-earth.co.uk> On 10:41 Thu 25 Aug , Weijun Wang wrote: > Hi All > > I was talking with Xuelei on how to better display certificate info. > There are 3 cases we can currently think of: > > 1. debug output > 2. keytool/jarsigner output > 3. Java plugin display > > The 1st one is the most primitive one and can be a single string, the > 2nd is also a string but have some format and needs to localized, the > third is a series of Swing controls. > > But the contents of all 3 are the same, and hopefully can be provided in > a single method. Each consumer can just display it in its own style, > with no need to understand Certificate fields, OIDs, etc. It's just like > XSLT transformation of XML files. > > So what shall I do? Let toString() outputs a long string in XML or JSON? > I be against that. It goes against the usual expectation of toString output being (fairly) human-readable. > Or, create a new method describe() or toDescription() that returns a > UnmodifiableMap (based on a LinkedHashMap to preserve order)? > > I prefer the latter because there is no need to parse the output, and at > least in the case of certificate, since a certificate contains > extensions, it's very easy to stuff several maps inside another one. The > map's keys are strings, and values can be another map or a simple data > object, say, primitive, string, or Date. > > So this needs a new interface Descriptable. It can either be: > > interface sun.security.util.Descriptable; > sun.security.x509.X509CertImpl implements Descriptable; > sun.security.x509.Extension implements Descriptable; > > or > > interface java.security.Descriptable; > java.security.cert.X509Certificate implements Descriptable; > java.security.cert.Extension implements Descriptable; > > or if there are other people find it useful, it can be inside the > java.util package. > This sounds like a good idea to me, but would there be a standard set of keys and values? Especially if it's going to be part of java.security, the keys and values should be part of the method specification. This becomes a harder task if it's generalised into java.util. BTW, it should be Describable :-) > What's your ideas? Do you also need such a method? > > Thanks > Max -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From sebastian.sickelmann at gmx.de Thu Aug 25 15:03:56 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 26 Aug 2011 00:03:56 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E52758D.2020208@oracle.com> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> Message-ID: <4E56C6CC.7010305@gmx.de> I have found more places in jdk source where an Exception has a private cause field. share/classes/javax/management/remote/JMXProviderException.java: private Throwable cause = null; share/classes/javax/xml/crypto/KeySelectorException.java: private Throwable cause; share/classes/javax/xml/crypto/NoSuchMechanismException.java: private Throwable cause; share/classes/javax/xml/crypto/MarshalException.java: private Throwable cause; share/classes/javax/xml/crypto/dsig/XMLSignatureException.java: private Throwable cause; share/classes/javax/xml/crypto/dsig/TransformException.java: private Throwable cause; share/classes/javax/xml/crypto/URIReferenceException.java: private Throwable cause; 7081804 handles NoSuchMechanismException. Is there a way to expand it to at least the xml/crypto/**/* Exceptions? JMXProviderException should be fine too. I would create a CR for the changes to me made to change and test this. Would it be good to have some utility-code in Throwable to don't introduce to much code-duplication? -- Sebastian From sebastian.sickelmann at gmx.de Thu Aug 25 15:24:16 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 26 Aug 2011 00:24:16 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E56C6CC.7010305@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E56C6CC.7010305@gmx.de> Message-ID: <4E56CB90.60508@gmx.de> Am 26.08.2011 00:03, schrieb Sebastian Sickelmann: > I have found more places in jdk source where an Exception has a > private cause field. > > share/classes/javax/management/remote/JMXProviderException.java: > private Throwable cause = null; > share/classes/javax/xml/crypto/KeySelectorException.java: private > Throwable cause; > share/classes/javax/xml/crypto/NoSuchMechanismException.java: > private Throwable cause; > share/classes/javax/xml/crypto/MarshalException.java: private > Throwable cause; > share/classes/javax/xml/crypto/dsig/XMLSignatureException.java: > private Throwable cause; > share/classes/javax/xml/crypto/dsig/TransformException.java: > private Throwable cause; > share/classes/javax/xml/crypto/URIReferenceException.java: private > Throwable cause; > > 7081804 handles NoSuchMechanismException. > Is there a way to expand it to at least the xml/crypto/**/* Exceptions? > JMXProviderException should be fine too. > > I would create a CR for the changes to me made to change and test this. > Would it be good to have some utility-code in Throwable to don't > introduce to much code-duplication? > > -- Sebastian After a very quick analysis i think i found more candidates for removing private causes. share/classes/javax/security/sasl/SaslException.java: private Throwable _exception; share/classes/java/lang/reflect/UndeclaredThrowableException.java: private Throwable undeclaredThrowable; share/classes/java/lang/reflect/InvocationTargetException.java: private Throwable target; share/classes/java/lang/ClassNotFoundException.java: private Throwable ex; share/classes/com/sun/java/browser/dom/DOMAccessException.java: private Throwable ex; share/classes/com/sun/java/browser/dom/DOMUnsupportedException.java: private Throwable ex; share/classes/javax/naming/NamingException.java: protected Throwable rootException = null; share/classes/java/rmi/RemoteException.java: public Throwable detail; share/classes/java/rmi/activation/ActivationException.java: public Throwable detail; Some of them need deeper inspection. Some of them are the same as the above noted Exceptions in xml/crypto package. - Sebastian From sebastian.sickelmann at gmx.de Thu Aug 25 17:00:53 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 26 Aug 2011 02:00:53 +0200 Subject: Request for review Remove "private" cause in jdk exceptions In-Reply-To: <4E56CB90.60508@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E56C6CC.7010305@gmx.de> <4E56CB90.60508@gmx.de> Message-ID: <4E56E235.6010307@gmx.de> Am 26.08.2011 00:24, schrieb Sebastian Sickelmann: > Am 26.08.2011 00:03, schrieb Sebastian Sickelmann: >> I have found more places in jdk source where an Exception has a >> private cause field. >> >> share/classes/javax/management/remote/JMXProviderException.java: >> private Throwable cause = null; >> share/classes/javax/xml/crypto/KeySelectorException.java: private >> Throwable cause; >> share/classes/javax/xml/crypto/NoSuchMechanismException.java: >> private Throwable cause; >> share/classes/javax/xml/crypto/MarshalException.java: private >> Throwable cause; >> share/classes/javax/xml/crypto/dsig/XMLSignatureException.java: >> private Throwable cause; >> share/classes/javax/xml/crypto/dsig/TransformException.java: >> private Throwable cause; >> share/classes/javax/xml/crypto/URIReferenceException.java: private >> Throwable cause; >> >> 7081804 handles NoSuchMechanismException. >> Is there a way to expand it to at least the xml/crypto/**/* Exceptions? >> JMXProviderException should be fine too. >> >> I would create a CR for the changes to me made to change and test this. >> Would it be good to have some utility-code in Throwable to don't >> introduce to much code-duplication? >> >> -- Sebastian > After a very quick analysis i think i found more candidates for > removing private causes. > share/classes/javax/security/sasl/SaslException.java: private > Throwable _exception; > share/classes/java/lang/reflect/UndeclaredThrowableException.java: > private Throwable undeclaredThrowable; > share/classes/java/lang/reflect/InvocationTargetException.java: > private Throwable target; > share/classes/java/lang/ClassNotFoundException.java: private > Throwable ex; > share/classes/com/sun/java/browser/dom/DOMAccessException.java: > private Throwable ex; > share/classes/com/sun/java/browser/dom/DOMUnsupportedException.java: private > Throwable ex; > share/classes/javax/naming/NamingException.java: protected > Throwable rootException = null; > share/classes/java/rmi/RemoteException.java: public Throwable detail; > share/classes/java/rmi/activation/ActivationException.java: public > Throwable detail; > > Some of them need deeper inspection. Some of them are the same as the > above noted Exceptions in xml/crypto package. > > - Sebastian OK. Webrev is there: http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/ Can someone review this? -- Sebastian From weijun.wang at oracle.com Thu Aug 25 18:44:28 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Aug 2011 09:44:28 +0800 Subject: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile) In-Reply-To: <4E56A1F7.2070300@oracle.com> References: <4E56A1F7.2070300@oracle.com> Message-ID: <4E56FA7C.4010505@oracle.com> [ Add security-dev at openjdk.java.net to CC] I think so. javax/xml/crypto is public API and it should go to jdk_security2 (along with javax/crypto). Of course, that is still not included in the default run. I've filed a bug: 7083576: add javax/xml/crypto into jdk_security2 test rule and here is a webrev: http://cr.openjdk.java.net/~weijun/7083576/webrev.00 Note that one test now uses /othervm because it loads a SecurityManager with its own policy file. JPRT runs fine except that one windows-i586 job is still initializing. Ignored. Thanks Max On 08/26/2011 03:26 AM, Sean Mullan wrote: > I noticed that none of the jprt test targets in test/Makefile run tests in the > javax/xml/crypto directory (i.e. JSR 105 tests) - would that be considered a bug? > > --Sean From mike.duigou at oracle.com Thu Aug 25 19:03:36 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 25 Aug 2011 19:03:36 -0700 Subject: Enhance toString() to return structured info, for certificate and probably more In-Reply-To: <20110825210141.GB9583@rivendell.middle-earth.co.uk> References: <4E55B66C.4020008@oracle.com> <20110825210141.GB9583@rivendell.middle-earth.co.uk> Message-ID: On Aug 25 2011, at 14:01 , Dr Andrew John Hughes wrote: > On 10:41 Thu 25 Aug , Weijun Wang wrote: >> Hi All >> >> I was talking with Xuelei on how to better display certificate info. >> There are 3 cases we can currently think of: >> >> 1. debug output >> 2. keytool/jarsigner output >> 3. Java plugin display >> >> The 1st one is the most primitive one and can be a single string, the >> 2nd is also a string but have some format and needs to localized, the >> third is a series of Swing controls. >> >> But the contents of all 3 are the same, and hopefully can be provided in >> a single method. Each consumer can just display it in its own style, >> with no need to understand Certificate fields, OIDs, etc. It's just like >> XSLT transformation of XML files. >> >> So what shall I do? Let toString() outputs a long string in XML or JSON? >> > > I be against that. It goes against the usual expectation of toString output > being (fairly) human-readable. I agree. The format of toString() should favour debugging uses rather than machine readable. Other than for primitive types it's usually a mistake if the output of toString() meant to be machine parsed. If there needs to be machine parsable text representation then that should be on some other method. Secondly, the toString output format, being for debugging doesn't need to display every byte of the data, in some cases such as a 4096 RSA key, the hash value of the key is generally more useful than emitting the whole key. No reasonable human comparing two traces would want to check 8192 hex bytes to see if two keys match. Making it easy by printing the key hash helps a lot. Mike From weijun.wang at oracle.com Thu Aug 25 19:22:27 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Aug 2011 10:22:27 +0800 Subject: Enhance toString() to return structured info, for certificate and probably more In-Reply-To: References: <4E55B66C.4020008@oracle.com> <20110825210141.GB9583@rivendell.middle-earth.co.uk> Message-ID: <4E570363.8070601@oracle.com> Well, I mentioned toString() there just to make it look absurd so that I can promote my alternative method. :) As for the toDescription() method, do you know if there are other cases it can be useful? Thanks Max On 08/26/2011 10:03 AM, Mike Duigou wrote: > > On Aug 25 2011, at 14:01 , Dr Andrew John Hughes wrote: > >> On 10:41 Thu 25 Aug , Weijun Wang wrote: >>> Hi All >>> >>> I was talking with Xuelei on how to better display certificate info. >>> There are 3 cases we can currently think of: >>> >>> 1. debug output >>> 2. keytool/jarsigner output >>> 3. Java plugin display >>> >>> The 1st one is the most primitive one and can be a single string, the >>> 2nd is also a string but have some format and needs to localized, the >>> third is a series of Swing controls. >>> >>> But the contents of all 3 are the same, and hopefully can be provided in >>> a single method. Each consumer can just display it in its own style, >>> with no need to understand Certificate fields, OIDs, etc. It's just like >>> XSLT transformation of XML files. >>> >>> So what shall I do? Let toString() outputs a long string in XML or JSON? >>> >> >> I be against that. It goes against the usual expectation of toString output >> being (fairly) human-readable. > > I agree. The format of toString() should favour debugging uses rather than machine readable. Other than for primitive types it's usually a mistake if the output of toString() meant to be machine parsed. If there needs to be machine parsable text representation then that should be on some other method. > > Secondly, the toString output format, being for debugging doesn't need to display every byte of the data, in some cases such as a 4096 RSA key, the hash value of the key is generally more useful than emitting the whole key. No reasonable human comparing two traces would want to check 8192 hex bytes to see if two keys match. Making it easy by printing the key hash helps a lot. > > Mike > From Alan.Bateman at oracle.com Fri Aug 26 00:22:19 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Aug 2011 08:22:19 +0100 Subject: Request for review Remove "private" cause in jdk exceptions In-Reply-To: <4E56E235.6010307@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E56C6CC.7010305@gmx.de> <4E56CB90.60508@gmx.de> <4E56E235.6010307@gmx.de> Message-ID: <4E5749AB.9040705@oracle.com> Sebastian Sickelmann wrote: > > OK. Webrev is there: > http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/ > > > Can someone review this? I think this one will require careful review and I'm not even sure that it's worth it. Using serialPersistentFields and overriding the readObject/writeObject method is the right thing for this kind of issue but it's bringing complexity that hardy seems worth it. There are a few awkward issues in here. I have to admit that I don't know, without checking, what the deal is with APIs that continued life as standalone JSRs after going into Java SE. I also suspect that some of these changes have subtly changed the behavior of a few of the exceptions. On RemoteException the patch removes a public field which we can't do. I think the other clean-up patches that you have posted here in the last week or two are good and we should move forward on them. -Alan. From fweimer at bfk.de Fri Aug 26 00:26:13 2011 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 26 Aug 2011 07:26:13 +0000 Subject: Enhance toString() to return structured info, for certificate and probably more In-Reply-To: <4E55B66C.4020008@oracle.com> (Weijun Wang's message of "Thu, 25 Aug 2011 10:41:48 +0800") References: <4E55B66C.4020008@oracle.com> Message-ID: <82ei084oru.fsf@mid.bfk.de> * Weijun Wang: > What's your ideas? Do you also need such a method? I suspect that many applications which need to look at certificates in detail would benefit more from an official ASN.1 decoder. Defining yet another data model for X.509 certificates (after ASN.1 and the current Java API) seems a bit superfluous, IMHO. But perhaps I misunderstood what you meant. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Fri Aug 26 00:35:14 2011 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 26 Aug 2011 07:35:14 +0000 Subject: Fix for: 6415637: PKCS#12 key stores with empty passwords In-Reply-To: <82sjr4ejoz.fsf@mid.bfk.de> (Florian Weimer's message of "Mon, 20 Jun 2011 13:06:20 +0000") References: <82sjr4ejoz.fsf@mid.bfk.de> Message-ID: <8262lk4oct.fsf@mid.bfk.de> * Florian Weimer: > Presumably, this does not count as a small change, so BFK needs to sign > a contributor agreement. Is the sun.com email address still the right > one to submit the scanned copy? We got the paperwork sorted out, so we can start work on the process of getting the change in. Max, which forest should I target for the initial push? I will base my next proposal on that, and I will also incorporate the changes you ask for. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From weijun.wang at oracle.com Fri Aug 26 00:40:38 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Aug 2011 15:40:38 +0800 Subject: Fix for: 6415637: PKCS#12 key stores with empty passwords In-Reply-To: <8262lk4oct.fsf@mid.bfk.de> References: <82sjr4ejoz.fsf@mid.bfk.de> <8262lk4oct.fsf@mid.bfk.de> Message-ID: <4E574DF6.6000406@oracle.com> I think security changeset should go to tl forest first. -Max On 08/26/2011 03:35 PM, Florian Weimer wrote: > * Florian Weimer: > >> Presumably, this does not count as a small change, so BFK needs to sign >> a contributor agreement. Is the sun.com email address still the right >> one to submit the scanned copy? > > We got the paperwork sorted out, so we can start work on the process of > getting the change in. > > Max, which forest should I target for the initial push? I will base my > next proposal on that, and I will also incorporate the changes you ask > for. > From sean.coffey at oracle.com Fri Aug 26 02:56:21 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 26 Aug 2011 09:56:21 +0000 Subject: hg: jdk8/tl/jdk: 7024697: SessionRef.dispose() should determine if the token referred to by the token object is still valid Message-ID: <20110826095639.080AB47129@hg.openjdk.java.net> Changeset: 3a13b7ab57f7 Author: coffeys Date: 2011-08-26 10:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a13b7ab57f7 7024697: SessionRef.dispose() should determine if the token referred to by the token object is still valid Reviewed-by: valeriep ! src/share/classes/sun/security/pkcs11/Session.java ! src/share/classes/sun/security/pkcs11/Token.java From sebastian.sickelmann at gmx.de Fri Aug 26 03:59:45 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 26 Aug 2011 12:59:45 +0200 Subject: Request for review Remove "private" cause in jdk exceptions In-Reply-To: References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E56C6CC.7010305@gmx.de> <4E56CB90.60508@gmx.de> <4E56E235.6010307@gmx.de> Message-ID: <4E577CA1.4000000@gmx.de> Am 26.08.2011 08:32, schrieb Peter Jones: > On Aug 25, 2011, at 8:00 PM, Sebastian Sickelmann wrote: >> Am 26.08.2011 00:24, schrieb Sebastian Sickelmann: >>> Am 26.08.2011 00:03, schrieb Sebastian Sickelmann: >>>> I have found more places in jdk source where an Exception has a private cause field. >>>> >>>> share/classes/javax/management/remote/JMXProviderException.java: private Throwable cause = null; >>>> share/classes/javax/xml/crypto/KeySelectorException.java: private Throwable cause; >>>> share/classes/javax/xml/crypto/NoSuchMechanismException.java: private Throwable cause; >>>> share/classes/javax/xml/crypto/MarshalException.java: private Throwable cause; >>>> share/classes/javax/xml/crypto/dsig/XMLSignatureException.java: private Throwable cause; >>>> share/classes/javax/xml/crypto/dsig/TransformException.java: private Throwable cause; >>>> share/classes/javax/xml/crypto/URIReferenceException.java: private Throwable cause; >>>> >>>> 7081804 handles NoSuchMechanismException. >>>> Is there a way to expand it to at least the xml/crypto/**/* Exceptions? >>>> JMXProviderException should be fine too. >>>> >>>> I would create a CR for the changes to me made to change and test this. >>>> Would it be good to have some utility-code in Throwable to don't introduce to much code-duplication? >>>> >>>> -- Sebastian >>> After a very quick analysis i think i found more candidates for removing private causes. >>> share/classes/javax/security/sasl/SaslException.java: private Throwable _exception; >>> share/classes/java/lang/reflect/UndeclaredThrowableException.java: private Throwable undeclaredThrowable; >>> share/classes/java/lang/reflect/InvocationTargetException.java: private Throwable target; >>> share/classes/java/lang/ClassNotFoundException.java: private Throwable ex; >>> share/classes/com/sun/java/browser/dom/DOMAccessException.java: private Throwable ex; >>> share/classes/com/sun/java/browser/dom/DOMUnsupportedException.java: private Throwable ex; >>> share/classes/javax/naming/NamingException.java: protected Throwable rootException = null; >>> share/classes/java/rmi/RemoteException.java: public Throwable detail; >>> share/classes/java/rmi/activation/ActivationException.java: public Throwable detail; >>> >>> Some of them need deeper inspection. Some of them are the same as the above noted Exceptions in xml/crypto package. >>> >>> - Sebastian >> OK. Webrev is there: http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/ >> >> Can someone review this? > Sebastian, > > Public fields like RemoteException.detail, ill-advised as they may have been, cannot be removed (would break binary compatibility). Sorry for that. It was more a reflex (remove "evil" public fields) than a real problem with this. Breaking this would breaking binary compatibility but can this be a real show-stopper for not fixing this? But you are right. Changes with binary incompatibility should be done really carefully. > This change proposes additions to the public API (subclass interface) of java.lang.Throwable, which would need additional approval process. Without getting into detailed design critique, the proposed protected methods seem to add subtle complexity to the subclass interface of this central class, which leads me to: > > Is there a particular problem that these changes are attempting to address? Many of these exception classes had cause-like fields prior to the addition of Throwable.cause in 1.4, and as described in their class docs, for 1.4 they were each retrofitted, with some care, to work well with the general cause APIs added to Throwable. (Also see the doc for Throwable.getCause, which describes how subclasses can override it to take responsibility for their causes.) > > These changes seem to be about implementing an alternate approach to that retrofitting, with considerably higher complexity (serialized form compatibility code) and risk, and I don't understand why-- I don't see a motivation discussed earlier on core-libs-dev? Discussion started at core-libs-dev in another threads[1]. The main-reason was to chain more Exceptions together where possible. I changed the NoSuchMechanismException in javax.xml.crypto while try to chain more Exceptions that extends RuntimeException. I just removed the field, Alan noted that this would change to compatibility and said that this CR should be discussed at security-dev. Additionally he created a bug "7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException"[3] The changes for chained-exceptions in Throwable made to javax/xml/crypto/*Exceptions are not done so well as in the other cases here. So i tried to fix it like here[2]. Alternatively i could fix javax/xml/crypto by adopting the solution used in the other cases. The question i have is what is the best solution that should used. Changing the serialization thought custom serialization or through using the solution used in the other cases? I think we should only have one solution to address this. > Cheers, > > -- Peter > -- Sebastian [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007462.html [2] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_85919cd409d1/ [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7081804 From sebastian.sickelmann at gmx.de Fri Aug 26 04:15:17 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 26 Aug 2011 13:15:17 +0200 Subject: Request for review Remove "private" cause in jdk exceptions In-Reply-To: <4E5749AB.9040705@oracle.com> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E56C6CC.7010305@gmx.de> <4E56CB90.60508@gmx.de> <4E56E235.6010307@gmx.de> <4E5749AB.9040705@oracle.com> Message-ID: <4E578045.1060906@gmx.de> Am 26.08.2011 09:22, schrieb Alan Bateman: > Sebastian Sickelmann wrote: >> >> OK. Webrev is there: >> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/ >> >> >> Can someone review this? > I think this one will require careful review and I'm not even sure > that it's worth it. Using serialPersistentFields and overriding the > readObject/writeObject method is the right thing for this kind of > issue but it's bringing complexity that hardy seems worth it. As Peter noted in his reply there is another solution to handle chaining as introduced in Throwable for Exceptions that already has an own cause field. Like in InvocationTargetException [1]. The Change is much simple and introduces much less complexity, for the cost of one additional reference to the cause (which should be no problem). > There are a few awkward issues in here. I have to admit that I don't > know, without checking, what the deal is with APIs that continued life > as standalone JSRs after going into Java SE. I also suspect that some > of these changes have subtly changed the behavior of a few of the > exceptions. On RemoteException the patch removes a public field which > we can't do. I think the other clean-up patches that you have posted > here in the last week or two are good and we should move forward on them. I will continue on the other issues too. Thanks for reviewing/supporting on my CRs. (Does CR mean Change Request???) -- Sebastian > > -Alan. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/file/37a05a11f281/src/share/classes/java/lang/reflect/InvocationTargetException.java From sean.mullan at oracle.com Fri Aug 26 06:15:48 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Aug 2011 09:15:48 -0400 Subject: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile) In-Reply-To: <4E56FA7C.4010505@oracle.com> References: <4E56A1F7.2070300@oracle.com> <4E56FA7C.4010505@oracle.com> Message-ID: <4E579C84.30407@oracle.com> Looks fine though you missed updating the copyright date on the test. --Sean On 8/25/11 9:44 PM, Weijun Wang wrote: > [ Add security-dev at openjdk.java.net to CC] > > I think so. javax/xml/crypto is public API and it should go to > jdk_security2 (along with javax/crypto). Of course, that is still not > included in the default run. > > I've filed a bug: > > 7083576: add javax/xml/crypto into jdk_security2 test rule > > and here is a webrev: > > http://cr.openjdk.java.net/~weijun/7083576/webrev.00 > > Note that one test now uses /othervm because it loads a SecurityManager > with its own policy file. > > JPRT runs fine except that one windows-i586 job is still initializing. > Ignored. > > Thanks > Max > > On 08/26/2011 03:26 AM, Sean Mullan wrote: >> I noticed that none of the jprt test targets in test/Makefile run tests in the >> javax/xml/crypto directory (i.e. JSR 105 tests) - would that be considered a bug? >> >> --Sean From weijun.wang at oracle.com Fri Aug 26 06:42:11 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Aug 2011 21:42:11 +0800 Subject: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile) In-Reply-To: <4E579C84.30407@oracle.com> References: <4E56A1F7.2070300@oracle.com> <4E56FA7C.4010505@oracle.com> <4E579C84.30407@oracle.com> Message-ID: <4E57A2B3.80203@oracle.com> On 08/26/2011 09:15 PM, Sean Mullan wrote: > Looks fine though you missed updating the copyright date on the test. Recently I form a new habit of not touching copyright years at all, so that a changeset can be ported to another version with no change at all. -Max > > --Sean > > On 8/25/11 9:44 PM, Weijun Wang wrote: >> [ Add security-dev at openjdk.java.net to CC] >> >> I think so. javax/xml/crypto is public API and it should go to >> jdk_security2 (along with javax/crypto). Of course, that is still not >> included in the default run. >> >> I've filed a bug: >> >> 7083576: add javax/xml/crypto into jdk_security2 test rule >> >> and here is a webrev: >> >> http://cr.openjdk.java.net/~weijun/7083576/webrev.00 >> >> Note that one test now uses /othervm because it loads a SecurityManager >> with its own policy file. >> >> JPRT runs fine except that one windows-i586 job is still initializing. >> Ignored. >> >> Thanks >> Max >> >> On 08/26/2011 03:26 AM, Sean Mullan wrote: >>> I noticed that none of the jprt test targets in test/Makefile run tests in the >>> javax/xml/crypto directory (i.e. JSR 105 tests) - would that be considered a bug? >>> >>> --Sean From sean.mullan at oracle.com Fri Aug 26 06:45:22 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Aug 2011 09:45:22 -0400 Subject: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile) In-Reply-To: <4E57A2B3.80203@oracle.com> References: <4E56A1F7.2070300@oracle.com> <4E56FA7C.4010505@oracle.com> <4E579C84.30407@oracle.com> <4E57A2B3.80203@oracle.com> Message-ID: <4E57A372.7060601@oracle.com> On 8/26/11 9:42 AM, Weijun Wang wrote: > > > On 08/26/2011 09:15 PM, Sean Mullan wrote: >> Looks fine though you missed updating the copyright date on the test. > > Recently I form a new habit of not touching copyright years at all, so > that a changeset can be ported to another version with no change at all. Ok, so does that mean someone else will update the copyright later on? --Sean From weijun.wang at oracle.com Fri Aug 26 07:01:46 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Aug 2011 22:01:46 +0800 Subject: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile) In-Reply-To: <4E57A372.7060601@oracle.com> References: <4E56A1F7.2070300@oracle.com> <4E56FA7C.4010505@oracle.com> <4E579C84.30407@oracle.com> <4E57A2B3.80203@oracle.com> <4E57A372.7060601@oracle.com> Message-ID: <4E57A74A.2050106@oracle.com> On 08/26/2011 09:45 PM, Sean Mullan wrote: > On 8/26/11 9:42 AM, Weijun Wang wrote: >> >> >> On 08/26/2011 09:15 PM, Sean Mullan wrote: >>> Looks fine though you missed updating the copyright date on the test. >> >> Recently I form a new habit of not touching copyright years at all, so >> that a changeset can be ported to another version with no change at all. > > Ok, so does that mean someone else will update the copyright later on? Like this: 7033660 Update copyright year to 2011 on any files changed in 2011 http://monaco.sfbay.sun.com/detail.jsf?cr=7033660 -Max > > --Sean From chris.hegarty at oracle.com Fri Aug 26 07:08:25 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 26 Aug 2011 15:08:25 +0100 Subject: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile) In-Reply-To: <4E57A372.7060601@oracle.com> References: <4E56A1F7.2070300@oracle.com> <4E56FA7C.4010505@oracle.com> <4E579C84.30407@oracle.com> <4E57A2B3.80203@oracle.com> <4E57A372.7060601@oracle.com> Message-ID: <4E57A8D9.104@oracle.com> On 08/26/11 02:45 PM, Sean Mullan wrote: > On 8/26/11 9:42 AM, Weijun Wang wrote: >> >> >> On 08/26/2011 09:15 PM, Sean Mullan wrote: >>> Looks fine though you missed updating the copyright date on the test. >> >> Recently I form a new habit of not touching copyright years at all, so >> that a changeset can be ported to another version with no change at all. > > Ok, so does that mean someone else will update the copyright later on? This comes up from time to time, and I've never seen a definitive answer ( unless the answer is do whatever you like ;-) ). There is a script in the repo [1] for updating the copyright year, that is run occasionally. I typically leave it to the script to take care of the updates, but occasionally take it upon myself. I don't think there is a hard and fast rule here, but I stand to be corrected. -Chris [1] http://hg.openjdk.java.net/jdk7/jdk7/file/tip/make/scripts/update_copyright_year.sh > > --Sean From fweimer at bfk.de Fri Aug 26 07:52:54 2011 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 26 Aug 2011 14:52:54 +0000 Subject: Fix for: 6415637: PKCS#12 key stores with empty passwords In-Reply-To: <4E574DF6.6000406@oracle.com> (Weijun Wang's message of "Fri, 26 Aug 2011 15:40:38 +0800") References: <82sjr4ejoz.fsf@mid.bfk.de> <8262lk4oct.fsf@mid.bfk.de> <4E574DF6.6000406@oracle.com> Message-ID: <82fwkoz0l5.fsf@mid.bfk.de> * Weijun Wang: > I think security changeset should go to tl forest first. Is this ? This forest rejects OpenJDK 6 as a bootstrap compiler. Do I need a working build of OpenJDK 7 first? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From weijun.wang at oracle.com Fri Aug 26 08:03:17 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Aug 2011 23:03:17 +0800 Subject: Fix for: 6415637: PKCS#12 key stores with empty passwords In-Reply-To: <82fwkoz0l5.fsf@mid.bfk.de> References: <82sjr4ejoz.fsf@mid.bfk.de> <8262lk4oct.fsf@mid.bfk.de> <4E574DF6.6000406@oracle.com> <82fwkoz0l5.fsf@mid.bfk.de> Message-ID: On Aug 26, 2011, at 10:52 PM, Florian Weimer wrote: > * Weijun Wang: > >> I think security changeset should go to tl forest first. > > Is this ? Yes. > > This forest rejects OpenJDK 6 as a bootstrap compiler. Do I need a > working build of OpenJDK 7 first? Yes, I guess building JDK 8 needs JDK 7 to bootstrap. Also, I always use the Oracle (non-open) JDK as boot JDK or import JDK, not sure if openjdk works, but it should do. -Max > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra?e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 From sean.mullan at oracle.com Fri Aug 26 08:38:35 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Aug 2011 11:38:35 -0400 Subject: 7024771 code review request Message-ID: <4E57BDFB.2060807@oracle.com> Hi Vinnie, Could you review the following webrev: http://cr.openjdk.java.net/~mullan/webrevs/7024771/webrev.00/ A couple of notes on the webrev: - I have removed support for DNs which use <> as delimiters, ex "". This is an obscure syntax that I have never seen used in practice, and our parser wouldn't accept this anyway - we had only partially implemented support for it - which was related to the cause of this bug. - I have also removed some dead code for strict RFC 1779 parsing. It wasn't being used by any other code. Thanks, Sean From kelly.ohair at oracle.com Fri Aug 26 09:59:49 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 26 Aug 2011 09:59:49 -0700 Subject: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile) In-Reply-To: <4E57A8D9.104@oracle.com> References: <4E56A1F7.2070300@oracle.com> <4E56FA7C.4010505@oracle.com> <4E579C84.30407@oracle.com> <4E57A2B3.80203@oracle.com> <4E57A372.7060601@oracle.com> <4E57A8D9.104@oracle.com> Message-ID: <47129229-85A1-40EB-B52A-2619864E51E9@oracle.com> On Aug 26, 2011, at 7:08 AM, Chris Hegarty wrote: > On 08/26/11 02:45 PM, Sean Mullan wrote: >> On 8/26/11 9:42 AM, Weijun Wang wrote: >>> >>> >>> On 08/26/2011 09:15 PM, Sean Mullan wrote: >>>> Looks fine though you missed updating the copyright date on the test. >>> >>> Recently I form a new habit of not touching copyright years at all, so >>> that a changeset can be ported to another version with no change at all. >> >> Ok, so does that mean someone else will update the copyright later on? > > This comes up from time to time, and I've never seen a definitive answer ( unless the answer is do whatever you like ;-) ). > > There is a script in the repo [1] for updating the copyright year, that is run occasionally. I typically leave it to the script to take care of the updates, but occasionally take it upon myself. I don't think there is a hard and fast rule here, but I stand to be corrected. There is no hard and fast rule, and it's ok to leave them alone. I have taken it upon myself to run this script occasionally, but the real responsibility has never been assigned to any one person or group, I hope to correct that. Just not sure who the target of my attempt will be yet. ;^) -kto > > -Chris > > [1] http://hg.openjdk.java.net/jdk7/jdk7/file/tip/make/scripts/update_copyright_year.sh > >> >> --Sean From alan.bateman at oracle.com Fri Aug 26 14:26:13 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 26 Aug 2011 21:26:13 +0000 Subject: hg: jdk8/tl/jdk: 7060243: (dc) Multicasting tests fail on Windows XP if IPv6 is enabled Message-ID: <20110826212638.5FB2B47149@hg.openjdk.java.net> Changeset: 6d2f09eed4e3 Author: alanb Date: 2011-08-26 22:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d2f09eed4e3 7060243: (dc) Multicasting tests fail on Windows XP if IPv6 is enabled Reviewed-by: alanb Contributed-by: kurchi.subhra.hazra at oracle.com ! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java From sebastian.sickelmann at gmx.de Fri Aug 26 14:41:21 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 26 Aug 2011 23:41:21 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E52758D.2020208@oracle.com> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> Message-ID: <4E581301.7010904@gmx.de> Am 22.08.2011 17:28, schrieb Sean Mullan: > (dropping core-libs-dev) > > On 8/22/11 9:03 AM, Sebastian Sickelmann wrote: >> Hi, >> >> while making some change for using exception-chaining on RuntimeException in >> more cases, i found that javax.xml.crypto.NoSuchMechnismException had a private >> cause field that isn't necessary since throwable can handle it. But just >> removing isn't that simple as Alan pointed out[1]. > The history behind this is that this API is part of JSR 105. JSR 105 was > released independently of Java SE as a "standalone JSR" and later integrated > into Java SE 6 as part of the platform JSR. Thus as I understand, all JSR 105 > API changes need to first go through a maintenance revision of JSR 105. > > JSR 105 was designed to be used by applications using JDK 1.2 and up, thus there > are no API dependencies on any releases later than that. Therefore, this class > (and other exception classes in JSR 105) included their own methods to capture > the cause. > > I've been aware of this issue for a little while but I did not have the cycles > to analyze it thoroughly so I am glad you are looking into it. > > I think you will find the same issue in the other Exception classes in the > javax.xml.crypto package and its subpackages. Have you looked at those yet? > > I am not sure if removing the 3 overloaded methods qualifies as an API change. > If so, it would first require it go through a maintenance JSR. I will need to > ask someone else about that and get back to you. I checked it for binary compatibility and source compatibility and it seems to me that both are preserved. So i don't see any reason cause this should be handled as API change. Have you heard something about this topic? I have a discussion with Peter Jones and Alan Bateman in this Thread (swapped over to core-libs-dev again, cause i made bigger CR) there is also a other way of handling cause chaining in a way more like Trowable.cause. I think we should consider to choose this type of change for javax/xml/crypto too. So we got only one pattern how to use Throwable.cause in cases where a cause-chain was available long time before. -- Sebastian From Alan.Bateman at oracle.com Fri Aug 26 14:45:46 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Aug 2011 22:45:46 +0100 Subject: Request-Review: Remove two simple warnings in HttpsURLConnection.java In-Reply-To: <4E58076F.4090500@gmx.de> References: <4E58076F.4090500@gmx.de> Message-ID: <4E58140A.5080203@oracle.com> Sebastian Sickelmann wrote: > Hi, > > is there someone who wants to review / support this simple warning > removal? > > The webrev is: > http://oss-patches.24.eu/openjdk8/Simple_Warning/ > > -- Sebastian* > * This is JSSE so probably best if someone from the security area pushes this for Sebastian. -Alan. From xueming.shen at oracle.com Fri Aug 26 15:25:44 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 26 Aug 2011 22:25:44 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110826222610.C33384714C@hg.openjdk.java.net> Changeset: 973d923af88c Author: sherman Date: 2011-08-26 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/973d923af88c 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field Summary: fixed the wrong size when writing out the cen table for ZIP64 Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/java/util/zip/LargeZip.java Changeset: 9bd06beac455 Author: sherman Date: 2011-08-26 15:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bd06beac455 Merge From xuelei.fan at oracle.com Fri Aug 26 18:01:42 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 27 Aug 2011 09:01:42 +0800 Subject: Request-Review: Remove two simple warnings in HttpsURLConnection.java In-Reply-To: <4E58140A.5080203@oracle.com> References: <4E58076F.4090500@gmx.de> <4E58140A.5080203@oracle.com> Message-ID: <4E5841F6.10908@oracle.com> Hi Sebastian, Thank you for your contribution on OpenJDK. The update looks fine to me. Do you have a CR (Change Request) for this update? BTW, have you signed the Oracle Contribution Agreement [1]? I did not find you name in the OpenJDK people list. Thanks, Xuelei [1] http://openjdk.java.net/contribute/ On 8/27/2011 5:45 AM, Alan Bateman wrote: > Sebastian Sickelmann wrote: >> Hi, >> >> is there someone who wants to review / support this simple warning >> removal? >> >> The webrev is: >> http://oss-patches.24.eu/openjdk8/Simple_Warning/ >> >> -- Sebastian* >> * > This is JSSE so probably best if someone from the security area pushes > this for Sebastian. > > -Alan. From Alan.Bateman at oracle.com Fri Aug 26 23:13:52 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 27 Aug 2011 07:13:52 +0100 Subject: Request-Review: Remove two simple warnings in HttpsURLConnection.java In-Reply-To: <4E5841F6.10908@oracle.com> References: <4E58076F.4090500@gmx.de> <4E58140A.5080203@oracle.com> <4E5841F6.10908@oracle.com> Message-ID: <4E588B20.4060105@oracle.com> Xuelei Fan wrote: > Hi Sebastian, > > Thank you for your contribution on OpenJDK. > > The update looks fine to me. Do you have a CR (Change Request) for this > update? > > BTW, have you signed the Oracle Contribution Agreement [1]? I did not > find you name in the OpenJDK people list. > I don't think there is a specific bug created for this. Sasha made great progress on squashing warnings but I think only got through about half of the security area. There are may be more general bugs created for the remaining areas but I would suggest just creating a specific bug for this. He's listed in the CA signatories file and both Joe Darcy and I have pushed changes for him. -Alan. From xuelei.fan at oracle.com Sat Aug 27 01:27:46 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 27 Aug 2011 16:27:46 +0800 Subject: Request-Review: Remove two simple warnings in HttpsURLConnection.java In-Reply-To: <4E588B20.4060105@oracle.com> References: <4E58076F.4090500@gmx.de> <4E58140A.5080203@oracle.com> <4E5841F6.10908@oracle.com> <4E588B20.4060105@oracle.com> Message-ID: <4E58AA82.3000005@oracle.com> On 8/27/2011 2:13 PM, Alan Bateman wrote: > Xuelei Fan wrote: >> Hi Sebastian, >> >> Thank you for your contribution on OpenJDK. >> >> The update looks fine to me. Do you have a CR (Change Request) for this >> update? >> >> BTW, have you signed the Oracle Contribution Agreement [1]? I did not >> find you name in the OpenJDK people list. >> > I don't think there is a specific bug created for this. Sasha made great > progress on squashing warnings but I think only got through about half > of the security area. There are may be more general bugs created for the > remaining areas but I would suggest just creating a specific bug for this. > I will try to clear up some security warning one or two weeks later. I will create a special CR for this one. > He's listed in the CA signatories file and both Joe Darcy and I have > pushed changes for him. > Good, I will push the changes on behavior of Sebastian. Thanks, Xuelei > -Alan. From xuelei.fan at oracle.com Sat Aug 27 02:18:18 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sat, 27 Aug 2011 09:18:18 +0000 Subject: hg: jdk8/tl/jdk: 7084040: Clearup warning in HttpsURLConnection Message-ID: <20110827091835.6692D47166@hg.openjdk.java.net> Changeset: e4729ad0d7b5 Author: xuelei Date: 2011-08-27 02:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4729ad0d7b5 7084040: Clearup warning in HttpsURLConnection Reviewed-by: xuelei Contributed-by: nsebastian.sickelmann at gmx.de ! src/share/classes/javax/net/ssl/HttpsURLConnection.java From xuelei.fan at oracle.com Sat Aug 27 02:22:44 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 27 Aug 2011 17:22:44 +0800 Subject: Request-Review: Remove two simple warnings in HttpsURLConnection.java In-Reply-To: <4E58AA82.3000005@oracle.com> References: <4E58076F.4090500@gmx.de> <4E58140A.5080203@oracle.com> <4E5841F6.10908@oracle.com> <4E588B20.4060105@oracle.com> <4E58AA82.3000005@oracle.com> Message-ID: <4E58B764.1010404@oracle.com> The fix was integrated into OpenJDK 8. http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4729ad0d7b5 Sebastian, thank you for the contribution. Xuelei On 8/27/2011 4:27 PM, Xuelei Fan wrote: > On 8/27/2011 2:13 PM, Alan Bateman wrote: >> Xuelei Fan wrote: >>> Hi Sebastian, >>> >>> Thank you for your contribution on OpenJDK. >>> >>> The update looks fine to me. Do you have a CR (Change Request) for this >>> update? >>> >>> BTW, have you signed the Oracle Contribution Agreement [1]? I did not >>> find you name in the OpenJDK people list. >>> >> I don't think there is a specific bug created for this. Sasha made great >> progress on squashing warnings but I think only got through about half >> of the security area. There are may be more general bugs created for the >> remaining areas but I would suggest just creating a specific bug for this. >> > I will try to clear up some security warning one or two weeks later. I > will create a special CR for this one. > >> He's listed in the CA signatories file and both Joe Darcy and I have >> pushed changes for him. >> > Good, I will push the changes on behavior of Sebastian. > > Thanks, > Xuelei > >> -Alan. > From xuelei.fan at oracle.com Sat Aug 27 06:51:01 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 27 Aug 2011 21:51:01 +0800 Subject: Move forward to use java logging in Oracle JSSE provider Message-ID: <4E58F645.5060007@oracle.com> Hi, At present, Oracle JSSE provider, SunJSSE, uses hard coded System.out to logger the debug information, with Java option "javax.net.debug". The benefit of the debug mechanism is that it is simple and straightforward. The drawback is that it is hard to redirect to other output stream, hard to parse in multi-threads environment[2], and hard to customize the output[3]. It might be the time to move forward to use java.util.logging in SunJSSE, so that SunJSSE would benefit from the framework of java.util.logging. We may concern about the following issues: 1. the performance impact. I would suggest use the coding style: if (logger != null && logger.isLoggable(Level.WARNING)) { logger.warning(...); } When the logging is turned off, the "logger" will be set to "null", so that there is no additional performance impact. Java logging uses fine granulated logging level, as would filter out a lot of unnecessary log information for some configurations. 2. compatibility issue We would continue support java option, "javax.net.debug". But the log output may change. For example, in the past, one log item may look like: keyStore provider is: jks In the new implementation, we may add additional thread ID and time-stamp, it may be changed to: CONFIG: [TH: 9] 2011-08-26 20:48:28.754 PDT keyStore provider is: jsk One more example, in the past, the log ClientHello message may look like: *** ClientHello, TLSv1.1 RandomCookie: GMT: 1314416910 bytes = { 80, 11, 21, 95, 232, 11, 193, 233, 222, 34, 181, 50, 37, 221, 149, 179, 54, 73, 187, 233, 68, 31, 63, 36, 171, 66, 75, 117} Session ID: {} Cipher Suites: [TLS_RSA_WITH_AES_128_CBC_SHA] Extension renegotiation_info, renegotiated_connection: *** In the new implementation, it may be changed to: INFO: [TH: 10] 2011-08-26 20:48:30.460 PDT ClientHello, TLSv1.1 { RandomCookie: GMT: 1314416910 bytes = {30:0B:....} Session ID: {} Cipher Suites: [TLS_RSA_WITH_AES_128_CBC_SHA] Extension renegotiation_info, renegotiated_connection: } 3. compatibility issue, continue If java option "javax.net.debug" is defined, the debug options (see [1] for the define of the option) may be mapped to three logger: logger "javax.net.ssl.handshake" will support the following debug options: handshake, keygen, session, seesioncache. logger "javax.net.ssl.managerment" will support debug options: keymanager, trustmanager, sslctx, defaultctx. logger "javax.net.ssl" will support all other debug options. 4. compatibility issue, more continue If java option "javax.net.debug" is defined, as past, System.out will be log output stream unless there is customized logger configurations for above loggers. 5. default implementation SunJSSE will only implement the logger handler to support "javax.net.debug" option, application is free to define/customize its own logging handler. There is a prototype for your reference, http://cr.openjdk.java.net/~xuelei/7013776/webrev/. Your comment is welcome. Thanks, Xuelei [1]: the usage of "javax.net.debug" option: ------------------------ $ java -Djavax.net.debug=help Foo all turn on all debugging ssl turn on ssl debugging The following can be used with ssl: record enable per-record tracing handshake print each handshake message keygen print key generation data session print session activity defaultctx print default SSL initialization sslctx print SSLContext tracing sessioncache print session cache tracing keymanager print key manager tracing trustmanager print trust manager tracing pluggability print pluggability tracing handshake debugging can be widened with: data hex dump of each handshake message verbose verbose handshake message printing record debugging can be widened with: plaintext hex dump of record plaintext packet print raw SSL/TLS packets ------------------------ [2]: http://monaco.us.oracle.com/detail.jsf?cr=7013776 [3]:http://sim.ivi.co/2009/05/these-days-i-was-asked-about-strange.html From alan.bateman at oracle.com Sat Aug 27 08:13:50 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 27 Aug 2011 15:13:50 +0000 Subject: hg: jdk8/tl/jdk: 7060790: (fs) FileSystem.newWatchService error message confusing when maximum inotify descriptors reached Message-ID: <20110827151410.DCB4347173@hg.openjdk.java.net> Changeset: 83add4632b49 Author: alanb Date: 2011-08-27 15:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83add4632b49 7060790: (fs) FileSystem.newWatchService error message confusing when maximum inotify descriptors reached Reviewed-by: forax ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/native/sun/nio/fs/genUnixConstants.c From Xuelei.Fan at Oracle.Com Sat Aug 27 17:21:29 2011 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Sun, 28 Aug 2011 08:21:29 +0800 Subject: hg: jdk8/tl/jdk: 7084040: Clearup warning in HttpsURLConnection In-Reply-To: <20110827091835.6692D47166@hg.openjdk.java.net> References: <20110827091835.6692D47166@hg.openjdk.java.net> Message-ID: Sorry that there is a typo of the email address of the contributor. The mail address should be sebastian.sickelmann at gmx.de. My apologies for my mistake. Xuelei On Aug 27, 2011, at 5:18 PM, xuelei.fan at oracle.com wrote: > Changeset: e4729ad0d7b5 > Author: xuelei > Date: 2011-08-27 02:17 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4729ad0d7b5 > > 7084040: Clearup warning in HttpsURLConnection > Reviewed-by: xuelei > Contributed-by: nsebastian.sickelmann at gmx.de > > ! src/share/classes/javax/net/ssl/HttpsURLConnection.java > From xuelei.fan at oracle.com Sun Aug 28 03:36:39 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 28 Aug 2011 18:36:39 +0800 Subject: Code review request: 7059542 JNDI name operations should be locale independent In-Reply-To: <4E3605D6.5020305@oracle.com> References: <4E27D4C1.1030608@oracle.com> <4E2CBB3B.8070405@oracle.com> <4E340CA6.4060405@oracle.com> <4E3605D6.5020305@oracle.com> Message-ID: <4E5A1A37.6040402@oracle.com> Hi Weijun, Would you please review the new update? I also include the changes in security components. webrev: webrev: http://cr.openjdk.java.net/~xuelei/7059542/webrev.01/ Thanks, Xuelei On 8/1/2011 9:48 AM, Xuelei Fan wrote: > Hi Weijun, > > Please pending the code review. Another thread is addressing the warning > issues in JNDI, I will wait for a while to remove the warning update > from this fix. > > Thanks, > Xuelei > > On 7/30/2011 9:52 PM, Xuelei Fan wrote: >> Hi Weijun, >> >> It was "test/javax/naming/ldap/LdapName/CompareToEqualsTests fails >> intermittently". I updated the synopsis to "JNDI name operations should >> be locale independent" when found the underlying failure problem. >> >> Would you please review the JNDI update when you available? The fix also >> include Alan's fix of JNDI compiler warnings. >> >> Thanks, >> Xuelei >> >> On 7/25/2011 8:39 AM, Xuelei Fan wrote: >>> Ping ... >>> >>> Xuelei >>> >>> On 7/21/2011 3:26 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> In JNDI implementation, String.toUpperCase() and String.toLowerCase() is >>>> used to compare or hashcode case-insensitive strings. These operations >>>> are locale dependent, and may result in unexpected behaviors in some >>>> locale.[1] >>>> >>>> This fix is try to interpret case-insensitive string locale >>>> independently in JNDI component. >>>> >>>> webrev: http://cr.openjdk.java.net/~xuelei/7059542/webrev.00/ >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> [1]: http://sim.ivi.co/2011/07/trap-of-case-insensitive-string.html >>> >> > From sebastian.sickelmann at gmx.de Sun Aug 28 12:35:58 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sun, 28 Aug 2011 21:35:58 +0200 Subject: Request for review: 7084245: Update usages of InternalError to use exception chaining Message-ID: <4E5A989E.8070103@gmx.de> Hi, here is a webrev[1] for some cleanup that i want to integrated in tl-repositories. Alan Bateman had scanned the changes and gave me some good input[3] for further discussion here: The changes to java.util.concurrent should go through Doug Lea's upstream CVS. Alan told me that Chris Hegarty is on this topic already. The suggested changes for this is here[2]. I have changed some classes in awt / sun.java2d maybe someone of the 2d-dev maillinglist can look at these changes. I also changed some classes in java/securtiy maybe someone of security-dev maillinglist can look at these changes. Let me know if there is a need to split/rebase the main-webrev[1] to review and/or push it individually. Mostly the patch changes exception-chains. But there are some places where the patch changes behavoir: - I removed some printstackTraces in sun.java2d.pipe.LoopPipe.getStrokesSpans and sun.misc.Launcher (Alan told me that kumar maybe want to have a look at it?). - I changed java.text.Format.clone not to return null. I think it will never happen. But if so throwing an InternalError seems to be better than returning null and let all the extended classes crash in there clone Method with a NullPointerException. And so catching an Exception in java.text.DecimalFormat.clone is unnecessary. -- Sebastian [1] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_0/ [2] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/ [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007563.html From neugens.limasoftware at gmail.com Sun Aug 28 13:54:49 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 28 Aug 2011 22:54:49 +0200 Subject: [OpenJDK 2D-Dev] Request for review: 7084245: Update usages of InternalError to use exception chaining In-Reply-To: <4E5A989E.8070103@gmx.de> References: <4E5A989E.8070103@gmx.de> Message-ID: <1314564891.2813.8.camel@galactica> Il giorno dom, 28/08/2011 alle 21.35 +0200, Sebastian Sickelmann ha scritto: > Hi, here is a webrev[1] for some cleanup that i want to integrated in > tl-repositories. Hi, The patch seems good for me (speaking in particular about the AWT/2D part), and I don't think it will introduce any side effects. Just a note: src/share/classes/java/lang/invoke/CallSite.java: } catch (ReflectiveOperationException ignore) { - throw new InternalError(); + throw new InternalError(ignore); } Being a refactoring patch, I would not change the name from "ignore" to the more classical "e", since we are not ignoring the exception anymore. Also in src/share/classes/com/sun/servicetag/BrowserSupport.java, it seems to me that you can also aggregate the InvocationTargetException in the multi catch. In fact, the block could be probably rewritten to take advantage of ReflectiveOperationException. Same for src/share/classes/sun/misc/Launcher.java, src/share/classes/sun/security/util/SecurityConstants.java and src/share/classes/sun/tracing/dtrace/DTraceProvider.java Cheers, Mario From weijun.wang at oracle.com Sun Aug 28 23:33:04 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 29 Aug 2011 14:33:04 +0800 Subject: Code review request: 7059542 JNDI name operations should be locale independent In-Reply-To: <4E5A1A37.6040402@oracle.com> References: <4E27D4C1.1030608@oracle.com> <4E2CBB3B.8070405@oracle.com> <4E340CA6.4060405@oracle.com> <4E3605D6.5020305@oracle.com> <4E5A1A37.6040402@oracle.com> Message-ID: <4E5B32A0.4040006@oracle.com> The code changes look fine, and thanks for including the sun/security/{tools,krb5} codes. -Max On 08/28/2011 06:36 PM, Xuelei Fan wrote: > Hi Weijun, > > Would you please review the new update? I also include the changes in > security components. > > webrev: webrev: http://cr.openjdk.java.net/~xuelei/7059542/webrev.01/ > > Thanks, > Xuelei > > On 8/1/2011 9:48 AM, Xuelei Fan wrote: >> Hi Weijun, >> >> Please pending the code review. Another thread is addressing the warning >> issues in JNDI, I will wait for a while to remove the warning update >> from this fix. >> >> Thanks, >> Xuelei >> >> On 7/30/2011 9:52 PM, Xuelei Fan wrote: >>> Hi Weijun, >>> >>> It was "test/javax/naming/ldap/LdapName/CompareToEqualsTests fails >>> intermittently". I updated the synopsis to "JNDI name operations should >>> be locale independent" when found the underlying failure problem. >>> >>> Would you please review the JNDI update when you available? The fix also >>> include Alan's fix of JNDI compiler warnings. >>> >>> Thanks, >>> Xuelei >>> >>> On 7/25/2011 8:39 AM, Xuelei Fan wrote: >>>> Ping ... >>>> >>>> Xuelei >>>> >>>> On 7/21/2011 3:26 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> In JNDI implementation, String.toUpperCase() and String.toLowerCase() is >>>>> used to compare or hashcode case-insensitive strings. These operations >>>>> are locale dependent, and may result in unexpected behaviors in some >>>>> locale.[1] >>>>> >>>>> This fix is try to interpret case-insensitive string locale >>>>> independently in JNDI component. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~xuelei/7059542/webrev.00/ >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> [1]: http://sim.ivi.co/2011/07/trap-of-case-insensitive-string.html >>>> >>> >> > From fweimer at bfk.de Mon Aug 29 04:24:28 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 29 Aug 2011 11:24:28 +0000 Subject: Review request for 7020513 : Add com.sun.xml.internal to the "package.access" property in java.security In-Reply-To: <4D654E60.9070106@oracle.com> (Rama Pulavarthi's message of "Wed, 23 Feb 2011 10:13:52 -0800") References: <4D64558A.6040807@oracle.com> <4D64C8EF.2050101@oracle.com> <4D654E60.9070106@oracle.com> Message-ID: <8239gkqx3n.fsf@mid.bfk.de> * Rama Pulavarthi: > Just porting the fix along with tests from Open JDK 6 workspace, > that's why I kept the old date. Does it need to be changed? This test > was added then following the convention of other tests. I will check > other tests in JDK 7 to see if it needs any update. I see that the test was dropped in the final webrev and the commit (cfc05963734e). Was this intentional? The Makefile changes are still present, though. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From xuelei.fan at oracle.com Mon Aug 29 05:11:03 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 29 Aug 2011 05:11:03 -0700 (PDT) Subject: Request for review: 7084245: Update usages of InternalError to use exception chaining In-Reply-To: <4E5A989E.8070103@gmx.de> References: <4E5A989E.8070103@gmx.de> Message-ID: <4E5B81D7.1060002@oracle.com> I reviewed the security part. In general, it looks fine. But sometimes, from my very personal view, the exception-chain might be over used. For example, the following code: try { md = MessageDigest.getInstance("SHA"); } catch (NoSuchAlgorithmException nsae) { throw new InternalError("internal error: SHA-1 not available."); } The exception message and stack is simple and easy to understand. If using exception-chain, the message chain looks like: "internal error: SHA-1 not available." -> "SHA ... not available"" I think the information is redundant, and expose unnecessary call stack. Exceptions thrown by a method should be defined at an abstraction level consistent with what the method does, not necessarily with the low-level details of how it is implemented. Please also refer to item 61, "Throw exceptions appropriate to the abstraction", in "Effective Java 2nd Editor". It seems that the webrev offline now, I cannot access it. Thanks, Xuelei On 8/29/2011 3:35 AM, Sebastian Sickelmann wrote: > Hi, here is a webrev[1] for some cleanup that i want to integrated in > tl-repositories. > > Alan Bateman had scanned the changes and gave me some good input[3] for > further discussion here: > > The changes to java.util.concurrent should go through Doug Lea's > upstream CVS. Alan told me that Chris Hegarty is on this topic already. > The suggested changes for this is here[2]. > > I have changed some classes in awt / sun.java2d maybe someone of the > 2d-dev maillinglist can look at these changes. > I also changed some classes in java/securtiy maybe someone of > security-dev maillinglist can look at these changes. > > Let me know if there is a need to split/rebase the main-webrev[1] to > review and/or push it individually. > > Mostly the patch changes exception-chains. But there are some places > where the patch changes behavoir: > > - I removed some printstackTraces in > sun.java2d.pipe.LoopPipe.getStrokesSpans and sun.misc.Launcher (Alan > told me that kumar maybe want to have a look at it?). > - I changed java.text.Format.clone not to return null. I think it will > never happen. But if so throwing an InternalError seems to be better > than returning null and let all the extended classes crash in there > clone Method with a NullPointerException. And so catching an Exception > in java.text.DecimalFormat.clone is unnecessary. > > -- Sebastian > > [1] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_0/ > [2] > http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/ > [3] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007563.html > From vincent.x.ryan at oracle.com Mon Aug 29 05:42:04 2011 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 29 Aug 2011 13:42:04 +0100 Subject: 7024771 code review request In-Reply-To: <4E57BDFB.2060807@oracle.com> References: <4E57BDFB.2060807@oracle.com> Message-ID: <4E5B891C.2060706@oracle.com> Your fix looks fine. On 08/26/11 04:38 PM, Sean Mullan wrote: > Hi Vinnie, > > Could you review the following webrev: > > http://cr.openjdk.java.net/~mullan/webrevs/7024771/webrev.00/ > > A couple of notes on the webrev: > > - I have removed support for DNs which use <> as delimiters, ex "". This > is an obscure syntax that I have never seen used in practice, and our parser > wouldn't accept this anyway - we had only partially implemented support for it - > which was related to the cause of this bug. > > - I have also removed some dead code for strict RFC 1779 parsing. It wasn't > being used by any other code. > > Thanks, > Sean From xuelei.fan at oracle.com Mon Aug 29 05:56:22 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 29 Aug 2011 12:56:22 +0000 Subject: hg: jdk8/tl/jdk: 7059542: JNDI name operations should be locale independent Message-ID: <20110829125644.4A6A5471D1@hg.openjdk.java.net> Changeset: 02c2d38f4271 Author: xuelei Date: 2011-08-29 05:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/02c2d38f4271 7059542: JNDI name operations should be locale independent Reviewed-by: weijun ! src/share/classes/com/sun/jndi/ldap/ClientId.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/jndi/toolkit/dir/HierMemDirCtx.java ! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/share/classes/com/sun/security/ntlm/NTLM.java ! src/share/classes/java/security/KeyRep.java ! src/share/classes/java/security/Security.java ! src/share/classes/javax/naming/NameImpl.java ! src/share/classes/javax/naming/directory/BasicAttributes.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/provider/JavaKeyStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/tools/KeyStoreUtil.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java ! test/javax/naming/ldap/LdapName/CompareToEqualsTests.java From sean.mullan at oracle.com Mon Aug 29 10:41:27 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 29 Aug 2011 17:41:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110829174147.1BB9F471E4@hg.openjdk.java.net> Changeset: d1c04dac850d Author: mullan Date: 2011-08-29 12:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1c04dac850d 7024771: "\\<>" in attribute value part of X500Principal constructor parameter makes strange effect Reviewed-by: vinnie ! src/share/classes/sun/security/x509/AVA.java ! src/share/classes/sun/security/x509/X500Name.java + test/javax/security/auth/x500/X500Principal/Parse.java Changeset: c2b4e0ea3ab9 Author: mullan Date: 2011-08-29 12:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2b4e0ea3ab9 Merge ! src/share/classes/sun/security/x509/X500Name.java From kumar.x.srinivasan at oracle.COM Mon Aug 29 11:04:43 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 29 Aug 2011 11:04:43 -0700 Subject: Request for review: 7084245: Update usages of InternalError to use exception chaining In-Reply-To: <4E5A989E.8070103@gmx.de> References: <4E5A989E.8070103@gmx.de> Message-ID: <4E5BD4BB.7070107@oracle.COM> Hi, Sorry for the delay, was on vacation...comment inlined. > Hi, here is a webrev[1] for some cleanup that i want to integrated in > tl-repositories. > > Alan Bateman had scanned the changes and gave me some good input[3] > for further discussion here: > > The changes to java.util.concurrent should go through Doug Lea's > upstream CVS. Alan told me that Chris Hegarty is on this topic > already. The suggested changes for this is here[2]. > > I have changed some classes in awt / sun.java2d maybe someone of the > 2d-dev maillinglist can look at these changes. > I also changed some classes in java/securtiy maybe someone of > security-dev maillinglist can look at these changes. > > Let me know if there is a need to split/rebase the main-webrev[1] to > review and/or push it individually. > > Mostly the patch changes exception-chains. But there are some places > where the patch changes behavoir: > > - I removed some printstackTraces in > sun.java2d.pipe.LoopPipe.getStrokesSpans and sun.misc.Launcher (Alan > told me that kumar maybe want to have a look at it?). The methods in question in sun.misc.Launcher are not called by the java launcher, I think these were added to facilitate the JavaWebstart Launcher javaws. Nevertheless, the changes look good to me. Thanks Kumar > - I changed java.text.Format.clone not to return null. I think it will > never happen. But if so throwing an InternalError seems to be better > than returning null and let all the extended classes crash in there > clone Method with a NullPointerException. And so catching an Exception > in java.text.DecimalFormat.clone is unnecessary. > > -- Sebastian > > [1] http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_0/ > [2] > http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_concurrent_0/ > [3] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007563.html From weijun.wang at oracle.com Mon Aug 29 19:46:54 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 30 Aug 2011 02:46:54 +0000 Subject: hg: jdk8/tl/jdk: 7083576: add javax/xml/crypto into jdk_security2 Message-ID: <20110830024704.BF422471FA@hg.openjdk.java.net> Changeset: 6d6d75421e8a Author: weijun Date: 2011-08-30 10:46 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d6d75421e8a 7083576: add javax/xml/crypto into jdk_security2 Reviewed-by: mullan ! test/Makefile ! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java From weijun.wang at oracle.com Mon Aug 29 21:56:48 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 30 Aug 2011 12:56:48 +0800 Subject: code review request: 7081783: jarsigner error when no $HOME/.keystore Message-ID: <4E5C6D90.4050204@oracle.com> Hi All 7081783: jarsigner error when no $HOME/.keystore Webrev is at -- http://cr.openjdk.java.net/~weijun/7081783/webrev.00/ Description: jarsigner includes a certpath validation check, and shows a warning when the check fails. The CertPathValidator object, unfortunately, is initialized in a method that can only be executed if a local keystore is found (either ~/.keystore or specified by -keystore). Therefore, if there is no local keystore but the jarfile's signer can be directly verified by a cert in cacerts, we still see: Warning: This jar contains entries whose certificate chain is not validated. The code changes make sure the CertPathValidator object is always initialized. For reg test, it's a simple call -- ${TESTJAVA}${FS}bin${FS}jarsigner \ -J-Duser.home=. \ -verify -strict ${TESTSRC}${FS}bootstrap.jar Here I override user.home so that even if the test machine has a ./keystore, it won't be affected. The bootstrap.jar file is a small signed jar that is signed by a real CA that can be chained into an item in cacerts. Thanks Max From sebastian.sickelmann at gmx.de Mon Aug 29 22:59:54 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 30 Aug 2011 07:59:54 +0200 Subject: [OpenJDK 2D-Dev] Request for review: 7084245: Update usages of InternalError to use exception chaining In-Reply-To: <1314564891.2813.8.camel@galactica> References: <4E5A989E.8070103@gmx.de> <1314564891.2813.8.camel@galactica> Message-ID: <4E5C7C5A.9020601@gmx.de> Am 28.08.2011 22:54, schrieb Mario Torre: > Il giorno dom, 28/08/2011 alle 21.35 +0200, Sebastian Sickelmann ha > scritto: >> Hi, here is a webrev[1] for some cleanup that i want to integrated in >> tl-repositories. > Hi, Hi created a new webrev with your suggested changes at: http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_1/ I have created some comments inline in this mail. > The patch seems good for me (speaking in particular about the AWT/2D > part), and I don't think it will introduce any side effects. > > Just a note: > > src/share/classes/java/lang/invoke/CallSite.java: > > } catch (ReflectiveOperationException ignore) { > - throw new InternalError(); > + throw new InternalError(ignore); > } > > Being a refactoring patch, I would not change the name from "ignore" to > the more classical "e", since we are not ignoring the exception anymore. > > Also in src/share/classes/com/sun/servicetag/BrowserSupport.java, it > seems to me that you can also aggregate the InvocationTargetException in > the multi catch. I think we should not make further aggregating on InvocationTargetException in this patch. It changes behavoir. Which of the two places to you mean we can aggregate into multi catch? > In fact, the block could be probably rewritten to take advantage of > ReflectiveOperationException. > > Same for src/share/classes/sun/misc/Launcher.java, > src/share/classes/sun/security/util/SecurityConstants.java and > src/share/classes/sun/tracing/dtrace/DTraceProvider.java Changed that to ReflectiveOperationException. > Cheers, > Mario > -- Sebastian From weijun.wang at oracle.com Tue Aug 30 00:34:52 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 30 Aug 2011 15:34:52 +0800 Subject: code review request: 7083664: test hard code of using c:/temp but this dir might not exist Message-ID: <4E5C929C.9080305@oracle.com> Hi All 7083664: test hard code of using c:/temp but this dir might not exist Webrev is at -- http://cr.openjdk.java.net/~weijun/7083664/webrev.00/ Some of our regression tests set TMP variables on different platforms, and on Windows, it's c:\temp. Unfortunately one of the test machines does not have this directory and a call to zip fails. This fix simply removes all TMP setting lines in security-related tests. Most are in sun/security/tools, with the exception of lib/security/java.policy/Ext_AllPolicy.sh My opinion is that touching TMP is simply a bad idea. A JPRT run also shows it's not needed. I remember there was a time that a certain test harness using by the SQE team stripped all existing environment variables, and caused troubles when a test needed it. Little by little, the harness added some variables and the tests were happy. I don't know if this code change will break it, but I'm optimistic because in most other parts of OpenJDK, shell script tests do not set TMP. Or maybe that test harness (forget the name) is already not in use. Webrev for closed tests will go in another mail. Thanks Max From weijun.wang at oracle.com Tue Aug 30 05:26:20 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 30 Aug 2011 20:26:20 +0800 Subject: code review request: 7081411: Change more keytool -genkeypair to RSA Message-ID: <4E5CD6EC.6000201@oracle.com> Hi All 7081411: Change more keytool -genkeypair to RSA http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7081411 Webrev at http://cr.openjdk.java.net/~weijun/7081411/webrev.01/ Because of the Solaris DSA bug described in 7041639, we keep seeing tests generating DSA key pairs failing. Therefore I'm changing most keypair generation to use RSA instead. In all code changes, KeyToolTest.java is called by standard.sh, which makes so many "keytool -genkeypair" calls that I decide to add "-keysize 512" to make it fast. Please note that in this test there are still explicit calls to "-genkeypair -keyalg dsa". These still have a chance to fail on Solaris, but I like to keep them there to make the test complete. Code changes in the closed repo will be sent in another mail. Thanks Max From michael.x.mcmahon at oracle.com Tue Aug 30 06:41:53 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 30 Aug 2011 13:41:53 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110830134225.AFE1F47215@hg.openjdk.java.net> Changeset: fe205518c3a7 Author: michaelm Date: 2011-08-30 14:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe205518c3a7 7084560: Crash in net.dll Reviewed-by: chegar Contributed-by: luchsh at linux.vnet.ibm.com ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c Changeset: ef4f24534a96 Author: michaelm Date: 2011-08-30 14:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef4f24534a96 Merge From xuelei.fan at oracle.com Tue Aug 30 06:52:29 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 30 Aug 2011 21:52:29 +0800 Subject: code review request: 7081783: jarsigner error when no $HOME/.keystore In-Reply-To: <4E5C6D90.4050204@oracle.com> References: <4E5C6D90.4050204@oracle.com> Message-ID: <4E5CEB1D.2010007@oracle.com> 1. Do you want to add more debug info? line 1509-1511: + if (debug) { + e.printStackTrace(); + } 2. It looks a little strange to me that even if there is Runtime exception, we still do some additional work in final block. 3. I try hard to understand the code how to solve the issue. It is not easy for me to understand why the update works. I'm thinking, is it possible to ignore user_home/.keystore instead of try to load it when the file does not exist (File.exists() or catch FileNotFoundException, etc)? The current logic is, "loading keystore from user_home/.keystore". Can we change to use a refined logic, "if user_home/.keystore exists, we load the keysore; otherwise, ignore it". I'm not sure the new logic get the code more complicated, or more intuitive. Xuelei On 8/30/2011 12:56 PM, Weijun Wang wrote: > Hi All > > 7081783: jarsigner error when no $HOME/.keystore > > Webrev is at -- > http://cr.openjdk.java.net/~weijun/7081783/webrev.00/ > > Description: > > jarsigner includes a certpath validation check, and shows a warning when > the check fails. The CertPathValidator object, unfortunately, is > initialized in a method that can only be executed if a local keystore is > found (either ~/.keystore or specified by -keystore). Therefore, if > there is no local keystore but the jarfile's signer can be directly > verified by a cert in cacerts, we still see: > > Warning: > This jar contains entries whose certificate chain is not validated. > > The code changes make sure the CertPathValidator object is always > initialized. > > For reg test, it's a simple call -- > > ${TESTJAVA}${FS}bin${FS}jarsigner \ > -J-Duser.home=. \ > -verify -strict ${TESTSRC}${FS}bootstrap.jar > > Here I override user.home so that even if the test machine has a > ./keystore, it won't be affected. The bootstrap.jar file is a small > signed jar that is signed by a real CA that can be chained into an item > in cacerts. > > Thanks > Max > From xuelei.fan at oracle.com Tue Aug 30 07:01:00 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 30 Aug 2011 22:01:00 +0800 Subject: code review request: 7083664: test hard code of using c:/temp but this dir might not exist In-Reply-To: <4E5C929C.9080305@oracle.com> References: <4E5C929C.9080305@oracle.com> Message-ID: <4E5CED1C.8020201@oracle.com> > but I'm optimistic because in most other parts of > OpenJDK, shell script tests do not set TMP. I normally only set the variables when the test need it explicitly. So I'm also optimistic about your changes. Looks fine to me. Xuelei On 8/30/2011 3:34 PM, Weijun Wang wrote: > Hi All > > 7083664: test hard code of using c:/temp but this dir might not exist > > Webrev is at -- > > http://cr.openjdk.java.net/~weijun/7083664/webrev.00/ > > Some of our regression tests set TMP variables on different platforms, > and on Windows, it's c:\temp. Unfortunately one of the test machines > does not have this directory and a call to zip fails. > > This fix simply removes all TMP setting lines in security-related tests. > Most are in sun/security/tools, with the exception of > > lib/security/java.policy/Ext_AllPolicy.sh > > My opinion is that touching TMP is simply a bad idea. A JPRT run also > shows it's not needed. > > I remember there was a time that a certain test harness using by the SQE > team stripped all existing environment variables, and caused troubles > when a test needed it. Little by little, the harness added some > variables and the tests were happy. I don't know if this code change > will break it, but I'm optimistic because in most other parts of > OpenJDK, shell script tests do not set TMP. Or maybe that test harness > (forget the name) is already not in use. > > Webrev for closed tests will go in another mail. > > Thanks > Max > From xuelei.fan at oracle.com Tue Aug 30 07:36:56 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 30 Aug 2011 22:36:56 +0800 Subject: code review request: 7081411: Change more keytool -genkeypair to RSA In-Reply-To: <4E5CD6EC.6000201@oracle.com> References: <4E5CD6EC.6000201@oracle.com> Message-ID: <4E5CF588.3010607@oracle.com> The update, in both open and closed repositories, looks fine to me. However, the following reason cannot convince me of the necessity to make the change. > Because of the Solaris DSA bug described in 7041639, we keep seeing > tests generating DSA key pairs failing. Therefore I'm changing most > keypair generation to use RSA instead. Most of the updated tests using the default key algorithm ("DSA"). I'm thinking, shall we replace "RSA" back with "DSA" again when there is a RSA bug in the native libraries in the future? It may be not a good choice to cut the tests to fit problematic platform. These tests are also very good test to find the potential problems, right? When we change the test to be able to passed on all platform, the test may lost it function to find potential issues partially. Just my very personal view. Thanks, Xuelei On 8/30/2011 8:26 PM, Weijun Wang wrote: > Hi All > > 7081411: Change more keytool -genkeypair to RSA > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7081411 > > Webrev at http://cr.openjdk.java.net/~weijun/7081411/webrev.01/ > > Because of the Solaris DSA bug described in 7041639, we keep seeing > tests generating DSA key pairs failing. Therefore I'm changing most > keypair generation to use RSA instead. > > In all code changes, KeyToolTest.java is called by standard.sh, which > makes so many "keytool -genkeypair" calls that I decide to add "-keysize > 512" to make it fast. Please note that in this test there are still > explicit calls to "-genkeypair -keyalg dsa". These still have a chance > to fail on Solaris, but I like to keep them there to make the test > complete. > > Code changes in the closed repo will be sent in another mail. > > Thanks > Max > From kelly.ohair at oracle.com Tue Aug 30 09:05:32 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 30 Aug 2011 09:05:32 -0700 Subject: code review request: 7083664: test hard code of using c:/temp but this dir might not exist In-Reply-To: <4E5C929C.9080305@oracle.com> References: <4E5C929C.9080305@oracle.com> Message-ID: <01B89F77-17CE-4B03-A979-6BE4C020D338@oracle.com> Looks ok to me. -kto On Aug 30, 2011, at 12:34 AM, Weijun Wang wrote: > Hi All > > 7083664: test hard code of using c:/temp but this dir might not exist > > Webrev is at -- > > http://cr.openjdk.java.net/~weijun/7083664/webrev.00/ > > Some of our regression tests set TMP variables on different platforms, and on Windows, it's c:\temp. Unfortunately one of the test machines does not have this directory and a call to zip fails. > > This fix simply removes all TMP setting lines in security-related tests. Most are in sun/security/tools, with the exception of > > lib/security/java.policy/Ext_AllPolicy.sh > > My opinion is that touching TMP is simply a bad idea. A JPRT run also shows it's not needed. > > I remember there was a time that a certain test harness using by the SQE team stripped all existing environment variables, and caused troubles when a test needed it. Little by little, the harness added some variables and the tests were happy. I don't know if this code change will break it, but I'm optimistic because in most other parts of OpenJDK, shell script tests do not set TMP. Or maybe that test harness (forget the name) is already not in use. > > Webrev for closed tests will go in another mail. > > Thanks > Max > From xueming.shen at oracle.com Tue Aug 30 11:38:05 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 30 Aug 2011 18:38:05 +0000 Subject: hg: jdk8/tl/jdk: 7084245: Update usages of InternalError to use exception chaining Message-ID: <20110830183814.F1AB147230@hg.openjdk.java.net> Changeset: 8a51f0e24380 Author: sherman Date: 2011-08-30 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a51f0e24380 7084245: Update usages of InternalError to use exception chaining Summary: to use new InternalError constructor with cause chainning Reviewed-by: alanb, ksrini, xuelei, neugens Contributed-by: sebastian.sickelmann at gmx.de ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java ! src/share/classes/com/sun/jmx/snmp/SnmpInt.java ! src/share/classes/com/sun/jmx/snmp/SnmpNull.java ! src/share/classes/com/sun/jmx/snmp/SnmpString.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/servicetag/BrowserSupport.java ! src/share/classes/com/sun/servicetag/RegistrationDocument.java ! src/share/classes/java/awt/BufferCapabilities.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/ImageCapabilities.java ! src/share/classes/java/awt/Insets.java ! src/share/classes/java/awt/JobAttributes.java ! src/share/classes/java/awt/PageAttributes.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/font/TextLayout.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/CubicCurve2D.java ! src/share/classes/java/awt/geom/Dimension2D.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/geom/Point2D.java ! src/share/classes/java/awt/geom/QuadCurve2D.java ! src/share/classes/java/awt/geom/RectangularShape.java ! src/share/classes/java/awt/image/ImageFilter.java ! src/share/classes/java/awt/image/Kernel.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/security/cert/CollectionCertStoreParameters.java ! src/share/classes/java/security/cert/LDAPCertStoreParameters.java ! src/share/classes/java/security/cert/PKIXCertPathChecker.java ! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java ! src/share/classes/java/security/cert/PKIXParameters.java ! src/share/classes/java/security/cert/X509CRLSelector.java ! src/share/classes/java/security/cert/X509CertSelector.java ! src/share/classes/java/text/AttributedString.java ! src/share/classes/java/text/BreakDictionary.java ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/Collator.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/RuleBasedBreakIterator.java ! src/share/classes/java/text/StringCharacterIterator.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/javax/management/openmbean/TabularDataSupport.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/rtf/RTFReader.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/font/FontLineMetrics.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/classes/sun/management/counter/perf/PerfDataEntry.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/NetworkServer.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/smtp/SmtpClient.java ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/gopher/GopherClient.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/reflect/UTF8.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/rmi/transport/LiveRef.java ! src/share/classes/sun/security/provider/SecureRandom.java ! src/share/classes/sun/security/provider/SeedGenerator.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/classes/sun/text/CompactByteArray.java ! src/share/classes/sun/text/normalizer/NormalizerBase.java ! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! src/share/classes/sun/tools/jconsole/LocalVirtualMachine.java ! src/share/classes/sun/tools/tree/Node.java ! src/share/classes/sun/tracing/dtrace/DTraceProvider.java ! src/share/classes/sun/util/calendar/CalendarDate.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java From weijun.wang at oracle.com Tue Aug 30 18:23:32 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 31 Aug 2011 01:23:32 +0000 Subject: hg: jdk8/tl/jdk: 7083664: test hard code of using c:/temp but this dir might not exist Message-ID: <20110831012342.3169047240@hg.openjdk.java.net> Changeset: f5120b47f93d Author: weijun Date: 2011-08-31 09:22 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f5120b47f93d 7083664: test hard code of using c:/temp but this dir might not exist Reviewed-by: xuelei, ohair ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/security/tools/jarsigner/AlgOptions.sh ! test/sun/security/tools/jarsigner/PercentSign.sh ! test/sun/security/tools/jarsigner/diffend.sh ! test/sun/security/tools/jarsigner/oldsig.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/SecretKeyKS.sh ! test/sun/security/tools/keytool/StandardAlgName.sh ! test/sun/security/tools/keytool/i18n.sh ! test/sun/security/tools/keytool/resource.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh From weijun.wang at oracle.com Wed Aug 31 01:00:56 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 31 Aug 2011 16:00:56 +0800 Subject: code review request: 7081783: jarsigner error when no $HOME/.keystore In-Reply-To: <4E5CEB1D.2010007@oracle.com> References: <4E5C6D90.4050204@oracle.com> <4E5CEB1D.2010007@oracle.com> Message-ID: <4E5DEA38.60201@oracle.com> On 08/30/2011 09:52 PM, Xuelei Fan wrote: > 1. Do you want to add more debug info? line 1509-1511: > + if (debug) { > + e.printStackTrace(); > + } Yes. The -debug option is used to show exception full stack when an error occurs. I want the exception printed for warnings also. > > 2. It looks a little strange to me that even if there is Runtime > exception, we still do some additional work in final block. Well, the handling of exception at signing and verification are different (compare line 212 and 227). There must be a keystore at signing time but not necessary at verification. Therefore, the exception handling is outside of this method. > > 3. I try hard to understand the code how to solve the issue. It is not > easy for me to understand why the update works. It's because for verification the exception is ignored in the test case (line 214-218), so even if ~/.keystore does not exist, the new finally block makes sure the CertPathValidator is properly initialized. Before this fix, although the exception is also ignored, the CertPathValidator lines are totally ignored, and the CertPath validation shows an NPE and a warning is shown. > I'm thinking, is it > possible to ignore user_home/.keystore instead of try to load it when > the file does not exist (File.exists() or catch FileNotFoundException, etc)? > > The current logic is, "loading keystore from user_home/.keystore". > Can we change to use a refined logic, "if user_home/.keystore exists, we > load the keysore; otherwise, ignore it". I'm not sure the new logic get > the code more complicated, or more intuitive. Well, it looks more correct, but is complicated in 2 senses: 1. ~/.keystore and user-specified -keystore are not treated the same. You can ignore ~/.keystore, but if a user-specified -keystore does not exist, it's an error. 2. signing and verification have different behaviors on exception handling. See above. Therefore I prefer my current code changes more. It's focused on only one place where the bug is: make sure CertPathValidator is always initialized, and leave all old logic unchanged. Thanks Max > > Xuelei > > On 8/30/2011 12:56 PM, Weijun Wang wrote: >> Hi All >> >> 7081783: jarsigner error when no $HOME/.keystore >> >> Webrev is at -- >> http://cr.openjdk.java.net/~weijun/7081783/webrev.00/ >> >> Description: >> >> jarsigner includes a certpath validation check, and shows a warning when >> the check fails. The CertPathValidator object, unfortunately, is >> initialized in a method that can only be executed if a local keystore is >> found (either ~/.keystore or specified by -keystore). Therefore, if >> there is no local keystore but the jarfile's signer can be directly >> verified by a cert in cacerts, we still see: >> >> Warning: >> This jar contains entries whose certificate chain is not validated. >> >> The code changes make sure the CertPathValidator object is always >> initialized. >> >> For reg test, it's a simple call -- >> >> ${TESTJAVA}${FS}bin${FS}jarsigner \ >> -J-Duser.home=. \ >> -verify -strict ${TESTSRC}${FS}bootstrap.jar >> >> Here I override user.home so that even if the test machine has a >> ./keystore, it won't be affected. The bootstrap.jar file is a small >> signed jar that is signed by a real CA that can be chained into an item >> in cacerts. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Wed Aug 31 01:23:43 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 31 Aug 2011 16:23:43 +0800 Subject: code review request: 7081411: Change more keytool -genkeypair to RSA In-Reply-To: <4E5CF588.3010607@oracle.com> References: <4E5CD6EC.6000201@oracle.com> <4E5CF588.3010607@oracle.com> Message-ID: <4E5DEF8F.6000005@oracle.com> My personal view was not faraway from yours -- I am not so frightened by test failures. However, zero tolerance of any test failure is becoming a common sense of the team and the whole JPG [1]. Evaluating test failures is consuming too much time for both release engineers, SQE and us. Especially in this case, other people might not easily find out it's the Solaris DSA bug that causes the failure. Therefore, my current opinion is that once the reason of a test failure is known, we should take actions immediately. Either fix it if we can, or fix the test (or problem list it) if we cannot fix the bug. There is no benefit in leaving them there making noises from time to time. In this case, I certainly do not want to add all of them to problems list. Also, since the changeset is there, we always have a chance to backout the changes when we want to bring the old tests back. In fact, if you are worried that changing the tests might hide the bug, I can add a new test that detects this bug. I'll make sure the test always fails on Solaris. Thanks Max [1] http://wiki.se.oracle.com/display/JPG/Home On 08/30/2011 10:36 PM, Xuelei Fan wrote: > The update, in both open and closed repositories, looks fine to me. > > However, the following reason cannot convince me of the necessity to > make the change. > >> Because of the Solaris DSA bug described in 7041639, we keep seeing >> tests generating DSA key pairs failing. Therefore I'm changing most >> keypair generation to use RSA instead. > > Most of the updated tests using the default key algorithm ("DSA"). I'm > thinking, shall we replace "RSA" back with "DSA" again when there is a > RSA bug in the native libraries in the future? It may be not a good > choice to cut the tests to fit problematic platform. These tests are > also very good test to find the potential problems, right? When we > change the test to be able to passed on all platform, the test may lost > it function to find potential issues partially. > > Just my very personal view. > > Thanks, > Xuelei > > > On 8/30/2011 8:26 PM, Weijun Wang wrote: >> Hi All >> >> 7081411: Change more keytool -genkeypair to RSA >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7081411 >> >> Webrev at http://cr.openjdk.java.net/~weijun/7081411/webrev.01/ >> >> Because of the Solaris DSA bug described in 7041639, we keep seeing >> tests generating DSA key pairs failing. Therefore I'm changing most >> keypair generation to use RSA instead. >> >> In all code changes, KeyToolTest.java is called by standard.sh, which >> makes so many "keytool -genkeypair" calls that I decide to add "-keysize >> 512" to make it fast. Please note that in this test there are still >> explicit calls to "-genkeypair -keyalg dsa". These still have a chance >> to fail on Solaris, but I like to keep them there to make the test >> complete. >> >> Code changes in the closed repo will be sent in another mail. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Wed Aug 31 01:37:00 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 31 Aug 2011 16:37:00 +0800 Subject: code review request: 7081411: Change more keytool -genkeypair to RSA In-Reply-To: <4E5DEF8F.6000005@oracle.com> References: <4E5CD6EC.6000201@oracle.com> <4E5CF588.3010607@oracle.com> <4E5DEF8F.6000005@oracle.com> Message-ID: <4E5DF2AC.7010604@oracle.com> More: You can see that I simply added "-keyalg rsa". Most of these tests are not designed to test on any algorithm, instead, they test various functions/commands of the tool. Maybe this change will reveal some RSA problems. Who knows? :) (I admit if it really finds out any, I don't know what my next change should be) For a few tests that do test key algorithms, I have not changed them. For example, in KeyToolTest.java, some lines check the matching of -keyalg and -sigalg. Those still have a chance to fail on Solaris but I haven't removed them. Thanks Max On 08/31/2011 04:23 PM, Weijun Wang wrote: > My personal view was not faraway from yours -- I am not so frightened by > test failures. > > However, zero tolerance of any test failure is becoming a common sense > of the team and the whole JPG [1]. Evaluating test failures is consuming > too much time for both release engineers, SQE and us. Especially in this > case, other people might not easily find out it's the Solaris DSA bug > that causes the failure. > > Therefore, my current opinion is that once the reason of a test failure > is known, we should take actions immediately. Either fix it if we can, > or fix the test (or problem list it) if we cannot fix the bug. There is > no benefit in leaving them there making noises from time to time. > > In this case, I certainly do not want to add all of them to problems > list. Also, since the changeset is there, we always have a chance to > backout the changes when we want to bring the old tests back. > > In fact, if you are worried that changing the tests might hide the bug, > I can add a new test that detects this bug. I'll make sure the test > always fails on Solaris. > > Thanks > Max > > [1] http://wiki.se.oracle.com/display/JPG/Home > > On 08/30/2011 10:36 PM, Xuelei Fan wrote: >> The update, in both open and closed repositories, looks fine to me. >> >> However, the following reason cannot convince me of the necessity to >> make the change. >> >>> Because of the Solaris DSA bug described in 7041639, we keep seeing >>> tests generating DSA key pairs failing. Therefore I'm changing most >>> keypair generation to use RSA instead. >> >> Most of the updated tests using the default key algorithm ("DSA"). I'm >> thinking, shall we replace "RSA" back with "DSA" again when there is a >> RSA bug in the native libraries in the future? It may be not a good >> choice to cut the tests to fit problematic platform. These tests are >> also very good test to find the potential problems, right? When we >> change the test to be able to passed on all platform, the test may lost >> it function to find potential issues partially. >> >> Just my very personal view. >> >> Thanks, >> Xuelei >> >> >> On 8/30/2011 8:26 PM, Weijun Wang wrote: >>> Hi All >>> >>> 7081411: Change more keytool -genkeypair to RSA >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7081411 >>> >>> Webrev at http://cr.openjdk.java.net/~weijun/7081411/webrev.01/ >>> >>> Because of the Solaris DSA bug described in 7041639, we keep seeing >>> tests generating DSA key pairs failing. Therefore I'm changing most >>> keypair generation to use RSA instead. >>> >>> In all code changes, KeyToolTest.java is called by standard.sh, which >>> makes so many "keytool -genkeypair" calls that I decide to add "-keysize >>> 512" to make it fast. Please note that in this test there are still >>> explicit calls to "-genkeypair -keyalg dsa". These still have a chance >>> to fail on Solaris, but I like to keep them there to make the test >>> complete. >>> >>> Code changes in the closed repo will be sent in another mail. >>> >>> Thanks >>> Max >>> >> From xuelei.fan at oracle.com Wed Aug 31 05:16:18 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 31 Aug 2011 20:16:18 +0800 Subject: code review request: 7081411: Change more keytool -genkeypair to RSA In-Reply-To: <4E5DF2AC.7010604@oracle.com> References: <4E5CD6EC.6000201@oracle.com> <4E5CF588.3010607@oracle.com> <4E5DEF8F.6000005@oracle.com> <4E5DF2AC.7010604@oracle.com> Message-ID: <4E5E2612.8060600@oracle.com> I may argue more in a different viewpoint from you. ;-) 1. I don't think the failure is noise, it is valuable information to tell us that there is problem in our implementation or underlying platform. If it happens again and again, it means that we don't solve the problem from build to build. If we decrease the possibility to reproduce the problem, we also also decrease the possibility to find the underlying problem. 2. I don't concern too much about how you avoid the problem in keytool. I'm against the approach to cut the test to fit problematic platform. The "best" result of the approach at last would be that we will not likely to find any problem by running regression test, because we have already filtered out nearly all known issues by cutting the test. It is a good test if it can expose problems, it can be anything but a test if it is expected to pass in all situation. Test is not designed to pass, at least I think so. 3. If we do find the platform problem, and it do impact a lot of tests, and it cannot be fixed in a short team. I think we may be able to isolate the platform problem in the tests in a short run. But we should not isolate the function in all platform. For example, we know that there are PKCS11 padding problems in solaris 11. If we do want to cut the tests, We may only need to isolate PKCS11 provider in solaris 11, but not PKCS11 provider problem in all platforms, or even worse to isolate all padding operations. Just my very few sense about the approach. It is up to you to make the final decision. Thanks, Xuelei On 8/31/2011 4:37 PM, Weijun Wang wrote: > More: > > You can see that I simply added "-keyalg rsa". Most of these tests are > not designed to test on any algorithm, instead, they test various > functions/commands of the tool. Maybe this change will reveal some RSA > problems. Who knows? :) > > (I admit if it really finds out any, I don't know what my next change > should be) > > For a few tests that do test key algorithms, I have not changed them. > For example, in KeyToolTest.java, some lines check the matching of > -keyalg and -sigalg. Those still have a chance to fail on Solaris but I > haven't removed them. > > Thanks > Max > > On 08/31/2011 04:23 PM, Weijun Wang wrote: >> My personal view was not faraway from yours -- I am not so frightened by >> test failures. >> >> However, zero tolerance of any test failure is becoming a common sense >> of the team and the whole JPG [1]. Evaluating test failures is consuming >> too much time for both release engineers, SQE and us. Especially in this >> case, other people might not easily find out it's the Solaris DSA bug >> that causes the failure. >> >> Therefore, my current opinion is that once the reason of a test failure >> is known, we should take actions immediately. Either fix it if we can, >> or fix the test (or problem list it) if we cannot fix the bug. There is >> no benefit in leaving them there making noises from time to time. >> >> In this case, I certainly do not want to add all of them to problems >> list. Also, since the changeset is there, we always have a chance to >> backout the changes when we want to bring the old tests back. >> >> In fact, if you are worried that changing the tests might hide the bug, >> I can add a new test that detects this bug. I'll make sure the test >> always fails on Solaris. >> >> Thanks >> Max >> >> [1] http://wiki.se.oracle.com/display/JPG/Home >> >> On 08/30/2011 10:36 PM, Xuelei Fan wrote: >>> The update, in both open and closed repositories, looks fine to me. >>> >>> However, the following reason cannot convince me of the necessity to >>> make the change. >>> >>>> Because of the Solaris DSA bug described in 7041639, we keep seeing >>>> tests generating DSA key pairs failing. Therefore I'm changing most >>>> keypair generation to use RSA instead. >>> >>> Most of the updated tests using the default key algorithm ("DSA"). I'm >>> thinking, shall we replace "RSA" back with "DSA" again when there is a >>> RSA bug in the native libraries in the future? It may be not a good >>> choice to cut the tests to fit problematic platform. These tests are >>> also very good test to find the potential problems, right? When we >>> change the test to be able to passed on all platform, the test may lost >>> it function to find potential issues partially. >>> >>> Just my very personal view. >>> >>> Thanks, >>> Xuelei >>> >>> >>> On 8/30/2011 8:26 PM, Weijun Wang wrote: >>>> Hi All >>>> >>>> 7081411: Change more keytool -genkeypair to RSA >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7081411 >>>> >>>> Webrev at http://cr.openjdk.java.net/~weijun/7081411/webrev.01/ >>>> >>>> Because of the Solaris DSA bug described in 7041639, we keep seeing >>>> tests generating DSA key pairs failing. Therefore I'm changing most >>>> keypair generation to use RSA instead. >>>> >>>> In all code changes, KeyToolTest.java is called by standard.sh, which >>>> makes so many "keytool -genkeypair" calls that I decide to add >>>> "-keysize >>>> 512" to make it fast. Please note that in this test there are still >>>> explicit calls to "-genkeypair -keyalg dsa". These still have a chance >>>> to fail on Solaris, but I like to keep them there to make the test >>>> complete. >>>> >>>> Code changes in the closed repo will be sent in another mail. >>>> >>>> Thanks >>>> Max >>>> >>> From xuelei.fan at oracle.com Wed Aug 31 06:17:21 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 31 Aug 2011 21:17:21 +0800 Subject: code review request: 7081783: jarsigner error when no $HOME/.keystore In-Reply-To: <4E5DEA38.60201@oracle.com> References: <4E5C6D90.4050204@oracle.com> <4E5CEB1D.2010007@oracle.com> <4E5DEA38.60201@oracle.com> Message-ID: <4E5E3461.2010405@oracle.com> I understand the code, fine to me. But the loadKeyStore() method looks really ugly and lazy. :-) Just for your reference in the inline comments. On 8/31/2011 4:00 PM, Weijun Wang wrote: > > > On 08/30/2011 09:52 PM, Xuelei Fan wrote: >> 1. Do you want to add more debug info? line 1509-1511: >> + if (debug) { >> + e.printStackTrace(); >> + } > > Yes. The -debug option is used to show exception full stack when an > error occurs. I want the exception printed for warnings also. > >> >> 2. It looks a little strange to me that even if there is Runtime >> exception, we still do some additional work in final block. > > Well, the handling of exception at signing and verification are > different (compare line 212 and 227). There must be a keystore at > signing time but not necessary at verification. Therefore, the exception > handling is outside of this method. > >> >> 3. I try hard to understand the code how to solve the issue. It is not >> easy for me to understand why the update works. > > It's because for verification the exception is ignored in the test case > (line 214-218), so even if ~/.keystore does not exist, the new finally > block makes sure the CertPathValidator is properly initialized. Before > this fix, although the exception is also ignored, the CertPathValidator > lines are totally ignored, and the CertPath validation shows an NPE and > a warning is shown. > >> I'm thinking, is it >> possible to ignore user_home/.keystore instead of try to load it when >> the file does not exist (File.exists() or catch FileNotFoundException, >> etc)? >> >> The current logic is, "loading keystore from user_home/.keystore". >> Can we change to use a refined logic, "if user_home/.keystore exists, we >> load the keysore; otherwise, ignore it". I'm not sure the new logic get >> the code more complicated, or more intuitive. > > Well, it looks more correct, but is complicated in 2 senses: > > 1. ~/.keystore and user-specified -keystore are not treated the same. > You can ignore ~/.keystore, but if a user-specified -keystore does not > exist, it's an error. > We can handle the logic simply at the following blok, roght? 1562 if (!nullStream && keyStoreName == null) { 1563 keyStoreName = System.getProperty("user.home") + File.separator 1564 + ".keystore"; + // check file existence, ignore it if non-exist 1565 } > 2. signing and verification have different behaviors on exception > handling. See above. > We don't need to make more significant update in other blocks because of we have ignore the non-exist keystore, right? If no required private key, the following steps will throw the expected exception. Or is there any other thing that I missed? Thanks, Xuelei > Therefore I prefer my current code changes more. It's focused on only > one place where the bug is: make sure CertPathValidator is always > initialized, and leave all old logic unchanged. > > Thanks > Max > >> >> Xuelei >> >> On 8/30/2011 12:56 PM, Weijun Wang wrote: >>> Hi All >>> >>> 7081783: jarsigner error when no $HOME/.keystore >>> >>> Webrev is at -- >>> http://cr.openjdk.java.net/~weijun/7081783/webrev.00/ >>> >>> Description: >>> >>> jarsigner includes a certpath validation check, and shows a warning when >>> the check fails. The CertPathValidator object, unfortunately, is >>> initialized in a method that can only be executed if a local keystore is >>> found (either ~/.keystore or specified by -keystore). Therefore, if >>> there is no local keystore but the jarfile's signer can be directly >>> verified by a cert in cacerts, we still see: >>> >>> Warning: >>> This jar contains entries whose certificate chain is not validated. >>> >>> The code changes make sure the CertPathValidator object is always >>> initialized. >>> >>> For reg test, it's a simple call -- >>> >>> ${TESTJAVA}${FS}bin${FS}jarsigner \ >>> -J-Duser.home=. \ >>> -verify -strict ${TESTSRC}${FS}bootstrap.jar >>> >>> Here I override user.home so that even if the test machine has a >>> ./keystore, it won't be affected. The bootstrap.jar file is a small >>> signed jar that is signed by a real CA that can be chained into an item >>> in cacerts. >>> >>> Thanks >>> Max >>> >> From maurizio.cimadamore at oracle.com Wed Aug 31 08:16:29 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 31 Aug 2011 15:16:29 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20110831151633.4F19247260@hg.openjdk.java.net> Changeset: b86277584776 Author: mcimadamore Date: 2011-08-31 16:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b86277584776 7085024: internal error; cannot instantiate Foo Summary: Types.isConvertible does not handle erroneous types correctly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/7085024/T7085024.java + test/tools/javac/7085024/T7085024.out Changeset: d0257833498e Author: mcimadamore Date: 2011-08-31 16:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d0257833498e 7079713: javac hangs when compiling a class that references a cyclically inherited class Summary: Types.membersClosure needs to handle pathological cases of cyclic inheritance Reviewed-by: jjg, jjh ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/7079713/TestCircularClassfile.java From sean.mullan at oracle.com Wed Aug 31 09:38:55 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 31 Aug 2011 12:38:55 -0400 Subject: code review request: 7081411: Change more keytool -genkeypair to RSA In-Reply-To: <4E5E2612.8060600@oracle.com> References: <4E5CD6EC.6000201@oracle.com> <4E5CF588.3010607@oracle.com> <4E5DEF8F.6000005@oracle.com> <4E5DF2AC.7010604@oracle.com> <4E5E2612.8060600@oracle.com> Message-ID: <4E5E639F.8000807@oracle.com> I agree that we should not remove all tests for DSA keypair generation - this could also hide any new regressions in that area. It's my understanding that there are still some tests that test DSA keypair generation, just not as many, so the likelihood of encountering the Solaris bug is smaller. Is that right, Max? As long as we still have some test coverage of DSA keypair generation - I think it is ok. --Sean On 8/31/11 8:16 AM, Xuelei Fan wrote: > I may argue more in a different viewpoint from you. ;-) > > 1. I don't think the failure is noise, it is valuable information to > tell us that there is problem in our implementation or underlying > platform. If it happens again and again, it means that we don't solve > the problem from build to build. If we decrease the possibility to > reproduce the problem, we also also decrease the possibility to find the > underlying problem. > > 2. I don't concern too much about how you avoid the problem in keytool. > I'm against the approach to cut the test to fit problematic platform. > The "best" result of the approach at last would be that we will not > likely to find any problem by running regression test, because we have > already filtered out nearly all known issues by cutting the test. > > It is a good test if it can expose problems, it can be anything but a > test if it is expected to pass in all situation. Test is not designed to > pass, at least I think so. > > 3. If we do find the platform problem, and it do impact a lot of tests, > and it cannot be fixed in a short team. I think we may be able to > isolate the platform problem in the tests in a short run. But we should > not isolate the function in all platform. > > For example, we know that there are PKCS11 padding problems in > solaris 11. If we do want to cut the tests, We may only need to isolate > PKCS11 provider in solaris 11, but not PKCS11 provider problem in all > platforms, or even worse to isolate all padding operations. > > Just my very few sense about the approach. It is up to you to make the > final decision. > > Thanks, > Xuelei > > On 8/31/2011 4:37 PM, Weijun Wang wrote: >> More: >> >> You can see that I simply added "-keyalg rsa". Most of these tests are >> not designed to test on any algorithm, instead, they test various >> functions/commands of the tool. Maybe this change will reveal some RSA >> problems. Who knows? :) >> >> (I admit if it really finds out any, I don't know what my next change >> should be) >> >> For a few tests that do test key algorithms, I have not changed them. >> For example, in KeyToolTest.java, some lines check the matching of >> -keyalg and -sigalg. Those still have a chance to fail on Solaris but I >> haven't removed them. >> >> Thanks >> Max >> >> On 08/31/2011 04:23 PM, Weijun Wang wrote: >>> My personal view was not faraway from yours -- I am not so frightened by >>> test failures. >>> >>> However, zero tolerance of any test failure is becoming a common sense >>> of the team and the whole JPG [1]. Evaluating test failures is consuming >>> too much time for both release engineers, SQE and us. Especially in this >>> case, other people might not easily find out it's the Solaris DSA bug >>> that causes the failure. >>> >>> Therefore, my current opinion is that once the reason of a test failure >>> is known, we should take actions immediately. Either fix it if we can, >>> or fix the test (or problem list it) if we cannot fix the bug. There is >>> no benefit in leaving them there making noises from time to time. >>> >>> In this case, I certainly do not want to add all of them to problems >>> list. Also, since the changeset is there, we always have a chance to >>> backout the changes when we want to bring the old tests back. >>> >>> In fact, if you are worried that changing the tests might hide the bug, >>> I can add a new test that detects this bug. I'll make sure the test >>> always fails on Solaris. >>> >>> Thanks >>> Max >>> >>> [1] http://wiki.se.oracle.com/display/JPG/Home >>> >>> On 08/30/2011 10:36 PM, Xuelei Fan wrote: >>>> The update, in both open and closed repositories, looks fine to me. >>>> >>>> However, the following reason cannot convince me of the necessity to >>>> make the change. >>>> >>>>> Because of the Solaris DSA bug described in 7041639, we keep seeing >>>>> tests generating DSA key pairs failing. Therefore I'm changing most >>>>> keypair generation to use RSA instead. >>>> >>>> Most of the updated tests using the default key algorithm ("DSA"). I'm >>>> thinking, shall we replace "RSA" back with "DSA" again when there is a >>>> RSA bug in the native libraries in the future? It may be not a good >>>> choice to cut the tests to fit problematic platform. These tests are >>>> also very good test to find the potential problems, right? When we >>>> change the test to be able to passed on all platform, the test may lost >>>> it function to find potential issues partially. >>>> >>>> Just my very personal view. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> >>>> On 8/30/2011 8:26 PM, Weijun Wang wrote: >>>>> Hi All >>>>> >>>>> 7081411: Change more keytool -genkeypair to RSA >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7081411 >>>>> >>>>> Webrev at http://cr.openjdk.java.net/~weijun/7081411/webrev.01/ >>>>> >>>>> Because of the Solaris DSA bug described in 7041639, we keep seeing >>>>> tests generating DSA key pairs failing. Therefore I'm changing most >>>>> keypair generation to use RSA instead. >>>>> >>>>> In all code changes, KeyToolTest.java is called by standard.sh, which >>>>> makes so many "keytool -genkeypair" calls that I decide to add >>>>> "-keysize >>>>> 512" to make it fast. Please note that in this test there are still >>>>> explicit calls to "-genkeypair -keyalg dsa". These still have a chance >>>>> to fail on Solaris, but I like to keep them there to make the test >>>>> complete. >>>>> >>>>> Code changes in the closed repo will be sent in another mail. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>> > From jonathan.gibbons at oracle.com Wed Aug 31 15:39:26 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 31 Aug 2011 22:39:26 +0000 Subject: hg: jdk8/tl/langtools: 7074416: Regression: JSR199: javac doesn't unwrap clientcodewrapper objects Message-ID: <20110831223928.C51BA47275@hg.openjdk.java.net> Changeset: f85d980faaf8 Author: jjg Date: 2011-08-31 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f85d980faaf8 7074416: Regression: JSR199: javac doesn't unwrap clientcodewrapper objects Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/javax/tools/JavaCompiler.java ! test/tools/javac/TryWithResources/UnusedResourcesTest.java ! test/tools/javac/diags/Example.java ! test/tools/javac/processing/errors/TestSuppression.java From weijun.wang at oracle.com Wed Aug 31 21:31:38 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 01 Sep 2011 12:31:38 +0800 Subject: code review request: 7081783: jarsigner error when no $HOME/.keystore In-Reply-To: <4E5E3461.2010405@oracle.com> References: <4E5C6D90.4050204@oracle.com> <4E5CEB1D.2010007@oracle.com> <4E5DEA38.60201@oracle.com> <4E5E3461.2010405@oracle.com> Message-ID: <4E5F0AAA.2050904@oracle.com> On 08/31/2011 09:17 PM, Xuelei Fan wrote: > I understand the code, fine to me. But the loadKeyStore() method looks > really ugly and lazy. :-) It's ugly, but not very lazy. Anyway, I'm going to putback this version since you already said fine. > > Just for your reference in the inline comments. > ... >> >> Well, it looks more correct, but is complicated in 2 senses: >> >> 1. ~/.keystore and user-specified -keystore are not treated the same. >> You can ignore ~/.keystore, but if a user-specified -keystore does not >> exist, it's an error. >> > We can handle the logic simply at the following blok, right? > 1562 if (!nullStream&& keyStoreName == null) { > 1563 keyStoreName = System.getProperty("user.home") + File.separator > 1564 + ".keystore"; > + // check file existence, ignore it if non-exist > 1565 } > >> 2. signing and verification have different behaviors on exception >> handling. See above. >> > We don't need to make more significant update in other blocks because of > we have ignore the non-exist keystore, right? If no required private > key, the following steps will throw the expected exception. If you ignore non-existing ~/.keystore, there will be no exception, and store will be either null or uninitialized. Then when it's used, NPE or KeyStoreException will be thrown and the user is confused. So you still need to check it earlier. Thanks Max > > Or is there any other thing that I missed? > > Thanks, > Xuelei From xuelei.fan at oracle.com Wed Aug 31 21:37:43 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 01 Sep 2011 12:37:43 +0800 Subject: code review request: 7081783: jarsigner error when no $HOME/.keystore In-Reply-To: <4E5F0AAA.2050904@oracle.com> References: <4E5C6D90.4050204@oracle.com> <4E5CEB1D.2010007@oracle.com> <4E5DEA38.60201@oracle.com> <4E5E3461.2010405@oracle.com> <4E5F0AAA.2050904@oracle.com> Message-ID: <4E5F0C17.8070801@oracle.com> On 9/1/2011 12:31 PM, Weijun Wang wrote: > > On 08/31/2011 09:17 PM, Xuelei Fan wrote: >> I understand the code, fine to me. But the loadKeyStore() method looks >> really ugly and lazy. :-) > > It's ugly, but not very lazy. > Lazy code is not a bad coding style. ;-) > Anyway, I'm going to putback this version since you already said fine. > Please go ahead. It's fine to me. I just want to talk about some of my concerns. Thanks, Xuelei >> >> Just for your reference in the inline comments. >> > ... > >>> >>> Well, it looks more correct, but is complicated in 2 senses: >>> >>> 1. ~/.keystore and user-specified -keystore are not treated the same. >>> You can ignore ~/.keystore, but if a user-specified -keystore does not >>> exist, it's an error. >>> >> We can handle the logic simply at the following blok, right? >> 1562 if (!nullStream&& keyStoreName == null) { >> 1563 keyStoreName = System.getProperty("user.home") + File.separator >> 1564 + ".keystore"; >> + // check file existence, ignore it if non-exist >> 1565 } >> >>> 2. signing and verification have different behaviors on exception >>> handling. See above. >>> >> We don't need to make more significant update in other blocks because of >> we have ignore the non-exist keystore, right? If no required private >> key, the following steps will throw the expected exception. > > If you ignore non-existing ~/.keystore, there will be no exception, and > store will be either null or uninitialized. Then when it's used, NPE or > KeyStoreException will be thrown and the user is confused. So you still > need to check it earlier. > > Thanks > Max > >> >> Or is there any other thing that I missed? >> >> Thanks, >> Xuelei From chris.hegarty at oracle.com Wed Aug 31 22:45:47 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 01 Sep 2011 05:45:47 +0000 Subject: hg: jdk8/tl/jdk: 7014860: Socket.getInputStream().available() not clear for shutdown input Message-ID: <20110901054606.0B82E47290@hg.openjdk.java.net> Changeset: a5a28b040714 Author: chegar Date: 2011-09-01 06:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5a28b040714 7014860: Socket.getInputStream().available() not clear for shutdown input Reviewed-by: alanb, michaelm ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketImpl.java + test/java/net/Socket/ShutdownInput.java From sebastian.sickelmann at gmx.de Wed Aug 31 12:26:27 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Wed, 31 Aug 2011 21:26:27 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E52758D.2020208@oracle.com> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> Message-ID: <4E5E8AE3.3070402@gmx.de> Am 22.08.2011 17:28, schrieb Sean Mullan: > (dropping core-libs-dev) > > On 8/22/11 9:03 AM, Sebastian Sickelmann wrote: >> Hi, >> >> while making some change for using exception-chaining on RuntimeException in >> more cases, i found that javax.xml.crypto.NoSuchMechnismException had a private >> cause field that isn't necessary since throwable can handle it. But just >> removing isn't that simple as Alan pointed out[1]. > The history behind this is that this API is part of JSR 105. JSR 105 was > released independently of Java SE as a "standalone JSR" and later integrated > into Java SE 6 as part of the platform JSR. Thus as I understand, all JSR 105 > API changes need to first go through a maintenance revision of JSR 105. > > JSR 105 was designed to be used by applications using JDK 1.2 and up, thus there > are no API dependencies on any releases later than that. Therefore, this class > (and other exception classes in JSR 105) included their own methods to capture > the cause. > > I've been aware of this issue for a little while but I did not have the cycles > to analyze it thoroughly so I am glad you are looking into it. > > I think you will find the same issue in the other Exception classes in the > javax.xml.crypto package and its subpackages. Have you looked at those yet? > > I am not sure if removing the 3 overloaded methods qualifies as an API change. > If so, it would first require it go through a maintenance JSR. I will need to > ask someone else about that and get back to you. > >> First of all i thought just changing the serialversionUID was the right >> solution, but Alan disagreed and i actually think that too. Unfortunatly Alan >> doen't had the time to explain it in detail, but i think that we must search for >> a solution that doen't break backward serialization compatability. >> >> I created a webrev for my suggested change here: >> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2/ >> >> In a following post Alan writes that this should best be discussed here. What is >> the hg repository for patches in this mailinglist? I don't see any security-dev >> related repository for openjdk8 in http://hg.openjdk.java.net/ the patch is >> based on ****jdk8/tl/jdk maybe i >> should rebase it onto another repository. >> >> Another problem i have is testing. I think we should add some test for this. But >> got no real clue how to do it right. I tested it manually with the source >> here[2] and the files in here[3]. >> >> The files are created with an openjdk7 build(Unfortunatly i think with an quite >> old private build) and with an openjdk8(with my patches to >> NoSuchMechanismException). I tested it manually with my openjdk 7 and 8 build >> and in both cases the serialized objects could be loaded correctly in all cases. >> >> What is the best way to test this automatically. I thought about checking if the >> newly created openjdk8 serialization is binary equal to the jdk7 output, but it >> isn't because of some unavoidable changes (ex. jdk8 has the >> custom-serialization-bit) >> >> Alan mentioned that it may be ok to embed some serialized-objects as byte[] in >> testcode. > Yes, that is probably the best solution. I remember I had created some tests for > this a while back. I'll see if I can find them. > >> I will try to create a jtreg for this. Hope to be back on this soon. In the >> meantime it would be great to have someone reviewed the webrev. > I am pretty busy but will try to find some cycles to review it more carefully in > the next couple of days. > > --Sean > Some discussions went on in this thread as i tried to apply this solution to some other classes. These classes has adressed the new chaining support in Throwable quite different. In the meanwhile i think it is done best the way it is done in java/lang/{UndeclaredThrowableException|InvocationTargetException|ClassNotFoundException} I changed the webrev to mirror this pattern of supporting exception chain from java/lang. The solution is far easier to understand and i think it needs no addtional regression-tests. The solution to delete the cause field and patch serialisation is far more complex. I like the deletion of this field much more like prohibiting initCause. But this change should be mirrored to many Exceptions out there, and would require many discussion. Here is the updated webrev: http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_0/ Maybe the title of the bug isn't right anymore. @Alan: Can we change it into something like prohibit unintentional initCause() after construction? -- Sebastian >> @core-libs-dev: I crosspost it to core-libs-dev because the thread started >> there. So the interessted parties can move over to security-dev archive[4] >> >> -- Sebastian >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007462.html >> [2] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/SeriallizeTest.java >> [3] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/ >> [4] http://mail.openjdk.java.net/pipermail/security-dev/2011-August/thread.html