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 littlee at linux.vnet.ibm.com Tue Jul 5 02:10:53 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Tue, 05 Jul 2011 17:10:53 +0800 Subject: SocketPermission's implies() interesting behavior In-Reply-To: <4D9ECB98.9030705@oracle.com> References: <4D5CE83C.7050009@linux.vnet.ibm.com> <4D5E9C3E.3090200@oracle.com> <4D61CF99.9030806@linux.vnet.ibm.com> <4D626F67.9030101@oracle.com> <4D6326D5.4070208@linux.vnet.ibm.com> <4D63854C.8030001@oracle.com> <4D6B4399.7050500@linux.vnet.ibm.com> <4D6BEC23.6080002@oracle.com> <4D6C5347.8070107@linux.vnet.ibm.com> <4D6CB9E9.1020408@oracle.com> <4D7842ED.1080702@linux.vnet.ibm.com> <4D7A342C.8060203@oracle.com> <1302191588.5350.22.camel@chalkhill> <4D9ECB98.9030705@oracle.com> Message-ID: <4E12D51D.5040805@linux.vnet.ibm.com> On 04/08/2011 04:47 PM, Chris Hegarty wrote: > On 04/ 7/11 04:53 PM, Neil Richards wrote: >> On Wed, 2011-03-16 at 10:43 +0000, Neil Richards wrote: >>> On 11 March 2011 14:39, Chris Hegarty wrote: >>>> As Michael (cc'ed) mentioned in an earlier mail, he is going to be >>>> making >>>> some significant changes in this area in the next week or two. He will >>>> include this change with the other one, so their impact can be >>>> considered >>>> together, if that is ok? >>> >>> That's fine by me, so long as the changeset that addresses this >>> problem is linked back to this conversation (so that one can track the >>> progress of the fix for this problem into the component, then master >>> repository). >> >> Can you tell me if the changes headlined above have yet been made to the >> code (and point me to the URL of the change) ? > > These changes have not yet been integrated. I believe Michael will be > pushing them soon. > > -Chris. > >> >> Thanks, >> Neil >> Hi Chris, I have tested this issue with latest openjdk7 build (b147). The "blabla"[1] test case still fails. Is it ok if I am going to give a patch according the openjdk 8 code base? [1] http://bugs.sun.com/view_bug.do?bug_id=7021280 -- Yours Charles 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 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 lvjing at linux.vnet.ibm.com Wed Jul 6 02:05:28 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Wed, 06 Jul 2011 17:05:28 +0800 Subject: Socket InputStream.available may return a positive value after shutdown In-Reply-To: <4DB7F17F.1090402@oracle.com> References: <4D3EED20.6090802@linux.vnet.ibm.com> <4D401452.6030403@oracle.com> <4D5CD7BA.2000904@linux.vnet.ibm.com> <4D5CEAB5.8070408@oracle.com> <4D63812B.9080900@linux.vnet.ibm.com> <4D638420.5010801@oracle.com> <4DB7EC67.9010607@linux.vnet.ibm.com> <4DB7F17F.1090402@oracle.com> Message-ID: <4E142558.3050808@linux.vnet.ibm.com> Hello, Alan (or anyone else), do we have time to discuss these postponed defects? Or do you have a outlook for this? Thank you. ? 2011-4-27 18:35, Alan Bateman ??: > Jing LV wrote: >> Hello, >> >> Currently I don't see any patch available so I am trying to >> create one by myself. I see the problem occurs in >> AbstractPlainSocketImpl.available() and it seems it is design to >> return 0 when meed a closed socket - this may not be correct >> according to the spec, thus change it like this. Would someone review >> please? > I don't think I understand your proposed change as the connection > isn't reset in this case. Maybe you meant to change available to check > shut_rd? In any case, I think we need to be cautious as it would > change the behavior for the EOF case and so could cause problems for > existing applications. There is also a concern for custom SocketImpl > implementations that I mentioned previously. I think that whatever > approach is decided on will also require adding clarification to the > javadoc. So if it's okay with you, I think we should postpone this to 8. > > -Alan -- Best Regards, Jimmy, Jing LV 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 zhouyx at linux.vnet.ibm.com Wed Jul 6 22:16:27 2011 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Thu, 7 Jul 2011 13:16:27 +0800 Subject: HttpCookie.domainMatches("hostname.local", "hostname") return false In-Reply-To: <4D80F94F.1090309@oracle.com> References: <4D6E0BA1.3010907@oracle.com> <4D80F94F.1090309@oracle.com> Message-ID: Hi guys, Is there any update to this bug? or is it targeted to java8? 2011/3/17 Chris Hegarty > Hi Sean, > > I applied your patch to my local repo and it doesn't compile, startWith -> > startsWith ;-) > > More critically it doesn't resolve the problem, isLocalDomain will be false > for 'hostname.local'. > > I am working on an alternative fix ( please feel free to work on an > alternative fix also). Additional, we should update > test/java/net/CookieHandler/**TestHttpCookie.java ( under "Test > domainMatches" ). > > -Chris. > > > On 03/14/11 08:03 AM, Sean Chou wrote: > >> Hi, >> >> Is there any update to this issue? If not, I have a simple patch as >> follows: >> >> >> diff -r e947a98ea3c1 src/share/classes/java/net/**HttpCookie.java >> --- a/src/share/classes/java/net/**HttpCookie.java Thu Mar 10 17:11:08 >> 2011 -0800 >> +++ b/src/share/classes/java/net/**HttpCookie.java Mon Mar 14 16:02:14 >> 2011 +0800 >> @@ -771,6 +771,10 @@ >> host.equalsIgnoreCase(domain.**substring(1))); >> } >> >> + if (isLocalDomain && domain.startWith(host)){ >> + return true; >> + } >> + >> return false; >> } >> >> >> 2011/3/2 Chris Hegarty > >> >> >> >> On 03/ 2/11 01:50 AM, Sean Chou wrote: >> >> Hi, >> If there's no different opinions or objection, can someone >> raise a >> bug on the Oracle bug system for me please? >> >> >> Sorry, I though I replied to this. >> >> It would appear to be a bug. I filed CR 7023713, >> "HttpCookie.domainMatches("**hostname.local", "hostname") should >> return true", for this issue. >> >> -Chris. >> >> Thanks. >> >> >> 2011/2/22 Sean Chou > > >> >> >>> >> >> Hi, >> I find that HttpCookie.domainMatches("**hostname.local", >> "hostname") returns false, which may be a bug. >> According to spec, the effective host name of "hostname" is >> "hostname.local", which is string >> exactly the same with the first parameter. Thus the method >> should >> return true for this invocation. >> >> I attached the simple testcase here: >> // Testcase >> import java.net.HttpCookie; >> >> public class DomainMatchTest{ >> >> public static void main(String args[]){ >> // "true" should be printed, but get "false". >> >> System.out.println(HttpCookie.**domainMatches("hostname.local"**, >> "hostname")); >> } >> >> } >> // End of testcase >> >> Any comments? >> >> -- >> Best Regards, >> Sean Chou >> >> >> >> >> -- >> Best Regards, >> Sean Chou >> >> >> >> >> -- >> Best Regards, >> Sean Chou >> >> -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20110707/13f58015/attachment.html From spoole at linux.vnet.ibm.com Thu Jul 7 06:09:17 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Thu, 07 Jul 2011 14:09:17 +0100 Subject: Socket InputStream.available may return a positive value after shutdown In-Reply-To: <4E142558.3050808@linux.vnet.ibm.com> References: <4D3EED20.6090802@linux.vnet.ibm.com> <4D401452.6030403@oracle.com> <4D5CD7BA.2000904@linux.vnet.ibm.com> <4D5CEAB5.8070408@oracle.com> <4D63812B.9080900@linux.vnet.ibm.com> <4D638420.5010801@oracle.com> <4DB7EC67.9010607@linux.vnet.ibm.com> <4DB7F17F.1090402@oracle.com> <4E142558.3050808@linux.vnet.ibm.com> Message-ID: <4E15AFFD.7070908@linux.vnet.ibm.com> On 06/07/11 10:05, Jing LV wrote: > Hello, > > Alan (or anyone else), do we have time to discuss these postponed > defects? Or do you have a outlook for this? > Thank you. Hi Jimmy - it may be that everyone is very busy with the Java 7 launch and, probably, collapsing in a heap after all their great work :-) Also it might be worth reposting a summary of the defects you want to discuss just to remind people. > > ? 2011-4-27 18:35, Alan Bateman ??: >> Jing LV wrote: >>> Hello, >>> >>> Currently I don't see any patch available so I am trying to >>> create one by myself. I see the problem occurs in >>> AbstractPlainSocketImpl.available() and it seems it is design to >>> return 0 when meed a closed socket - this may not be correct >>> according to the spec, thus change it like this. Would someone >>> review please? >> I don't think I understand your proposed change as the connection >> isn't reset in this case. Maybe you meant to change available to >> check shut_rd? In any case, I think we need to be cautious as it >> would change the behavior for the EOF case and so could cause >> problems for existing applications. There is also a concern for >> custom SocketImpl implementations that I mentioned previously. I >> think that whatever approach is decided on will also require adding >> clarification to the javadoc. So if it's okay with you, I think we >> should postpone this to 8. >> >> -Alan > > 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 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 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 chris.hegarty at oracle.com Tue Jul 12 04:03:01 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 12 Jul 2011 12:03:01 +0100 Subject: SocketPermission's implies() interesting behavior In-Reply-To: <4E12D51D.5040805@linux.vnet.ibm.com> References: <4D5CE83C.7050009@linux.vnet.ibm.com> <4D5E9C3E.3090200@oracle.com> <4D61CF99.9030806@linux.vnet.ibm.com> <4D626F67.9030101@oracle.com> <4D6326D5.4070208@linux.vnet.ibm.com> <4D63854C.8030001@oracle.com> <4D6B4399.7050500@linux.vnet.ibm.com> <4D6BEC23.6080002@oracle.com> <4D6C5347.8070107@linux.vnet.ibm.com> <4D6CB9E9.1020408@oracle.com> <4D7842ED.1080702@linux.vnet.ibm.com> <4D7A342C.8060203@oracle.com> <1302191588.5350.22.camel@chalkhill> <4D9ECB98.9030705@oracle.com> <4E12D51D.5040805@linux.vnet.ibm.com> Message-ID: <4E1C29E5.8080708@oracle.com> On 07/ 5/11 10:10 AM, Charles Lee wrote: > On 04/08/2011 04:47 PM, Chris Hegarty wrote: >> On 04/ 7/11 04:53 PM, Neil Richards wrote: >>> On Wed, 2011-03-16 at 10:43 +0000, Neil Richards wrote: >>>> On 11 March 2011 14:39, Chris Hegarty wrote: >>>>> As Michael (cc'ed) mentioned in an earlier mail, he is going to be >>>>> making >>>>> some significant changes in this area in the next week or two. He will >>>>> include this change with the other one, so their impact can be >>>>> considered >>>>> together, if that is ok? >>>> >>>> That's fine by me, so long as the changeset that addresses this >>>> problem is linked back to this conversation (so that one can track the >>>> progress of the fix for this problem into the component, then master >>>> repository). >>> >>> Can you tell me if the changes headlined above have yet been made to the >>> code (and point me to the URL of the change) ? >> >> These changes have not yet been integrated. I believe Michael will be >> pushing them soon. >> >> -Chris. >> >>> >>> Thanks, >>> Neil >>> > Hi Chris, > > I have tested this issue with latest openjdk7 build (b147). The > "blabla"[1] test case still fails. Is it ok if I am going to give a > patch according the openjdk 8 code base? I apologize for this. By the time the other changes were ready for SocketPermission we were past the lock down period for JDK7. I'll proceed with getting the changes we agreed upon [1] into JDK8. -Chris. [1] http://cr.openjdk.java.net/~chegar/7021280/webrev.01/webrev/ > > [1] http://bugs.sun.com/view_bug.do?bug_id=7021280 > 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 littlee at linux.vnet.ibm.com Tue Jul 12 20:07:51 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Wed, 13 Jul 2011 11:07:51 +0800 Subject: SocketPermission's implies() interesting behavior In-Reply-To: <4E1C29E5.8080708@oracle.com> References: <4D5CE83C.7050009@linux.vnet.ibm.com> <4D5E9C3E.3090200@oracle.com> <4D61CF99.9030806@linux.vnet.ibm.com> <4D626F67.9030101@oracle.com> <4D6326D5.4070208@linux.vnet.ibm.com> <4D63854C.8030001@oracle.com> <4D6B4399.7050500@linux.vnet.ibm.com> <4D6BEC23.6080002@oracle.com> <4D6C5347.8070107@linux.vnet.ibm.com> <4D6CB9E9.1020408@oracle.com> <4D7842ED.1080702@linux.vnet.ibm.com> <4D7A342C.8060203@oracle.com> <1302191588.5350.22.camel@chalkhill> <4D9ECB98.9030705@oracle.com> <4E12D51D.5040805@linux.vnet.ibm.com> <4E1C29E5.8080708@oracle.com> Message-ID: <4E1D0C07.7010205@linux.vnet.ibm.com> On 07/12/2011 07:03 PM, Chris Hegarty wrote: > > > On 07/ 5/11 10:10 AM, Charles Lee wrote: >> On 04/08/2011 04:47 PM, Chris Hegarty wrote: >>> On 04/ 7/11 04:53 PM, Neil Richards wrote: >>>> On Wed, 2011-03-16 at 10:43 +0000, Neil Richards wrote: >>>>> On 11 March 2011 14:39, Chris Hegarty >>>>> wrote: >>>>>> As Michael (cc'ed) mentioned in an earlier mail, he is going to be >>>>>> making >>>>>> some significant changes in this area in the next week or two. He >>>>>> will >>>>>> include this change with the other one, so their impact can be >>>>>> considered >>>>>> together, if that is ok? >>>>> >>>>> That's fine by me, so long as the changeset that addresses this >>>>> problem is linked back to this conversation (so that one can track >>>>> the >>>>> progress of the fix for this problem into the component, then master >>>>> repository). >>>> >>>> Can you tell me if the changes headlined above have yet been made >>>> to the >>>> code (and point me to the URL of the change) ? >>> >>> These changes have not yet been integrated. I believe Michael will be >>> pushing them soon. >>> >>> -Chris. >>> >>>> >>>> Thanks, >>>> Neil >>>> >> Hi Chris, >> >> I have tested this issue with latest openjdk7 build (b147). The >> "blabla"[1] test case still fails. Is it ok if I am going to give a >> patch according the openjdk 8 code base? > > I apologize for this. By the time the other changes were ready for > SocketPermission we were past the lock down period for JDK7. I'll > proceed with getting the changes we agreed upon [1] into JDK8. > > -Chris. > > [1] http://cr.openjdk.java.net/~chegar/7021280/webrev.01/webrev/ > >> >> [1] http://bugs.sun.com/view_bug.do?bug_id=7021280 >> No problem. Thank you very much, Chris. -- Yours Charles 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 Alan.Bateman at oracle.com Wed Jul 13 10:39:34 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Jul 2011 18:39:34 +0100 Subject: Socket InputStream.available may return a positive value after shutdown In-Reply-To: <4E142558.3050808@linux.vnet.ibm.com> References: <4D3EED20.6090802@linux.vnet.ibm.com> <4D401452.6030403@oracle.com> <4D5CD7BA.2000904@linux.vnet.ibm.com> <4D5CEAB5.8070408@oracle.com> <4D63812B.9080900@linux.vnet.ibm.com> <4D638420.5010801@oracle.com> <4DB7EC67.9010607@linux.vnet.ibm.com> <4DB7F17F.1090402@oracle.com> <4E142558.3050808@linux.vnet.ibm.com> Message-ID: <4E1DD856.3000500@oracle.com> Jing LV wrote: > Hello, > > Alan (or anyone else), do we have time to discuss these postponed > defects? Or do you have a outlook for this? > Thank you. Sorry for the late reply, I've been on vacation. I think now is a good time to discuss this one. As I mentioned in the initial discussion, the existing behavior is platform specific. Once shutdown for input, then the ioctl(FIONREAD) or equivalent will continue to return the number of bytes in the socket buffer, other platforms will return 0. Changing the implementation is trivial and the question is whether this is the right thing to do. We will also need to clarify the specification. Chris, Michael - do you have opinions on this one? -Alan. From chris.hegarty at oracle.com Wed Jul 13 14:13:28 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Jul 2011 22:13:28 +0100 Subject: Socket InputStream.available may return a positive value after shutdown In-Reply-To: <4E1DD856.3000500@oracle.com> References: <4D3EED20.6090802@linux.vnet.ibm.com> <4D401452.6030403@oracle.com> <4D5CD7BA.2000904@linux.vnet.ibm.com> <4D5CEAB5.8070408@oracle.com> <4D63812B.9080900@linux.vnet.ibm.com> <4D638420.5010801@oracle.com> <4DB7EC67.9010607@linux.vnet.ibm.com> <4DB7F17F.1090402@oracle.com> <4E142558.3050808@linux.vnet.ibm.com> <4E1DD856.3000500@oracle.com> Message-ID: <4E1E0A78.2060907@oracle.com> On 07/13/11 06:39 PM, Alan Bateman wrote: > Jing LV wrote: >> Hello, >> >> Alan (or anyone else), do we have time to discuss these postponed >> defects? Or do you have a outlook for this? >> Thank you. > Sorry for the late reply, I've been on vacation. Sorry, I also meant to respond. Just got lost in all the noise recently. > I think now is a good time to discuss this one. As I mentioned in the > initial discussion, the existing behavior is platform specific. Once > shutdown for input, then the ioctl(FIONREAD) or equivalent will continue > to return the number of bytes in the socket buffer, other platforms will > return 0. Changing the implementation is trivial and the question is > whether this is the right thing to do. We will also need to clarify the > specification. Chris, Michael - do you have opinions on this one? I can't see that anyone could be depending on the fact the available() would return > 0 after shutdownInput(), given that subsequent reads will always return -1. I just can't see why anyone would require this, but maybe I'm missing something. -Chris. > > -Alan. From Alan.Bateman at oracle.com Thu Jul 14 01:36:26 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Jul 2011 09:36:26 +0100 Subject: Socket InputStream.available may return a positive value after shutdown In-Reply-To: <4E1E0A78.2060907@oracle.com> References: <4D3EED20.6090802@linux.vnet.ibm.com> <4D401452.6030403@oracle.com> <4D5CD7BA.2000904@linux.vnet.ibm.com> <4D5CEAB5.8070408@oracle.com> <4D63812B.9080900@linux.vnet.ibm.com> <4D638420.5010801@oracle.com> <4DB7EC67.9010607@linux.vnet.ibm.com> <4DB7F17F.1090402@oracle.com> <4E142558.3050808@linux.vnet.ibm.com> <4E1DD856.3000500@oracle.com> <4E1E0A78.2060907@oracle.com> Message-ID: <4E1EAA8A.3050601@oracle.com> Chris Hegarty wrote: > : > > I can't see that anyone could be depending on the fact the available() > would return > 0 after shutdownInput(), given that subsequent reads > will always return -1. I just can't see why anyone would require this, > but maybe I'm missing something. You're probably right, and it's just the concern that there may be code that won't now read and see the end-of-stream. The other concern is that we don't know how custom SocketImpls might behave. Overall the risk does seem low. -Alan. From chris.hegarty at oracle.com Thu Jul 14 02:00:59 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Jul 2011 10:00:59 +0100 Subject: Socket InputStream.available may return a positive value after shutdown In-Reply-To: <4E1EAA8A.3050601@oracle.com> References: <4D3EED20.6090802@linux.vnet.ibm.com> <4D401452.6030403@oracle.com> <4D5CD7BA.2000904@linux.vnet.ibm.com> <4D5CEAB5.8070408@oracle.com> <4D63812B.9080900@linux.vnet.ibm.com> <4D638420.5010801@oracle.com> <4DB7EC67.9010607@linux.vnet.ibm.com> <4DB7F17F.1090402@oracle.com> <4E142558.3050808@linux.vnet.ibm.com> <4E1DD856.3000500@oracle.com> <4E1E0A78.2060907@oracle.com> <4E1EAA8A.3050601@oracle.com> Message-ID: <4E1EB04B.3050207@oracle.com> On 07/14/11 09:36 AM, Alan Bateman wrote: > Chris Hegarty wrote: >> : >> >> I can't see that anyone could be depending on the fact the available() >> would return > 0 after shutdownInput(), given that subsequent reads >> will always return -1. I just can't see why anyone would require this, >> but maybe I'm missing something. > You're probably right, and it's just the concern that there may be code > that won't now read and see the end-of-stream. The other concern is that Yes, interesting point. I think this may be less of a concern though. Can anyone even depend on this today, i.e. use available to determine when to read and expect to reach eof? I don't think so because they may just happen to read the exact amount of data being sent and available will always return 0. Also, it does seems unlikely that this change would surprise too may people, they are calling shutdownInput explicitly on the socket. Let me put together a webrev and see the extent of the changes. -Chris. > we don't know how custom SocketImpls might behave. Overall the risk does > seem low. > > -Alan. 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 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 lvjing at linux.vnet.ibm.com Mon Jul 18 01:09:20 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Mon, 18 Jul 2011 16:09:20 +0800 Subject: Socket InputStream.available may return a positive value after shutdown In-Reply-To: <4E1EB04B.3050207@oracle.com> References: <4D3EED20.6090802@linux.vnet.ibm.com> <4D401452.6030403@oracle.com> <4D5CD7BA.2000904@linux.vnet.ibm.com> <4D5CEAB5.8070408@oracle.com> <4D63812B.9080900@linux.vnet.ibm.com> <4D638420.5010801@oracle.com> <4DB7EC67.9010607@linux.vnet.ibm.com> <4DB7F17F.1090402@oracle.com> <4E142558.3050808@linux.vnet.ibm.com> <4E1DD856.3000500@oracle.com> <4E1E0A78.2060907@oracle.com> <4E1EAA8A.3050601@oracle.com> <4E1EB04B.3050207@oracle.com> Message-ID: <4E23EA30.7010800@linux.vnet.ibm.com> Hi Chris, Alan, Thanks for reply. I am looking for a conclusion and solution for this issue. If I understand correctly, it'd fix the spec rather than fix the code? ? 2011-7-14 17:00, Chris Hegarty ??: > On 07/14/11 09:36 AM, Alan Bateman wrote: >> Chris Hegarty wrote: >>> : >>> >>> I can't see that anyone could be depending on the fact the available() >>> would return > 0 after shutdownInput(), given that subsequent reads >>> will always return -1. I just can't see why anyone would require this, >>> but maybe I'm missing something. >> You're probably right, and it's just the concern that there may be code >> that won't now read and see the end-of-stream. The other concern is that > > Yes, interesting point. I think this may be less of a concern though. > Can anyone even depend on this today, i.e. use available to determine > when to read and expect to reach eof? I don't think so because they > may just happen to read the exact amount of data being sent and > available will always return 0. > > Also, it does seems unlikely that this change would surprise too may > people, they are calling shutdownInput explicitly on the socket. > > Let me put together a webrev and see the extent of the changes. > > -Chris. > >> we don't know how custom SocketImpls might behave. Overall the risk does >> seem low. >> >> -Alan. -- Best Regards, Jimmy, Jing LV From chris.hegarty at oracle.com Mon Jul 18 03:00:12 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 18 Jul 2011 11:00:12 +0100 Subject: Socket InputStream.available may return a positive value after shutdown In-Reply-To: <4E23EA30.7010800@linux.vnet.ibm.com> References: <4D3EED20.6090802@linux.vnet.ibm.com> <4D401452.6030403@oracle.com> <4D5CD7BA.2000904@linux.vnet.ibm.com> <4D5CEAB5.8070408@oracle.com> <4D63812B.9080900@linux.vnet.ibm.com> <4D638420.5010801@oracle.com> <4DB7EC67.9010607@linux.vnet.ibm.com> <4DB7F17F.1090402@oracle.com> <4E142558.3050808@linux.vnet.ibm.com> <4E1DD856.3000500@oracle.com> <4E1E0A78.2060907@oracle.com> <4E1EAA8A.3050601@oracle.com> <4E1EB04B.3050207@oracle.com> <4E23EA30.7010800@linux.vnet.ibm.com> Message-ID: <4E24042C.1090402@oracle.com> On 07/18/11 09:09 AM, Jing LV wrote: > Hi Chris, Alan, > > Thanks for reply. I am looking for a conclusion and solution for this > issue. If I understand correctly, it'd fix the spec rather than fix the > code? The current plan of record is to clarify the spec to indicate that available will return 0 after shutdownInput is invoked. Then change the implementation to do just this. I'll send out a webrev soon. -Chris. > > ? 2011-7-14 17:00, Chris Hegarty ??: >> On 07/14/11 09:36 AM, Alan Bateman wrote: >>> Chris Hegarty wrote: >>>> : >>>> >>>> I can't see that anyone could be depending on the fact the available() >>>> would return > 0 after shutdownInput(), given that subsequent reads >>>> will always return -1. I just can't see why anyone would require this, >>>> but maybe I'm missing something. >>> You're probably right, and it's just the concern that there may be code >>> that won't now read and see the end-of-stream. The other concern is that >> >> Yes, interesting point. I think this may be less of a concern though. >> Can anyone even depend on this today, i.e. use available to determine >> when to read and expect to reach eof? I don't think so because they >> may just happen to read the exact amount of data being sent and >> available will always return 0. >> >> Also, it does seems unlikely that this change would surprise too may >> people, they are calling shutdownInput explicitly on the socket. >> >> Let me put together a webrev and see the extent of the changes. >> >> -Chris. >> >>> we don't know how custom SocketImpls might behave. Overall the risk does >>> seem low. >>> >>> -Alan. > > 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 chris.hegarty at oracle.com Mon Jul 18 05:25:18 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 18 Jul 2011 13:25:18 +0100 Subject: SocketPermission's implies() interesting behavior In-Reply-To: <4E1D0C07.7010205@linux.vnet.ibm.com> References: <4D5CE83C.7050009@linux.vnet.ibm.com> <4D5E9C3E.3090200@oracle.com> <4D61CF99.9030806@linux.vnet.ibm.com> <4D626F67.9030101@oracle.com> <4D6326D5.4070208@linux.vnet.ibm.com> <4D63854C.8030001@oracle.com> <4D6B4399.7050500@linux.vnet.ibm.com> <4D6BEC23.6080002@oracle.com> <4D6C5347.8070107@linux.vnet.ibm.com> <4D6CB9E9.1020408@oracle.com> <4D7842ED.1080702@linux.vnet.ibm.com> <4D7A342C.8060203@oracle.com> <1302191588.5350.22.camel@chalkhill> <4D9ECB98.9030705@oracle.com> <4E12D51D.5040805@linux.vnet.ibm.com> <4E1C29E5.8080708@oracle.com> <4E1D0C07.7010205@linux.vnet.ibm.com> Message-ID: <4E24262E.9080007@oracle.com> Michael, Can you please review this change. It has already been discussed and agreed, I just rebased it against jdk8 and added a test. http://cr.openjdk.java.net/~chegar/7021280/webrev.02/webrev/ Thanks, -Chris. On 07/13/11 04:07 AM, Charles Lee wrote: > On 07/12/2011 07:03 PM, Chris Hegarty wrote: >> >> >> On 07/ 5/11 10:10 AM, Charles Lee wrote: >>> On 04/08/2011 04:47 PM, Chris Hegarty wrote: >>>> On 04/ 7/11 04:53 PM, Neil Richards wrote: >>>>> On Wed, 2011-03-16 at 10:43 +0000, Neil Richards wrote: >>>>>> On 11 March 2011 14:39, Chris Hegarty >>>>>> wrote: >>>>>>> As Michael (cc'ed) mentioned in an earlier mail, he is going to be >>>>>>> making >>>>>>> some significant changes in this area in the next week or two. He >>>>>>> will >>>>>>> include this change with the other one, so their impact can be >>>>>>> considered >>>>>>> together, if that is ok? >>>>>> >>>>>> That's fine by me, so long as the changeset that addresses this >>>>>> problem is linked back to this conversation (so that one can track >>>>>> the >>>>>> progress of the fix for this problem into the component, then master >>>>>> repository). >>>>> >>>>> Can you tell me if the changes headlined above have yet been made >>>>> to the >>>>> code (and point me to the URL of the change) ? >>>> >>>> These changes have not yet been integrated. I believe Michael will be >>>> pushing them soon. >>>> >>>> -Chris. >>>> >>>>> >>>>> Thanks, >>>>> Neil >>>>> >>> Hi Chris, >>> >>> I have tested this issue with latest openjdk7 build (b147). The >>> "blabla"[1] test case still fails. Is it ok if I am going to give a >>> patch according the openjdk 8 code base? >> >> I apologize for this. By the time the other changes were ready for >> SocketPermission we were past the lock down period for JDK7. I'll >> proceed with getting the changes we agreed upon [1] into JDK8. >> >> -Chris. >> >> [1] http://cr.openjdk.java.net/~chegar/7021280/webrev.01/webrev/ >> >>> >>> [1] http://bugs.sun.com/view_bug.do?bug_id=7021280 >>> > No problem. Thank you very much, Chris. > From michael.x.mcmahon at oracle.com Mon Jul 18 06:24:25 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 18 Jul 2011 14:24:25 +0100 Subject: SocketPermission's implies() interesting behavior In-Reply-To: <4E24262E.9080007@oracle.com> References: <4D5CE83C.7050009@linux.vnet.ibm.com> <4D5E9C3E.3090200@oracle.com> <4D61CF99.9030806@linux.vnet.ibm.com> <4D626F67.9030101@oracle.com> <4D6326D5.4070208@linux.vnet.ibm.com> <4D63854C.8030001@oracle.com> <4D6B4399.7050500@linux.vnet.ibm.com> <4D6BEC23.6080002@oracle.com> <4D6C5347.8070107@linux.vnet.ibm.com> <4D6CB9E9.1020408@oracle.com> <4D7842ED.1080702@linux.vnet.ibm.com> <4D7A342C.8060203@oracle.com> <1302191588.5350.22.camel@chalkhill> <4D9ECB98.9030705@oracle.com> <4E12D51D.5040805@linux.vnet.ibm.com> <4E1C29E5.8080708@oracle.com> <4E1D0C07.7010205@linux.vnet.ibm.com> <4E24262E.9080007@oracle.com> Message-ID: <4E243409.1080400@oracle.com> Looks fine, - Michael. On 18/07/11 13:25, Chris Hegarty wrote: > Michael, > > Can you please review this change. It has already been discussed and > agreed, I just rebased it against jdk8 and added a test. > > http://cr.openjdk.java.net/~chegar/7021280/webrev.02/webrev/ > > Thanks, > -Chris. > > On 07/13/11 04:07 AM, Charles Lee wrote: >> On 07/12/2011 07:03 PM, Chris Hegarty wrote: >>> >>> >>> On 07/ 5/11 10:10 AM, Charles Lee wrote: >>>> On 04/08/2011 04:47 PM, Chris Hegarty wrote: >>>>> On 04/ 7/11 04:53 PM, Neil Richards wrote: >>>>>> On Wed, 2011-03-16 at 10:43 +0000, Neil Richards wrote: >>>>>>> On 11 March 2011 14:39, Chris Hegarty >>>>>>> wrote: >>>>>>>> As Michael (cc'ed) mentioned in an earlier mail, he is going to be >>>>>>>> making >>>>>>>> some significant changes in this area in the next week or two. He >>>>>>>> will >>>>>>>> include this change with the other one, so their impact can be >>>>>>>> considered >>>>>>>> together, if that is ok? >>>>>>> >>>>>>> That's fine by me, so long as the changeset that addresses this >>>>>>> problem is linked back to this conversation (so that one can track >>>>>>> the >>>>>>> progress of the fix for this problem into the component, then >>>>>>> master >>>>>>> repository). >>>>>> >>>>>> Can you tell me if the changes headlined above have yet been made >>>>>> to the >>>>>> code (and point me to the URL of the change) ? >>>>> >>>>> These changes have not yet been integrated. I believe Michael will be >>>>> pushing them soon. >>>>> >>>>> -Chris. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Neil >>>>>> >>>> Hi Chris, >>>> >>>> I have tested this issue with latest openjdk7 build (b147). The >>>> "blabla"[1] test case still fails. Is it ok if I am going to give a >>>> patch according the openjdk 8 code base? >>> >>> I apologize for this. By the time the other changes were ready for >>> SocketPermission we were past the lock down period for JDK7. I'll >>> proceed with getting the changes we agreed upon [1] into JDK8. >>> >>> -Chris. >>> >>> [1] http://cr.openjdk.java.net/~chegar/7021280/webrev.01/webrev/ >>> >>>> >>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7021280 >>>> >> No problem. Thank you very much, Chris. >> 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 chris.hegarty at oracle.com Tue Jul 19 01:00:07 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Jul 2011 09:00:07 +0100 Subject: SocketPermission's implies() interesting behavior In-Reply-To: <4E1D0C07.7010205@linux.vnet.ibm.com> References: <4D5CE83C.7050009@linux.vnet.ibm.com> <4D5E9C3E.3090200@oracle.com> <4D61CF99.9030806@linux.vnet.ibm.com> <4D626F67.9030101@oracle.com> <4D6326D5.4070208@linux.vnet.ibm.com> <4D63854C.8030001@oracle.com> <4D6B4399.7050500@linux.vnet.ibm.com> <4D6BEC23.6080002@oracle.com> <4D6C5347.8070107@linux.vnet.ibm.com> <4D6CB9E9.1020408@oracle.com> <4D7842ED.1080702@linux.vnet.ibm.com> <4D7A342C.8060203@oracle.com> <1302191588.5350.22.camel@chalkhill> <4D9ECB98.9030705@oracle.com> <4E12D51D.5040805@linux.vnet.ibm.com> <4E1C29E5.8080708@oracle.com> <4E1D0C07.7010205@linux.vnet.ibm.com> Message-ID: <4E253987.8000707@oracle.com> On 07/13/11 04:07 AM, Charles Lee wrote: > On 07/12/2011 07:03 PM, Chris Hegarty wrote: >> >> >> On 07/ 5/11 10:10 AM, Charles Lee wrote: >>> On 04/08/2011 04:47 PM, Chris Hegarty wrote: >>>> On 04/ 7/11 04:53 PM, Neil Richards wrote: >>>>> On Wed, 2011-03-16 at 10:43 +0000, Neil Richards wrote: >>>>>> On 11 March 2011 14:39, Chris Hegarty >>>>>> wrote: >>>>>>> As Michael (cc'ed) mentioned in an earlier mail, he is going to be >>>>>>> making >>>>>>> some significant changes in this area in the next week or two. He >>>>>>> will >>>>>>> include this change with the other one, so their impact can be >>>>>>> considered >>>>>>> together, if that is ok? >>>>>> >>>>>> That's fine by me, so long as the changeset that addresses this >>>>>> problem is linked back to this conversation (so that one can track >>>>>> the >>>>>> progress of the fix for this problem into the component, then master >>>>>> repository). >>>>> >>>>> Can you tell me if the changes headlined above have yet been made >>>>> to the >>>>> code (and point me to the URL of the change) ? >>>> >>>> These changes have not yet been integrated. I believe Michael will be >>>> pushing them soon. >>>> >>>> -Chris. >>>> >>>>> >>>>> Thanks, >>>>> Neil >>>>> >>> Hi Chris, >>> >>> I have tested this issue with latest openjdk7 build (b147). The >>> "blabla"[1] test case still fails. Is it ok if I am going to give a >>> patch according the openjdk 8 code base? >> >> I apologize for this. By the time the other changes were ready for >> SocketPermission we were past the lock down period for JDK7. I'll >> proceed with getting the changes we agreed upon [1] into JDK8. I pushed a changeset for this last night. 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 -Chris. >> >> -Chris. >> >> [1] http://cr.openjdk.java.net/~chegar/7021280/webrev.01/webrev/ >> >>> >>> [1] http://bugs.sun.com/view_bug.do?bug_id=7021280 >>> > No problem. Thank you very much, Chris. > From littlee at linux.vnet.ibm.com Tue Jul 19 01:07:29 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Tue, 19 Jul 2011 16:07:29 +0800 Subject: SocketPermission's implies() interesting behavior In-Reply-To: <4E253987.8000707@oracle.com> References: <4D5CE83C.7050009@linux.vnet.ibm.com> <4D5E9C3E.3090200@oracle.com> <4D61CF99.9030806@linux.vnet.ibm.com> <4D626F67.9030101@oracle.com> <4D6326D5.4070208@linux.vnet.ibm.com> <4D63854C.8030001@oracle.com> <4D6B4399.7050500@linux.vnet.ibm.com> <4D6BEC23.6080002@oracle.com> <4D6C5347.8070107@linux.vnet.ibm.com> <4D6CB9E9.1020408@oracle.com> <4D7842ED.1080702@linux.vnet.ibm.com> <4D7A342C.8060203@oracle.com> <1302191588.5350.22.camel@chalkhill> <4D9ECB98.9030705@oracle.com> <4E12D51D.5040805@linux.vnet.ibm.com> <4E1C29E5.8080708@oracle.com> <4E1D0C07.7010205@linux.vnet.ibm.com> <4E253987.8000707@oracle.com> Message-ID: <4E253B41.90404@linux.vnet.ibm.com> On 07/19/2011 04:00 PM, Chris Hegarty wrote: > > > On 07/13/11 04:07 AM, Charles Lee wrote: >> On 07/12/2011 07:03 PM, Chris Hegarty wrote: >>> >>> >>> On 07/ 5/11 10:10 AM, Charles Lee wrote: >>>> On 04/08/2011 04:47 PM, Chris Hegarty wrote: >>>>> On 04/ 7/11 04:53 PM, Neil Richards wrote: >>>>>> On Wed, 2011-03-16 at 10:43 +0000, Neil Richards wrote: >>>>>>> On 11 March 2011 14:39, Chris Hegarty >>>>>>> wrote: >>>>>>>> As Michael (cc'ed) mentioned in an earlier mail, he is going to be >>>>>>>> making >>>>>>>> some significant changes in this area in the next week or two. He >>>>>>>> will >>>>>>>> include this change with the other one, so their impact can be >>>>>>>> considered >>>>>>>> together, if that is ok? >>>>>>> >>>>>>> That's fine by me, so long as the changeset that addresses this >>>>>>> problem is linked back to this conversation (so that one can track >>>>>>> the >>>>>>> progress of the fix for this problem into the component, then >>>>>>> master >>>>>>> repository). >>>>>> >>>>>> Can you tell me if the changes headlined above have yet been made >>>>>> to the >>>>>> code (and point me to the URL of the change) ? >>>>> >>>>> These changes have not yet been integrated. I believe Michael will be >>>>> pushing them soon. >>>>> >>>>> -Chris. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Neil >>>>>> >>>> Hi Chris, >>>> >>>> I have tested this issue with latest openjdk7 build (b147). The >>>> "blabla"[1] test case still fails. Is it ok if I am going to give a >>>> patch according the openjdk 8 code base? >>> >>> I apologize for this. By the time the other changes were ready for >>> SocketPermission we were past the lock down period for JDK7. I'll >>> proceed with getting the changes we agreed upon [1] into JDK8. > > I pushed a changeset for this last night. > > 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 > > > -Chris. > Yes. Chris. I saw this change on the jdk8 tools and language repos. It works. Thank you very much. >>> >>> -Chris. >>> >>> [1] http://cr.openjdk.java.net/~chegar/7021280/webrev.01/webrev/ >>> >>>> >>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7021280 >>>> >> No problem. Thank you very much, Chris. >> -- Yours Charles 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 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 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 chris.hegarty at oracle.com Wed Jul 20 03:10:04 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 20 Jul 2011 11:10:04 +0100 Subject: Code Review 7068416: Lightweight HTTP Server should support TCP_NODELAY Message-ID: <4E26A97C.1000505@oracle.com> Hi Michael, It has been noticed that there is a perceived delay in response from the Lightweight HTTP Server implementation that ships with the JDK, compared to other production HTTP Servers. The cause for this delay has been identified as the Nagle algorithm buffering the response data until there is sufficient data ( not always the case especially for headers ), or a timeout occurs that triggers the data to be sent. CR 7068416 is requesting that a property be provided to allow applications to effectively set the TCP_NODELAY socket option on sockets being used by the server, i.e. disable Nagle. This is similar to what other production HTTP servers provide. For example, see: http://download.oracle.com/docs/cd/E19798-01/821-1794/aeoko/index.html Webrev: http://cr.openjdk.java.net/~chegar/7068416/webrev.00/webrev/ Thanks, -Chris. From michael.x.mcmahon at oracle.com Wed Jul 20 08:51:39 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 20 Jul 2011 16:51:39 +0100 Subject: Code Review 7068416: Lightweight HTTP Server should support TCP_NODELAY In-Reply-To: <4E26A97C.1000505@oracle.com> References: <4E26A97C.1000505@oracle.com> Message-ID: <4E26F98B.5020900@oracle.com> Looks fine. Thanks, Michael. On 20/07/11 11:10, Chris Hegarty wrote: > Hi Michael, > > It has been noticed that there is a perceived delay in response from > the Lightweight HTTP Server implementation that ships with the JDK, > compared to other production HTTP Servers. The cause for this delay > has been identified as the Nagle algorithm buffering the response data > until there is sufficient data ( not always the case especially for > headers ), or a timeout occurs that triggers the data to be sent. > > CR 7068416 is requesting that a property be provided to allow > applications to effectively set the TCP_NODELAY socket option on > sockets being used by the server, i.e. disable Nagle. This is similar > to what other production HTTP servers provide. For example, see: > http://download.oracle.com/docs/cd/E19798-01/821-1794/aeoko/index.html > > Webrev: > http://cr.openjdk.java.net/~chegar/7068416/webrev.00/webrev/ > > Thanks, > -Chris. From Alan.Bateman at oracle.com Wed Jul 20 07:56:10 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Jul 2011 15:56:10 +0100 Subject: Code Review 7068416: Lightweight HTTP Server should support TCP_NODELAY In-Reply-To: <4E26A97C.1000505@oracle.com> References: <4E26A97C.1000505@oracle.com> Message-ID: <4E26EC8A.8070802@oracle.com> Chris Hegarty wrote: > Hi Michael, > > It has been noticed that there is a perceived delay in response from > the Lightweight HTTP Server implementation that ships with the JDK, > compared to other production HTTP Servers. The cause for this delay > has been identified as the Nagle algorithm buffering the response data > until there is sufficient data ( not always the case especially for > headers ), or a timeout occurs that triggers the data to be sent. > > CR 7068416 is requesting that a property be provided to allow > applications to effectively set the TCP_NODELAY socket option on > sockets being used by the server, i.e. disable Nagle. This is similar > to what other production HTTP servers provide. For example, see: > http://download.oracle.com/docs/cd/E19798-01/821-1794/aeoko/index.html > > Webrev: > http://cr.openjdk.java.net/~chegar/7068416/webrev.00/webrev/ > > Thanks, > -Chris. A side comment is that I see that the lookup of each property is its own privileged block. Would it be more efficient to have one to lookup all the properties? -Alan From chris.hegarty at oracle.com Wed Jul 20 08:55:33 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 20 Jul 2011 16:55:33 +0100 Subject: Code Review 7068416: Lightweight HTTP Server should support TCP_NODELAY In-Reply-To: <4E26EC8A.8070802@oracle.com> References: <4E26A97C.1000505@oracle.com> <4E26EC8A.8070802@oracle.com> Message-ID: <4E26FA75.6050702@oracle.com> On 07/20/11 03:56 PM, Alan Bateman wrote: > Chris Hegarty wrote: >> Hi Michael, >> >> It has been noticed that there is a perceived delay in response from >> the Lightweight HTTP Server implementation that ships with the JDK, >> compared to other production HTTP Servers. The cause for this delay >> has been identified as the Nagle algorithm buffering the response data >> until there is sufficient data ( not always the case especially for >> headers ), or a timeout occurs that triggers the data to be sent. >> >> CR 7068416 is requesting that a property be provided to allow >> applications to effectively set the TCP_NODELAY socket option on >> sockets being used by the server, i.e. disable Nagle. This is similar >> to what other production HTTP servers provide. For example, see: >> http://download.oracle.com/docs/cd/E19798-01/821-1794/aeoko/index.html >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/7068416/webrev.00/webrev/ >> >> Thanks, >> -Chris. > A side comment is that I see that the lookup of each property is its own > privileged block. Would it be more efficient to have one to lookup all > the properties? Yes, certainly make sense. Updated Webrev: http://cr.openjdk.java.net/~chegar/7068416/webrev.01/webrev/ -Chris. > > -Alan 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 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 lvjing at linux.vnet.ibm.com Thu Jul 21 01:42:37 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Thu, 21 Jul 2011 16:42:37 +0800 Subject: Socket InputStream.available may return a positive value after shutdown In-Reply-To: <4E24042C.1090402@oracle.com> References: <4D3EED20.6090802@linux.vnet.ibm.com> <4D401452.6030403@oracle.com> <4D5CD7BA.2000904@linux.vnet.ibm.com> <4D5CEAB5.8070408@oracle.com> <4D63812B.9080900@linux.vnet.ibm.com> <4D638420.5010801@oracle.com> <4DB7EC67.9010607@linux.vnet.ibm.com> <4DB7F17F.1090402@oracle.com> <4E142558.3050808@linux.vnet.ibm.com> <4E1DD856.3000500@oracle.com> <4E1E0A78.2060907@oracle.com> <4E1EAA8A.3050601@oracle.com> <4E1EB04B.3050207@oracle.com> <4E23EA30.7010800@linux.vnet.ibm.com> <4E24042C.1090402@oracle.com> Message-ID: <4E27E67D.2050004@linux.vnet.ibm.com> Hi, Thank you Chris! Would you please send the link when you have some progress? ? 2011-7-18 18:00, Chris Hegarty ??: > On 07/18/11 09:09 AM, Jing LV wrote: >> Hi Chris, Alan, >> >> Thanks for reply. I am looking for a conclusion and solution for this >> issue. If I understand correctly, it'd fix the spec rather than fix the >> code? > > The current plan of record is to clarify the spec to indicate that > available will return 0 after shutdownInput is invoked. Then change > the implementation to do just this. > > I'll send out a webrev soon. > > -Chris. > >> >> ? 2011-7-14 17:00, Chris Hegarty ??: >>> On 07/14/11 09:36 AM, Alan Bateman wrote: >>>> Chris Hegarty wrote: >>>>> : >>>>> >>>>> I can't see that anyone could be depending on the fact the >>>>> available() >>>>> would return > 0 after shutdownInput(), given that subsequent reads >>>>> will always return -1. I just can't see why anyone would require >>>>> this, >>>>> but maybe I'm missing something. >>>> You're probably right, and it's just the concern that there may be >>>> code >>>> that won't now read and see the end-of-stream. The other concern is >>>> that >>> >>> Yes, interesting point. I think this may be less of a concern though. >>> Can anyone even depend on this today, i.e. use available to determine >>> when to read and expect to reach eof? I don't think so because they >>> may just happen to read the exact amount of data being sent and >>> available will always return 0. >>> >>> Also, it does seems unlikely that this change would surprise too may >>> people, they are calling shutdownInput explicitly on the socket. >>> >>> Let me put together a webrev and see the extent of the changes. >>> >>> -Chris. >>> >>>> we don't know how custom SocketImpls might behave. Overall the risk >>>> does >>>> seem low. >>>> >>>> -Alan. >> >> -- Best Regards, Jimmy, Jing LV 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 kurchi.subhra.hazra at oracle.com Thu Jul 21 15:05:58 2011 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 21 Jul 2011 15:05:58 -0700 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause Message-ID: <4E28A2C6.9040609@oracle.com> Hi, Due to a recent update in javac to issue a warning on detecting unreachable code, the following warning started showing up in the jdk networking code: ../../../src/share/classes/java/net/DatagramSocket.java:183: warning: unreachable catch clause. This fix aims at removing this warning by removing the IOException. On inspection, it was found that currently, the native code does not throw any IOException. The fix involves updates in: jdk/src/share/classes/java/net/DatagramSocket.java Webrev: http://cr.openjdk.java.net/~chegar/7035556/webrev.00/ Thanks, -Kurchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20110721/605425db/attachment.html From bradford.wetmore at oracle.com Thu Jul 21 15:54:24 2011 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 21 Jul 2011 15:54:24 -0700 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E28A2C6.9040609@oracle.com> References: <4E28A2C6.9040609@oracle.com> Message-ID: <4E28AE20.8080007@oracle.com> Kurchi, Please have an additional reviewer for the networking portion of this, but in doing a quick look, I believe the point of the two catches is to make sure that any IOException that isn't already a SocketException (SocketException is a subclass of IOException) is rebranded to SocketException. If these internal methods are guaranteed to only throw SocketExeptions (and it looks like it), then you can simplify this code to: public DatagramSocket() throws SocketException { createImpl(); bind(new InetSocketAddress(0)); } bind throws SocketException, InetSocketAddress(int) only throws a IAE (a RuntimeException). Brad On 7/21/2011 3:05 PM, Kurchi Hazra wrote: > Hi, > > Due to a recent update in javac to issue a warning on detecting > unreachable code, the following warning started showing up in the jdk > networking code: > ../../../src/share/classes/java/net/DatagramSocket.java:183: warning: > unreachable catch clause. > > This fix aims at removing this warning by removing the IOException. On > inspection, it was found that currently, the native code does not throw > any IOException. > > The fix involves updates in: > jdk/src/share/classes/java/net/DatagramSocket.java > > > Webrev: http://cr.openjdk.java.net/~chegar/7035556/webrev.00/ > > Thanks, > -Kurchi 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 Alan.Bateman at oracle.com Thu Jul 21 19:45:35 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Jul 2011 03:45:35 +0100 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E28A2C6.9040609@oracle.com> References: <4E28A2C6.9040609@oracle.com> Message-ID: <4E28E44F.1040301@oracle.com> Kurchi Hazra wrote: > Hi, > > Due to a recent update in javac to issue a warning on detecting > unreachable code, the following warning started showing up in the jdk > networking code: > ../../../src/share/classes/java/net/DatagramSocket.java:183: warning: > unreachable catch clause. > > This fix aims at removing this warning by removing the IOException. On > inspection, it was found that currently, the native code does not > throw any IOException. > > The fix involves updates in: > jdk/src/share/classes/java/net/DatagramSocket.java > > > Webrev: http://cr.openjdk.java.net/~chegar/7035556/webrev.00/ > > Thanks, > -Kurchi Kurchi - one suggestion is to close the UDP socket in the event that the bind fails. That would be nicer than leaving it to the impl's finalizer. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20110722/cda9c7f0/attachment.html From michael.x.mcmahon at oracle.com Fri Jul 22 03:02:30 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 22 Jul 2011 11:02:30 +0100 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E28AE20.8080007@oracle.com> References: <4E28A2C6.9040609@oracle.com> <4E28AE20.8080007@oracle.com> Message-ID: <4E294AB6.9020006@oracle.com> There seems to be only a couple of places where IOException (specifically) is thrown in the networking code and it can't occur in this code path as far as I can see. Perhaps that wasn't always the case, which could explain why the unusual construction exists. So, the simplification suggested below seems reasonable. - Michael. On 21/07/11 23:54, Brad Wetmore wrote: > Kurchi, > > Please have an additional reviewer for the networking portion of this, > but in doing a quick look, I believe the point of the two catches is > to make sure that any IOException that isn't already a SocketException > (SocketException is a subclass of IOException) is rebranded to > SocketException. > > If these internal methods are guaranteed to only throw SocketExeptions > (and it looks like it), then you can simplify this code to: > > public DatagramSocket() throws SocketException { > createImpl(); > bind(new InetSocketAddress(0)); > } > > bind throws SocketException, InetSocketAddress(int) only throws a IAE > (a RuntimeException). > > Brad > > > > > On 7/21/2011 3:05 PM, Kurchi Hazra wrote: >> Hi, >> >> Due to a recent update in javac to issue a warning on detecting >> unreachable code, the following warning started showing up in the jdk >> networking code: >> ../../../src/share/classes/java/net/DatagramSocket.java:183: warning: >> unreachable catch clause. >> >> This fix aims at removing this warning by removing the IOException. On >> inspection, it was found that currently, the native code does not throw >> any IOException. >> >> The fix involves updates in: >> jdk/src/share/classes/java/net/DatagramSocket.java >> >> >> Webrev: http://cr.openjdk.java.net/~chegar/7035556/webrev.00/ >> >> Thanks, >> -Kurchi From chris.hegarty at oracle.com Fri Jul 22 05:51:34 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 Jul 2011 13:51:34 +0100 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E28E44F.1040301@oracle.com> References: <4E28A2C6.9040609@oracle.com> <4E28E44F.1040301@oracle.com> Message-ID: <4E297256.8060101@oracle.com> On 7/22/2011 3:45 AM, Alan Bateman wrote: > Kurchi Hazra wrote: >> Hi, >> >> Due to a recent update in javac to issue a warning on detecting >> unreachable code, the following warning started showing up in the jdk >> networking code: >> ../../../src/share/classes/java/net/DatagramSocket.java:183: warning: >> unreachable catch clause. >> >> This fix aims at removing this warning by removing the IOException. >> On inspection, it was found that currently, the native code does not >> throw any IOException. >> >> The fix involves updates in: >> jdk/src/share/classes/java/net/DatagramSocket.java >> >> >> Webrev: http://cr.openjdk.java.net/~chegar/7035556/webrev.00/ >> >> Thanks, >> -Kurchi > Kurchi - one suggestion is to close the UDP socket in the event that > the bind fails. That would be nicer than leaving it to the impl's > finalizer. Ah yes, makes sense. thanks for catching this Alan. -Chris. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20110722/83df3290/attachment.html From michael.x.mcmahon at oracle.com Fri Jul 22 06:41:48 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 22 Jul 2011 14:41:48 +0100 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E297256.8060101@oracle.com> References: <4E28A2C6.9040609@oracle.com> <4E28E44F.1040301@oracle.com> <4E297256.8060101@oracle.com> Message-ID: <4E297E1C.6000003@oracle.com> On 22/07/11 13:51, Chris Hegarty wrote: > On 7/22/2011 3:45 AM, Alan Bateman wrote: >> Kurchi Hazra wrote: >>> Hi, >>> >>> Due to a recent update in javac to issue a warning on detecting >>> unreachable code, the following warning started showing up in the >>> jdk networking code: >>> ../../../src/share/classes/java/net/DatagramSocket.java:183: >>> warning: unreachable catch clause. >>> >>> This fix aims at removing this warning by removing the IOException. >>> On inspection, it was found that currently, the native code does not >>> throw any IOException. >>> >>> The fix involves updates in: >>> jdk/src/share/classes/java/net/DatagramSocket.java >>> >>> >>> Webrev: http://cr.openjdk.java.net/~chegar/7035556/webrev.00/ >>> >>> Thanks, >>> -Kurchi >> Kurchi - one suggestion is to close the UDP socket in the event that >> the bind fails. That would be nicer than leaving it to the impl's >> finalizer. > > Ah yes, makes sense. thanks for catching this Alan. > But, bind() already closes the impl internally before throwing the exception. - Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20110722/d56eb8bd/attachment.html From chris.hegarty at oracle.com Fri Jul 22 06:49:04 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 Jul 2011 14:49:04 +0100 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E297E1C.6000003@oracle.com> References: <4E28A2C6.9040609@oracle.com> <4E28E44F.1040301@oracle.com> <4E297256.8060101@oracle.com> <4E297E1C.6000003@oracle.com> Message-ID: <4E297FD0.90004@oracle.com> On 7/22/2011 2:41 PM, Michael McMahon wrote: > On 22/07/11 13:51, Chris Hegarty wrote: >> On 7/22/2011 3:45 AM, Alan Bateman wrote: >>> Kurchi Hazra wrote: >>>> Hi, >>>> >>>> Due to a recent update in javac to issue a warning on detecting >>>> unreachable code, the following warning started showing up in the >>>> jdk networking code: >>>> ../../../src/share/classes/java/net/DatagramSocket.java:183: >>>> warning: unreachable catch clause. >>>> >>>> This fix aims at removing this warning by removing the IOException. >>>> On inspection, it was found that currently, the native code does >>>> not throw any IOException. >>>> >>>> The fix involves updates in: >>>> jdk/src/share/classes/java/net/DatagramSocket.java >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~chegar/7035556/webrev.00/ >>>> >>>> Thanks, >>>> -Kurchi >>> Kurchi - one suggestion is to close the UDP socket in the event that >>> the bind fails. That would be nicer than leaving it to the impl's >>> finalizer. >> >> Ah yes, makes sense. thanks for catching this Alan. >> > But, bind() already closes the impl internally before throwing the > exception. Oh, I didn't notice this. Great, then your original comment stands ( simply remove all catches ). -Chris. > > - Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20110722/1e3ef086/attachment.html From Alan.Bateman at oracle.com Fri Jul 22 06:55:28 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Jul 2011 14:55:28 +0100 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E297E1C.6000003@oracle.com> References: <4E28A2C6.9040609@oracle.com> <4E28E44F.1040301@oracle.com> <4E297256.8060101@oracle.com> <4E297E1C.6000003@oracle.com> Message-ID: <4E298150.7070204@oracle.com> Michael McMahon wrote: > But, bind() already closes the impl internally before throwing the > exception. I was wondering about that and whether this is a bug. Suppose someone creates an unbound DatagramSocket and then attempts to bind it to a port. If the bind fails (say port already in use) then it may be surprising that they can't retry with a different port. Should this be specified? I see there are cases such as the security exception where it doesn't the close the impl. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20110722/4763e460/attachment.html From michael.x.mcmahon at oracle.com Fri Jul 22 07:25:32 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 22 Jul 2011 15:25:32 +0100 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E298150.7070204@oracle.com> References: <4E28A2C6.9040609@oracle.com> <4E28E44F.1040301@oracle.com> <4E297256.8060101@oracle.com> <4E297E1C.6000003@oracle.com> <4E298150.7070204@oracle.com> Message-ID: <4E29885C.2010207@oracle.com> On 22/07/11 14:55, Alan Bateman wrote: > Michael McMahon wrote: >> But, bind() already closes the impl internally before throwing the >> exception. > I was wondering about that and whether this is a bug. Suppose someone > creates an unbound DatagramSocket and then attempts to bind it to a > port. If the bind fails (say port already in use) then it may be > surprising that they can't retry with a different port. Should this > be specified? I see there are cases such as the security exception > where it doesn't the close the impl. > > -Alan. It doesn't seem to be specified either way, though it does seem to be inconsistent. I'd be wary about changing the behaviour though unless there was a strong justification (more than a compiler warning :) ) - Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20110722/d2eb6564/attachment.html From kurchi.subhra.hazra at oracle.com Fri Jul 22 10:31:52 2011 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Fri, 22 Jul 2011 10:31:52 -0700 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E29885C.2010207@oracle.com> References: <4E28A2C6.9040609@oracle.com> <4E28E44F.1040301@oracle.com> <4E297256.8060101@oracle.com> <4E297E1C.6000003@oracle.com> <4E298150.7070204@oracle.com> <4E29885C.2010207@oracle.com> Message-ID: <4E29B408.8010208@oracle.com> Hi, I changed the implementation according to Brad's comments. I am reposting the output of hg diff src/share/classes/java/net/DatagramSocket.java since I don't have an openjdk account: bash-3.00$ hg diff src/share/classes/java/net/DatagramSocket.java diff --git a/src/share/classes/java/net/DatagramSocket.java b/src/share/classes/java/net/DatagramSocket.java --- a/src/share/classes/java/net/DatagramSocket.java +++ b/src/share/classes/java/net/DatagramSocket.java @@ -176,13 +176,7 @@ class DatagramSocket implements java.io. public DatagramSocket() throws SocketException { // create a datagram socket. createImpl(); - try { - bind(new InetSocketAddress(0)); - } catch (SocketException se) { - throw se; - } catch(IOException e) { - throw new SocketException(e.getMessage()); - } + bind(new InetSocketAddress(0)); } Thanks, Kurchi On 7/22/2011 7:25 AM, Michael McMahon wrote: > On 22/07/11 14:55, Alan Bateman wrote: >> Michael McMahon wrote: >>> But, bind() already closes the impl internally before throwing the >>> exception. >> I was wondering about that and whether this is a bug. Suppose someone >> creates an unbound DatagramSocket and then attempts to bind it to a >> port. If the bind fails (say port already in use) then it may be >> surprising that they can't retry with a different port. Should this >> be specified? I see there are cases such as the security exception >> where it doesn't the close the impl. >> >> -Alan. > It doesn't seem to be specified either way, though it does seem to be > inconsistent. > I'd be wary about changing the behaviour though > unless there was a strong justification (more than a compiler warning :) ) > > - Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20110722/58388123/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 01:24:08 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 Jul 2011 09:24:08 +0100 Subject: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E29B408.8010208@oracle.com> References: <4E28A2C6.9040609@oracle.com> <4E28E44F.1040301@oracle.com> <4E297256.8060101@oracle.com> <4E297E1C.6000003@oracle.com> <4E298150.7070204@oracle.com> <4E29885C.2010207@oracle.com> <4E29B408.8010208@oracle.com> Message-ID: <4E2D2828.7070405@oracle.com> The changes look fine to me. Thanks for taking care of this one. -Chris. On 07/22/11 06:31 PM, Kurchi Hazra wrote: > > Hi, > > I changed the implementation according to Brad's comments. I am > reposting the output of hg diff > src/share/classes/java/net/DatagramSocket.java since I don't have an > openjdk account: > > bash-3.00$ hg diff src/share/classes/java/net/DatagramSocket.java > diff --git a/src/share/classes/java/net/DatagramSocket.java > b/src/share/classes/java/net/DatagramSocket.java > --- a/src/share/classes/java/net/DatagramSocket.java > +++ b/src/share/classes/java/net/DatagramSocket.java > @@ -176,13 +176,7 @@ class DatagramSocket implements java.io. > public DatagramSocket() throws SocketException { > // create a datagram socket. > createImpl(); > - try { > - bind(new InetSocketAddress(0)); > - } catch (SocketException se) { > - throw se; > - } catch(IOException e) { > - throw new SocketException(e.getMessage()); > - } > + bind(new InetSocketAddress(0)); > } > > > Thanks, > Kurchi > > > > On 7/22/2011 7:25 AM, Michael McMahon wrote: >> On 22/07/11 14:55, Alan Bateman wrote: >>> Michael McMahon wrote: >>>> But, bind() already closes the impl internally before throwing the >>>> exception. >>> I was wondering about that and whether this is a bug. Suppose someone >>> creates an unbound DatagramSocket and then attempts to bind it to a >>> port. If the bind fails (say port already in use) then it may be >>> surprising that they can't retry with a different port. Should this >>> be specified? I see there are cases such as the security exception >>> where it doesn't the close the impl. >>> >>> -Alan. >> It doesn't seem to be specified either way, though it does seem to be >> inconsistent. >> I'd be wary about changing the behaviour though >> unless there was a strong justification (more than a compiler warning :) ) >> >> - Michael. > > 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 chris.hegarty at oracle.com Mon Jul 25 14:52:58 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 Jul 2011 22:52:58 +0100 Subject: hg: jdk8/tl/jdk: 7035556: DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <20110725214247.121EF47709@hg.openjdk.java.net> References: <20110725214247.121EF47709@hg.openjdk.java.net> Message-ID: <4E2DE5BA.6030606@oracle.com> Congratulation Kurchi on your first contribution to OpenJDK. Hope to see more in the future. -Chris. On 07/25/11 10:42 PM, chris.hegarty at oracle.com wrote: > 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 kurchi.subhra.hazra at oracle.com Mon Jul 25 15:23:22 2011 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 25 Jul 2011 15:23:22 -0700 Subject: hg: jdk8/tl/jdk: 7035556: DatagramSocket.java:183: warning: unreachable catch clause In-Reply-To: <4E2DE5BA.6030606@oracle.com> References: <20110725214247.121EF47709@hg.openjdk.java.net> <4E2DE5BA.6030606@oracle.com> Message-ID: <4E2DECDA.5050404@oracle.com> Thanks a lot and I look forward to making more contributions too! Thanks, Kurchi On 7/25/2011 2:52 PM, Chris Hegarty wrote: > Congratulation Kurchi on your first contribution to OpenJDK. Hope to > see more in the future. > > -Chris. > > On 07/25/11 10:42 PM, chris.hegarty at oracle.com wrote: >> 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 >> -- -Kurchi From chris.hegarty at oracle.com Tue Jul 26 08:21:20 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Jul 2011 16:21:20 +0100 Subject: Code Review 6670868: StackOverFlow with bad authenticated Proxy tunnels Message-ID: <4E2EDB70.5060107@oracle.com> Michael, There is an issue in the tunneling/Http retry code whereby a proxy requiring authentication, if it gives a bad response after the initial 407, may cause the HTTPClient to perform recursive calls to parseHTTP until StackOverFlow. The reason is obvious when you look at the "try once more" in HttpClient (webrev). This fix required some cleaned in HttpURLConnection, and partially removes a previous fix, CR 6216082. I verified that this part of the change for 6216082 is no longer required, and confirmed this by running the test that was added as part of 6216082. Webrev: http://cr.openjdk.java.net/~chegar/6670868/webrev.00/webrev/ -Chris. 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 michael.x.mcmahon at oracle.com Wed Jul 27 05:15:23 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 27 Jul 2011 13:15:23 +0100 Subject: Code Review 6670868: StackOverFlow with bad authenticated Proxy tunnels In-Reply-To: <4E2EDB70.5060107@oracle.com> References: <4E2EDB70.5060107@oracle.com> Message-ID: <4E30015B.5010104@oracle.com> On 26/07/11 16:21, Chris Hegarty wrote: > Michael, > > There is an issue in the tunneling/Http retry code whereby a proxy > requiring authentication, if it gives a bad response after the initial > 407, may cause the HTTPClient to perform recursive calls to parseHTTP > until StackOverFlow. The reason is obvious when you look at the "try > once more" in HttpClient (webrev). > > This fix required some cleaned in HttpURLConnection, and partially > removes a previous fix, CR 6216082. I verified that this part of the > change for 6216082 is no longer required, and confirmed this by > running the test that was added as part of 6216082. > > Webrev: > http://cr.openjdk.java.net/~chegar/6670868/webrev.00/webrev/ > > -Chris. Looks fine. Thanks Michael. 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 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 kurchi.subhra.hazra at oracle.com Thu Jul 28 14:29:25 2011 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 28 Jul 2011 14:29:25 -0700 Subject: Code Review Request: 6978200 ServerSocket.toString include "port=0" in the returned String Message-ID: <4E31D4B5.5090808@oracle.com> Hi, The ServerSocket.toString method returns a string that, besides the ServerSocket's local port information, also contains "port=0". For example: "ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=7005]". The fix aims at modifying the string returned by the toString method by removing impl.getPort() from the method and subsequently "port=0" from it. Although we know that anyone parsing toString (and ignoring port) may suffer from this change, but we don't expect that many (if anyone ) is doing this since accessor methods provide easier access to the local address and port. The fix involves updates in: jdk/src/share/classes/java/net/ServerSocket.java I am posting the output of hg diff here: bash-3.00$ hg diff src/share/classes/java/net/ServerSocket.java diff -r a80562f7ea50 src/share/classes/java/net/ServerSocket.java --- a/src/share/classes/java/net/ServerSocket.java Wed Jul 27 18:10:10 2011 +0100 +++ b/src/share/classes/java/net/ServerSocket.java Thu Jul 28 14:16:10 2011 -0700 @@ -716,7 +716,6 @@ class ServerSocket implements java.io.Cl if (!isBound()) return "ServerSocket[unbound]"; return "ServerSocket[addr=" + impl.getInetAddress() + - ",port=" + impl.getPort() + ",localport=" + impl.getLocalPort() + "]"; } Thanks! -- -Kurchi 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 Alan.Bateman at oracle.com Thu Jul 28 20:01:01 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Jul 2011 04:01:01 +0100 Subject: Code Review Request: 6978200 ServerSocket.toString include "port=0" in the returned String In-Reply-To: <4E31D4B5.5090808@oracle.com> References: <4E31D4B5.5090808@oracle.com> Message-ID: <4E32226C.4070802@oracle.com> Kurchi Hazra wrote: > Hi, > > The ServerSocket.toString method returns a string that, besides the > ServerSocket's local port information, also contains "port=0". For > example: "ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=7005]". > > The fix aims at modifying the string returned by the toString method > by removing impl.getPort() from the method and subsequently "port=0" > from it. This make sense as it's only the local port that is interesting. The change looks good to me. -Alan From chris.hegarty at oracle.com Fri Jul 29 02:24:04 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 29 Jul 2011 10:24:04 +0100 Subject: Code Review Request: 6978200 ServerSocket.toString include "port=0" in the returned String In-Reply-To: <4E31D4B5.5090808@oracle.com> References: <4E31D4B5.5090808@oracle.com> Message-ID: <4E327C34.6040802@oracle.com> This change looks fine to me. Thanks Kurchi, -Chris. On 7/28/2011 10:29 PM, Kurchi Hazra wrote: > Hi, > > The ServerSocket.toString method returns a string that, besides the > ServerSocket's local port information, also contains "port=0". For > example: "ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=7005]". > > The fix aims at modifying the string returned by the toString method > by removing impl.getPort() from the method and subsequently "port=0" > from it. Although we know that anyone parsing toString (and ignoring > port) may suffer from this change, but we don't expect that many (if > anyone ) is doing this since accessor methods provide easier access to > the local address and port. > > The fix involves updates in: > jdk/src/share/classes/java/net/ServerSocket.java > > > > I am posting the output of hg diff here: > > bash-3.00$ hg diff src/share/classes/java/net/ServerSocket.java > diff -r a80562f7ea50 src/share/classes/java/net/ServerSocket.java > --- a/src/share/classes/java/net/ServerSocket.java Wed Jul 27 > 18:10:10 2011 +0100 > +++ b/src/share/classes/java/net/ServerSocket.java Thu Jul 28 > 14:16:10 2011 -0700 > @@ -716,7 +716,6 @@ class ServerSocket implements java.io.Cl > if (!isBound()) > return "ServerSocket[unbound]"; > return "ServerSocket[addr=" + impl.getInetAddress() + > - ",port=" + impl.getPort() + > ",localport=" + impl.getLocalPort() + "]"; > } > > > Thanks! > 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 alexandre.boulgakov at oracle.com Fri Jul 29 11:37:00 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Fri, 29 Jul 2011 11:37:00 -0700 Subject: Different javac options for explicitly and automatically compiled files Message-ID: <4E32FDCC.7020600@oracle.com> Hello, I am working on removing the javac -Xlint warnings from java.net.*. After removing these warnings, I would like to turn on javac's -Werror flag in make/java/net/Makefile. However, it seems that the javac task in make/java/net/Makefile has to automatically compile some dependencies (not listed in the makefile, presumably inferred by the compiler from the sourcepath) which have not had warnings fixed yet (sun.net.idn.*, com.sun.security.ntlm.*). Is there some way to have the -Werror flag only apply to explicitly specified source files, but not to the ones that javac pulls in automatically? Thanks, Sasha 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 >> >