From kumar.x.srinivasan at oracle.com Fri Jul 1 13:49:48 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 01 Jul 2011 20:49:48 +0000 Subject: hg: jdk8/tl/langtools: 6735320: StringIndexOutOfBoundsException for empty @serialField tag Message-ID: <20110701204950.A4AB5470F8@hg.openjdk.java.net> Changeset: 409b104f8b86 Author: ksrini Date: 2011-07-01 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/409b104f8b86 6735320: StringIndexOutOfBoundsException for empty @serialField tag Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java + test/com/sun/javadoc/T6735320/SerialFieldTest.java + test/com/sun/javadoc/T6735320/T6735320.java ! test/com/sun/javadoc/lib/JavadocTester.java From jonathan.gibbons at oracle.com Fri Jul 1 14:07:08 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Jul 2011 21:07:08 +0000 Subject: hg: jdk8/tl: 7061195: Clean up makefiles for JDK 8 Message-ID: <20110701210709.063EE470FA@hg.openjdk.java.net> Changeset: 0b615980879e Author: jjg Date: 2011-06-30 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0b615980879e 7061195: Clean up makefiles for JDK 8 Reviewed-by: ohair, jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/sanity-rules.gmk From jonathan.gibbons at oracle.com Fri Jul 1 14:07:24 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Jul 2011 21:07:24 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20110701210801.3BC1F470FB@hg.openjdk.java.net> Changeset: e4c936c28960 Author: jjg Date: 2011-06-30 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4c936c28960 7061190: Update boot JDK version for JDK 8 Reviewed-by: ohair, jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/common/shared/Defs-versions.gmk Changeset: cf4edfcd7119 Author: jjg Date: 2011-06-30 16:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119 7061195: Clean up makefiles for JDK 8 Reviewed-by: ohair, jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/common/shared/Defs-java.gmk Changeset: 74328e59a4bf Author: jjg Date: 2011-06-30 17:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74328e59a4bf 7058708: Eliminate JDK build tools build warnings Reviewed-by: ohair, jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/tools/Makefile ! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java ! make/tools/src/build/tools/compileproperties/CompileProperties.java ! make/tools/src/build/tools/dirdiff/DirDiff.java ! make/tools/src/build/tools/dtdbuilder/DTDBuilder.java ! make/tools/src/build/tools/dtdbuilder/DTDInputStream.java ! make/tools/src/build/tools/dtdbuilder/DTDParser.java ! make/tools/src/build/tools/dtdbuilder/PublicMapping.java ! make/tools/src/build/tools/generatebreakiteratordata/CharSet.java ! make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java ! make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java ! make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java ! make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java ! make/tools/src/build/tools/generatecharacter/GenerateCharacter.java ! make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java ! make/tools/src/build/tools/generatecharacter/UnicodeSpec.java ! make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java ! make/tools/src/build/tools/hasher/Hasher.java ! make/tools/src/build/tools/jarsplit/JarSplit.java ! make/tools/src/build/tools/javazic/Gen.java ! make/tools/src/build/tools/javazic/GenDoc.java ! make/tools/src/build/tools/javazic/Main.java ! make/tools/src/build/tools/javazic/Mappings.java ! make/tools/src/build/tools/javazic/Simple.java ! make/tools/src/build/tools/javazic/Time.java ! make/tools/src/build/tools/javazic/Zoneinfo.java ! make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java ! make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java ! make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java ! make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java ! make/tools/src/build/tools/jdwpgen/AltNode.java ! make/tools/src/build/tools/jdwpgen/CommandSetNode.java ! make/tools/src/build/tools/jdwpgen/ConstantSetNode.java ! make/tools/src/build/tools/jdwpgen/ErrorSetNode.java ! make/tools/src/build/tools/jdwpgen/Node.java ! make/tools/src/build/tools/jdwpgen/OutNode.java ! make/tools/src/build/tools/jdwpgen/RootNode.java ! make/tools/src/build/tools/jdwpgen/SelectNode.java ! make/tools/src/build/tools/makeclasslist/MakeClasslist.java ! make/tools/src/build/tools/stripproperties/StripProperties.java From kumar.x.srinivasan at oracle.com Fri Jul 1 14:28:56 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 01 Jul 2011 21:28:56 +0000 Subject: hg: jdk8/tl/langtools: 7060642: (javadoc) improve performance on accessing inlinedTags Message-ID: <20110701212858.44F0147107@hg.openjdk.java.net> Changeset: 0d8edba73d70 Author: ksrini Date: 2011-07-01 14:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d8edba73d70 7060642: (javadoc) improve performance on accessing inlinedTags Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java From valerie.peng at oracle.com Fri Jul 1 17:16:45 2011 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Sat, 02 Jul 2011 00:16:45 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110702001704.9357B4710F@hg.openjdk.java.net> Changeset: e93679cf1e1a Author: valeriep Date: 2011-06-30 18:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e93679cf1e1a 7058133: Javah should use the freshly built classes instead of those from the BOOTDIR jdk Summary: Changed javah to use the newly built classes specified by $(CLASSDESTDIR) Reviewed-by: vinnie ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile Changeset: f0ec49c21d09 Author: valeriep Date: 2011-07-01 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0ec49c21d09 Merge From sean.coffey at oracle.com Tue Jul 5 07:27:02 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 05 Jul 2011 14:27:02 +0000 Subject: hg: jdk8/tl/jdk: 7041125: LDAP API does not catch malformed filters that contain two operands for the ! operator Message-ID: <20110705142726.3BB92471CB@hg.openjdk.java.net> Changeset: e88093d75e36 Author: coffeys Date: 2011-07-05 15:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e88093d75e36 7041125: LDAP API does not catch malformed filters that contain two operands for the ! operator Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/jndi/ldap/Filter.java ! test/com/sun/jndi/ldap/InvalidLdapFilters.java From sean.mullan at oracle.com Tue Jul 5 13:58:00 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 05 Jul 2011 16:58:00 -0400 Subject: 7064969 code review request Message-ID: <4E137AD8.6030308@oracle.com> Hi Vinnie, Can you review this one: http://cr.openjdk.java.net/~mullan/webrevs/7054969/webrev.00/ --Sean From joe.darcy at oracle.com Tue Jul 5 16:38:48 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 05 Jul 2011 23:38:48 +0000 Subject: hg: jdk8/tl/langtools: 7025809: Provided new utility visitors supporting SourceVersion.RELEASE_8 Message-ID: <20110705233850.38127471E1@hg.openjdk.java.net> Changeset: 111bbf1ad913 Author: darcy Date: 2011-07-05 16:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/111bbf1ad913 7025809: Provided new utility visitors supporting SourceVersion.RELEASE_8 Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java + src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java + src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java + src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java + src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/ElementScanner7.java + src/share/classes/javax/lang/model/util/ElementScanner8.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java + src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java + src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java + src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java + src/share/classes/javax/lang/model/util/TypeKindVisitor8.java ! src/share/sample/javac/processing/src/CheckNamesProcessor.java ! test/tools/javac/6402516/CheckLocalElements.java ! test/tools/javac/api/TestOperators.java ! test/tools/javac/enum/6350057/T6350057.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/failover/FailOver15.out ! test/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/TestSymtabItems.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestResourceVariable.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/type/TestUnionType.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java From vincent.x.ryan at oracle.com Wed Jul 6 08:00:17 2011 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 6 Jul 2011 08:00:17 -0700 (PDT) Subject: 7064969 code review request In-Reply-To: <4E137AD8.6030308@oracle.com> References: <4E137AD8.6030308@oracle.com> Message-ID: <4E147881.20505@oracle.com> All looks good. On 07/05/11 21:58, Sean Mullan wrote: > Hi Vinnie, > > Can you review this one: > > http://cr.openjdk.java.net/~mullan/webrevs/7054969/webrev.00/ > > --Sean From sean.mullan at oracle.com Wed Jul 6 08:14:20 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 06 Jul 2011 15:14:20 +0000 Subject: hg: jdk8/tl/jdk: 7054969: Null-check-in-finally pattern in java/security documentation Message-ID: <20110706151446.09DB44720B@hg.openjdk.java.net> Changeset: f68d30c0a2e3 Author: mullan Date: 2011-07-06 11:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f68d30c0a2e3 7054969: Null-check-in-finally pattern in java/security documentation Reviewed-by: vinnie ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/java/security/cert/X509Extension.java From bradford.wetmore at oracle.com Wed Jul 6 17:04:07 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 06 Jul 2011 17:04:07 -0700 Subject: 7064969 code review request In-Reply-To: <4E147881.20505@oracle.com> References: <4E137AD8.6030308@oracle.com> <4E147881.20505@oracle.com> Message-ID: <4E14F7F7.9020408@oracle.com> A little late, but Ditto. Brad On 7/6/2011 8:00 AM, Vincent Ryan wrote: > All looks good. > > > On 07/05/11 21:58, Sean Mullan wrote: >> Hi Vinnie, >> >> Can you review this one: >> >> http://cr.openjdk.java.net/~mullan/webrevs/7054969/webrev.00/ >> >> --Sean > From weijun.wang at oracle.com Wed Jul 6 18:10:38 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 07 Jul 2011 09:10:38 +0800 Subject: code review request: 7061379: [Kerberos] Cross-realm authentication fails, due to nameType problemThe Message-ID: <4E15078E.20001@oracle.com> 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.equalsWithoutRealm(). 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 weijun.wang at oracle.com Thu Jul 7 01:30:03 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 07 Jul 2011 16:30:03 +0800 Subject: On 7063702: To interprete case-insensitive string locale independently Message-ID: <4E156E8B.8040909@oracle.com> Hi Xuelei There are some other places using equalsIgnoreCase(). Is this method safe for all locales? Thanks Max From Xuelei.Fan at Oracle.Com Thu Jul 7 01:42:28 2011 From: Xuelei.Fan at Oracle.Com (Xuelei.Fan at Oracle.Com) Date: Thu, 7 Jul 2011 16:42:28 +0800 Subject: On 7063702: To interprete case-insensitive string locale independently In-Reply-To: <4E156E8B.8040909@oracle.com> References: <4E156E8B.8040909@oracle.com> Message-ID: I did not check all directories. I think we may need to evaluate them in the same CR or according to modules. Andrew On Jul 7, 2011, at 4:30 PM, Weijun Wang wrote: > Hi Xuelei > > There are some other places using equalsIgnoreCase(). Is this method safe for all locales? > > Thanks > Max From Xuelei.Fan at Oracle.Com Thu Jul 7 01:45:54 2011 From: Xuelei.Fan at Oracle.Com (Xuelei.Fan at Oracle.Com) Date: Thu, 7 Jul 2011 16:45:54 +0800 Subject: On 7063702: To interprete case-insensitive string locale independently In-Reply-To: <4E156E8B.8040909@oracle.com> References: <4E156E8B.8040909@oracle.com> Message-ID: On Jul 7, 2011, at 4:30 PM, Weijun Wang wrote: > Hi Xuelei > > There are some other places using equalsIgnoreCase(). Is this method safe for all locales? > equalsIgnoreCase() is safe. Looking into the code of this method, you will find that the implementation is a little different from just converting to lower case or upper case. Andrew > Thanks > Max From xuelei.fan at oracle.com Thu Jul 7 01:53:06 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 07 Jul 2011 16:53:06 +0800 Subject: On 7063702: To interprete case-insensitive string locale independently In-Reply-To: References: <4E156E8B.8040909@oracle.com> Message-ID: <4E1573F2.4030702@oracle.com> On 7/7/2011 4:42 PM, Xuelei.Fan at Oracle.Com wrote: > I did not check all directories. I think we may need to evaluate them in the same CR or according to modules. Too quick to reply the e-mail. I refer "them" to toUpperCase() and toLowerCase() methods, rather than the equalsIgnoreCase() methood. Xuelei > > Andrew > > On Jul 7, 2011, at 4:30 PM, Weijun Wang wrote: > >> Hi Xuelei >> >> There are some other places using equalsIgnoreCase(). Is this method safe for all locales? >> >> Thanks >> Max From xuelei.fan at oracle.com Thu Jul 7 08:40:15 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 07 Jul 2011 23:40:15 +0800 Subject: On 7063702: To interprete case-insensitive string locale independently In-Reply-To: <4E1573F2.4030702@oracle.com> References: <4E156E8B.8040909@oracle.com> <4E1573F2.4030702@oracle.com> Message-ID: <4E15D35F.50506@oracle.com> I have a blog to talk about the trap. http://sim.ivi.co/2011/07/trap-of-case-insensitive-string.html Xuelei On 7/7/2011 4:53 PM, Xuelei Fan wrote: > On 7/7/2011 4:42 PM, Xuelei.Fan at Oracle.Com wrote: >> I did not check all directories. I think we may need to evaluate them in the same CR or according to modules. > Too quick to reply the e-mail. I refer "them" to toUpperCase() and > toLowerCase() methods, rather than the equalsIgnoreCase() methood. > > Xuelei > >> >> Andrew >> >> On Jul 7, 2011, at 4:30 PM, Weijun Wang wrote: >> >>> Hi Xuelei >>> >>> There are some other places using equalsIgnoreCase(). Is this method safe for all locales? >>> >>> Thanks >>> Max > From jonathan.gibbons at oracle.com Thu Jul 7 13:29:54 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 07 Jul 2011 20:29:54 +0000 Subject: hg: jdk8/tl/langtools: 7061125: Proposed javac argument processing performance improvement Message-ID: <20110707202959.16B3247265@hg.openjdk.java.net> Changeset: 7337295434b6 Author: jjg Date: 2011-07-07 13:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7337295434b6 7061125: Proposed javac argument processing performance improvement Reviewed-by: jjg, dlsmith, mcimadamore, forax Contributed-by: schlosna at gmail.com ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6358168.java From weijun.wang at oracle.com Thu Jul 7 20:22:55 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 08 Jul 2011 11:22:55 +0800 Subject: code review request: 6330275: Rework the PaddingTest regression test. (was Re: Fwd: jdk_security2 tests) In-Reply-To: <4E028D6E.1040503@oracle.com> References: <4E006369.3010808@oracle.com> <4E0282D2.2040708@oracle.com> <4E028D6E.1040503@oracle.com> Message-ID: <4E16780F.3040707@oracle.com> Ping again. Or, someone else can take a look? On 06/23/2011 08:48 AM, Weijun Wang wrote: > http://cr.openjdk.java.net/~weijun/6330275/webrev.00/ > > Thanks > Max > > On 06/23/2011 08:03 AM, Brad Wetmore wrote: >> No, feel free to take it. >> >> Brad >> >> >> >> On 6/21/2011 2:24 AM, Weijun Wang wrote: >>> Hi Brad >>> >>> >>>> # Timed out, Solaris 10 64bit sparcv9 >>>> com/sun/crypto/provider/Cipher/DES/PaddingTest.java generic-all >>>> >>>> This test has not generated random numbers (all key material in byte[] >>>> constants) so there is no entropy pool issue. One special thing is that >>>> it calls the external diff command on two files but only prints out the >>>> result with no exception thrown when the files are different (6330275). >>> >>> I see you're RE for . Are you working on it now? >>> >>> Thanks >>> Max >>> From bradford.wetmore at oracle.com Thu Jul 7 22:05:49 2011 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 07 Jul 2011 22:05:49 -0700 Subject: code review request: 6330275: Rework the PaddingTest regression test. (was Re: Fwd: jdk_security2 tests) In-Reply-To: <4E028D6E.1040503@oracle.com> References: <4E006369.3010808@oracle.com> <4E0282D2.2040708@oracle.com> <4E028D6E.1040503@oracle.com> Message-ID: <4E16902D.1060305@oracle.com> Hi Max, > Ping Pong. :) My only comment is in the diff section. I realize it's a FileInputStream and all the bytes should be obtained on a read, but I think you might want to consider the case of a short read for whatever reason. FileInputStream doesn't guarantee that all bytes will be returned, just "some". It might be better to read both files until EOF, then compare sizes/contents. Otherwise, looks fine. Brad On 6/22/2011 5:48 PM, Weijun Wang wrote: > http://cr.openjdk.java.net/~weijun/6330275/webrev.00/ > > Thanks > Max > > On 06/23/2011 08:03 AM, Brad Wetmore wrote: >> No, feel free to take it. >> >> Brad >> >> >> >> On 6/21/2011 2:24 AM, Weijun Wang wrote: >>> Hi Brad >>> >>> >>>> # Timed out, Solaris 10 64bit sparcv9 >>>> com/sun/crypto/provider/Cipher/DES/PaddingTest.java generic-all >>>> >>>> This test has not generated random numbers (all key material in byte[] >>>> constants) so there is no entropy pool issue. One special thing is that >>>> it calls the external diff command on two files but only prints out the >>>> result with no exception thrown when the files are different (6330275). >>> >>> I see you're RE for . Are you working on it now? >>> >>> Thanks >>> Max >>> From stuart.marks at oracle.com Thu Jul 7 23:13:25 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 07 Jul 2011 23:13:25 -0700 Subject: code review request: 6330275: Rework the PaddingTest regression test. (was Re: Fwd: jdk_security2 tests) In-Reply-To: <4E16902D.1060305@oracle.com> References: <4E006369.3010808@oracle.com> <4E0282D2.2040708@oracle.com> <4E028D6E.1040503@oracle.com> <4E16902D.1060305@oracle.com> Message-ID: <4E16A005.3040104@oracle.com> On 7/7/11 10:05 PM, Bradford Wetmore wrote: > My only comment is in the diff section. I realize it's a FileInputStream and > all the bytes should be obtained on a read, but I think you might want to > consider the case of a short read for whatever reason. FileInputStream doesn't > guarantee that all bytes will be returned, just "some". It might be better to > read both files until EOF, then compare sizes/contents. In this vein, it might be reasonable to consider using java.nio.file.Files.readAllBytes(), which takes a Path and returns a byte[]. Then simply call Arrays.equals() on the results. s'marks > Otherwise, looks fine. > > Brad > > > > > > > > On 6/22/2011 5:48 PM, Weijun Wang wrote: >> http://cr.openjdk.java.net/~weijun/6330275/webrev.00/ >> >> Thanks >> Max >> >> On 06/23/2011 08:03 AM, Brad Wetmore wrote: >>> No, feel free to take it. >>> >>> Brad >>> >>> >>> >>> On 6/21/2011 2:24 AM, Weijun Wang wrote: >>>> Hi Brad >>>> >>>> >>>>> # Timed out, Solaris 10 64bit sparcv9 >>>>> com/sun/crypto/provider/Cipher/DES/PaddingTest.java generic-all >>>>> >>>>> This test has not generated random numbers (all key material in byte[] >>>>> constants) so there is no entropy pool issue. One special thing is that >>>>> it calls the external diff command on two files but only prints out the >>>>> result with no exception thrown when the files are different (6330275). >>>> >>>> I see you're RE for . Are you working on it now? >>>> >>>> Thanks >>>> Max >>>> From weijun.wang at oracle.com Fri Jul 8 00:55:18 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 08 Jul 2011 15:55:18 +0800 Subject: code review request: 6330275: Rework the PaddingTest regression test. (was Re: Fwd: jdk_security2 tests) In-Reply-To: <4E16A005.3040104@oracle.com> References: <4E006369.3010808@oracle.com> <4E0282D2.2040708@oracle.com> <4E028D6E.1040503@oracle.com> <4E16902D.1060305@oracle.com> <4E16A005.3040104@oracle.com> Message-ID: <4E16B7E6.6020505@oracle.com> On 07/08/2011 02:13 PM, Stuart Marks wrote: > On 7/7/11 10:05 PM, Bradford Wetmore wrote: >> My only comment is in the diff section. I realize it's a >> FileInputStream and >> all the bytes should be obtained on a read, but I think you might want to >> consider the case of a short read for whatever reason. FileInputStream >> doesn't >> guarantee that all bytes will be returned, just "some". It might be >> better to >> read both files until EOF, then compare sizes/contents. You're correct. > > In this vein, it might be reasonable to consider using > java.nio.file.Files.readAllBytes(), which takes a Path and returns a > byte[]. Then simply call Arrays.equals() on the results. The diff method is now -- private static void diff(String fname1, String fname2) throws Exception { if (!Arrays.equals(Files.readAllBytes(new File(fname1).toPath()), Files.readAllBytes(new File(fname2).toPath()))) { throw new Exception( "files " + fname1 + " and " + fname2 + " differ"); } } I should learn these new JDK 7 classes more. I guess "new File(f).toPath()" is the most straight forward way to get a Path object? Thanks Max > > s'marks > > >> Otherwise, looks fine. >> >> Brad >> >> >> >> >> >> >> >> On 6/22/2011 5:48 PM, Weijun Wang wrote: >>> http://cr.openjdk.java.net/~weijun/6330275/webrev.00/ >>> >>> Thanks >>> Max >>> >>> On 06/23/2011 08:03 AM, Brad Wetmore wrote: >>>> No, feel free to take it. >>>> >>>> Brad >>>> >>>> >>>> >>>> On 6/21/2011 2:24 AM, Weijun Wang wrote: >>>>> Hi Brad >>>>> >>>>> >>>>>> # Timed out, Solaris 10 64bit sparcv9 >>>>>> com/sun/crypto/provider/Cipher/DES/PaddingTest.java generic-all >>>>>> >>>>>> This test has not generated random numbers (all key material in >>>>>> byte[] >>>>>> constants) so there is no entropy pool issue. One special thing is >>>>>> that >>>>>> it calls the external diff command on two files but only prints >>>>>> out the >>>>>> result with no exception thrown when the files are different >>>>>> (6330275). >>>>> >>>>> I see you're RE for . Are you working on it now? >>>>> >>>>> Thanks >>>>> Max >>>>> From stuart.marks at oracle.com Fri Jul 8 08:53:25 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 08 Jul 2011 08:53:25 -0700 Subject: code review request: 6330275: Rework the PaddingTest regression test. (was Re: Fwd: jdk_security2 tests) In-Reply-To: <4E16B7E6.6020505@oracle.com> References: <4E006369.3010808@oracle.com> <4E0282D2.2040708@oracle.com> <4E028D6E.1040503@oracle.com> <4E16902D.1060305@oracle.com> <4E16A005.3040104@oracle.com> <4E16B7E6.6020505@oracle.com> Message-ID: <4E1727F5.3020709@oracle.com> On 7/8/11 12:55 AM, Weijun Wang wrote: > The diff method is now -- > > private static void diff(String fname1, String fname2) throws Exception { > if (!Arrays.equals(Files.readAllBytes(new File(fname1).toPath()), > Files.readAllBytes(new File(fname2).toPath()))) { > throw new Exception( > "files " + fname1 + " and " + fname2 + " differ"); > } > } > > I should learn these new JDK 7 classes more. I guess "new File(f).toPath()" is > the most straight forward way to get a Path object? I think Paths.get(f) is probably preferable. Yes, there's a lot of new stuff here in Java 7. I learned all I know about it from Alan. :-) s'marks From kumar.x.srinivasan at oracle.com Sat Jul 9 12:24:36 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 09 Jul 2011 19:24:36 +0000 Subject: hg: jdk8/tl/jdk: 7060849: Eliminate pack200 build warnings Message-ID: <20110709192500.45625472FE@hg.openjdk.java.net> Changeset: 63be90976177 Author: ksrini Date: 2011-07-08 10:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/63be90976177 7060849: Eliminate pack200 build warnings Reviewed-by: ksrini, jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/com/sun/java/pack/Makefile ! make/common/shared/Defs-java.gmk ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java From alexandre.boulgakov at oracle.com Mon Jul 11 13:56:06 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Mon, 11 Jul 2011 13:56:06 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror Message-ID: <4E1B6366.106@oracle.com> Hello Brad, Could you please review these changes? Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 webrev: http://cr.openjdk.java.net/~jjg/7076075/ Summary: * Small changes to Java files to remove most build warnings. * Small changes to relevant makefiles to prevent reintroduction of removed warnings. Thanks, Sasha Boulgakov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20110711/d9abe2f8/attachment.html From schlosna at gmail.com Mon Jul 11 15:39:09 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Mon, 11 Jul 2011 18:39:09 -0400 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E1B6366.106@oracle.com> References: <4E1B6366.106@oracle.com> Message-ID: On Mon, Jul 11, 2011 at 4:56 PM, Alexandre Boulgakov wrote: > Could you please review these changes? > > Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 > webrev: http://cr.openjdk.java.net/~jjg/7076075/ > > Summary: > > Small changes to Java files to remove most build warnings. > Small changes to relevant makefiles to prevent reintroduction of removed > warnings. Sasha, You can avoid the need for the @SuppressWarnings("unchecked") in many cases by using Class.cast(Object) instead of (T). For example, in BlockCipherParamsCore.java line 97: 93 T getParameterSpec(Class paramSpec) 94 throws InvalidParameterSpecException 95 { 96 if (IvParameterSpec.class.isAssignableFrom(paramSpec)) { 97 return paramSpec.cast(new IvParameterSpec(this.iv)); 98 } else { 99 throw new InvalidParameterSpecException 100 ("Inappropriate parameter specification"); 101 } 102 } Also see these locations as well: BlockCipherParamsCore.java line 97 DHKeyFactory.java lines 153, 158, 171, 176 DHParameters.java line 103 OAEPParameters.java line 187 PBEParameters.java line 106 RC2Parameters.java line 185 GSSUtil.java line 352 SubjectComber.java line 60 DSAKeyFactory.java lines 195, 201, 220, 226 DSAParameters.java line 106 RSAKeyFactory.java lines 355, 360, 368, 372, 388 - Dave From alexandre.boulgakov at oracle.com Mon Jul 11 15:41:31 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Mon, 11 Jul 2011 15:41:31 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: References: <4E1B6366.106@oracle.com> Message-ID: <4E1B7C1B.1070305@oracle.com> Thanks, Dave. I didn't know that existed. -Sasha On 7/11/2011 3:39 PM, David Schlosnagle wrote: > On Mon, Jul 11, 2011 at 4:56 PM, Alexandre Boulgakov > wrote: >> Could you please review these changes? >> >> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 >> webrev: http://cr.openjdk.java.net/~jjg/7076075/ >> >> Summary: >> >> Small changes to Java files to remove most build warnings. >> Small changes to relevant makefiles to prevent reintroduction of removed >> warnings. > Sasha, > > You can avoid the need for the @SuppressWarnings("unchecked") in many > cases by using Class.cast(Object) instead of (T). For example, in > BlockCipherParamsCore.java line 97: > 93 T > getParameterSpec(Class paramSpec) > 94 throws InvalidParameterSpecException > 95 { > 96 if (IvParameterSpec.class.isAssignableFrom(paramSpec)) { > 97 return paramSpec.cast(new IvParameterSpec(this.iv)); > 98 } else { > 99 throw new InvalidParameterSpecException > 100 ("Inappropriate parameter specification"); > 101 } > 102 } > > Also see these locations as well: > BlockCipherParamsCore.java line 97 > DHKeyFactory.java lines 153, 158, 171, 176 > DHParameters.java line 103 > OAEPParameters.java line 187 > PBEParameters.java line 106 > RC2Parameters.java line 185 > GSSUtil.java line 352 > SubjectComber.java line 60 > DSAKeyFactory.java lines 195, 201, 220, 226 > DSAParameters.java line 106 > RSAKeyFactory.java lines 355, 360, 368, 372, 388 > > - Dave From dfpomeroy at gmail.com Mon Jul 11 16:13:09 2011 From: dfpomeroy at gmail.com (David Pomeroy) Date: Mon, 11 Jul 2011 16:13:09 -0700 Subject: complete certificate path validation Message-ID: Hello All, I'm trying to figure out if a certain security configuration is supported in openJDK or not. I want to do client authentication at the server with one trusted root self-signed anchor certificate. Then I want the client to send up only a client certificate, that was issued by a subordinate CA. I want to use the "PKIX" TrustManagerFactory to accomplish this. The client authentication succeeds when the subordinate CA certificate is added to the truststore used to initialize the PKIXBuilderParameters that is fed into the TrustManagerFactory. However, the subordinate CA is not a root (self-signed) certificate and the PKIXCertPathValidator doesn't seem to care about that. This doesn't meet my requirements, since the client cert path is not built all the way up to a root certificate. If I do not include the subordinate CA certificate in the truststore, the client cannot connect and it doesn't seem like the validator is invoked at all. I know I would have to include the sub CA certificate somehow but I'm not sure how to do this. Is this configuration even supported? I have tried openJDK 6 and 7, same results with each. I imagine if the client sent up the sub CA certificate as well as the client certificate, the chain would be validated from the root all the way down. However, this is not the desired configuration. Any help here would be appreciated. Thanks! Dave P -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20110711/9b9a82e1/attachment.html From xuelei.fan at oracle.com Mon Jul 11 18:21:13 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 Jul 2011 09:21:13 +0800 Subject: complete certificate path validation In-Reply-To: References: Message-ID: <4E1BA189.4070700@oracle.com> Hi Dave, What's the underlying requirements that the client cannot send a full certification path? That's not the way TLS works. You may be also interesting in the post, "Best Practice: to Include the Complete Certificate Chain in the KeyStore", http://sim.ivi.co/2011/06/best-practice-to-include-compelete.html Regards, Xuelei On 7/12/2011 7:13 AM, David Pomeroy wrote: > Hello All, > > I'm trying to figure out if a certain security configuration is > supported in openJDK or not. > > I want to do client authentication at the server with one trusted root > self-signed anchor certificate. Then I want the client to send up only > a client certificate, that was issued by a subordinate CA. I want to > use the "PKIX" TrustManagerFactory to accomplish this. > > The client authentication succeeds when the subordinate CA certificate > is added to the truststore used to initialize the PKIXBuilderParameters > that is fed into the TrustManagerFactory. However, the subordinate CA > is not a root (self-signed) certificate and the PKIXCertPathValidator > doesn't seem to care about that. This doesn't meet my requirements, > since the client cert path is not built all the way up to a root > certificate. > > If I do not include the subordinate CA certificate in the truststore, > the client cannot connect and it doesn't seem like the validator is > invoked at all. I know I would have to include the sub CA certificate > somehow but I'm not sure how to do this. > > Is this configuration even supported? I have tried openJDK 6 and 7, > same results with each. > > I imagine if the client sent up the sub CA certificate as well as the > client certificate, the chain would be validated from the root all the > way down. However, this is not the desired configuration. > > Any help here would be appreciated. > > Thanks! > Dave P From dfpomeroy at gmail.com Mon Jul 11 18:59:01 2011 From: dfpomeroy at gmail.com (David Pomeroy) Date: Mon, 11 Jul 2011 18:59:01 -0700 Subject: complete certificate path validation In-Reply-To: <4E1BA189.4070700@oracle.com> References: <4E1BA189.4070700@oracle.com> Message-ID: Hi Xuelei, The requirement is to keep the client certificate as small as possible. I'd rather not have to store the sub CA certificate on the client. I see that the server is sending a "certificate request" as part of the TLS handshake protocol. The DNs of the trusted certificates are specified in the request. It looks like the Sun JSSE provider does not support this configuration. Can you confirm? Thanks, Dave On Mon, Jul 11, 2011 at 6:21 PM, Xuelei Fan wrote: > Hi Dave, > > What's the underlying requirements that the client cannot send a full > certification path? That's not the way TLS works. > > You may be also interesting in the post, "Best Practice: to Include the > Complete Certificate Chain in the KeyStore", > http://sim.ivi.co/2011/06/best-practice-to-include-compelete.html > > Regards, > Xuelei > > On 7/12/2011 7:13 AM, David Pomeroy wrote: > > Hello All, > > > > I'm trying to figure out if a certain security configuration is > > supported in openJDK or not. > > > > I want to do client authentication at the server with one trusted root > > self-signed anchor certificate. Then I want the client to send up only > > a client certificate, that was issued by a subordinate CA. I want to > > use the "PKIX" TrustManagerFactory to accomplish this. > > > > The client authentication succeeds when the subordinate CA certificate > > is added to the truststore used to initialize the PKIXBuilderParameters > > that is fed into the TrustManagerFactory. However, the subordinate CA > > is not a root (self-signed) certificate and the PKIXCertPathValidator > > doesn't seem to care about that. This doesn't meet my requirements, > > since the client cert path is not built all the way up to a root > > certificate. > > > > If I do not include the subordinate CA certificate in the truststore, > > the client cannot connect and it doesn't seem like the validator is > > invoked at all. I know I would have to include the sub CA certificate > > somehow but I'm not sure how to do this. > > > > Is this configuration even supported? I have tried openJDK 6 and 7, > > same results with each. > > > > I imagine if the client sent up the sub CA certificate as well as the > > client certificate, the chain would be validated from the root all the > > way down. However, this is not the desired configuration. > > > > Any help here would be appreciated. > > > > Thanks! > > Dave P > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20110711/f13c2313/attachment.html From xuelei.fan at oracle.com Mon Jul 11 19:32:02 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 Jul 2011 10:32:02 +0800 Subject: complete certificate path validation In-Reply-To: References: <4E1BA189.4070700@oracle.com> Message-ID: <4E1BB222.5060809@oracle.com> On 7/12/2011 9:59 AM, David Pomeroy wrote: > Hi Xuelei, > > The requirement is to keep the client certificate as small as possible. > I'd rather not have to store the sub CA certificate on the client. > > I see that the server is sending a "certificate request" as part of the > TLS handshake protocol. The DNs of the trusted certificates are > specified in the request. > > It looks like the Sun JSSE provider does not support this > configuration. Can you confirm? > It depends. If there is no way to build a certification path to the trusted certificates sent by server, Oracle JSSE provider, SunJSSE, cannot work by default. JSSE is an flexible framework, you can do a lot of customization. Please refer to JSSE reference guide if you want change the default behaviors of SunJSSE, http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html. Xuelei > Thanks, Dave > > > On Mon, Jul 11, 2011 at 6:21 PM, Xuelei Fan > wrote: > > Hi Dave, > > What's the underlying requirements that the client cannot send a full > certification path? That's not the way TLS works. > > You may be also interesting in the post, "Best Practice: to Include the > Complete Certificate Chain in the KeyStore", > http://sim.ivi.co/2011/06/best-practice-to-include-compelete.html > > Regards, > Xuelei > > On 7/12/2011 7:13 AM, David Pomeroy wrote: > > Hello All, > > > > I'm trying to figure out if a certain security configuration is > > supported in openJDK or not. > > > > I want to do client authentication at the server with one trusted root > > self-signed anchor certificate. Then I want the client to send up > only > > a client certificate, that was issued by a subordinate CA. I want to > > use the "PKIX" TrustManagerFactory to accomplish this. > > > > The client authentication succeeds when the subordinate CA certificate > > is added to the truststore used to initialize the > PKIXBuilderParameters > > that is fed into the TrustManagerFactory. However, the subordinate CA > > is not a root (self-signed) certificate and the PKIXCertPathValidator > > doesn't seem to care about that. This doesn't meet my requirements, > > since the client cert path is not built all the way up to a root > > certificate. > > > > If I do not include the subordinate CA certificate in the truststore, > > the client cannot connect and it doesn't seem like the validator is > > invoked at all. I know I would have to include the sub CA certificate > > somehow but I'm not sure how to do this. > > > > Is this configuration even supported? I have tried openJDK 6 and 7, > > same results with each. > > > > I imagine if the client sent up the sub CA certificate as well as the > > client certificate, the chain would be validated from the root all the > > way down. However, this is not the desired configuration. > > > > Any help here would be appreciated. > > > > Thanks! > > Dave P > > From yuka.kamiya at oracle.com Mon Jul 11 15:32:41 2011 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Mon, 11 Jul 2011 22:32:41 +0000 Subject: hg: jdk8/tl/jdk: 7012364: test/java/util/Locale/LocaleCategory.sh fails on Cygwin Message-ID: <20110711223255.8E2FF47371@hg.openjdk.java.net> Changeset: 5adf431673ac Author: peytoia Date: 2011-07-12 07:32 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5adf431673ac 7012364: test/java/util/Locale/LocaleCategory.sh fails on Cygwin Reviewed-by: okutsu ! test/java/util/Locale/LocaleCategory.sh From fweimer at bfk.de Tue Jul 12 00:20:58 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 12 Jul 2011 07:20:58 +0000 Subject: complete certificate path validation In-Reply-To: (David Pomeroy's message of "Mon, 11 Jul 2011 18:59:01 -0700") References: <4E1BA189.4070700@oracle.com> Message-ID: <82sjqcrmlh.fsf@mid.bfk.de> * David Pomeroy: > It looks like the Sun JSSE provider does not support this > configuration. If you supply your own X509TrustManager implementation, I'm pretty sure you can get it to work. It definitely works if the client supplies a self-signed certificate, and I see no reason why it wouldn't if it's not self-signed. -- 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 chris.hegarty at oracle.com Tue Jul 12 07:24:52 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 12 Jul 2011 14:24:52 +0000 Subject: hg: jdk8/tl/jdk: 7058828: test/java/util/concurrent/Phaser/Arrive.java fails intermittently Message-ID: <20110712142517.56AC24739F@hg.openjdk.java.net> Changeset: 549b7c3f0bdc Author: dl Date: 2011-07-12 15:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/549b7c3f0bdc 7058828: test/java/util/concurrent/Phaser/Arrive.java fails intermittently Reviewed-by: chegar ! test/java/util/concurrent/Phaser/Arrive.java From naoto.sato at oracle.com Tue Jul 12 10:36:48 2011 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 12 Jul 2011 17:36:48 +0000 Subject: hg: jdk8/tl/jdk: 7022407: Spinning CPU in LocaleObjectCache.get() Message-ID: <20110712173710.21D48473A7@hg.openjdk.java.net> Changeset: 42fe05e54e69 Author: naoto Date: 2011-07-12 10:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42fe05e54e69 7022407: Spinning CPU in LocaleObjectCache.get() Reviewed-by: okutsu ! src/share/classes/sun/util/locale/LocaleObjectCache.java From bradford.wetmore at oracle.com Tue Jul 12 13:03:45 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 12 Jul 2011 13:03:45 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E1B6366.106@oracle.com> References: <4E1B6366.106@oracle.com> Message-ID: <4E1CA8A1.1050409@oracle.com> Sean/Valerie/Max/Xuelei, > Hello Brad, > > Could you please review these changes? I'm swamped again, can one of you take a look at Sasha's changes? Brad On 7/11/2011 1:56 PM, Alexandre Boulgakov wrote: > Hello Brad, > > Could you please review these changes? > > Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 > webrev: http://cr.openjdk.java.net/~jjg/7076075/ > > Summary: > > * Small changes to Java files to remove most build warnings. > * Small changes to relevant makefiles to prevent reintroduction of > removed warnings. > > > Thanks, > Sasha Boulgakov > From alexandre.boulgakov at oracle.com Tue Jul 12 13:16:18 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Tue, 12 Jul 2011 13:16:18 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E1CA8A1.1050409@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> Message-ID: <4E1CAB92.8080408@oracle.com> Since yesterday's webrev, I've changed some unchecked casts to use Class.cast(Object) instead, per Dave's suggestion. Updated webrev: http://cr.openjdk.java.net/~jjg/7064075.1/ Also, the original webrev was posted under the wrong bug ID, so it's been moved to http://cr.openjdk.java.net/~jjg/7064075/. Thanks, Sasha On 7/12/2011 1:03 PM, Brad Wetmore wrote: > Sean/Valerie/Max/Xuelei, > > > Hello Brad, > > > > Could you please review these changes? > > I'm swamped again, can one of you take a look at Sasha's changes? > > Brad > > > > On 7/11/2011 1:56 PM, Alexandre Boulgakov wrote: >> Hello Brad, >> >> Could you please review these changes? >> >> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 >> webrev: http://cr.openjdk.java.net/~jjg/7076075/ >> >> Summary: >> >> * Small changes to Java files to remove most build warnings. >> * Small changes to relevant makefiles to prevent reintroduction of >> removed warnings. >> >> >> Thanks, >> Sasha Boulgakov >> From sean.mullan at oracle.com Tue Jul 12 13:52:27 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 12 Jul 2011 16:52:27 -0400 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E1CA8A1.1050409@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> Message-ID: <4E1CB40B.3010804@oracle.com> I'll look at it tomorrow, unless Valerie/Max/Xuelei beat me to it. --Sean On 7/12/11 4:03 PM, Brad Wetmore wrote: > Sean/Valerie/Max/Xuelei, > > > Hello Brad, > > > > Could you please review these changes? > > I'm swamped again, can one of you take a look at Sasha's changes? > > Brad > > > > On 7/11/2011 1:56 PM, Alexandre Boulgakov wrote: >> Hello Brad, >> >> Could you please review these changes? >> >> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 >> webrev: http://cr.openjdk.java.net/~jjg/7076075/ >> >> Summary: >> >> * Small changes to Java files to remove most build warnings. >> * Small changes to relevant makefiles to prevent reintroduction of >> removed warnings. >> >> >> Thanks, >> Sasha Boulgakov >> From dfpomeroy at gmail.com Tue Jul 12 14:07:36 2011 From: dfpomeroy at gmail.com (David Pomeroy) Date: Tue, 12 Jul 2011 14:07:36 -0700 Subject: complete certificate path validation In-Reply-To: <82sjqcrmlh.fsf@mid.bfk.de> References: <4E1BA189.4070700@oracle.com> <82sjqcrmlh.fsf@mid.bfk.de> Message-ID: Hi Florian, I'd prefer not to override the Sun provider since I am utilizing the CRL distribution point checking. This may be my only option though. Thanks, Dave On Tue, Jul 12, 2011 at 12:20 AM, Florian Weimer wrote: > * David Pomeroy: > > > It looks like the Sun JSSE provider does not support this > > configuration. > > If you supply your own X509TrustManager implementation, I'm pretty sure > you can get it to work. It definitely works if the client supplies a > self-signed certificate, and I see no reason why it wouldn't if it's not > self-signed. > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20110712/31de1e7b/attachment.html From chris.hegarty at oracle.com Wed Jul 13 04:25:47 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 13 Jul 2011 11:25:47 +0000 Subject: hg: jdk8/tl/jdk: 7057320: test/java/util/concurrent/Executors/AutoShutdown.java failing intermittently Message-ID: <20110713112607.CC1A7473D8@hg.openjdk.java.net> Changeset: db419c454f92 Author: dl Date: 2011-07-13 12:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db419c454f92 7057320: test/java/util/concurrent/Executors/AutoShutdown.java failing intermittently Summary: Add retry/timeout for checking activeCount Reviewed-by: chegar ! test/java/util/concurrent/Executors/AutoShutdown.java From weijun.wang at oracle.com Thu Jul 14 00:24:51 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 Jul 2011 15:24:51 +0800 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: <4E1E99C3.7010501@oracle.com> Ping again. Thanks Max On 07/07/2011 09:10 AM, 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.equalsWithoutRealm(). > 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 lana.steuck at oracle.com Thu Jul 14 22:57:54 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 15 Jul 2011 05:57:54 +0000 Subject: hg: jdk8/tl: 5 new changesets Message-ID: <20110715055754.5765F47440@hg.openjdk.java.net> Changeset: 8da980eedab6 Author: jeff Date: 2011-06-22 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8da980eedab6 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d91364304d7c Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d91364304d7c Merge Changeset: ee67ee3bd597 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ee67ee3bd597 Added tag jdk7-b147 for changeset d91364304d7c ! .hgtags Changeset: 04734fe746f0 Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/04734fe746f0 Merge Changeset: 05e24d6ed56d Author: lana Date: 2011-07-14 18:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/05e24d6ed56d Merge From lana.steuck at oracle.com Thu Jul 14 22:57:58 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 15 Jul 2011 05:57:58 +0000 Subject: hg: jdk8/tl/jaxws: 4 new changesets Message-ID: <20110715055758.2205647441@hg.openjdk.java.net> Changeset: 632e38191caa Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/632e38191caa 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d13b1f877bb5 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d13b1f877bb5 Merge Changeset: 2605f832dfbf Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2605f832dfbf Added tag jdk7-b147 for changeset d13b1f877bb5 ! .hgtags Changeset: 47022a1b59be Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/47022a1b59be Merge From lana.steuck at oracle.com Thu Jul 14 22:57:54 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 15 Jul 2011 05:57:54 +0000 Subject: hg: jdk8/tl/corba: 4 new changesets Message-ID: <20110715055758.65FBB47442@hg.openjdk.java.net> Changeset: bba0e37d7006 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/bba0e37d7006 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 73323cb33962 Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/73323cb33962 Merge Changeset: 960011ba4bf2 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/960011ba4bf2 Added tag jdk7-b147 for changeset 73323cb33962 ! .hgtags Changeset: 97014e43181f Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/97014e43181f Merge From lana.steuck at oracle.com Thu Jul 14 22:57:59 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 15 Jul 2011 05:57:59 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20110715055759.AADBF47443@hg.openjdk.java.net> Changeset: eed2486cb10b Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/eed2486cb10b 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: fc268cd1dd5d Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/fc268cd1dd5d Merge Changeset: 6c9ac74190a0 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6c9ac74190a0 Added tag jdk7-b147 for changeset fc268cd1dd5d ! .hgtags Changeset: 58dfc6f729e8 Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/58dfc6f729e8 Merge From lana.steuck at oracle.com Thu Jul 14 22:58:06 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 15 Jul 2011 05:58:06 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20110715055821.BB8D847444@hg.openjdk.java.net> Changeset: a72412b148d7 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a72412b148d7 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 58bc532d6341 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58bc532d6341 Merge Changeset: ce654f4ecfd8 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ce654f4ecfd8 Added tag jdk7-b147 for changeset 58bc532d6341 ! .hgtags Changeset: e0dec1645823 Author: schien Date: 2011-06-27 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e0dec1645823 Merge Changeset: 469e3bec9b27 Author: lana Date: 2011-06-30 14:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/469e3bec9b27 Merge Changeset: 025a370b9fc3 Author: lana Date: 2011-07-14 18:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/025a370b9fc3 Merge From lana.steuck at oracle.com Thu Jul 14 22:58:17 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 15 Jul 2011 05:58:17 +0000 Subject: hg: jdk8/tl/jdk: 9 new changesets Message-ID: <20110715055956.8327947445@hg.openjdk.java.net> Changeset: cfd7602f5c52 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfd7602f5c52 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: f097ca2434b1 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f097ca2434b1 Merge Changeset: 9b8c96f96a0f Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b8c96f96a0f Added tag jdk7-b147 for changeset f097ca2434b1 ! .hgtags Changeset: fc350fd41f31 Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc350fd41f31 Merge Changeset: 685a01aa8cd2 Author: prr Date: 2011-05-25 19:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/685a01aa8cd2 7044394: TrueTypeFont inner class DirectoryEntry should be static Reviewed-by: bae, jgodinez ! src/share/classes/sun/font/TrueTypeFont.java Changeset: 73d420a7199b Author: dlila Date: 2011-06-24 16:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73d420a7199b 7049339: AnyBlit is broken with non-rectangular clips. Reviewed-by: flar ! src/share/classes/sun/java2d/loops/Blit.java + test/sun/java2d/loops/Bug7049339.java Changeset: bb481604e929 Author: lana Date: 2011-06-30 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb481604e929 Merge Changeset: 9bcf6217a374 Author: lana Date: 2011-06-30 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bcf6217a374 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: 7ac6a297f9a0 Author: lana Date: 2011-07-14 18:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ac6a297f9a0 Merge From sean.mullan at oracle.com Fri Jul 15 05:19:03 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 15 Jul 2011 08:19:03 -0400 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E1CAB92.8080408@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> Message-ID: <4E203037.6000605@oracle.com> All the changes look good. I only have a couple of questions/comments: 1) How did you calculate the serialVersionUID for the classes that had omitted this field? Ideally you want to calculate it on a previous version of the class, for compatibility reasons. This is especially important for Serializable objects that are exposed via public APIs. 2) Consider adding a comment explaining the "@SuppressWarnings("unchecked")" annotations --Sean On 7/12/11 4:16 PM, Alexandre Boulgakov wrote: > Since yesterday's webrev, I've changed some unchecked casts to use > Class.cast(Object) instead, per Dave's suggestion. > Updated webrev: http://cr.openjdk.java.net/~jjg/7064075.1/ > > Also, the original webrev was posted under the wrong bug ID, so it's > been moved to http://cr.openjdk.java.net/~jjg/7064075/. > > Thanks, > Sasha > > On 7/12/2011 1:03 PM, Brad Wetmore wrote: >> Sean/Valerie/Max/Xuelei, >> >>> Hello Brad, >>> >>> Could you please review these changes? >> >> I'm swamped again, can one of you take a look at Sasha's changes? >> >> Brad >> >> >> >> On 7/11/2011 1:56 PM, Alexandre Boulgakov wrote: >>> Hello Brad, >>> >>> Could you please review these changes? >>> >>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 >>> webrev: http://cr.openjdk.java.net/~jjg/7076075/ >>> >>> Summary: >>> >>> * Small changes to Java files to remove most build warnings. >>> * Small changes to relevant makefiles to prevent reintroduction of >>> removed warnings. >>> >>> >>> Thanks, >>> Sasha Boulgakov >>> From chris.hegarty at oracle.com Fri Jul 15 06:18:59 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 15 Jul 2011 14:18:59 +0100 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E203037.6000605@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> Message-ID: <4E203E43.1010305@oracle.com> On 07/15/11 01:19 PM, Sean Mullan wrote: > All the changes look good. I only have a couple of questions/comments: > > 1) How did you calculate the serialVersionUID for the classes that had omitted > this field? Ideally you want to calculate it on a previous version of the class, > for compatibility reasons. This is especially important for Serializable objects > that are exposed via public APIs. I added serialVersionUID to a bunch of public java lang/net/util classes a wile back. I used jdk/bin/serialver to generate the serialVersionUID and verified that it was the same for previous versions of the class back to when the class was originally added. Not such a problem when you have archived jdk's back to 1.1.8 in /java/re in the US domain! Maybe Sasha could do something similar. -Chris. > > 2) Consider adding a comment explaining the "@SuppressWarnings("unchecked")" > annotations > > --Sean > > On 7/12/11 4:16 PM, Alexandre Boulgakov wrote: >> Since yesterday's webrev, I've changed some unchecked casts to use >> Class.cast(Object) instead, per Dave's suggestion. >> Updated webrev: http://cr.openjdk.java.net/~jjg/7064075.1/ >> >> Also, the original webrev was posted under the wrong bug ID, so it's >> been moved to http://cr.openjdk.java.net/~jjg/7064075/. >> >> Thanks, >> Sasha >> >> On 7/12/2011 1:03 PM, Brad Wetmore wrote: >>> Sean/Valerie/Max/Xuelei, >>> >>>> Hello Brad, >>>> >>>> Could you please review these changes? >>> >>> I'm swamped again, can one of you take a look at Sasha's changes? >>> >>> Brad >>> >>> >>> >>> On 7/11/2011 1:56 PM, Alexandre Boulgakov wrote: >>>> Hello Brad, >>>> >>>> Could you please review these changes? >>>> >>>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 >>>> webrev: http://cr.openjdk.java.net/~jjg/7076075/ >>>> >>>> Summary: >>>> >>>> * Small changes to Java files to remove most build warnings. >>>> * Small changes to relevant makefiles to prevent reintroduction of >>>> removed warnings. >>>> >>>> >>>> Thanks, >>>> Sasha Boulgakov >>>> From kumar.x.srinivasan at oracle.com Fri Jul 15 16:39:42 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 15 Jul 2011 23:39:42 +0000 Subject: hg: jdk8/tl/jdk: 7062969: java -help still shows http://java.sun.com/javase/reference Message-ID: <20110715234004.08B6447477@hg.openjdk.java.net> Changeset: c0c983ca797b Author: ksrini Date: 2011-07-15 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0c983ca797b 7062969: java -help still shows http://java.sun.com/javase/reference Reviewed-by: ohair, darcy ! src/share/classes/sun/launcher/resources/launcher.properties From joe.darcy at oracle.com Sun Jul 17 18:54:02 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 18 Jul 2011 01:54:02 +0000 Subject: hg: jdk8/tl/jdk: 7062430: Minor inconsistency in ulp descriptions Message-ID: <20110718015423.68BC1474E3@hg.openjdk.java.net> Changeset: d987f8738096 Author: darcy Date: 2011-07-17 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d987f8738096 7062430: Minor inconsistency in ulp descriptions Reviewed-by: smarks, alanb ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java From alan.bateman at oracle.com Mon Jul 18 05:12:29 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 18 Jul 2011 12:12:29 +0000 Subject: hg: jdk8/tl/jdk: 7068059: Update jdk/test/ProblemList.txt Message-ID: <20110718121251.4A28B474F8@hg.openjdk.java.net> Changeset: cbfc7f910af3 Author: alanb Date: 2011-07-18 13:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cbfc7f910af3 7068059: Update jdk/test/ProblemList.txt Reviewed-by: mchung, chegar ! test/ProblemList.txt From alexandre.boulgakov at oracle.com Mon Jul 18 10:17:17 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Mon, 18 Jul 2011 10:17:17 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E203E43.1010305@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> Message-ID: <4E246A9D.4010702@oracle.com> Please see my responses in-line. Thanks for reviewing! -Sasha On 7/15/2011 6:18 AM, Chris Hegarty wrote: > On 07/15/11 01:19 PM, Sean Mullan wrote: >> All the changes look good. I only have a couple of questions/comments: >> >> 1) How did you calculate the serialVersionUID for the classes that >> had omitted >> this field? Ideally you want to calculate it on a previous version of >> the class, >> for compatibility reasons. This is especially important for >> Serializable objects >> that are exposed via public APIs. > > I added serialVersionUID to a bunch of public java lang/net/util > classes a wile back. I used jdk/bin/serialver to generate the > serialVersionUID and verified that it was the same for previous > versions of the class back to when the class was originally added. Not > such a problem when you have archived jdk's back to 1.1.8 in /java/re > in the US domain! Maybe Sasha could do something similar. I used jdk/bin/serialver from JDK 7. Should I check if it's the same for when the classes were originally added? > > -Chris. > >> >> 2) Consider adding a comment explaining the >> "@SuppressWarnings("unchecked")" >> annotations That sounds good. I'll post another webrev once I've added the comments. >> >> --Sean >> >> On 7/12/11 4:16 PM, Alexandre Boulgakov wrote: >>> Since yesterday's webrev, I've changed some unchecked casts to use >>> Class.cast(Object) instead, per Dave's suggestion. >>> Updated webrev: http://cr.openjdk.java.net/~jjg/7064075.1/ >>> >>> Also, the original webrev was posted under the wrong bug ID, so it's >>> been moved to http://cr.openjdk.java.net/~jjg/7064075/. >>> >>> Thanks, >>> Sasha >>> >>> On 7/12/2011 1:03 PM, Brad Wetmore wrote: >>>> Sean/Valerie/Max/Xuelei, >>>> >>>>> Hello Brad, >>>>> >>>>> Could you please review these changes? >>>> >>>> I'm swamped again, can one of you take a look at Sasha's changes? >>>> >>>> Brad >>>> >>>> >>>> >>>> On 7/11/2011 1:56 PM, Alexandre Boulgakov wrote: >>>>> Hello Brad, >>>>> >>>>> Could you please review these changes? >>>>> >>>>> Bug detail: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 >>>>> webrev: http://cr.openjdk.java.net/~jjg/7076075/ >>>>> >>>>> Summary: >>>>> >>>>> * Small changes to Java files to remove most build warnings. >>>>> * Small changes to relevant makefiles to prevent >>>>> reintroduction of >>>>> removed warnings. >>>>> >>>>> >>>>> Thanks, >>>>> Sasha Boulgakov >>>>> From sean.mullan at oracle.com Mon Jul 18 13:43:39 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 18 Jul 2011 16:43:39 -0400 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E246A9D.4010702@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> Message-ID: <4E249AFB.6040804@oracle.com> On 7/18/11 1:17 PM, Alexandre Boulgakov wrote: > Please see my responses in-line. > > Thanks for reviewing! > > -Sasha > > On 7/15/2011 6:18 AM, Chris Hegarty wrote: >> On 07/15/11 01:19 PM, Sean Mullan wrote: >>> All the changes look good. I only have a couple of questions/comments: >>> >>> 1) How did you calculate the serialVersionUID for the classes that >>> had omitted >>> this field? Ideally you want to calculate it on a previous version of >>> the class, >>> for compatibility reasons. This is especially important for >>> Serializable objects >>> that are exposed via public APIs. >> >> I added serialVersionUID to a bunch of public java lang/net/util >> classes a wile back. I used jdk/bin/serialver to generate the >> serialVersionUID and verified that it was the same for previous >> versions of the class back to when the class was originally added. Not >> such a problem when you have archived jdk's back to 1.1.8 in /java/re >> in the US domain! Maybe Sasha could do something similar. > I used jdk/bin/serialver from JDK 7. Should I check if it's the same for > when the classes were originally added? Yes, if it is the same as when the class was originally added to the JDK that would most likely mean it has not changed since and it is safe to use. --Sean >> >> -Chris. >> >>> >>> 2) Consider adding a comment explaining the >>> "@SuppressWarnings("unchecked")" >>> annotations > That sounds good. I'll post another webrev once I've added the comments. >>> >>> --Sean >>> >>> On 7/12/11 4:16 PM, Alexandre Boulgakov wrote: >>>> Since yesterday's webrev, I've changed some unchecked casts to use >>>> Class.cast(Object) instead, per Dave's suggestion. >>>> Updated webrev: http://cr.openjdk.java.net/~jjg/7064075.1/ >>>> >>>> Also, the original webrev was posted under the wrong bug ID, so it's >>>> been moved to http://cr.openjdk.java.net/~jjg/7064075/. >>>> >>>> Thanks, >>>> Sasha >>>> >>>> On 7/12/2011 1:03 PM, Brad Wetmore wrote: >>>>> Sean/Valerie/Max/Xuelei, >>>>> >>>>>> Hello Brad, >>>>>> >>>>>> Could you please review these changes? >>>>> >>>>> I'm swamped again, can one of you take a look at Sasha's changes? >>>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>> On 7/11/2011 1:56 PM, Alexandre Boulgakov wrote: >>>>>> Hello Brad, >>>>>> >>>>>> Could you please review these changes? >>>>>> >>>>>> Bug detail: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 >>>>>> webrev: http://cr.openjdk.java.net/~jjg/7076075/ >>>>>> >>>>>> Summary: >>>>>> >>>>>> * Small changes to Java files to remove most build warnings. >>>>>> * Small changes to relevant makefiles to prevent >>>>>> reintroduction of >>>>>> removed warnings. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Sasha Boulgakov >>>>>> From chris.hegarty at oracle.com Mon Jul 18 14:31:13 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 18 Jul 2011 21:31:13 +0000 Subject: hg: jdk8/tl/jdk: 7021280: SocketPermission should accept wildcards Message-ID: <20110718213131.DE79247511@hg.openjdk.java.net> Changeset: 8bbea505b060 Author: chegar Date: 2011-07-18 22:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8bbea505b060 7021280: SocketPermission should accept wildcards Reviewed-by: michaelm ! src/share/classes/java/net/SocketPermission.java + test/java/net/SocketPermission/Wildcard.java From alexandre.boulgakov at oracle.com Mon Jul 18 14:35:44 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Mon, 18 Jul 2011 14:35:44 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E249AFB.6040804@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> Message-ID: <4E24A730.1000301@oracle.com> Is there an easy way to see when a class was added to the JDK? Thanks, Sasha On 7/18/2011 1:43 PM, Sean Mullan wrote: > On 7/18/11 1:17 PM, Alexandre Boulgakov wrote: >> Please see my responses in-line. >> >> Thanks for reviewing! >> >> -Sasha >> >> On 7/15/2011 6:18 AM, Chris Hegarty wrote: >>> On 07/15/11 01:19 PM, Sean Mullan wrote: >>>> All the changes look good. I only have a couple of questions/comments: >>>> >>>> 1) How did you calculate the serialVersionUID for the classes that >>>> had omitted >>>> this field? Ideally you want to calculate it on a previous version of >>>> the class, >>>> for compatibility reasons. This is especially important for >>>> Serializable objects >>>> that are exposed via public APIs. >>> I added serialVersionUID to a bunch of public java lang/net/util >>> classes a wile back. I used jdk/bin/serialver to generate the >>> serialVersionUID and verified that it was the same for previous >>> versions of the class back to when the class was originally added. Not >>> such a problem when you have archived jdk's back to 1.1.8 in /java/re >>> in the US domain! Maybe Sasha could do something similar. >> I used jdk/bin/serialver from JDK 7. Should I check if it's the same for >> when the classes were originally added? > Yes, if it is the same as when the class was originally added to the JDK that > would most likely mean it has not changed since and it is safe to use. > > --Sean > >>> -Chris. >>> >>>> 2) Consider adding a comment explaining the >>>> "@SuppressWarnings("unchecked")" >>>> annotations >> That sounds good. I'll post another webrev once I've added the comments. >>>> --Sean >>>> >>>> On 7/12/11 4:16 PM, Alexandre Boulgakov wrote: >>>>> Since yesterday's webrev, I've changed some unchecked casts to use >>>>> Class.cast(Object) instead, per Dave's suggestion. >>>>> Updated webrev: http://cr.openjdk.java.net/~jjg/7064075.1/ >>>>> >>>>> Also, the original webrev was posted under the wrong bug ID, so it's >>>>> been moved to http://cr.openjdk.java.net/~jjg/7064075/. >>>>> >>>>> Thanks, >>>>> Sasha >>>>> >>>>> On 7/12/2011 1:03 PM, Brad Wetmore wrote: >>>>>> Sean/Valerie/Max/Xuelei, >>>>>> >>>>>>> Hello Brad, >>>>>>> >>>>>>> Could you please review these changes? >>>>>> I'm swamped again, can one of you take a look at Sasha's changes? >>>>>> >>>>>> Brad >>>>>> >>>>>> >>>>>> >>>>>> On 7/11/2011 1:56 PM, Alexandre Boulgakov wrote: >>>>>>> Hello Brad, >>>>>>> >>>>>>> Could you please review these changes? >>>>>>> >>>>>>> Bug detail: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064075 >>>>>>> webrev: http://cr.openjdk.java.net/~jjg/7076075/ >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> * Small changes to Java files to remove most build warnings. >>>>>>> * Small changes to relevant makefiles to prevent >>>>>>> reintroduction of >>>>>>> removed warnings. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Sasha Boulgakov >>>>>>> From sean.mullan at oracle.com Mon Jul 18 15:00:24 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 18 Jul 2011 18:00:24 -0400 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E24A730.1000301@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> Message-ID: <4E24ACF8.30009@oracle.com> 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. 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. Chris, do you have any other ideas? --Sean From bradford.wetmore at oracle.com Mon Jul 18 17:33:19 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 18 Jul 2011 17:33:19 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E24ACF8.30009@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> Message-ID: <4E24D0CF.5060801@oracle.com> (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 Mon Jul 18 18:21:07 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Mon, 18 Jul 2011 18:21:07 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E24D0CF.5060801@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> Message-ID: <4E24DC03.3030407@oracle.com> 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 chris.hegarty at oracle.com Tue Jul 19 01:11:55 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Jul 2011 09:11:55 +0100 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E24ACF8.30009@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> Message-ID: <4E253C4B.8080404@oracle.com> On 07/18/11 11:00 PM, 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. > > 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. > > Chris, do you have any other ideas? I did this process manually. Yes it's a pain, but it doesn't really take that long, 1-2 minutes per class. As Sean said, the pathnames are fairly consistent. -Chris. > --Sean From xuelei.fan at oracle.com Tue Jul 19 08:22:38 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 19 Jul 2011 15:22:38 +0000 Subject: hg: jdk8/tl/jdk: 7059709: close the IO in a final block Message-ID: <20110719152258.C6DBC4753A@hg.openjdk.java.net> Changeset: 5355b9ccd19d Author: xuelei Date: 2011-07-19 08:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5355b9ccd19d 7059709: close the IO in a final block Reviewed-by: smarks, mullan, wetmore ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java From kumar.x.srinivasan at oracle.com Tue Jul 19 10:59:27 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 19 Jul 2011 17:59:27 +0000 Subject: hg: jdk8/tl/jdk: 7067922: (launcher) java -jar throws NPE if JAR file does not contain Main-Class attribute Message-ID: <20110719175938.8D9E047540@hg.openjdk.java.net> Changeset: d17eb3380a49 Author: ksrini Date: 2011-07-19 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d17eb3380a49 7067922: (launcher) java -jar throws NPE if JAR file does not contain Main-Class attribute Reviewed-by: darcy, ohair, alanb, mduigou ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java From alexandre.boulgakov at oracle.com Tue Jul 19 16:22:10 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Tue, 19 Jul 2011 16:22:10 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E24DC03.3030407@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> Message-ID: <4E2611A2.2080400@oracle.com> 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 joe.darcy at oracle.com Tue Jul 19 17:36:44 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 20 Jul 2011 00:36:44 +0000 Subject: hg: jdk8/tl/jdk: 7007535: (reflect) Please generalize Constructor and Method Message-ID: <20110720003657.82E9447552@hg.openjdk.java.net> Changeset: d083644bc615 Author: darcy Date: 2011-07-19 17:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d083644bc615 7007535: (reflect) Please generalize Constructor and Method Reviewed-by: mduigou, peterjones, dholmes, andrew ! src/share/classes/java/lang/reflect/Constructor.java + src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java From xuelei.fan at oracle.com Tue Jul 19 19:32:46 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 20 Jul 2011 10:32:46 +0800 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E2611A2.2080400@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> Message-ID: <4E263E4E.7030006@oracle.com> 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 Tue Jul 19 20:10:23 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 20 Jul 2011 11:10:23 +0800 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E2611A2.2080400@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> Message-ID: <4E26471F.2000802@oracle.com> 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 xuelei.fan at oracle.com Tue Jul 19 21:48:28 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 20 Jul 2011 04:48:28 +0000 Subject: hg: jdk8/tl/jdk: 7065972: Some race condition may happen in SSLSocketImpl class Message-ID: <20110720044846.4F3144755D@hg.openjdk.java.net> Changeset: 99dc852080e1 Author: xuelei Date: 2011-07-19 21:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99dc852080e1 7065972: Some race condition may happen in SSLSocketImpl class Reviewed-by: wetmore, weijun, dgu ! src/share/classes/sun/security/ssl/SSLSocketImpl.java From sean.mullan at oracle.com Wed Jul 20 06:32:11 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 20 Jul 2011 09:32:11 -0400 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E24DC03.3030407@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> Message-ID: <4E26D8DB.6060903@oracle.com> Hi Sasha, The updates look fine to me. --Sean On 7/18/11 9: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 Jul 20 10:25:56 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Wed, 20 Jul 2011 10:25:56 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E263E4E.7030006@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> Message-ID: <4E270FA4.4010605@oracle.com> 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. -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 Jul 20 10:28:17 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Wed, 20 Jul 2011 10:28:17 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E26471F.2000802@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> Message-ID: <4E271031.1060202@oracle.com> "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 jonathan.gibbons at oracle.com Wed Jul 20 13:23:12 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 20 Jul 2011 20:23:12 +0000 Subject: hg: jdk8/tl/jdk: 7068617: Core libraries don't build with javac -Xlint:all -Werror Message-ID: <20110720202322.A374947585@hg.openjdk.java.net> Changeset: 9505edecc8b5 Author: jjg Date: 2011-07-20 12:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9505edecc8b5 7068617: Core libraries don't build with javac -Xlint:all -Werror Reviewed-by: darcy Contributed-by: alexandre.boulgakov at oracle.com ! make/java/java/Makefile ! src/share/classes/sun/reflect/generics/reflectiveObjects/NotImplementedException.java ! src/share/classes/sun/reflect/misc/ConstructorUtil.java ! src/share/classes/sun/reflect/misc/FieldUtil.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java From Xuelei.Fan at Oracle.Com Wed Jul 20 15:37:52 2011 From: Xuelei.Fan at Oracle.Com (Xuelei.Fan at Oracle.Com) Date: Thu, 21 Jul 2011 06:37:52 +0800 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror In-Reply-To: <4E270FA4.4010605@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> Message-ID: <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> 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 Thu Jul 21 00:26:57 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Jul 2011 15:26:57 +0800 Subject: Code review request: 7059542 JNDI name operations should be locale independent Message-ID: <4E27D4C1.1030608@oracle.com> 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 chris.hegarty at oracle.com Thu Jul 21 09:29:11 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 21 Jul 2011 16:29:11 +0000 Subject: hg: jdk8/tl/jdk: 7068416: Lightweight HTTP Server should support TCP_NODELAY Message-ID: <20110721162934.6C4F8475B2@hg.openjdk.java.net> Changeset: 70ec3aa8e99a Author: chegar Date: 2011-07-21 17:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70ec3aa8e99a 7068416: Lightweight HTTP Server should support TCP_NODELAY Reviewed-by: alanb, michaelm ! src/share/classes/sun/net/httpserver/ServerConfig.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! test/com/sun/net/httpserver/Test1.java From weijun.wang at oracle.com Thu Jul 21 19:25:57 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 22 Jul 2011 02:25:57 +0000 Subject: hg: jdk8/tl/jdk: 6330275: Rework the PaddingTest regression test. Message-ID: <20110722022608.0BF564762F@hg.openjdk.java.net> Changeset: c8dbb9e19355 Author: weijun Date: 2011-07-22 10:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8dbb9e19355 6330275: Rework the PaddingTest regression test. Reviewed-by: wetmore, smarks ! test/ProblemList.txt ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java From weijun.wang at oracle.com Thu Jul 21 21:56:04 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 22 Jul 2011 12:56:04 +0800 Subject: hg: jdk8/tl/jdk: 6330275: Rework the PaddingTest regression test. In-Reply-To: References: <20110722022608.0BF564762F@hg.openjdk.java.net> Message-ID: <4E2902E4.6090905@oracle.com> [ Removed several CC ] Thanks for watching the code changes of JDK 8. In this test, if the file does not exist, it's certainly a failure. Either the test itself is not complete (if pinfile not found), or the first part of the test has some error (if cfile not found). In either case, a FileNotFoundException will be thrown. The exception is unhandled and the test will report a failure. By looking at the stack trace for the exception, we will have a basic understanding of where the problem is. Isn't that what a regression test is for? There are altogether 3 try keywords here. The first is a normal try-catch, and you can see only IllegalBlockSizeException is caught. The other 2 ones are of the new try-with-resources JDK 7 feature. See http://download.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html The color describes the code changes, red means removed, and green newly added. You can always click the "file" link to view the final version. Thanks Max On 07/22/2011 12:42 PM, jitesh dundas wrote: > > Dear Sir. > > Thank you for your reply. > > * I was going through the code of your below patch and I thought of > maybe pointing you to this direction:- > > * > catch (IllegalBlockSizeException ex) { > - if ((totalInputLen % 8 != 0) && (padding.equals("NoPadding"))) > + try (FileInputStream fin = new FileInputStream(pinfile); > + BufferedInputStream pin = new BufferedInputStream(fin); > + FileOutputStream fout = new FileOutputStream(cfile); > + BufferedOutputStream cout = new BufferedOutputStream(fout)) { > + cipher.init(Cipher.ENCRYPT_MODE, cipherKey, params); > + > + while ((len = pin.read(input, 0, bufferLen)) > 0) { > + totalInputLen += len; > + byte[] output = cipher.update(input, 0, len); > + cout.write(output, 0, output.length); > + } > + > + len = cipher.getOutputSize(0); > + > + byte[] out = new byte[len]; > + len = cipher.doFinal(out, 0); > + cout.write(out, 0, len); > + } > *+ * > *+ try (FileInputStream fin = new FileInputStream(cfile); * > *+ BufferedInputStream cin = new BufferedInputStream(fin); * > *+ FileOutputStream fout = new FileOutputStream(poutfile); * > *+ BufferedOutputStream pout = new BufferedOutputStream(fout)) { * > + cipher.init(Cipher.DECRYPT_MODE, cipherKey, params); > + > + byte[] output = null; > + while ((len = cin.read(input, 0, bufferLen)) > 0) { > + output = cipher.update(input, 0, len); > + pout.write(output, 0, output.length); > + } > + > + len = cipher.getOutputSize(0); > + byte[] out = new byte[len]; > + len = cipher.doFinal(out, 0); > + pout.write(out, 0, len); > + } > + > + diff(pinfile, poutfile); > *+ } catch (IllegalBlockSizeException ex) { * > *+ if ((totalInputLen % 8 != 0) && (padding.equals("NoPadding"))) { * > **return; > - else { > > *I think that this needs a more specific approach to handling > exceptions. What if a file is not found? general exception handling is > ok but not a standard way of doing that. > > May i suggest:- > 1) if you are using a try-catch, please put specific error handlers in > place. I am sure that you aware of that.. > > > also, is this code commented. i do not know the meaning of each color in > the code. My apologies for the ignorance as am new to this group and > still getting started... > > Nice work.... > * > > Please let me know if you need anything else from my side. > > Thanks & Regards, > Jitesh Dundas > > http://openwetware.org/wiki/Jitesh_Dundas_Lab > > Phone:- +91-9004618282 > > > > > On Fri, Jul 22, 2011 at 7:55 AM, > wrote: > > Changeset: c8dbb9e19355 > Author: weijun > Date: 2011-07-22 10:25 +0800 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8dbb9e19355 > > 6330275: Rework the PaddingTest regression test. > Reviewed-by: wetmore, smarks > > ! test/ProblemList.txt > ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java > > From jbdundas at gmail.com Thu Jul 21 21:42:23 2011 From: jbdundas at gmail.com (jitesh dundas) Date: Fri, 22 Jul 2011 10:12:23 +0530 Subject: hg: jdk8/tl/jdk: 6330275: Rework the PaddingTest regression test. In-Reply-To: <20110722022608.0BF564762F@hg.openjdk.java.net> References: <20110722022608.0BF564762F@hg.openjdk.java.net> Message-ID: Dear Sir. Thank you for your reply. * I was going through the code of your below patch and I thought of maybe pointing you to this direction:- * catch (IllegalBlockSizeException ex) { - if ((totalInputLen % 8 != 0) && (padding.equals("NoPadding"))) + try (FileInputStream fin = new FileInputStream(pinfile); + BufferedInputStream pin = new BufferedInputStream(fin); + FileOutputStream fout = new FileOutputStream(cfile); + BufferedOutputStream cout = new BufferedOutputStream(fout)) { + cipher.init(Cipher.ENCRYPT_MODE, cipherKey, params); + + while ((len = pin.read(input, 0, bufferLen)) > 0) { + totalInputLen += len; + byte[] output = cipher.update(input, 0, len); + cout.write(output, 0, output.length); + } + + len = cipher.getOutputSize(0); + + byte[] out = new byte[len]; + len = cipher.doFinal(out, 0); + cout.write(out, 0, len); + } *+ * *+ try (FileInputStream fin = new FileInputStream(cfile); * *+ BufferedInputStream cin = new BufferedInputStream(fin); * *+ FileOutputStream fout = new FileOutputStream(poutfile); * *+ BufferedOutputStream pout = new BufferedOutputStream(fout)) { * + cipher.init(Cipher.DECRYPT_MODE, cipherKey, params); + + byte[] output = null; + while ((len = cin.read(input, 0, bufferLen)) > 0) { + output = cipher.update(input, 0, len); + pout.write(output, 0, output.length); + } + + len = cipher.getOutputSize(0); + byte[] out = new byte[len]; + len = cipher.doFinal(out, 0); + pout.write(out, 0, len); + } + + diff(pinfile, poutfile); *+ } catch (IllegalBlockSizeException ex) { * *+ if ((totalInputLen % 8 != 0) && (padding.equals("NoPadding"))) { * * *return; - else { *I think that this needs a more specific approach to handling exceptions. What if a file is not found? general exception handling is ok but not a standard way of doing that. May i suggest:- 1) if you are using a try-catch, please put specific error handlers in place. I am sure that you aware of that.. also, is this code commented. i do not know the meaning of each color in the code. My apologies for the ignorance as am new to this group and still getting started... Nice work.... * Please let me know if you need anything else from my side. Thanks & Regards, Jitesh Dundas http://openwetware.org/wiki/Jitesh_Dundas_Lab Phone:- +91-9004618282 On Fri, Jul 22, 2011 at 7:55 AM, wrote: > Changeset: c8dbb9e19355 > Author: weijun > Date: 2011-07-22 10:25 +0800 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8dbb9e19355 > > 6330275: Rework the PaddingTest regression test. > Reviewed-by: wetmore, smarks > > ! test/ProblemList.txt > ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20110722/3983e5eb/attachment.html From jbdundas at gmail.com Fri Jul 22 13:32:41 2011 From: jbdundas at gmail.com (jitesh dundas) Date: Sat, 23 Jul 2011 02:02:41 +0530 Subject: hg: jdk8/tl/jdk: 6330275: Rework the PaddingTest regression test. In-Reply-To: <4E2902E4.6090905@oracle.com> References: <20110722022608.0BF564762F@hg.openjdk.java.net> <4E2902E4.6090905@oracle.com> Message-ID: Dear Sir. Thank you for your reply. My apologies for the delay in reply as I get a chance to work on this in after office hours. I will study this and give you further findings on the same. Please let me know if you need anything else from my side. Thanks & Regards, Jitesh Dundas http://openwetware.org/wiki/Jitesh_Dundas_Lab Phone:- +91-9004618282 On Fri, Jul 22, 2011 at 10:26 AM, Weijun Wang wrote: > [ Removed several CC ] > > Thanks for watching the code changes of JDK 8. > > In this test, if the file does not exist, it's certainly a failure. Either > the test itself is not complete (if pinfile not found), or the first part of > the test has some error (if cfile not found). In either case, a > FileNotFoundException will be thrown. The exception is unhandled and the > test will report a failure. By looking at the stack trace for the exception, > we will have a basic understanding of where the problem is. > > Isn't that what a regression test is for? > > There are altogether 3 try keywords here. The first is a normal try-catch, > and you can see only IllegalBlockSizeException is caught. The other 2 ones > are of the new try-with-resources JDK 7 feature. See > > > http://download.oracle.com/**javase/tutorial/essential/** > exceptions/tryResourceClose.**html > > The color describes the code changes, red means removed, and green newly > added. You can always click the "file" link to view the final version. > > Thanks > Max > > > On 07/22/2011 12:42 PM, jitesh dundas wrote: > >> >> Dear Sir. >> >> Thank you for your reply. >> >> * I was going through the code of your below patch and I thought of >> maybe pointing you to this direction:- >> >> * >> catch (IllegalBlockSizeException ex) { >> - if ((totalInputLen % 8 != 0) && (padding.equals("NoPadding"))) >> + try (FileInputStream fin = new FileInputStream(pinfile); >> + BufferedInputStream pin = new BufferedInputStream(fin); >> + FileOutputStream fout = new FileOutputStream(cfile); >> + BufferedOutputStream cout = new BufferedOutputStream(fout)) { >> + cipher.init(Cipher.ENCRYPT_**MODE, cipherKey, params); >> + >> + while ((len = pin.read(input, 0, bufferLen)) > 0) { >> + totalInputLen += len; >> + byte[] output = cipher.update(input, 0, len); >> + cout.write(output, 0, output.length); >> + } >> + >> + len = cipher.getOutputSize(0); >> + >> + byte[] out = new byte[len]; >> + len = cipher.doFinal(out, 0); >> + cout.write(out, 0, len); >> + } >> *+ * >> *+ try (FileInputStream fin = new FileInputStream(cfile); * >> *+ BufferedInputStream cin = new BufferedInputStream(fin); * >> *+ FileOutputStream fout = new FileOutputStream(poutfile); * >> *+ BufferedOutputStream pout = new BufferedOutputStream(fout)) { * >> + cipher.init(Cipher.DECRYPT_**MODE, cipherKey, params); >> + >> + byte[] output = null; >> + while ((len = cin.read(input, 0, bufferLen)) > 0) { >> + output = cipher.update(input, 0, len); >> + pout.write(output, 0, output.length); >> + } >> + >> + len = cipher.getOutputSize(0); >> + byte[] out = new byte[len]; >> + len = cipher.doFinal(out, 0); >> + pout.write(out, 0, len); >> + } >> + >> + diff(pinfile, poutfile); >> *+ } catch (IllegalBlockSizeException ex) { * >> *+ if ((totalInputLen % 8 != 0) && (padding.equals("NoPadding"))) { * >> **return; >> - else { >> >> *I think that this needs a more specific approach to handling >> exceptions. What if a file is not found? general exception handling is >> ok but not a standard way of doing that. >> >> May i suggest:- >> 1) if you are using a try-catch, please put specific error handlers in >> place. I am sure that you aware of that.. >> >> >> also, is this code commented. i do not know the meaning of each color in >> the code. My apologies for the ignorance as am new to this group and >> still getting started... >> >> Nice work.... >> * >> >> Please let me know if you need anything else from my side. >> >> Thanks & Regards, >> Jitesh Dundas >> >> http://openwetware.org/wiki/**Jitesh_Dundas_Lab >> >> Phone:- +91-9004618282 >> >> >> >> >> On Fri, Jul 22, 2011 at 7:55 AM, > > wrote: >> >> Changeset: c8dbb9e19355 >> Author: weijun >> Date: 2011-07-22 10:25 +0800 >> URL: http://hg.openjdk.java.net/**jdk8/tl/jdk/rev/c8dbb9e19355 >> >> 6330275: Rework the PaddingTest regression test. >> Reviewed-by: wetmore, smarks >> >> ! test/ProblemList.txt >> ! test/com/sun/crypto/provider/**Cipher/DES/PaddingTest.java >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20110723/3cfe4916/attachment.html From kelly.ohair at oracle.com Fri Jul 22 21:32:59 2011 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Sat, 23 Jul 2011 04:32:59 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20110723043259.6B87D4767C@hg.openjdk.java.net> Changeset: fd8615098a54 Author: ohair Date: 2011-07-22 17:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fd8615098a54 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties Changeset: f42e3d9394b4 Author: ohair Date: 2011-07-22 21:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f42e3d9394b4 Merge From kelly.ohair at oracle.com Fri Jul 22 21:33:07 2011 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Sat, 23 Jul 2011 04:33:07 +0000 Subject: hg: jdk8/tl/corba: 7069993: Adjust make/jprt.properties file for jdk8 Message-ID: <20110723043309.49DC54767D@hg.openjdk.java.net> Changeset: 949fb60ca830 Author: ohair Date: 2011-07-22 17:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/949fb60ca830 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties From kelly.ohair at oracle.com Fri Jul 22 21:33:23 2011 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Sat, 23 Jul 2011 04:33:23 +0000 Subject: hg: jdk8/tl/jaxp: 7069993: Adjust make/jprt.properties file for jdk8 Message-ID: <20110723043323.AB5DA4767E@hg.openjdk.java.net> Changeset: 4f0fcb812767 Author: ohair Date: 2011-07-22 17:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4f0fcb812767 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties From kelly.ohair at oracle.com Fri Jul 22 21:33:31 2011 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Sat, 23 Jul 2011 04:33:31 +0000 Subject: hg: jdk8/tl/jaxws: 7069993: Adjust make/jprt.properties file for jdk8 Message-ID: <20110723043331.8B8964767F@hg.openjdk.java.net> Changeset: 64df57a1edec Author: ohair Date: 2011-07-22 17:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/64df57a1edec 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties From kelly.ohair at oracle.com Fri Jul 22 21:33:49 2011 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Sat, 23 Jul 2011 04:33:49 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110723043432.711CA47680@hg.openjdk.java.net> Changeset: 0ec4b6498a69 Author: ohair Date: 2011-07-22 17:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ec4b6498a69 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties Changeset: a499fdfbe723 Author: ohair Date: 2011-07-22 21:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a499fdfbe723 Merge From kelly.ohair at oracle.com Fri Jul 22 21:34:43 2011 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Sat, 23 Jul 2011 04:34:43 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20110723043450.24B1347681@hg.openjdk.java.net> Changeset: 2d3096441387 Author: ohair Date: 2011-07-22 17:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d3096441387 7069993: Adjust make/jprt.properties file for jdk8 Reviewed-by: katleman ! make/jprt.properties Changeset: 36f31b87b0ab Author: ohair Date: 2011-07-22 21:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/36f31b87b0ab Merge From xuelei.fan at oracle.com Sun Jul 24 17:39:23 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 25 Jul 2011 08:39:23 +0800 Subject: Code review request: 7059542 JNDI name operations should be locale independent In-Reply-To: <4E27D4C1.1030608@oracle.com> References: <4E27D4C1.1030608@oracle.com> Message-ID: <4E2CBB3B.8070405@oracle.com> 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 chris.hegarty at oracle.com Mon Jul 25 14:42:14 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 25 Jul 2011 21:42:14 +0000 Subject: hg: jdk8/tl/jdk: 7035556: DatagramSocket.java:183: warning: unreachable catch clause Message-ID: <20110725214247.121EF47709@hg.openjdk.java.net> Changeset: 07a12583d4ea Author: chegar Date: 2011-07-25 14:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07a12583d4ea 7035556: DatagramSocket.java:183: warning: unreachable catch clause Summary: Remove redundant catches in bind Reviewed-by: alanb, michaelm, wetmore, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/DatagramSocket.java From alexandre.boulgakov at oracle.com Tue Jul 26 10:31:49 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Tue, 26 Jul 2011 10:31:49 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror In-Reply-To: <3F614290-E355-4207-90F1-9AB01378FBF6@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> Message-ID: <4E2EFA05.60806@oracle.com> 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 jonathan.gibbons at oracle.com Tue Jul 26 16:39:22 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 26 Jul 2011 23:39:22 +0000 Subject: hg: jdk8/tl/jdk: 7069870: Parts of the JDK erroneously rely on generic array initializers with diamond Message-ID: <20110726233937.3F37147743@hg.openjdk.java.net> Changeset: c563e8060adf Author: jjg Date: 2011-07-25 16:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c563e8060adf 7069870: Parts of the JDK erroneously rely on generic array initializers with diamond Reviewed-by: ksrini, mcimadamore Contributed-by: alexandre.boulgakov at oracle.com ! make/tools/src/build/tools/jarsplit/JarSplit.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java From chris.hegarty at oracle.com Wed Jul 27 10:11:10 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 27 Jul 2011 17:11:10 +0000 Subject: hg: jdk8/tl/jdk: 6670868: StackOverFlow with bad authenticated Proxy tunnels Message-ID: <20110727171130.50DDF47774@hg.openjdk.java.net> Changeset: a80562f7ea50 Author: chegar Date: 2011-07-27 18:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a80562f7ea50 6670868: StackOverFlow with bad authenticated Proxy tunnels Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java From maurizio.cimadamore at oracle.com Wed Jul 27 11:05:32 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 27 Jul 2011 18:05:32 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20110727180538.6884A47776@hg.openjdk.java.net> Changeset: 0b5beb9562c6 Author: mcimadamore Date: 2011-07-27 19:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0b5beb9562c6 7062745: Regression: difference in overload resolution when two methods are maximally specific Summary: Fix most specific when two methods are maximally specific and only one has non-raw return type Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java + test/tools/javac/generics/rawOverride/7062745/T7062745neg.java + test/tools/javac/generics/rawOverride/7062745/T7062745neg.out + test/tools/javac/generics/rawOverride/7062745/T7062745pos.java Changeset: d5f33267a06d Author: mcimadamore Date: 2011-07-27 19:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d5f33267a06d 7046778: Project Coin: problem with diamond and member inner classes Summary: Diamond inference generates spurious error messages when target type is a member inner class Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/diamond/neg/Neg09.out Changeset: e427c42e1a7e Author: mcimadamore Date: 2011-07-27 19:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e427c42e1a7e 7057297: Project Coin: diamond erroneously accepts in array initializer expressions Summary: Diamond in array initializer expressions should be rejected Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CannotCreateArrayWithDiamond.java + test/tools/javac/generics/diamond/7057297/T7057297.java + test/tools/javac/generics/diamond/7057297/T7057297.out From alexandre.boulgakov at oracle.com Wed Jul 27 11:22:02 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Wed, 27 Jul 2011 11:22:02 -0700 Subject: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror In-Reply-To: <4E2EFA05.60806@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> Message-ID: <4E30574A.8020907@oracle.com> 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 kumar.x.srinivasan at oracle.com Wed Jul 27 13:39:55 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 27 Jul 2011 20:39:55 +0000 Subject: hg: jdk8/tl/langtools: 7068902: (javac) allow enabling or disabling of String folding Message-ID: <20110727203957.5D3FA47781@hg.openjdk.java.net> Changeset: 0d6d41563040 Author: ksrini Date: 2011-07-27 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d6d41563040 7068902: (javac) allow enabling or disabling of String folding Summary: Contributed by netbeans team, modified to suit by the langtools team. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/parser/StringFoldingTest.java From jonathan.gibbons at oracle.com Thu Jul 28 14:44:16 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 28 Jul 2011 21:44:16 +0000 Subject: hg: jdk8/tl/jdk: 7068616: NIO libraries do not build with javac -Xlint:all, -deprecation -Werror Message-ID: <20110728214426.116BF477BD@hg.openjdk.java.net> Changeset: 7525866a4046 Author: jjg Date: 2011-07-28 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7525866a4046 7068616: NIO libraries do not build with javac -Xlint:all,-deprecation -Werror Reviewed-by: alanb, chegar Contributed-by: alexandre.boulgakov at oracle.com ! make/com/sun/nio/Makefile ! make/com/sun/nio/sctp/Makefile ! make/java/nio/Makefile ! make/java/sun_nio/Makefile ! make/sun/nio/Makefile ! make/sun/nio/cs/Makefile ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/Reflect.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/cs/FastCharsetProvider.java ! src/share/classes/sun/nio/cs/StreamDecoder.java ! src/share/classes/sun/nio/cs/ThreadLocalCoders.java ! src/share/classes/sun/nio/fs/Util.java ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpNet.java ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/ch/PendingIoCache.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java From xuelei.fan at oracle.com Fri Jul 29 02:53:13 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 29 Jul 2011 09:53:13 +0000 Subject: hg: jdk8/tl/jdk: 7068662: Reserve and restore the default locale Message-ID: <20110729095335.A6C9A477DD@hg.openjdk.java.net> Changeset: cea7c749f805 Author: xuelei Date: 2011-07-29 02:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cea7c749f805 7068662: Reserve and restore the default locale Reviewed-by: alanb, weijun ! test/com/sun/org/apache/xml/internal/security/exceptions/LocaleTest.java ! test/java/beans/XMLDecoder/Test6341798.java ! test/java/io/pathNames/win32/bug6344646.java ! test/java/net/CookieHandler/B6791927.java ! test/java/net/URLConnection/SetIfModifiedSince.java ! test/java/util/Locale/LocaleCategory.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/ResourceBundle/Bug6190861.java ! test/java/util/ResourceBundle/Control/Bug6530694.java ! test/java/util/ResourceBundle/Control/StressTest.java ! test/java/util/ResourceBundle/Test4314141.java ! test/java/util/ResourceBundle/Test4318520.java ! test/java/util/jar/JarFile/TurkCert.java ! test/javax/crypto/Cipher/Turkish.java ! test/javax/swing/JColorChooser/Test6524757.java ! test/sun/security/tools/keytool/KeyToolTest.java ! test/sun/text/resources/Collator/Bug4248694.java ! test/sun/text/resources/Collator/Bug4804273.java ! test/sun/text/resources/Collator/Bug4848897.java ! test/sun/text/resources/Format/Bug4651568.java ! test/sun/util/resources/Locale/Bug4965260.java ! test/sun/util/resources/TimeZone/Bug4640234.java From jonathan.gibbons at oracle.com Fri Jul 29 17:08:15 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 30 Jul 2011 00:08:15 +0000 Subject: hg: jdk8/tl/jdk: 7072523: java.math should be built with javac -Xlint:all -Werror Message-ID: <20110730000824.9407647800@hg.openjdk.java.net> Changeset: 4030297803eb Author: jjg Date: 2011-07-29 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4030297803eb 7072523: java.math should be built with javac -Xlint:all -Werror Reviewed-by: darcy Contributed-by: alexandre.boulgakov at oracle.com ! make/java/math/Makefile From xuelei.fan at oracle.com Sat Jul 30 06:52:38 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 30 Jul 2011 21:52:38 +0800 Subject: Code review request: 7059542 JNDI name operations should be locale independent In-Reply-To: <4E2CBB3B.8070405@oracle.com> References: <4E27D4C1.1030608@oracle.com> <4E2CBB3B.8070405@oracle.com> Message-ID: <4E340CA6.4060405@oracle.com> 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 xuelei.fan at oracle.com Sun Jul 31 18:48:06 2011 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 01 Aug 2011 09:48:06 +0800 Subject: Code review request: 7059542 JNDI name operations should be locale independent In-Reply-To: <4E340CA6.4060405@oracle.com> References: <4E27D4C1.1030608@oracle.com> <4E2CBB3B.8070405@oracle.com> <4E340CA6.4060405@oracle.com> Message-ID: <4E3605D6.5020305@oracle.com> 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 >> >