From vincent.x.ryan at oracle.com Mon Oct 1 04:30:27 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 1 Oct 2012 12:30:27 +0100 Subject: Code review request: 7197652: Impossible to run any signed JNLP applications or applets, OCSP off by default Message-ID: Please review these changes for JDK 7 to correct the trust decision when examining the signer certificate of an OCSP response. When matching two certificates the key identifiers should only be checked if present in both. http://cr.openjdk.java.net/~vinnie/7197652/webrev.00/ Thanks. From alan.bateman at oracle.com Mon Oct 1 07:43:23 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 01 Oct 2012 14:43:23 +0000 Subject: hg: jdk8/tl/jdk: 8000269: Cleanup javadoc warnings Message-ID: <20121001144346.24F384714B@hg.openjdk.java.net> Changeset: 39cbe256c3d1 Author: alanb Date: 2012-10-01 15:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1 8000269: Cleanup javadoc warnings Reviewed-by: lancea, darcy, ulfzibis, iris, naoto, dholmes ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/io/Reader.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/InheritableThreadLocal.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/nio/channels/Channels.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/security/AllPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/RBCollationTables.java ! src/share/classes/java/text/RBTableBuilder.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/javax/crypto/CryptoAllPermission.java ! src/share/classes/javax/crypto/CryptoPermission.java ! src/share/classes/javax/crypto/CryptoPolicyParser.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/naming/spi/NamingManager.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java From mstjohns at comcast.net Mon Oct 1 09:06:32 2012 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 01 Oct 2012 12:06:32 -0400 Subject: JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores In-Reply-To: <20120929002706.22CE2C23@eggemoggin.niobe.net> References: <20120929002706.22CE2C23@eggemoggin.niobe.net> Message-ID: <20121001160631.558DE68A3@mail.openjdk.java.net> At 08:27 PM 9/28/2012, mark.reinhold at oracle.com wrote: >Posted: http://openjdk.java.net/jeps/166 > >- Mark This seems at least partially related to JEP 121 and maybe even dependent on it. Might be useful to have a cross reference. Also, probably useful to decide/state a new default PKCS12 algorithm? E.g. maybe PBEwithSHA256andAES-128? Mike From vincent.x.ryan at oracle.com Mon Oct 1 09:51:33 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 1 Oct 2012 17:51:33 +0100 Subject: JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores In-Reply-To: <201210011606.q91G6VaS021676@acsinet12.oracle.com> References: <20120929002706.22CE2C23@eggemoggin.niobe.net> <201210011606.q91G6VaS021676@acsinet12.oracle.com> Message-ID: <3BBBBF18-CAAD-4F28-9211-68819C85272E@oracle.com> Hello Mike, The new PBE algorithms in JEP-121, such as PBEWithHmacSHA256AndAES_128, could certainly be used for PKCS12 keystores within Java environments - the problem is maintaining interoperability with existing crypto toolkits and web browsers. Is there any interest among those on this list in promoting wider support for these PBE algorithms? Thanks. On 1 Oct 2012, at 17:06, Michael StJohns wrote: > At 08:27 PM 9/28/2012, mark.reinhold at oracle.com wrote: >> Posted: http://openjdk.java.net/jeps/166 >> >> - Mark > > This seems at least partially related to JEP 121 and maybe even dependent on it. Might be useful to have a cross reference. Also, probably useful to decide/state a new default PKCS12 algorithm? E.g. maybe PBEwithSHA256andAES-128? > > Mike > > From mstjohns at comcast.net Mon Oct 1 10:50:45 2012 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 01 Oct 2012 13:50:45 -0400 Subject: JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores In-Reply-To: <3BBBBF18-CAAD-4F28-9211-68819C85272E@oracle.com> References: <20120929002706.22CE2C23@eggemoggin.niobe.net> <201210011606.q91G6VaS021676@acsinet12.oracle.com> <3BBBBF18-CAAD-4F28-9211-68819C85272E@oracle.com> Message-ID: <20121001175045.6F0DB68BC@mail.openjdk.java.net> My main reason for suggesting this is that the all but one of the algorithm suites defined in PKCS12 are either deprecated or prohibited by NIST guidance. The undeprecated suite appears to be the default one used by the java implementation. It would be nice to have a choice. See below. At 12:51 PM 10/1/2012, Vincent Ryan wrote: >Hello Mike, > >The new PBE algorithms in JEP-121, such as PBEWithHmacSHA256AndAES_128, could certainly be used >for PKCS12 keystores within Java environments - the problem is maintaining interoperability with existing >crypto toolkits and web browsers. Yup - but someone has to be first.... :-) Mike >Is there any interest among those on this list in promoting wider support for these PBE algorithms? > >Thanks. > > >On 1 Oct 2012, at 17:06, Michael StJohns wrote: > >> At 08:27 PM 9/28/2012, mark.reinhold at oracle.com wrote: >>> Posted: http://openjdk.java.net/jeps/166 >>> >>> - Mark >> >> This seems at least partially related to JEP 121 and maybe even dependent on it. Might be useful to have a cross reference. Also, probably useful to decide/state a new default PKCS12 algorithm? E.g. maybe PBEwithSHA256andAES-128? >> >> Mike >> >> From vincent.x.ryan at oracle.com Mon Oct 1 11:17:32 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 1 Oct 2012 19:17:32 +0100 Subject: JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores In-Reply-To: <201210011750.q91HohNJ022734@rcsinet11.oracle.com> References: <20120929002706.22CE2C23@eggemoggin.niobe.net> <201210011606.q91G6VaS021676@acsinet12.oracle.com> <3BBBBF18-CAAD-4F28-9211-68819C85272E@oracle.com> <201210011750.q91HohNJ022734@rcsinet11.oracle.com> Message-ID: <8B5C7FC0-BC64-4DF2-B2DB-7B6F7CCF4002@oracle.com> We could examine a mechansim for keystore applications to override the default PBE algorithm for protecting keys and certs. Maybe extend KeyStore.LoadStoreParameter? On 1 Oct 2012, at 18:50, Michael StJohns wrote: > My main reason for suggesting this is that the all but one of the algorithm suites defined in PKCS12 are either deprecated or prohibited by NIST guidance. The undeprecated suite appears to be the default one used by the java implementation. It would be nice to have a choice. > > See below. > > At 12:51 PM 10/1/2012, Vincent Ryan wrote: >> Hello Mike, >> >> The new PBE algorithms in JEP-121, such as PBEWithHmacSHA256AndAES_128, could certainly be used >> for PKCS12 keystores within Java environments - the problem is maintaining interoperability with existing >> crypto toolkits and web browsers. > > Yup - but someone has to be first.... :-) > > Mike > > >> Is there any interest among those on this list in promoting wider support for these PBE algorithms? >> >> Thanks. >> >> >> On 1 Oct 2012, at 17:06, Michael StJohns wrote: >> >>> At 08:27 PM 9/28/2012, mark.reinhold at oracle.com wrote: >>>> Posted: http://openjdk.java.net/jeps/166 >>>> >>>> - Mark >>> >>> This seems at least partially related to JEP 121 and maybe even dependent on it. Might be useful to have a cross reference. Also, probably useful to decide/state a new default PKCS12 algorithm? E.g. maybe PBEwithSHA256andAES-128? >>> >>> Mike >>> >>> > > From mstjohns at comcast.net Mon Oct 1 12:03:19 2012 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 01 Oct 2012 15:03:19 -0400 Subject: JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores In-Reply-To: <8B5C7FC0-BC64-4DF2-B2DB-7B6F7CCF4002@oracle.com> References: <20120929002706.22CE2C23@eggemoggin.niobe.net> <201210011606.q91G6VaS021676@acsinet12.oracle.com> <3BBBBF18-CAAD-4F28-9211-68819C85272E@oracle.com> <201210011750.q91HohNJ022734@rcsinet11.oracle.com> <8B5C7FC0-BC64-4DF2-B2DB-7B6F7CCF4002@oracle.com> Message-ID: <20121001190319.CDFE168D6@mail.openjdk.java.net> At 02:17 PM 10/1/2012, Vincent Ryan wrote: >We could examine a mechansim for keystore applications to override the default PBE algorithm for protecting keys and certs. >Maybe extend KeyStore.LoadStoreParameter? So don't change the PKCS12 instance type, instead deal with this on an entry by entry basis? Makes sense. Probably the right change is to extend KeyStore.PasswordProtection, and allow the user to provide a different algorithm per entry? If you are loading, you can use KeyStore.PasswordProtection, and it takes the algorithm from the entry info. If you are storing, and you don't specify the algorithm, you get the default (perhaps specified in java.security props file next to the keystore default type?) Mike Mike >On 1 Oct 2012, at 18:50, Michael StJohns wrote: > >> My main reason for suggesting this is that the all but one of the algorithm suites defined in PKCS12 are either deprecated or prohibited by NIST guidance. The undeprecated suite appears to be the default one used by the java implementation. It would be nice to have a choice. >> >> See below. >> >> At 12:51 PM 10/1/2012, Vincent Ryan wrote: >>> Hello Mike, >>> >>> The new PBE algorithms in JEP-121, such as PBEWithHmacSHA256AndAES_128, could certainly be used >>> for PKCS12 keystores within Java environments - the problem is maintaining interoperability with existing >>> crypto toolkits and web browsers. >> >> Yup - but someone has to be first.... :-) >> >> Mike >> >> >>> Is there any interest among those on this list in promoting wider support for these PBE algorithms? >>> >>> Thanks. >>> >>> >>> On 1 Oct 2012, at 17:06, Michael StJohns wrote: >>> >>>> At 08:27 PM 9/28/2012, mark.reinhold at oracle.com wrote: >>>>> Posted: http://openjdk.java.net/jeps/166 >>>>> >>>>> - Mark >>>> >>>> This seems at least partially related to JEP 121 and maybe even dependent on it. Might be useful to have a cross reference. Also, probably useful to decide/state a new default PKCS12 algorithm? E.g. maybe PBEwithSHA256andAES-128? >>>> >>>> Mike >>>> >>>> >> >> From vincent.x.ryan at oracle.com Mon Oct 1 13:27:52 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 01 Oct 2012 21:27:52 +0100 Subject: JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores In-Reply-To: <201210011903.q91J3NAZ003657@rcsinet11.oracle.com> References: <20120929002706.22CE2C23@eggemoggin.niobe.net> <201210011606.q91G6VaS021676@acsinet12.oracle.com> <3BBBBF18-CAAD-4F28-9211-68819C85272E@oracle.com> <201210011750.q91HohNJ022734@rcsinet11.oracle.com> <8B5C7FC0-BC64-4DF2-B2DB-7B6F7CCF4002@oracle.com> <201210011903.q91J3NAZ003657@rcsinet11.oracle.com> Message-ID: <5069FCC8.1060106@oracle.com> Extending KeyStore.PasswordProtection works well for keys and for certs. To retain its immutability, a new constructor that takes the PBE algorithm name and a new getter could be added. Thanks. On 01/10/2012 20:03, Michael StJohns wrote: > At 02:17 PM 10/1/2012, Vincent Ryan wrote: > >> We could examine a mechansim for keystore applications to override the default PBE algorithm for protecting keys and certs. >> Maybe extend KeyStore.LoadStoreParameter? > > So don't change the PKCS12 instance type, instead deal with this on an entry by entry basis? Makes sense. > > Probably the right change is to extend KeyStore.PasswordProtection, and allow the user to provide a different algorithm per entry? If you are loading, you can use KeyStore.PasswordProtection, and it takes the algorithm from the entry info. If you are storing, and you don't specify the algorithm, you get the default (perhaps specified in java.security props file next to the keystore default type?) > > Mike > > > Mike > > > > >> On 1 Oct 2012, at 18:50, Michael StJohns wrote: >> >>> My main reason for suggesting this is that the all but one of the algorithm suites defined in PKCS12 are either deprecated or prohibited by NIST guidance. The undeprecated suite appears to be the default one used by the java implementation. It would be nice to have a choice. >>> >>> See below. >>> >>> At 12:51 PM 10/1/2012, Vincent Ryan wrote: >>>> Hello Mike, >>>> >>>> The new PBE algorithms in JEP-121, such as PBEWithHmacSHA256AndAES_128, could certainly be used >>>> for PKCS12 keystores within Java environments - the problem is maintaining interoperability with existing >>>> crypto toolkits and web browsers. >>> >>> Yup - but someone has to be first.... :-) >>> >>> Mike >>> >>> >>>> Is there any interest among those on this list in promoting wider support for these PBE algorithms? >>>> >>>> Thanks. >>>> >>>> >>>> On 1 Oct 2012, at 17:06, Michael StJohns wrote: >>>> >>>>> At 08:27 PM 9/28/2012, mark.reinhold at oracle.com wrote: >>>>>> Posted: http://openjdk.java.net/jeps/166 >>>>>> >>>>>> - Mark >>>>> >>>>> This seems at least partially related to JEP 121 and maybe even dependent on it. Might be useful to have a cross reference. Also, probably useful to decide/state a new default PKCS12 algorithm? E.g. maybe PBEwithSHA256andAES-128? >>>>> >>>>> Mike >>>>> >>>>> >>> >>> > > From stephen.flores at oracle.com Mon Oct 1 19:40:10 2012 From: stephen.flores at oracle.com (Stephen Flores) Date: Mon, 01 Oct 2012 22:40:10 -0400 Subject: 7194449: String resources for Key Tool and Policy Tool should be in their respective packages In-Reply-To: <505C1B28.5030700@oracle.com> References: <505BC7BD.6090501@oracle.com> <505C1B28.5030700@oracle.com> Message-ID: <506A540A.7030609@oracle.com> Max, Yes, I ran the tools and the unit tests which did find missing resources that I duplicated. This is not a type of new split, at one time all 3 tools had there resources in the sun...util.Resources class and the JarSigner was split out to not be in the rt.jar, but in tools.jar, so this logical conclusion to the spilt. Steve. On 09/21/2012 03:45 AM, Weijun Wang wrote: > Looks fine. I'm only not sure if dividing sun.security.util.Resources > into 3 files is safe. Is it possible that a string is shared by them? I > noticed you keep a duplicate of "NEWLINE". Hopefully you already figured > out all cases. > > Thanks > Max > > > On 09/21/2012 09:49 AM, Stephen Flores wrote: >> Max, Sean, Alan, >> >> Please review this webrev: >> >> http://cr.openjdk.java.net/~sflores/7194449/webrev-0/ >> >> Note: I will respond to any comments when I get back from vacation on >> Monday Oct. 1. >> >> Changes: >> >> Moved jarsigner and keytool into their own packages as was done >> for policytool. Unit tests and release.gmk were updated. >> >> Static methods in keytool called by jarsigner were moved to >> sun.security.tools.KeyStoreUtil. >> >> Spit out the String resources for keytool and policytool from >> sun.security.util.Resources into their respective packages. >> >> Sean, >> >> If everything is OK, can you commit the changes? >> >> Thanks, >> >> Steve. >> From stephen.flores at oracle.com Mon Oct 1 19:41:50 2012 From: stephen.flores at oracle.com (Stephen Flores) Date: Mon, 01 Oct 2012 22:41:50 -0400 Subject: 7194449: String resources for Key Tool and Policy Tool should be in their respective packages In-Reply-To: <505C1BE9.7060606@oracle.com> References: <505BC7BD.6090501@oracle.com> <505C1B28.5030700@oracle.com> <505C1BE9.7060606@oracle.com> Message-ID: <506A546E.9020501@oracle.com> Max, I got the impression from Alan that we will only do that when asked. Steve. On 09/21/2012 03:48 AM, Weijun Wang wrote: > Also, I remember we agreed on leaving a s.s.t.KeyTool class whose main() > simply calls s.s.t.k.Main.main(). Are we still going to do that? > > Thanks > Max > > On 09/21/2012 03:45 PM, Weijun Wang wrote: >> Looks fine. I'm only not sure if dividing sun.security.util.Resources >> into 3 files is safe. Is it possible that a string is shared by them? I >> noticed you keep a duplicate of "NEWLINE". Hopefully you already figured >> out all cases. >> >> Thanks >> Max >> >> >> On 09/21/2012 09:49 AM, Stephen Flores wrote: >>> Max, Sean, Alan, >>> >>> Please review this webrev: >>> >>> http://cr.openjdk.java.net/~sflores/7194449/webrev-0/ >>> >>> Note: I will respond to any comments when I get back from vacation on >>> Monday Oct. 1. >>> >>> Changes: >>> >>> Moved jarsigner and keytool into their own packages as was done >>> for policytool. Unit tests and release.gmk were updated. >>> >>> Static methods in keytool called by jarsigner were moved to >>> sun.security.tools.KeyStoreUtil. >>> >>> Spit out the String resources for keytool and policytool from >>> sun.security.util.Resources into their respective packages. >>> >>> Sean, >>> >>> If everything is OK, can you commit the changes? >>> >>> Thanks, >>> >>> Steve. >>> From stephen.flores at oracle.com Mon Oct 1 19:57:46 2012 From: stephen.flores at oracle.com (Stephen Flores) Date: Mon, 01 Oct 2012 22:57:46 -0400 Subject: 7194449: String resources for Key Tool and Policy Tool should be in their respective packages In-Reply-To: <505C419F.1040807@oracle.com> References: <505BC7BD.6090501@oracle.com> <505C419F.1040807@oracle.com> Message-ID: <506A582A.5030209@oracle.com> On 09/21/2012 06:29 AM, Alan Bateman wrote: > On 21/09/2012 02:49, Stephen Flores wrote: >> Max, Sean, Alan, >> >> Please review this webrev: >> >> http://cr.openjdk.java.net/~sflores/7194449/webrev-0/ >> >> Note: I will respond to any comments when I get back from vacation on >> Monday Oct. 1. >> >> Changes: >> >> Moved jarsigner and keytool into their own packages as was done >> for policytool. Unit tests and release.gmk were updated. >> >> Static methods in keytool called by jarsigner were moved to >> sun.security.tools.KeyStoreUtil. >> >> Spit out the String resources for keytool and policytool from >> sun.security.util.Resources into their respective packages. >> >> Sean, >> >> If everything is OK, can you commit the changes? >> >> Thanks, >> >> Steve. >> > I skimmed through this and I'm sure Sean and Max will give it a detailed > reviewed. > > Overall it looks very good to me, the only thing that I'm not sure about > is the resources for keytool. As they are in sun.security.tools.keytool > it means they will all need to be included with the tool. If you wanted > a en_US vs. all split without splitting packages then it would meaning > moving them again. > Alan, I am going to take you advice and push back on feature creep, I need to stick plan we agreed to and that I put in the CR, so I can move back to complete sun.security.ec decoupling work and I don't think this change makes it harder for me to move resources or a waste of time later. I think cleaning up modularity when you can is a good thing. I am willing help the g18n group with any other work need to just deliver english when the is a clear plan. > I agree with Max's question about whether you need to leave a > sun.security.tools.KeyTool in case anyone invokes it directly (no one > should be dependent on sun.security.** classes of course but still > working considering). > I got the impression from you that we would add the later. > In sun/security/tools/KeyStoreUtil.java then maybe getPassWithModifier > can use try-with-resources. > I don't understand what you mean by "try-with-resources", I don't think JarSigner should rely on KeyTool resources, so I copied the 3 resources it needed from keytool to jarsigner. I feel that even though for time reasons we did not put the other tools in their own JARs, to code should not preclude that in the future. > Is the change to sun/security/tools/keytool/autotest.sh just a merge issue? > When I ran jprt I got the very confusing "Cannot find LIBNAME" message, libsoftokn3.so, so I just wanted tester's in the future to have correct message. Steve. > -Alan. > > From alan.bateman at oracle.com Tue Oct 2 02:14:41 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 02 Oct 2012 09:14:41 +0000 Subject: hg: jdk8/tl/jdk: 7050528: Improve performance of java.text.DecimalFormat.format() call stack Message-ID: <20121002091518.BA1934715D@hg.openjdk.java.net> Changeset: 75080f572f84 Author: olagneau Date: 2012-10-02 10:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75080f572f84 7050528: Improve performance of java.text.DecimalFormat.format() call stack Reviewed-by: darcy ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/NumberFormat.java + test/java/text/Format/DecimalFormat/FormatMicroBenchmark.java + test/java/text/Format/DecimalFormat/GoldenDoubleValues.java + test/java/text/Format/DecimalFormat/GoldenFormattedValues.java + test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java From alan.bateman at oracle.com Tue Oct 2 02:37:28 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 02 Oct 2012 09:37:28 +0000 Subject: hg: jdk8/tl/jdk: 7197642: (sl) ServiceLoader.load(null) doesn't throw NPE Message-ID: <20121002093922.444EE4715E@hg.openjdk.java.net> Changeset: 041c687c4f40 Author: psandoz Date: 2012-10-02 10:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/041c687c4f40 7197642: (sl) ServiceLoader.load(null) doesn't throw NPE Reviewed-by: alanb ! src/share/classes/java/util/ServiceLoader.java + test/java/util/ServiceLoader/NPE.java From Alan.Bateman at oracle.com Tue Oct 2 03:22:34 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Oct 2012 11:22:34 +0100 Subject: 8000268: sun/security/provider/X509Factory/BigCRL.java testing on Linux 32-bit Message-ID: <506AC06A.3050605@oracle.com> This test has been failing intermittently for me on 32-bit systems since jdk8/tl picked up the perm gen removal work a few days ago. The test uses a 1GB heap and it doesn't seem to be possible to reduce it too much as it needs a largish heap on 64-bit systems. Any objection if I change the test to run without CDS? That allows the VM to reserve the 1GB. This is just a workaround for now, the alternative is to exclude it by putting it on the ProblemList. Thanks, -Alan diff --git a/test/sun/security/provider/X509Factory/BigCRL.java b/test/sun/security/provider/X509Factory/BigCRL.java --- a/test/sun/security/provider/X509Factory/BigCRL.java +++ b/test/sun/security/provider/X509Factory/BigCRL.java @@ -25,7 +25,7 @@ * @test * @bug 7099399 * @summary cannot deal with CRL file larger than 16MB - * @run main/othervm -Xmx1024m BigCRL + * @run main/othervm -Xshare:off -Xmx1024m BigCRL */ import java.io.FileInputStream; From Alan.Bateman at oracle.com Tue Oct 2 03:32:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Oct 2012 11:32:54 +0100 Subject: 7194449: String resources for Key Tool and Policy Tool should be in their respective packages In-Reply-To: <506A582A.5030209@oracle.com> References: <505BC7BD.6090501@oracle.com> <505C419F.1040807@oracle.com> <506A582A.5030209@oracle.com> Message-ID: <506AC2D6.10707@oracle.com> On 02/10/2012 03:57, Stephen Flores wrote: > : > > > Alan, > > I am going to take you advice and push back on feature creep, I need > to stick plan we agreed to and that I put in the CR, so I can move > back to complete sun.security.ec decoupling work and I don't think > this change makes it harder for me to move resources or a waste of > time later. I think cleaning up modularity when you can is a good thing. I'm okay with this. > : >> I agree with Max's question about whether you need to leave a >> sun.security.tools.KeyTool in case anyone invokes it directly (no one >> should be dependent on sun.security.** classes of course but still >> working considering). >> > > I got the impression from you that we would add the later. Max is away at the moment. I think we had a small concern that Glassfish and others may be using sun.security.tools.KeyTool directly, although I think Max checked it and said this was no longer the case. A forwarding class can be trivially added later if needed. > >> In sun/security/tools/KeyStoreUtil.java then maybe getPassWithModifier >> can use try-with-resources. >> > > I don't understand what you mean by "try-with-resources", I don't > think JarSigner should rely on KeyTool resources, so I copied the 3 > resources it needed from keytool to jarsigner. I feel that even though > for time reasons we did not put the other tools in their own JARs, to > code should not preclude that in the future. I wasn't clear, I meant try-with-resources, the language feature. You're using it already at line 97 of the test, I was just suggesting that you could use it at line 133 too and that will ensure that the stream is closed, even if the readLine fails. > > >> Is the change to sun/security/tools/keytool/autotest.sh just a merge >> issue? >> > > When I ran jprt I got the very confusing "Cannot find LIBNAME" > message, libsoftokn3.so, so I just wanted tester's in the future to > have correct message. > OK. -Alan. From sean.mullan at oracle.com Tue Oct 2 03:48:13 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 02 Oct 2012 11:48:13 +0100 Subject: 8000268: sun/security/provider/X509Factory/BigCRL.java testing on Linux 32-bit In-Reply-To: <506AC06A.3050605@oracle.com> References: <506AC06A.3050605@oracle.com> Message-ID: <506AC66D.5000308@oracle.com> On 10/2/12 11:22 AM, Alan Bateman wrote: > > This test has been failing intermittently for me on 32-bit systems since > jdk8/tl picked up the perm gen removal work a few days ago. > > The test uses a 1GB heap and it doesn't seem to be possible to reduce it > too much as it needs a largish heap on 64-bit systems. Any objection if > I change the test to run without CDS? No objection from me. > That allows the VM to reserve the > 1GB. This is just a workaround for now, the alternative is to exclude it > by putting it on the ProblemList. Also, parsing large CRLs are problematic in general so this is really a bigger problem that needs to be fixed. There is already a CR open for that : 6670894: CRL parsing implementation is extremely inefficient --Sean > > Thanks, > > -Alan > > > diff --git a/test/sun/security/provider/X509Factory/BigCRL.java > b/test/sun/security/provider/X509Factory/BigCRL.java > --- a/test/sun/security/provider/X509Factory/BigCRL.java > +++ b/test/sun/security/provider/X509Factory/BigCRL.java > @@ -25,7 +25,7 @@ > * @test > * @bug 7099399 > * @summary cannot deal with CRL file larger than 16MB > - * @run main/othervm -Xmx1024m BigCRL > + * @run main/othervm -Xshare:off -Xmx1024m BigCRL > */ > > import java.io.FileInputStream; > From alan.bateman at oracle.com Tue Oct 2 04:24:22 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 02 Oct 2012 11:24:22 +0000 Subject: hg: jdk8/tl/jdk: 8000268: sun/security/provider/X509Factory/BigCRL.java failing on Linux 32-bit Message-ID: <20121002112435.42F3A47162@hg.openjdk.java.net> Changeset: 6750ab947255 Author: alanb Date: 2012-10-02 12:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6750ab947255 8000268: sun/security/provider/X509Factory/BigCRL.java failing on Linux 32-bit Reviewed-by: mullan ! test/sun/security/provider/X509Factory/BigCRL.java From yuka.kamiya at oracle.com Tue Oct 2 23:13:12 2012 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Wed, 03 Oct 2012 06:13:12 +0000 Subject: hg: jdk8/tl/jdk: 7104012: AIOOBE from RuleBasedBreakIterator.lookupState for some suppl. chars Message-ID: <20121003061355.63DA747171@hg.openjdk.java.net> Changeset: 4744dc70e5d1 Author: peytoia Date: 2012-10-03 15:11 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4744dc70e5d1 7104012: AIOOBE from RuleBasedBreakIterator.lookupState for some suppl. chars Reviewed-by: okutsu ! src/share/classes/sun/text/SupplementaryCharacterData.java + test/java/text/BreakIterator/Bug7104012.java From alan.bateman at oracle.com Wed Oct 3 01:03:55 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 03 Oct 2012 08:03:55 +0000 Subject: hg: jdk8/tl/jdk: 6910472: Typo in : java.io.ObjectOutputStream.reset() "refered" Message-ID: <20121003080418.3979A47174@hg.openjdk.java.net> Changeset: 7fe88d457d85 Author: dxu Date: 2012-10-03 09:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fe88d457d85 6910472: Typo in : java.io.ObjectOutputStream.reset() "refered" Reviewed-by: dholmes, alanb ! src/share/classes/java/io/ObjectOutputStream.java From vincent.x.ryan at oracle.com Wed Oct 3 02:32:47 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 3 Oct 2012 10:32:47 +0100 Subject: 7133495: [macosx] KeyChain KeyStore implementation retrieves only one private key entry Message-ID: <75ACDA5C-E912-4947-BC7A-767C7F56F66D@oracle.com> FYI the following MacOS X fix has been forward-ported from JDK 7 to JDK 8: http://cr.openjdk.java.net/~vinnie/7133495/webrev.00/ Thanks. From vincent.x.ryan at oracle.com Wed Oct 3 07:54:30 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 3 Oct 2012 15:54:30 +0100 Subject: Review Request Jira bug # 80000204 In-Reply-To: References: Message-ID: <4ADDEFAF-0377-41A1-BDAB-F52E566A4B87@oracle.com> Fix looks good John. I can sponsor this for you if you wish. Just send me a patch generated using 'hg export'. Thanks. On 28 Sep 2012, at 15:41, John Zavgren wrote: > > Greetings: > > I just uploaded the webrev image of a memory leak fix: > > http://cr.openjdk.java.net/~chegar/8000204/webrev.00/ > (Jira bug ID 8000204) > > Thanks! > John Zavgren > john.zavgren at oracle.com From yuka.kamiya at oracle.com Wed Oct 3 19:38:08 2012 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Thu, 04 Oct 2012 02:38:08 +0000 Subject: hg: jdk8/tl/jdk: 7196316: Wrong rounding mode in DecimalFormat after deserialization Message-ID: <20121004023839.5A4B147194@hg.openjdk.java.net> Changeset: 123db1c28d92 Author: peytoia Date: 2012-10-04 11:36 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/123db1c28d92 7196316: Wrong rounding mode in DecimalFormat after deserialization Reviewed-by: okutsu ! src/share/classes/java/text/DecimalFormat.java + test/java/text/Format/DecimalFormat/Bug7196316.java From stephen.flores at oracle.com Wed Oct 3 20:44:51 2012 From: stephen.flores at oracle.com (Stephen Flores) Date: Wed, 03 Oct 2012 23:44:51 -0400 Subject: 7194449: String resources for Key Tool and Policy Tool should be in their respective packages In-Reply-To: <506AC2D6.10707@oracle.com> References: <505BC7BD.6090501@oracle.com> <505C419F.1040807@oracle.com> <506A582A.5030209@oracle.com> <506AC2D6.10707@oracle.com> Message-ID: <506D0633.8010009@oracle.com> On 10/02/2012 06:32 AM, Alan Bateman wrote: > On 02/10/2012 03:57, Stephen Flores wrote: >> : >> >> >> Alan, >> >> I am going to take you advice and push back on feature creep, I need >> to stick plan we agreed to and that I put in the CR, so I can move >> back to complete sun.security.ec decoupling work and I don't think >> this change makes it harder for me to move resources or a waste of >> time later. I think cleaning up modularity when you can is a good thing. > I'm okay with this. > >> : >>> I agree with Max's question about whether you need to leave a >>> sun.security.tools.KeyTool in case anyone invokes it directly (no one >>> should be dependent on sun.security.** classes of course but still >>> working considering). >>> >> >> I got the impression from you that we would add the later. > Max is away at the moment. I think we had a small concern that Glassfish > and others may be using sun.security.tools.KeyTool directly, although I > think Max checked it and said this was no longer the case. A forwarding > class can be trivially added later if needed. > >> >>> In sun/security/tools/KeyStoreUtil.java then maybe getPassWithModifier >>> can use try-with-resources. >>> >> >> I don't understand what you mean by "try-with-resources", I don't >> think JarSigner should rely on KeyTool resources, so I copied the 3 >> resources it needed from keytool to jarsigner. I feel that even though >> for time reasons we did not put the other tools in their own JARs, to >> code should not preclude that in the future. > I wasn't clear, I meant try-with-resources, the language feature. You're > using it already at line 97 of the test, I was just suggesting that you > could use it at line 133 too and that will ensure that the stream is > closed, even if the readLine fails. > Alan, I re-factored line 133 to use the try-with-resources construct. I updated the webrev in place. Steve. >> >> >>> Is the change to sun/security/tools/keytool/autotest.sh just a merge >>> issue? >>> >> >> When I ran jprt I got the very confusing "Cannot find LIBNAME" >> message, libsoftokn3.so, so I just wanted tester's in the future to >> have correct message. >> > OK. > > -Alan. > From Alan.Bateman at oracle.com Thu Oct 4 01:46:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Oct 2012 09:46:59 +0100 Subject: 7194449: String resources for Key Tool and Policy Tool should be in their respective packages In-Reply-To: <506D0633.8010009@oracle.com> References: <505BC7BD.6090501@oracle.com> <505C419F.1040807@oracle.com> <506A582A.5030209@oracle.com> <506AC2D6.10707@oracle.com> <506D0633.8010009@oracle.com> Message-ID: <506D4D03.9010401@oracle.com> On 04/10/2012 04:44, Stephen Flores wrote: > : > > Alan, > > I re-factored line 133 to use the try-with-resources construct. > > I updated the webrev in place. > > Steve. Thanks. Sean - are you going to sponsor this and help Steve get this into jdk8/tl? -Alan. From yuka.kamiya at oracle.com Thu Oct 4 02:07:35 2012 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Thu, 04 Oct 2012 09:07:35 +0000 Subject: hg: jdk8/tl/jdk: 7201151: Fix Contribution : Java cannot get Windows's IME name correctly Message-ID: <20121004090757.E256947199@hg.openjdk.java.net> Changeset: 8692e14b8ea8 Author: peytoia Date: 2012-10-04 18:05 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8692e14b8ea8 7201151: Fix Contribution : Java cannot get Windows's IME name correctly Reviewed-by: okutsu ! src/windows/native/sun/windows/awt_InputMethod.cpp From vincent.x.ryan at oracle.com Thu Oct 4 03:50:30 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 4 Oct 2012 11:50:30 +0100 Subject: Code review request for JEP-121 In-Reply-To: <504634B0.7000002@oracle.com> References: <4FC90790.5070109@oracle.com> <503E3333.7040100@oracle.com> <50401BCE.1010003@oracle.com> <504634B0.7000002@oracle.com> Message-ID: <52B22704-F455-48F0-8BB4-810994D99D36@oracle.com> I've made further modifications including adding support to PBEParameterSpec for an AlgorithmParameterSpec object. This is used to convey parameters (in addition to salt and iteration count) to the underlying cipher. For example, AES requires an initialization vector so PBE algorithms that use AES need a mechanism to supply an IV parameter. The latest webrev is at: http://cr.openjdk.java.net/~vinnie/6383200/webrev.04/ On 4 Sep 2012, at 18:04, Vincent Ryan wrote: > Thanks Valerie. > > I'd addressed your comments except the first one. > > Since RC4 is a stream cipher and RC2 is a block cipher they are handled > slightly differently. It would be possible to re-factor this code to > simplify it but I'd like to leave that for later as I'm under pressure > to meet the next promotion date. > > The latest webrev is at: > http://cr.openjdk.java.net/~vinnie/6383200/webrev.03/ > > > > On 08/31/12 03:05 AM, Valerie (Yu-Ching) Peng wrote: >> Vinnie, >> >> >> 1. Is it possible to replace the CipherCore object w/ CipherSpi object >> so to maximize the code re-use? The new code uses CipherSpi object for >> RC4 and CipherCore for RC2. Perhaps by using CipherSpi for both RC4 and >> RC2, we can have less code which would be easier to maintain... >> >> >> 1. line 57, change the initial set size to 17 from 4? >> >> >> 1. the impls of the two following engineInit() methods are inconsistent, >> i.e. >> engineInit(int, Key, AlgorithmParameterSpec, SecureRandom) - expects >> IvParameterSpec >> engineInit(int, Key, AlgorithmParameters, SecureRandom) - expects >> objects created from PBEParameterSpec >> 2. The impl of engineGetParameters() currently returns objects created >> from PBEParameterSpec. It should return whatever is expected in the >> engineInit(...) calls, I'd think. >> >> Will send you the rest of comments later, >> Valerie >> >> On 08/29/12 08:20, Vincent Ryan wrote: >>> On 06/ 1/12 07:18 PM, Vincent Ryan wrote: >>>> Hello Valerie, >>>> >>>> Could you please review these changes for JEP-121: >>>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.00/ >>>> >>>> Thanks. >>>> >>> >>> The latest webrev is now available at: >>> >>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.02/ >>> >>> I've incorporated review comments and made some fixes >>> to the implementation of AES-based PBE algorithms. >>> >>> Thanks. >> > From sean.mullan at oracle.com Thu Oct 4 03:57:54 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 04 Oct 2012 06:57:54 -0400 Subject: 7194449: String resources for Key Tool and Policy Tool should be in their respective packages In-Reply-To: <506D4D03.9010401@oracle.com> References: <505BC7BD.6090501@oracle.com> <505C419F.1040807@oracle.com> <506A582A.5030209@oracle.com> <506AC2D6.10707@oracle.com> <506D0633.8010009@oracle.com> <506D4D03.9010401@oracle.com> Message-ID: <506D6BB2.4010709@oracle.com> On 10/4/12 4:46 AM, Alan Bateman wrote: > On 04/10/2012 04:44, Stephen Flores wrote: >> : >> >> Alan, >> >> I re-factored line 133 to use the try-with-resources construct. >> >> I updated the webrev in place. >> >> Steve. > Thanks. > > Sean - are you going to sponsor this and help Steve get this into jdk8/tl? Yes, though I'm still way behind from vacation and have not yet reviewed this. I will do that in the next day or so. Thanks, Sean From vincent.x.ryan at oracle.com Thu Oct 4 03:58:02 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 04 Oct 2012 10:58:02 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20121004105931.35A3A4719A@hg.openjdk.java.net> Changeset: 344f0acff085 Author: vinnie Date: 2012-02-14 11:18 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/344f0acff085 7133495: [macosx] KeyChain KeyStore implementation retrieves only one private key entry Reviewed-by: weijun ! src/macosx/native/apple/security/KeystoreImpl.m + test/sun/security/tools/keytool/ListKeychainStore.sh Changeset: 77af5b4ae4f0 Author: vinnie Date: 2012-10-04 11:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77af5b4ae4f0 Merge From maurizio.cimadamore at oracle.com Thu Oct 4 05:27:29 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 04 Oct 2012 12:27:29 +0000 Subject: hg: jdk8/tl/langtools: 7177387: Add target-typing support in method context Message-ID: <20121004122734.6397E4719D@hg.openjdk.java.net> Changeset: 1408af4cd8b0 Author: mcimadamore Date: 2012-10-04 13:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1408af4cd8b0 7177387: Add target-typing support in method context Summary: Add support for deferred types and speculative attribution Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/conditional/Conditional.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/IncompatibleTypesInConditional.java + test/tools/javac/diags/examples/TypeConditional.java From naoto.sato at oracle.com Thu Oct 4 10:06:07 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 04 Oct 2012 17:06:07 +0000 Subject: hg: jdk8/tl/jdk: 7196799: CLDR adapter can not be invoked when region code is specified in Locale; ... Message-ID: <20121004170630.E257C471A8@hg.openjdk.java.net> Changeset: c6a0b13e6efa Author: naoto Date: 2012-10-04 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6a0b13e6efa 7196799: CLDR adapter can not be invoked when region code is specified in Locale 7197573: java/util/Locale/LocaleProviders.sh failed. Reviewed-by: okutsu ! make/java/java/FILES_java.gmk ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java + src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh From rob.mckenna at oracle.com Thu Oct 4 11:50:24 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Thu, 04 Oct 2012 18:50:24 +0000 Subject: hg: jdk8/tl/jdk: 7184932: Remove the temporary Selector usage in the NIO socket adapters Message-ID: <20121004185045.DA1DF471A9@hg.openjdk.java.net> Changeset: bba370caafad Author: robm Date: 2012-10-04 19:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bba370caafad 7184932: Remove the temporary Selector usage in the NIO socket adapters Reviewed-by: alanb ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/solaris/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/Net.c + test/java/nio/channels/etc/AdaptorCloseAndInterrupt.java From naoto.sato at oracle.com Thu Oct 4 21:05:39 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 05 Oct 2012 04:05:39 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20121005040612.79C33471BE@hg.openjdk.java.net> Changeset: cd4f181eb666 Author: naoto Date: 2012-10-04 21:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd4f181eb666 7200119: Collator.getAvailableLocales() doesn't return Locale.US Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java + test/java/text/Collator/Bug7200119.java Changeset: 647424d6cf65 Author: naoto Date: 2012-10-04 21:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/647424d6cf65 Merge From sean.mullan at oracle.com Fri Oct 5 06:37:53 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 05 Oct 2012 09:37:53 -0400 Subject: Code review request: 7201053: Krb5LoginModule shows NPE when both useTicketCache and storeKey are set to true In-Reply-To: <506284FC.9080209@oracle.com> References: <32842021.1348630850674.JavaMail.sbladm@swsblss4-new.central.sun.com> <506284FC.9080209@oracle.com> Message-ID: <506EE2B1.3080900@oracle.com> On 9/26/12 12:30 AM, Weijun Wang wrote: > Hi All > > Please take a look at > > http://cr.openjdk.java.net/~weijun/7201053/webrev.00/ Looks fine to me. --Sean > > In fact, even without this code change, LoginContext would wrap the NPE > inside a LoginException so no real harm will be made. However, it's > always nice to check for null before reference a variable, and an NPE > (no matter as a cause or in the message) is not user friendly. > > Thanks > Max > > > -------- Original Message -------- > 7201053: Krb5LoginModule shows NPE when both useTicketCache and storeKey > are set to true > > === *Description* > ============================================================ > useTicketCache normally used in the intiator side, and storeKey on the > acceptor side. When both are set to true, and a valid TGT is found > inside the cache, no password or keytab will be required, and therefore > no key to store. > > This combination is useless and should have been set to illegal. > However, some customers simply set a lot of arguments to true and this > will actually work if password or key is used. We don't want to break > their programs. > > For this case, when there is no key but storeKey is true, a proper > LoginException should be thrown. This is also consistent with the JDK 6 > behavior. > From maurizio.cimadamore at oracle.com Fri Oct 5 06:50:10 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 05 Oct 2012 13:50:10 +0000 Subject: hg: jdk8/tl/langtools: 7177385: Add attribution support for lambda expressions Message-ID: <20121005135014.E3F20471C9@hg.openjdk.java.net> Changeset: 573ceb23beeb Author: mcimadamore Date: 2012-10-05 14:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/573ceb23beeb 7177385: Add attribution support for lambda expressions Summary: Add support for function descriptor lookup, functional interface inference and lambda expression type-checking Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/6402516/TestLocalElements.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java + test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java + test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java ! test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/CyclicInference.java + test/tools/javac/diags/examples/IncompatibleAbstracts.java + test/tools/javac/diags/examples/IncompatibleArgTypesInLambda.java + test/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java + test/tools/javac/diags/examples/IncompatibleRetTypeInLambda.java + test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java + test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/MissingReturnValueFragment.java + test/tools/javac/diags/examples/NoAbstracts.java + test/tools/javac/diags/examples/NoSuitableFunctionalIntfInst.java + test/tools/javac/diags/examples/NotAFunctionalIntf.java + test/tools/javac/diags/examples/PotentialLambdaFound.java - test/tools/javac/diags/examples/TypeConditional.java + test/tools/javac/diags/examples/UnexpectedLambda.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.out From alan.bateman at oracle.com Fri Oct 5 07:08:04 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 05 Oct 2012 14:08:04 +0000 Subject: hg: jdk8/tl/corba: 7195779: javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently, NPE in tie class Message-ID: <20121005140804.E6F84471CA@hg.openjdk.java.net> Changeset: 27d87f0031bf Author: alanb Date: 2012-10-05 15:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/27d87f0031bf 7195779: javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently, NPE in tie class Reviewed-by: alanb, coffeys Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java From naoto.sato at oracle.com Fri Oct 5 10:00:31 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 05 Oct 2012 17:00:31 +0000 Subject: hg: jdk8/tl/jdk: 7198834: HOST Adapter: one extra empty space in the end of the pattern string Message-ID: <20121005170052.C74A1471D1@hg.openjdk.java.net> Changeset: 88a726a5b2dc Author: naoto Date: 2012-10-05 09:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88a726a5b2dc 7198834: HOST Adapter: one extra empty space in the end of the pattern string Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh From sean.mullan at oracle.com Fri Oct 5 13:48:46 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 05 Oct 2012 16:48:46 -0400 Subject: 7194449: String resources for Key Tool and Policy Tool should be in their respective packages In-Reply-To: <505BC7BD.6090501@oracle.com> References: <505BC7BD.6090501@oracle.com> Message-ID: <506F47AE.3040909@oracle.com> Hi Steve, I've reviewed this and it looks good. One small nit is to add the @Override annotation to the getContents() method of all of the Resources* classes. Send me the latest patch when you are ready and I will push it for you. --Sean On 9/20/12 9:49 PM, Stephen Flores wrote: > Max, Sean, Alan, > > Please review this webrev: > > http://cr.openjdk.java.net/~sflores/7194449/webrev-0/ > > Note: I will respond to any comments when I get back from vacation on > Monday Oct. 1. > > Changes: > > Moved jarsigner and keytool into their own packages as was done > for policytool. Unit tests and release.gmk were updated. > > Static methods in keytool called by jarsigner were moved to > sun.security.tools.KeyStoreUtil. > > Spit out the String resources for keytool and policytool from > sun.security.util.Resources into their respective packages. > > Sean, > > If everything is OK, can you commit the changes? > > Thanks, > > Steve. > From bhavesh.x.patel at oracle.com Fri Oct 5 14:22:00 2012 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Fri, 05 Oct 2012 21:22:00 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20121005212208.3DF32471D7@hg.openjdk.java.net> Changeset: d604fd09480b Author: bpatel Date: 2012-10-05 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d604fd09480b 7132631: The help-doc.html generates an invalid link to constant-values.html Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties + test/com/sun/javadoc/testHelpFile/TestHelpFile.java Changeset: ef88ae455c88 Author: bpatel Date: 2012-10-05 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ef88ae455c88 7068595: html files in class-use dir do not get loaded correctly when Frames link is clicked Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java Changeset: f4e45397722a Author: bpatel Date: 2012-10-05 14:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f4e45397722a 4696488: javadoc doesn't handle UNC paths for destination directory Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + test/tools/javadoc/T4696488.java From stephen.flores at oracle.com Fri Oct 5 19:25:25 2012 From: stephen.flores at oracle.com (Stephen Flores) Date: Fri, 05 Oct 2012 22:25:25 -0400 Subject: 7194449: String resources for Key Tool and Policy Tool should be in their respective packages In-Reply-To: <506F47AE.3040909@oracle.com> References: <505BC7BD.6090501@oracle.com> <506F47AE.3040909@oracle.com> Message-ID: <506F9695.4050600@oracle.com> Sean, I updated the webrev in place, it should have the patch, if not I will send you what you need. Steve. On 10/05/2012 04:48 PM, Sean Mullan wrote: > Hi Steve, > > I've reviewed this and it looks good. One small nit is to add the @Override > annotation to the getContents() method of all of the Resources* classes. > > Send me the latest patch when you are ready and I will push it for you. > > --Sean > > > On 9/20/12 9:49 PM, Stephen Flores wrote: >> Max, Sean, Alan, >> >> Please review this webrev: >> >> http://cr.openjdk.java.net/~sflores/7194449/webrev-0/ >> >> Note: I will respond to any comments when I get back from vacation on >> Monday Oct. 1. >> >> Changes: >> >> Moved jarsigner and keytool into their own packages as was done >> for policytool. Unit tests and release.gmk were updated. >> >> Static methods in keytool called by jarsigner were moved to >> sun.security.tools.KeyStoreUtil. >> >> Spit out the String resources for keytool and policytool from >> sun.security.util.Resources into their respective packages. >> >> Sean, >> >> If everything is OK, can you commit the changes? >> >> Thanks, >> >> Steve. >> From maurizio.cimadamore at oracle.com Sat Oct 6 02:51:30 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sat, 06 Oct 2012 09:51:30 +0000 Subject: hg: jdk8/tl/langtools: 7177386: Add attribution support for method references Message-ID: <20121006095137.CD840471E8@hg.openjdk.java.net> Changeset: d4b3cb1ece84 Author: mcimadamore Date: 2012-10-06 10:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d4b3cb1ece84 7177386: Add attribution support for method references Summary: Add type-checking/lookup routines for method references Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! test/tools/javac/6758789/T6758789a.out ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/T6326754.out ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/CantAccessInnerClsConstr.java + test/tools/javac/diags/examples/CantApplySymbolFragment.java + test/tools/javac/diags/examples/CantApplySymbolsFragment.java + test/tools/javac/diags/examples/CantResolveLocationArgsFragment.java + test/tools/javac/diags/examples/CantResolveLocationArgsParamsFragment.java ! test/tools/javac/diags/examples/CyclicInference.java ! test/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java ! test/tools/javac/diags/examples/InaccessibleVarargsType/InaccessibleVarargsType.java ! test/tools/javac/diags/examples/IncompatibleEqUpperBounds.java + test/tools/javac/diags/examples/IncompatibleRetTypeInMref.java + test/tools/javac/diags/examples/IncompatibleThrownTypesInMref.java ! test/tools/javac/diags/examples/InferArgsLengthMismatch.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToEq.java ! test/tools/javac/diags/examples/InferredDoNotConformToUpper.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/MethodReferencesNotSupported.java ! test/tools/javac/diags/examples/NoArgs.java + test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessFragment.java + test/tools/javac/diags/examples/RefAmbiguousFragment.java + test/tools/javac/diags/examples/UnexpectedMref.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/7034511/T7034511a.out ! test/tools/javac/generics/7034511/T7034511b.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7177306/T7177306b.out ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/quid/T6999438.out ! test/tools/javac/varargs/6313164/T6313164.out From alan.bateman at oracle.com Sat Oct 6 06:08:47 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 06 Oct 2012 13:08:47 +0000 Subject: hg: jdk8/tl/jdk: 8000354: (props) Properties.storeToXML/loadFromXML need to allow for alternative implementations Message-ID: <20121006130910.CB0FF471EB@hg.openjdk.java.net> Changeset: f65871e75fde Author: alanb Date: 2012-10-06 13:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f65871e75fde 8000354: (props) Properties.storeToXML/loadFromXML need to allow for alternative implementations Reviewed-by: mchung, forax ! make/java/java/FILES_java.gmk ! make/sun/util/Makefile ! src/share/classes/java/util/Properties.java + src/share/classes/sun/util/spi/XmlPropertiesProvider.java + src/share/classes/sun/util/xml/META-INF/services/sun.util.spi.XmlPropertiesProvider + src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java - src/share/classes/sun/util/xml/XMLUtils.java + test/java/util/Properties/CustomProvider.java + test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/MyXmlPropertiesProvider.java From weijun.wang at oracle.com Sun Oct 7 19:43:54 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 08 Oct 2012 02:43:54 +0000 Subject: hg: jdk8/tl/jdk: 7201053: Krb5LoginModule shows NPE when both useTicketCache and storeKey are set to true Message-ID: <20121008024417.12A4D471FE@hg.openjdk.java.net> Changeset: 92f3a96f3c78 Author: weijun Date: 2012-10-08 10:42 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92f3a96f3c78 7201053: Krb5LoginModule shows NPE when both useTicketCache and storeKey are set to true Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java + test/sun/security/krb5/auto/UseCacheAndStoreKey.java From bradford.wetmore at oracle.com Mon Oct 8 18:03:36 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 08 Oct 2012 18:03:36 -0700 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <5063199C.80908@oracle.com> References: <5063199C.80908@oracle.com> Message-ID: <507377E8.2090604@oracle.com> On 9/26/2012 8:05 AM, Xuelei Fan wrote: > Hi, > > Please review the implementation of JEP 114/CR 7068321, Support TLS > Server Name Indication (SNI) Extension in JSSE Server. > > JEP 114: http://openjdk.java.net/jeps/114 > BuG : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068321 > webrev : http://cr.openjdk.java.net./~xuelei/7068321/webrev.10/ Not a lot of comments since we've already done so much over the last few months. :) If you modified anything else that we hadn't talked about previously, please call it out. I didn't do a complete line/line review, just looking at the main points and previous comments. javax/net/ssl/SSLSocket.java javax/net/ssl/SSLEngine.java javax/net/ssl/SSLServerSocket.java ================================== (Xuelei and I have been having internal discussions about how to rework some of the lengthy verbage currently in the SSLParameters class, so this comment builds on that discussion.) I just noticed three classes missing from the webrev. We are updating the SSLParameters class with two new data structures (Host names/Matchers), but the actual discussion of what happens to the underlying SSLSockets/SSLEngines/SSLServerSocket is missing. Note we did that for the other values like protocols/cipherSuites. Rather than the current discussion in SSLParameters about "previously configured/default", I would like to suggest we follow the simple discussion already in the javadocs, and it can shorten the verbiage in SSLParameters very significantly! Even though we don't have equivalent methods (setEnabledHostNames()) in SSLSocket/SSLEngine/SSLServer, we should still talk about what happens when called: Add: This means: o ...deleted... o if params.getServerNames() is non-null, the socket will configure its server names with that value. o if params.getSNIMatchers() is non-null, the socket will configure its SNI matchers with that value. This places the behavior explanation better where it should be, and not in the configuration discussion. Now in the SSLParameters we simply talk about the effects these methods have on the SSLParameters class and what the values represent. We already have the link to SSLSocket/SSLServerSocket/SSLEngine.setSSLParameters(). So... setServerNames() remains as is. setSNIHostNames() remains as is. getServerNames(): ================= 316: Add to the constructor ", or null if none has been set." 321-326: We can leave this discussion if desired, I think it sets up the discussion for 327-341 well. I might suggest reordering the points slightly: * It is recommended that providers initialize default Server Name * Indications when creating * SSLSocket/SSLEngines. In the following * examples, the server name could be represented by an instance of * {@link SNIHostName} which has been initialized with the hostname * "www.example.com" and type {@link StandardConstants#SNI_HOST_NAME}. * *
    *     Socket socket =
    *         sslSocketFactory.createSocket("www.example.com", 443);
    * 
* or *
    *     SSLEngine engine =
    *         sslContext.createSSLEngine("www.example.com", 443);
    * 
*

342-367: Remove these lines. All the necessary info is in the setSSLParameters methods. getSNIHostNames(): ================== 435: Add to the constructor ", or null if none has been set." 440-471: Remove these lines. Nice and clean. All the discussion about default/current goes away. javax/net/ssl/SNIHostName.java ============================== 52: Do you want to remind folks here that this class is supposed to be immutable? 64: Not sure if caching this hash value will actually add much to performance vs. volatile adds overhead. There will only a few of these (likely 1). 85-86: Should these fragments be separated "," instead of "." as you did below in 143-149. You probably need an "or" before the last item. 147: You probably need an "or" before the last item. javax/net/ssl/SNIMatcher.java ============================= 32: Do you want to spell out Server Name Indication before you use the abbreviation? Or link to RFC 6066? Just a thought, not strictly necessary. 105: Empty line at end of file. javax/net/ssl/SNIServerName.java ================================ 56: Same comment about hashCode/volatile. 136: Might want to add a

between sentences. javax/net/ssl/StandardConstants.java ==================================== OK javax/net/ssl/ExtendedSSLSession.java ===================================== OK javax/net/ssl/SSLParameters.java ================================ See above. No other comments. javax/net/ssl/SSLSocketFactory.java =================================== Ok. So that you can update and submit to CCC, I'll stop here, but the implementation review will be continued in next email. Hope this helps, Brad From sean.coffey at oracle.com Tue Oct 9 04:47:42 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 09 Oct 2012 11:47:42 +0000 Subject: hg: jdk8/tl/jdk: 7196533: TimeZone.getDefault() slow due to synchronization bottleneck Message-ID: <20121009114834.DBD304723C@hg.openjdk.java.net> Changeset: fecba6a8b78e Author: coffeys Date: 2012-10-09 12:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fecba6a8b78e 7196533: TimeZone.getDefault() slow due to synchronization bottleneck Reviewed-by: okutsu ! src/share/classes/java/util/TimeZone.java From alan.bateman at oracle.com Tue Oct 9 05:25:59 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 09 Oct 2012 12:25:59 +0000 Subject: hg: jdk8/tl: 7173494: some jdk tests are not run in test/Makefile Message-ID: <20121009122559.9D6B747240@hg.openjdk.java.net> Changeset: 4bde5640fb36 Author: alanb Date: 2012-10-09 13:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4bde5640fb36 7173494: some jdk tests are not run in test/Makefile Reviewed-by: chegar, mchung, mduigou, iris ! make/jprt.properties ! test/Makefile From alan.bateman at oracle.com Tue Oct 9 05:28:29 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 09 Oct 2012 12:28:29 +0000 Subject: hg: jdk8/tl/jdk: 7173494: some jdk tests are not run in test/Makefile Message-ID: <20121009122913.280C647241@hg.openjdk.java.net> Changeset: 3b79177ebfef Author: alanb Date: 2012-10-09 13:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b79177ebfef 7173494: some jdk tests are not run in test/Makefile Reviewed-by: chegar, mchung, mduigou, iris ! make/jprt.properties ! test/Makefile ! test/ProblemList.txt From lance.andersen at oracle.com Tue Oct 9 05:58:59 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Tue, 09 Oct 2012 12:58:59 +0000 Subject: hg: jdk8/tl/jdk: 7197395: Add @Deprecated to all deprecated methods to eliminate compiler warnings in JDBC Message-ID: <20121009125922.A5D8F47243@hg.openjdk.java.net> Changeset: 036c55976cef Author: lancea Date: 2012-10-09 08:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/036c55976cef 7197395: Add @Deprecated to all deprecated methods to eliminate compiler warnings in JDBC Reviewed-by: alanb, smarks ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java From vincent.x.ryan at oracle.com Tue Oct 9 08:51:55 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 9 Oct 2012 16:51:55 +0100 Subject: Transitioning the default keystore format to PKCS#12 Message-ID: <66A79E9E-3834-4B47-BBC9-18927D6EE8EB@oracle.com> We have a long-standing requirement to improve, or migrate from, the default JKS keystore format. JEP-166[1] plans to address this requirement by delivering the functionality necessary to transition to using PKCS#12 as the default keystore format. I'd like to solicit comments from the community on this issue. Both the old and new keystore formats must be supported in a compatible way for existing applications. As a first step I intend to modify the JKS and PKCS12 implementation classes to support both formats (by switching on the JKS magic number). Further steps will include enhancing the PKCS12 implementation to add support for storing secret keys (and passwords) and trusted certificates. In addition, the new PBE algorithms delivered by JEP-121[2,3] can also be employed for improved security. Although we are already at Milestone 5 I would like to examine two further areas as part of this JEP: permission-based access controls and virtual keystore views. Comments are welcome. Thanks. ____ [1] http://openjdk.java.net/jeps/166 [2] http://openjdk.java.net/jeps/121 [3] http://cr.openjdk.java.net/~vinnie/6383200/webrev.04/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20121009/29004a77/attachment.html From xuelei.fan at oracle.com Tue Oct 9 08:56:34 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 09 Oct 2012 23:56:34 +0800 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <507377E8.2090604@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> Message-ID: <50744932.3060701@oracle.com> Thanks for the comments. The new comments for SSLEngine/SSLSocket/SSLServerSocket do make the spec much more simple and clear. BTW, I removed the restriction on SSLSocketFactory.createSocket(), the socket parameter can be an instance of SSLSocket. The spec review is closed. Please file new bugs if you have other concerns. Thanks, Xuelei On 10/9/2012 9:03 AM, Brad Wetmore wrote: > > On 9/26/2012 8:05 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the implementation of JEP 114/CR 7068321, Support TLS >> Server Name Indication (SNI) Extension in JSSE Server. >> >> JEP 114: http://openjdk.java.net/jeps/114 >> BuG : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068321 >> webrev : http://cr.openjdk.java.net./~xuelei/7068321/webrev.10/ > > Not a lot of comments since we've already done so much over the last few > months. :) > > If you modified anything else that we hadn't talked about previously, > please call it out. I didn't do a complete line/line review, just > looking at the main points and previous comments. > > > javax/net/ssl/SSLSocket.java > javax/net/ssl/SSLEngine.java > javax/net/ssl/SSLServerSocket.java > ================================== > (Xuelei and I have been having internal discussions about how to rework > some of the lengthy verbage currently in the SSLParameters class, so > this comment builds on that discussion.) > > I just noticed three classes missing from the webrev. We are updating > the SSLParameters class with two new data structures (Host > names/Matchers), but the actual discussion of what happens to the > underlying SSLSockets/SSLEngines/SSLServerSocket is missing. Note we > did that for the other values like protocols/cipherSuites. > > Rather than the current discussion in SSLParameters about "previously > configured/default", I would like to suggest we follow the simple > discussion already in the javadocs, and it can shorten the verbiage in > SSLParameters very significantly! Even though we don't have equivalent > methods (setEnabledHostNames()) in SSLSocket/SSLEngine/SSLServer, we > should still talk about what happens when called: > > Add: > > This means: > > o ...deleted... > o if params.getServerNames() is non-null, the socket will configure > its server names with that value. > o if params.getSNIMatchers() is non-null, the socket will configure > its SNI matchers with that value. > > This places the behavior explanation better where it should be, and not > in the configuration discussion. > > Now in the SSLParameters we simply talk about the effects these methods > have on the SSLParameters class and what the values represent. We > already have the link to > SSLSocket/SSLServerSocket/SSLEngine.setSSLParameters(). So... > > setServerNames() remains as is. > setSNIHostNames() remains as is. > > getServerNames(): > ================= > 316: Add to the constructor > ", or null if none has been set." > > 321-326: We can leave this discussion if desired, I think it sets up > the discussion for 327-341 well. I might suggest reordering the points > slightly: > > * It is recommended that providers initialize default Server Name > * Indications when creating > * SSLSocket/SSLEngines. In the following > * examples, the server name could be represented by an instance of > * {@link SNIHostName} which has been initialized with the hostname > * "www.example.com" and type {@link StandardConstants#SNI_HOST_NAME}. > * > *

>    *     Socket socket =
>    *         sslSocketFactory.createSocket("www.example.com", 443);
>    * 
> * or > *
>    *     SSLEngine engine =
>    *         sslContext.createSSLEngine("www.example.com", 443);
>    * 
> *

> > 342-367: Remove these lines. All the necessary info is in the > setSSLParameters methods. > > getSNIHostNames(): > ================== > 435: Add to the constructor > ", or null if none has been set." > > 440-471: Remove these lines. > > Nice and clean. All the discussion about default/current goes away. > > javax/net/ssl/SNIHostName.java > ============================== > 52: Do you want to remind folks here that this class is supposed to be > immutable? > > 64: Not sure if caching this hash value will actually add much to > performance vs. volatile adds overhead. There will only a few of these > (likely 1). > > 85-86: Should these fragments be separated "," instead of "." as you > did below in 143-149. You probably need an "or" before the last item. > > 147: You probably need an "or" before the last item. > > javax/net/ssl/SNIMatcher.java > ============================= > 32: Do you want to spell out Server Name Indication before you use the > abbreviation? Or link to RFC 6066? Just a thought, not strictly > necessary. > > 105: Empty line at end of file. > > javax/net/ssl/SNIServerName.java > ================================ > 56: Same comment about hashCode/volatile. > > 136: Might want to add a

between sentences. > > javax/net/ssl/StandardConstants.java > ==================================== > OK > > javax/net/ssl/ExtendedSSLSession.java > ===================================== > OK > > javax/net/ssl/SSLParameters.java > ================================ > See above. No other comments. > > javax/net/ssl/SSLSocketFactory.java > =================================== > Ok. > > > So that you can update and submit to CCC, I'll stop here, but the > implementation review will be continued in next email. > > Hope this helps, > > Brad From xuelei.fan at oracle.com Tue Oct 9 09:02:30 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 10 Oct 2012 00:02:30 +0800 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <50744932.3060701@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> Message-ID: <50744A96.60803@oracle.com> The new webrev with the updated spec and implementation: http://cr.openjdk.java.net./~xuelei/7068321/webrev.12/ Xuelei On 10/9/2012 11:56 PM, Xuelei Fan wrote: > Thanks for the comments. The new comments for > SSLEngine/SSLSocket/SSLServerSocket do make the spec much more simple > and clear. > > BTW, I removed the restriction on SSLSocketFactory.createSocket(), the > socket parameter can be an instance of SSLSocket. > > The spec review is closed. Please file new bugs if you have other concerns. > > Thanks, > Xuelei > > On 10/9/2012 9:03 AM, Brad Wetmore wrote: >> >> On 9/26/2012 8:05 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the implementation of JEP 114/CR 7068321, Support TLS >>> Server Name Indication (SNI) Extension in JSSE Server. >>> >>> JEP 114: http://openjdk.java.net/jeps/114 >>> BuG : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068321 >>> webrev : http://cr.openjdk.java.net./~xuelei/7068321/webrev.10/ >> >> Not a lot of comments since we've already done so much over the last few >> months. :) >> >> If you modified anything else that we hadn't talked about previously, >> please call it out. I didn't do a complete line/line review, just >> looking at the main points and previous comments. >> >> >> javax/net/ssl/SSLSocket.java >> javax/net/ssl/SSLEngine.java >> javax/net/ssl/SSLServerSocket.java >> ================================== >> (Xuelei and I have been having internal discussions about how to rework >> some of the lengthy verbage currently in the SSLParameters class, so >> this comment builds on that discussion.) >> >> I just noticed three classes missing from the webrev. We are updating >> the SSLParameters class with two new data structures (Host >> names/Matchers), but the actual discussion of what happens to the >> underlying SSLSockets/SSLEngines/SSLServerSocket is missing. Note we >> did that for the other values like protocols/cipherSuites. >> >> Rather than the current discussion in SSLParameters about "previously >> configured/default", I would like to suggest we follow the simple >> discussion already in the javadocs, and it can shorten the verbiage in >> SSLParameters very significantly! Even though we don't have equivalent >> methods (setEnabledHostNames()) in SSLSocket/SSLEngine/SSLServer, we >> should still talk about what happens when called: >> >> Add: >> >> This means: >> >> o ...deleted... >> o if params.getServerNames() is non-null, the socket will configure >> its server names with that value. >> o if params.getSNIMatchers() is non-null, the socket will configure >> its SNI matchers with that value. >> >> This places the behavior explanation better where it should be, and not >> in the configuration discussion. >> >> Now in the SSLParameters we simply talk about the effects these methods >> have on the SSLParameters class and what the values represent. We >> already have the link to >> SSLSocket/SSLServerSocket/SSLEngine.setSSLParameters(). So... >> >> setServerNames() remains as is. >> setSNIHostNames() remains as is. >> >> getServerNames(): >> ================= >> 316: Add to the constructor >> ", or null if none has been set." >> >> 321-326: We can leave this discussion if desired, I think it sets up >> the discussion for 327-341 well. I might suggest reordering the points >> slightly: >> >> * It is recommended that providers initialize default Server Name >> * Indications when creating >> * SSLSocket/SSLEngines. In the following >> * examples, the server name could be represented by an instance of >> * {@link SNIHostName} which has been initialized with the hostname >> * "www.example.com" and type {@link StandardConstants#SNI_HOST_NAME}. >> * >> *

>>    *     Socket socket =
>>    *         sslSocketFactory.createSocket("www.example.com", 443);
>>    * 
>> * or >> *
>>    *     SSLEngine engine =
>>    *         sslContext.createSSLEngine("www.example.com", 443);
>>    * 
>> *

>> >> 342-367: Remove these lines. All the necessary info is in the >> setSSLParameters methods. >> >> getSNIHostNames(): >> ================== >> 435: Add to the constructor >> ", or null if none has been set." >> >> 440-471: Remove these lines. >> >> Nice and clean. All the discussion about default/current goes away. >> >> javax/net/ssl/SNIHostName.java >> ============================== >> 52: Do you want to remind folks here that this class is supposed to be >> immutable? >> >> 64: Not sure if caching this hash value will actually add much to >> performance vs. volatile adds overhead. There will only a few of these >> (likely 1). >> >> 85-86: Should these fragments be separated "," instead of "." as you >> did below in 143-149. You probably need an "or" before the last item. >> >> 147: You probably need an "or" before the last item. >> >> javax/net/ssl/SNIMatcher.java >> ============================= >> 32: Do you want to spell out Server Name Indication before you use the >> abbreviation? Or link to RFC 6066? Just a thought, not strictly >> necessary. >> >> 105: Empty line at end of file. >> >> javax/net/ssl/SNIServerName.java >> ================================ >> 56: Same comment about hashCode/volatile. >> >> 136: Might want to add a

between sentences. >> >> javax/net/ssl/StandardConstants.java >> ==================================== >> OK >> >> javax/net/ssl/ExtendedSSLSession.java >> ===================================== >> OK >> >> javax/net/ssl/SSLParameters.java >> ================================ >> See above. No other comments. >> >> javax/net/ssl/SSLSocketFactory.java >> =================================== >> Ok. >> >> >> So that you can update and submit to CCC, I'll stop here, but the >> implementation review will be continued in next email. >> >> Hope this helps, >> >> Brad > From naoto.sato at oracle.com Tue Oct 9 10:00:26 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 09 Oct 2012 17:00:26 +0000 Subject: hg: jdk8/tl/jdk: 7200341: DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some circumstances Message-ID: <20121009170052.2CF4E4724F@hg.openjdk.java.net> Changeset: c725ce4bbf12 Author: naoto Date: 2012-10-09 09:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c725ce4bbf12 7200341: DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some circumstances Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java From sean.coffey at oracle.com Tue Oct 9 11:42:20 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 09 Oct 2012 18:42:20 +0000 Subject: hg: jdk8/tl/jdk: 7181793: Socket getOutputStream create streams that cannot be GC'ed until Socket is closed Message-ID: <20121009184322.5A95047253@hg.openjdk.java.net> Changeset: 71de5e31d497 Author: coffeys Date: 2012-10-09 19:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71de5e31d497 7181793: Socket getOutputStream create streams that cannot be GC'ed until Socket is closed Reviewed-by: alanb, chegar ! src/share/classes/java/net/AbstractPlainSocketImpl.java + test/java/net/Socket/SocketGrowth.java From sean.coffey at oracle.com Tue Oct 9 12:16:07 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 09 Oct 2012 19:16:07 +0000 Subject: hg: jdk8/tl/corba: 7196086: update copyright years for files in corba repository (JDK 8) Message-ID: <20121009191609.7C1CC47254@hg.openjdk.java.net> Changeset: 679e8ad9874f Author: coffeys Date: 2012-10-09 20:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/679e8ad9874f 7196086: update copyright years for files in corba repository (JDK 8) Reviewed-by: lancea ! make/common/Defs-bsd.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Defs-bsd.gmk ! make/common/shared/Defs-utils.gmk ! make/tools/src/build/tools/stripproperties/StripPropertiesCorba.java ! make/tools/strip_properties/Makefile From huizhe.wang at oracle.com Tue Oct 9 14:17:05 2012 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 09 Oct 2012 21:17:05 +0000 Subject: hg: jdk8/tl/jaxp: 8000172: 2 SAX features does not work properly Message-ID: <20121009211710.B3FEB47258@hg.openjdk.java.net> Changeset: 53a2a4893c8f Author: joehw Date: 2012-10-09 14:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/53a2a4893c8f 8000172: 2 SAX features does not work properly Summary: When external dtd is not loaded, skippedEntity event should be reported for entity references. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java From bradford.wetmore at oracle.com Tue Oct 9 17:33:31 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 09 Oct 2012 17:33:31 -0700 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <50744932.3060701@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> Message-ID: <5074C25B.3040703@oracle.com> Hi again, On 10/9/2012 8:56 AM, Xuelei Fan wrote: > Thanks for the comments. The new comments for > SSLEngine/SSLSocket/SSLServerSocket do make the spec much more simple > and clear. Thanks, that looks so much cleaner, and I think developers will appreciate it. > BTW, I removed the restriction on SSLSocketFactory.createSocket(), the > socket parameter can be an instance of SSLSocket. > > The spec review is closed. Please file new bugs if you have other concerns. Very minor comments in the API which don't need CCC modification. javax/net/ssl/SNIHostName.java ============================== Changes look good. Didn't review everything. javax/net/ssl/SNIMatcher.java ============================= Changes look good. Didn't review everything. javax/net/ssl/SNIServerName.java ================================ Changes look good. Didn't review everything. javax/net/ssl/StandardConstants.java ==================================== Didn't review. javax/net/ssl/ExtendedSSLSession.java ===================================== Didn't review. javax/net/ssl/SSLParameters.java ================================ 60: Wow, good catch! 314: Looks great, thanks! javax/net/ssl/SSLSocketFactory.java =================================== Change look good. 216: I think you need a period at end of sentence here. 231: Might suggest some reason text for the UnsupportedOperationException. javax/net/ssl/SSLEngine.java ============================ Minor nit: Copyright. 1218/1220/1225: You are not closing the

  • properly, I think you are effectively adding another empty bullet. 1227: Copy/paste error. You said socket, but probably meant engine. :) javax/net/ssl/SSLServerSocket.java ================================== Minor nit: Copyright. 488/490/495: You are not closing the
  • properly. 499: Similar comment to above. You could say server socket or leave as is, since it is a kind of a socket. javax/net/ssl/SSLSocket.java ============================ Minor nit: Copyright. sun/security/ssl/Utilities.java =============================== 46: Minor comment on method name, you might want to use "addToSNIServerNameList" since you are adding. 84: Just wondering why you added this method here? This added a bit of overhead in extra methods calls (well, maybe not with hotspot unrolling) and added a few chars to the source. So given that you have added this, why not update the remainder also? EngineOutputRecord/InputRecord/OutputRecord. See the below comment in SSLSocketImpl.java. If you decide to accept it, you will want to remove the unmodifiable collection. sun/security/ssl/BaseSSLSocketImpl.java ======================================= OK sun/security/ssl/ClientHandshaker.java ====================================== OK sun/security/ssl/HandshakeInStream.java ======================================= OK sun/security/ssl/HandshakeMessage.java ====================================== OK sun/security/ssl/Handshaker.java ================================ 291: The change to allow for setting of SNI information has opened up a race condition. It's probably not too bad for SSLSocket, but might be more for SSLEngine. When we create ClientHandshaker/ServerHandshakers, we normally grab all the parameters necessary for the handshaker, and any future parameter modifications will apply to the next handshake. In the past, our SNI information would never change, so it wasn't necessary to pass it in on creation. That assumption no longer holds. So you could see something like this: sslEngine.beginHandshake(); SSLParameters sslp = new SSLParameters(); sslp.setHostnames("example.com"); sslEngine.setSSLParameters(sslp); // do handshake... and you'll get the new value instead of old. sun/security/ssl/HelloExtensions.java ===================================== 35: Are these extra imports necessary with the package import at line 31? 307: Can you add the "backwards compatibility" comment about the size? For backward compatibility, all future data structures associated with new NameTypes MUST begin with a 16-bit length field. I'll forget it otherwise. 423: This behavior is currently underspecified. Right now we have one SNI match type, but eventually we might have more. Your current impl requires that *ALL* SNI matchers match. What if you have more than one, and more than one SNI hostnames are sent? SNIHostname: "example.com" SNINickName: "www.example.com" SNIMatcher: "example.com" SNINickNameMatcher: "www1.example.com Should this fail or succeed? That is, should it be an AND or an OR? Whatever you decide, please document it at least here. Not sure if you want to make the doc at the API level. 438: Minor nit: snInOther -> sniInOther? sun/security/ssl/ProtocolList.java ================================== OK sun/security/ssl/SSLEngineImpl.java =================================== 2084: See comments in SSLSocketImpl.java:2509. 2100/2107: See comments in Handshaker. sun/security/ssl/SSLServerSocketImpl.java ========================================= OK sun/security/ssl/SSLSessionImpl.java ==================================== OK sun/security/ssl/SSLSocketFactoryImpl.java ========================================== OK sun/security/ssl/SSLSocketImpl.java =================================== 561: If I'm remembering and understanding this code right: this.host = sock.getLocalAddress().getHostName(); // in server mode Don't ServerSockets generally creates Sockets with just local IP addresses (no hostnames), so this getHostname() will trigger a reverse hostname lookup? Is that right? 2509: Something to investigate: you are depending on SSLParameters returning an unmodifiable list. But a subclass might not do that. Can you think of any situations where this might be a bad idea? If so, then we might want to change the unmodifiable language in SSLParameters and do regular cloning. This will have repercussions in other areas, like around 2527/2532, where you'll need to pass a copy to the Handshaker. 2524/2541: See comments in Handshaker. sun/security/ssl/ServerHandshaker.java ====================================== OK sun/security/ssl/SunJSSE.java ============================= OK sun/security/ssl/X509KeyManagerImpl.java ======================================== 133/150: Thanks for the comment here. sun/security/ssl/X509TrustManagerImpl.java ========================================== OK Thanks, Brad From jonathan.gibbons at oracle.com Tue Oct 9 19:12:07 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 10 Oct 2012 02:12:07 +0000 Subject: hg: jdk8/tl/langtools: 8000663: clean up langtools imports Message-ID: <20121010021212.4397447267@hg.openjdk.java.net> Changeset: c75be5bc5283 Author: jjg Date: 2012-10-09 19:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c75be5bc5283 8000663: clean up langtools imports Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java ! src/share/classes/javax/annotation/processing/Completions.java ! src/share/classes/javax/annotation/processing/FilerException.java ! src/share/classes/javax/annotation/processing/ProcessingEnvironment.java ! src/share/classes/javax/lang/model/element/AnnotationValue.java ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.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/ElementFilter.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/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/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/classes/javax/tools/ForwardingJavaFileManager.java ! src/share/classes/javax/tools/JavaFileObject.java From jonathan.gibbons at oracle.com Tue Oct 9 19:32:44 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 10 Oct 2012 02:32:44 +0000 Subject: hg: jdk8/tl/langtools: 8000208: fix langtools javadoc comment issues Message-ID: <20121010023249.D14FF47268@hg.openjdk.java.net> Changeset: fc123bdeddb8 Author: jjg Date: 2012-10-09 19:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fc123bdeddb8 8000208: fix langtools javadoc comment issues Reviewed-by: bpatel, mcimadamore ! src/share/classes/com/sun/javadoc/Tag.java ! src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/nio/PathFileManager.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Position.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java ! src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java From xuelei.fan at oracle.com Wed Oct 10 05:47:56 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 10 Oct 2012 20:47:56 +0800 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <5074C25B.3040703@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> Message-ID: <50756E7C.3020601@oracle.com> new webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.13/ On 10/10/2012 8:33 AM, Brad Wetmore wrote: > Hi again, > > On 10/9/2012 8:56 AM, Xuelei Fan wrote: >> Thanks for the comments. The new comments for >> SSLEngine/SSLSocket/SSLServerSocket do make the spec much more simple >> and clear. > > Thanks, that looks so much cleaner, and I think developers will > appreciate it. > >> BTW, I removed the restriction on SSLSocketFactory.createSocket(), the >> socket parameter can be an instance of SSLSocket. >> >> The spec review is closed. Please file new bugs if you have other >> concerns. > > Very minor comments in the API which don't need CCC modification. > > javax/net/ssl/SNIHostName.java > ============================== > Changes look good. Didn't review everything. > > javax/net/ssl/SNIMatcher.java > ============================= > Changes look good. Didn't review everything. > > javax/net/ssl/SNIServerName.java > ================================ > Changes look good. Didn't review everything. > > javax/net/ssl/StandardConstants.java > ==================================== > Didn't review. > > javax/net/ssl/ExtendedSSLSession.java > ===================================== > Didn't review. > > javax/net/ssl/SSLParameters.java > ================================ > 60: Wow, good catch! > > 314: Looks great, thanks! > > javax/net/ssl/SSLSocketFactory.java > =================================== > Change look good. > > 216: I think you need a period at end of sentence here. > > 231: Might suggest some reason text for the UnsupportedOperationException. > I think the exception name has say the exception clearly. I think it does not make sense to add additional message for it. I had a search in the packages of java.lang and java.uitl, most of the codes (39 of 42) use the default non-parameter constructor of UnsupportedOperationException. I will prefer to use the current style. > > javax/net/ssl/SSLEngine.java > ============================ > Minor nit: Copyright. > > 1218/1220/1225: You are not closing the
  • properly, I think you are > effectively adding another empty bullet. > > 1227: Copy/paste error. You said socket, but probably meant engine. :) > > javax/net/ssl/SSLServerSocket.java > ================================== > Minor nit: Copyright. > > 488/490/495: You are not closing the
  • properly. > > 499: Similar comment to above. You could say server socket or leave as > is, since it is a kind of a socket. > > javax/net/ssl/SSLSocket.java > ============================ > Minor nit: Copyright. > > sun/security/ssl/Utilities.java > =============================== > 46: Minor comment on method name, you might want to use > "addToSNIServerNameList" since you are adding. > > 84: Just wondering why you added this method here? This added a bit of > overhead in extra methods calls (well, maybe not with hotspot unrolling) > and added a few chars to the source. So given that you have added this, > why not update the remainder also? > EngineOutputRecord/InputRecord/OutputRecord. > Good point! > See the below comment in SSLSocketImpl.java. If you decide to accept > it, you will want to remove the unmodifiable collection. > See the reply in SSLSocketImpl.java > sun/security/ssl/BaseSSLSocketImpl.java > ======================================= > OK > > sun/security/ssl/ClientHandshaker.java > ====================================== > OK > > sun/security/ssl/HandshakeInStream.java > ======================================= > OK > > sun/security/ssl/HandshakeMessage.java > ====================================== > OK > > sun/security/ssl/Handshaker.java > ================================ > 291: The change to allow for setting of SNI information has opened up a > race condition. It's probably not too bad for SSLSocket, but might be > more for SSLEngine. When we create ClientHandshaker/ServerHandshakers, > we normally grab all the parameters necessary for the handshaker, and > any future parameter modifications will apply to the next handshake. In > the past, our SNI information would never change, so it wasn't necessary > to pass it in on creation. That assumption no longer holds. > > So you could see something like this: > > sslEngine.beginHandshake(); > SSLParameters sslp = new SSLParameters(); > sslp.setHostnames("example.com"); > sslEngine.setSSLParameters(sslp); > // do handshake... > > and you'll get the new value instead of old. > Good catch! Updated to store the local server name indication and matchers in Handshaker. > sun/security/ssl/HelloExtensions.java > ===================================== > 35: Are these extra imports necessary with the package import at line 31? > > 307: Can you add the "backwards compatibility" comment about the size? > > For > backward compatibility, all future data structures associated with > new NameTypes MUST begin with a 16-bit length field. > > I'll forget it otherwise. > > 423: This behavior is currently underspecified. I think the behavior is specified in RFC 6066: ... If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake. As means that the server will try to recognize every type of server name. In our spec, it is required that once a SNIMatcher is defined, it will be used to recognized the server name in the SNI extension. That's to say, every server name should be recognizable if the corresponding SNIMatcher is defined. I think the current spec is clear that SNIMather is used to match a particular server name type. > Right now we have one > SNI match type, but eventually we might have more. Your current impl > requires that *ALL* SNI matchers match. What if you have more than one, > and more than one SNI hostnames are sent? > > SNIHostname: "example.com" > SNINickName: "www.example.com" > > SNIMatcher: "example.com" > SNINickNameMatcher: "www1.example.com > > Should this fail or succeed? That is, should it be an AND or an OR? > Whatever you decide, please document it at least here. Not sure if you > want to make the doc at the API level. > If it is a "OR", we need to doc the special behaviors in API level. But it is a "AND", I think the current API is clear that a defined SNIMatcher is used to match a particular server name type in SNI extension. I think the current spec is OK. I added some a block of comment to describe the behaviors in HelloExtensions. > 438: Minor nit: snInOther -> sniInOther? > > sun/security/ssl/ProtocolList.java > ================================== > OK > > sun/security/ssl/SSLEngineImpl.java > =================================== > 2084: See comments in SSLSocketImpl.java:2509. > > 2100/2107: See comments in Handshaker. > > sun/security/ssl/SSLServerSocketImpl.java > ========================================= > OK > > sun/security/ssl/SSLSessionImpl.java > ==================================== > OK > > sun/security/ssl/SSLSocketFactoryImpl.java > ========================================== > OK > > sun/security/ssl/SSLSocketImpl.java > =================================== > 561: If I'm remembering and understanding this code right: > > this.host = sock.getLocalAddress().getHostName(); // in server mode > > Don't ServerSockets generally creates Sockets with just local IP > addresses (no hostnames), so this getHostname() will trigger a reverse > hostname lookup? Is that right? > Right. It is not really necessary to set the "host" and "serverNames" variables, because in server mode the two variables are useless. I will remove the setting. > 2509: Something to investigate: you are depending on SSLParameters > returning an unmodifiable list. But a subclass might not do that. Can > you think of any situations where this might be a bad idea? If so, then > we might want to change the unmodifiable language in SSLParameters and > do regular cloning. This will have repercussions in other areas, like > around 2527/2532, where you'll need to pass a copy to the Handshaker. > Well, I understand that something bad would happen if the subclass does not follow the method spec while doing method implementation overriding. That's an interesting topic that whether a none-final method can be declared to return immutable objects, or a none-final class can be declared as immutable class. The logic behind is that, the new implemented overridden method may not follow the spec of the original spec. Here comes other questions, can we trust the method spec of a non-final method? What's the general rules to override a method? I think it would be a very interesting topic. There are also many non-final other APIs that requires to return immutable object in Java APIs. We may want to extend the discussion more widely about what's the proper solution. Let's have the spec and implementation as it is. We can update the spec and implementation if we have strong concerns or a common solution for the issue before JDK 8 officially release. > 2524/2541: See comments in Handshaker. > > sun/security/ssl/ServerHandshaker.java > ====================================== > OK > > sun/security/ssl/SunJSSE.java > ============================= > OK > > sun/security/ssl/X509KeyManagerImpl.java > ======================================== > 133/150: Thanks for the comment here. > > sun/security/ssl/X509TrustManagerImpl.java > ========================================== > OK > All of other comments are accepted. I think there is no major concerns so far. Thank you so much for the detailed evaluation and comments on both spec and implementation. TLS and its implementation is very complicated, your support is the critical success factor to deliver quality product. Thanks, Xuelei > Thanks, > > Brad > From lance.andersen at oracle.com Wed Oct 10 08:15:48 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Wed, 10 Oct 2012 15:15:48 +0000 Subject: hg: jdk8/tl/jdk: 8000687: Correct javadoc typo for getLogWriter and setLogWriter Message-ID: <20121010151624.EDA6447284@hg.openjdk.java.net> Changeset: 3c4be36de073 Author: lancea Date: 2012-10-10 11:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c4be36de073 8000687: Correct javadoc typo for getLogWriter and setLogWriter Reviewed-by: alanb ! src/share/classes/java/sql/DriverManager.java From alan.bateman at oracle.com Wed Oct 10 12:47:09 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 10 Oct 2012 19:47:09 +0000 Subject: hg: jdk8/tl/jdk: 7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeLister methods Message-ID: <20121010194731.31C134728D@hg.openjdk.java.net> Changeset: 6455182d2797 Author: alanb Date: 2012-10-10 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6455182d2797 7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeLister methods Reviewed-by: mchung, lancea, chegar ! src/share/classes/java/util/logging/LogManager.java From lance.andersen at oracle.com Wed Oct 10 14:34:43 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Wed, 10 Oct 2012 21:34:43 +0000 Subject: hg: jdk8/tl/jdk: 8000712: Remove unused fields in SyncFactory Message-ID: <20121010213505.A649847297@hg.openjdk.java.net> Changeset: 734ca9f4719c Author: lancea Date: 2012-10-10 17:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/734ca9f4719c 8000712: Remove unused fields in SyncFactory Reviewed-by: mchung ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java From bradford.wetmore at oracle.com Wed Oct 10 16:38:52 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 10 Oct 2012 16:38:52 -0700 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <50756E7C.3020601@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> Message-ID: <5076070C.5010105@oracle.com> On 10/10/2012 5:47 AM, Xuelei Fan wrote: > new webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.13/ I guess you didn't need to have me as reviewer before going final with the CCC? >> javax/net/ssl/SSLSocketFactory.java >> =================================== >> Change look good. >> >> 216: I think you need a period at end of sentence here. You got the others, but missed this one. >> 231: Might suggest some reason text for the UnsupportedOperationException. >> > I think the exception name has say the exception clearly. I think it > does not make sense to add additional message for it. I had a search in > the packages of java.lang and java.uitl, most of the codes (39 of 42) > use the default non-parameter constructor of > UnsupportedOperationException. I will prefer to use the current style. No problem. >> sun/security/ssl/Utilities.java >> =============================== >> 46: Minor comment on method name, you might want to use >> "addToSNIServerNameList" since you are adding. >> >> 84: Just wondering why you added this method here? This added a bit of >> overhead in extra methods calls (well, maybe not with hotspot unrolling) >> and added a few chars to the source. So given that you have added this, >> why not update the remainder also? >> EngineOutputRecord/InputRecord/OutputRecord. >> > Good point! Or do it the way you did. This just adds a little extra source overhead. >> See the below comment in SSLSocketImpl.java. If you decide to accept >> it, you will want to remove the unmodifiable collection. >> > See the reply in SSLSocketImpl.java Ok. >> sun/security/ssl/Handshaker.java >> ================================ >> 291: The change to allow for setting of SNI information has opened up a >> race condition. It's probably not too bad for SSLSocket, but might be >> more for SSLEngine. When we create ClientHandshaker/ServerHandshakers, >> we normally grab all the parameters necessary for the handshaker, and >> any future parameter modifications will apply to the next handshake. In >> the past, our SNI information would never change, so it wasn't necessary >> to pass it in on creation. That assumption no longer holds. >> >> So you could see something like this: >> >> sslEngine.beginHandshake(); >> SSLParameters sslp = new SSLParameters(); >> sslp.setHostnames("example.com"); >> sslEngine.setSSLParameters(sslp); >> // do handshake... >> >> and you'll get the new value instead of old. >> > Good catch! > > Updated to store the local server name indication and matchers in > Handshaker. Just a comment: 459/468: Currently you have serverNames and sniMatchers as package private variables, so the ClientHandshaker/ServerHandshaker *could* inherit these variables rather than have a separate get methods. Or you could make them private and keep the get calls. >> sun/security/ssl/HelloExtensions.java >> ===================================== >> 423: This behavior is currently underspecified. > > I think the behavior is specified in RFC 6066: > > ... If the server understood the ClientHello extension but > does not recognize the server name, the server SHOULD take one of two > actions: either abort the handshake by sending a fatal-level > unrecognized_name(112) alert or continue the handshake. > > As means that the server will try to recognize every type of server > name. I'm just not seeing why this implies that it requires *EVERY* name must match. This just says we can do one of two things upon receipt of an unrecognized hostname: continue on, or alert/close. We can be very restrictive (ALL/AND) or less so (at least one/OR), and still be within the RFC, I think. > In our spec, it is required that once a SNIMatcher is defined, it > will be used to recognized the server name in the SNI extension. Where? We do say in SNIMatcher: Servers can use Server Name Indication (SNI) information to decide if specific {@link SSLSocket} or {@link SSLEngine} instances should accept a connection. But I don't think we have ever said that it MUST match or must match all or even what the implementation must do if there is a match failure. Nor should we specify that in the API, IMHO. That's implementation behavior. > That's > to say, every server name should be recognizable if the corresponding > SNIMatcher is defined. I think the current spec is clear that SNIMather > is used to match a particular server name type. Not seeing it, sorry. After this discussion, I think we are probably better off starting with AND anyway, because it will be easier to loosen that condition than starting with OR and having to tighten to AND. If you agree, can you add a few words to that effect around 431? >> Right now we have one >> SNI match type, but eventually we might have more. Your current impl >> requires that *ALL* SNI matchers match. What if you have more than one, >> and more than one SNI hostnames are sent? >> >> SNIHostname: "example.com" >> SNINickName: "www.example.com" >> >> SNIMatcher: "example.com" >> SNINickNameMatcher: "www1.example.com >> >> Should this fail or succeed? That is, should it be an AND or an OR? >> Whatever you decide, please document it at least here. Not sure if you >> want to make the doc at the API level. >> > If it is a "OR", we need to doc the special behaviors in API level. But > it is a "AND", I think the current API is clear that a defined > SNIMatcher is used to match a particular server name type in SNI > extension. I think the current spec is OK. I think we can leave it unspecified for now, but please add a quick note here. Thanks. >> sun/security/ssl/SSLSocketImpl.java >> =================================== >> 561: If I'm remembering and understanding this code right: >> >> this.host = sock.getLocalAddress().getHostName(); // in server mode >> >> Don't ServerSockets generally creates Sockets with just local IP >> addresses (no hostnames), so this getHostname() will trigger a reverse >> hostname lookup? Is that right? >> > Right. > > It is not really necessary to set the "host" and "serverNames" > variables, because in server mode the two variables are useless. I will > remove the setting. Ok. 561: // In server mode, it is not necessary to set host and serverNames. Can you add "...and would require a reverse DNS lookup" or something similar? >> 2509: Something to investigate: you are depending on SSLParameters >> returning an unmodifiable list. But a subclass might not do that. Can >> you think of any situations where this might be a bad idea? If so, then >> we might want to change the unmodifiable language in SSLParameters and >> do regular cloning. This will have repercussions in other areas, like >> around 2527/2532, where you'll need to pass a copy to the Handshaker. >> > Well, I understand that something bad would happen if the subclass does > not follow the method spec while doing method implementation overriding. Yes, it was just something to think about. Of course, I'm trying to think of exploit situations, since you're really just hurting yourself if tweak this in the middle of a handshake. If I see Joe Darcy around, I'll check in with him. > Let's have the spec and implementation as it is. We can update the spec > and implementation if we have strong concerns or a common solution for > the issue before JDK 8 officially release. I'm fine with this. >> sun/security/ssl/X509TrustManagerImpl.java >> ========================================== >> OK >> > All of other comments are accepted. > > I think there is no major concerns so far. None still outstanding. I looked over the previous comments I've made and what you've done to address them, and all looks good minus the little points above. > Thank you so much for the > detailed evaluation and comments on both spec and implementation. TLS > and its implementation is very complicated, your support is the critical > success factor to deliver quality product. Thanks, and be sure to give yourself a lot of that credit. With all the back/forth and development this feature has seen, I think you've done a great job. Brad From jonathan.gibbons at oracle.com Wed Oct 10 16:48:58 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 10 Oct 2012 23:48:58 +0000 Subject: hg: jdk8/tl/langtools: 8000665: fix "internal API" comments on javadoc files Message-ID: <20121010234903.EFFAF472A3@hg.openjdk.java.net> Changeset: 25e14ad23cef Author: jjg Date: 2012-10-10 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/25e14ad23cef 8000665: fix "internal API" comments on javadoc files Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstructorWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/FieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/NestedClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/XMLNode.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseExecutableMemberTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseInlineTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DocRootTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritableTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/CommentedMethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TaggedMethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TextTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Main.java ! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/TagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java From jonathan.gibbons at oracle.com Wed Oct 10 18:08:56 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 11 Oct 2012 01:08:56 +0000 Subject: hg: jdk8/tl/langtools: 8000743: docencoding not available to stylesheet Message-ID: <20121011010901.292FA472A5@hg.openjdk.java.net> Changeset: 560d4a5d14e6 Author: jjg Date: 2012-10-10 18:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/560d4a5d14e6 8000743: docencoding not available to stylesheet Reviewed-by: jjg Contributed-by: jviswana at linux.vnet.ibm.com ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java + test/com/sun/javadoc/testDocEncoding/TestDocEncoding.java + test/com/sun/javadoc/testDocEncoding/pkg/Test.java From jonathan.gibbons at oracle.com Wed Oct 10 18:35:22 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 11 Oct 2012 01:35:22 +0000 Subject: hg: jdk8/tl/langtools: 8000418: javadoc should used a standard "generated by javadoc" string Message-ID: <20121011013525.E77F8472A8@hg.openjdk.java.net> Changeset: 6517bf8e50d0 Author: jjg Date: 2012-10-10 18:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6517bf8e50d0 8000418: javadoc should used a standard "generated by javadoc" string Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! test/com/sun/javadoc/VersionNumber/VersionNumber.java + test/com/sun/javadoc/testGeneratedBy/TestGeneratedBy.java + test/com/sun/javadoc/testGeneratedBy/pkg/MyClass.java From jonathan.gibbons at oracle.com Wed Oct 10 18:44:52 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 11 Oct 2012 01:44:52 +0000 Subject: hg: jdk8/tl/langtools: 8000310: Clean up use of StringBuffer in langtools Message-ID: <20121011014457.34203472A9@hg.openjdk.java.net> Changeset: c46e0c9940d6 Author: jjg Date: 2012-10-10 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c46e0c9940d6 8000310: Clean up use of StringBuffer in langtools Reviewed-by: bpatel ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/util/Convert.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Mangle.java From weijun.wang at oracle.com Wed Oct 10 18:55:40 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 11 Oct 2012 09:55:40 +0800 Subject: Code review request: 7198507: [TEST_BUG] sun/security/tools/keytool/console.sh should be rewritten In-Reply-To: <50583E3D.8020500@oracle.com> References: <5452358.1347959568853.JavaMail.sbladm@swsblss4-new.central.sun.com> <50583E3D.8020500@oracle.com> Message-ID: <5076271C.8030507@oracle.com> Ping again. Thanks Max On 09/18/2012 05:26 PM, Weijun Wang wrote: > First, I'm very glad to see that we are running manual tests. > > Then, please take a look at > > http://cr.openjdk.java.net/~weijun/7198507/webrev.00 > > Nothing is changed in the real keytool command calls, only some small > changes: > > 1. Better prompt > 2. Keystore file now /tmp/kkk.$$, clean and no conflict > 3. Exit wherever a keytool command fails > 4. Remove "export". It causes an error on Solaris > 5. Add a "k" after "read". Only this can stop the process > > Thanks > Max > > -------- Original Message -------- > 7198507: [TEST_BUG] sun/security/tools/keytool/console.sh should be > rewritten > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198507 > > === *Description* > ============================================================ > test have 2 problems: > 1. It failed on solaris platforms due incorrect shell syntax > 2. It should be interactive but one always shows "passed" status on > linux and windows while really additional variables should be set by > user before running for successful execution and user should decide > passed test or failed. There are no any messages for user when test > running under jtreg. > > > solaris log: > ----------System.out:(0/0)---------- > ----------System.err:(1/244)*---------- > /net/stt-13.ru.oracle.com/export2/stt/newroot/regression/workspaces/1.8.0/1.8.0_fcsb55/j2se/test/sun/security/tools/keytool/console.sh: > PASS=\\303\\244\\303\\266\\303\\244\\303\\266\\303\\244\\303\\266\\303\\244\\303\\266: > is not an identifier > result: Failed. Execution failed: exit code 1 > > > linux log: > ----------System.err:(22/3266)---------- > rm: cannot remove `kkk': No such file or directory > /net/stt-13.ru.oracle.com/export2/stt/newroot/regression/workspaces/1.8.0/1.8.0_fcsb55/j2se/test/sun/security/tools/keytool/console.sh: > line 66: /bin/keytool: No such file or directory > ..... From xuelei.fan at oracle.com Wed Oct 10 19:54:43 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 11 Oct 2012 10:54:43 +0800 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <5076070C.5010105@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> Message-ID: <507634F3.9060703@oracle.com> No new webrev. I need a review of how to use SNIMatcher. See bellow inline comments. On 10/11/2012 7:38 AM, Brad Wetmore wrote: > > > On 10/10/2012 5:47 AM, Xuelei Fan wrote: >> new webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.13/ > > I guess you didn't need to have me as reviewer before going final with > the CCC? > The CCC has been finalized. ;-) I though you have done with spec review. Anyway, we still can make updates on specification within new bugs. >>> javax/net/ssl/SSLSocketFactory.java >>> =================================== >>> Change look good. >>> >>> 216: I think you need a period at end of sentence here. > > You got the others, but missed this one. > I think we discussed the style sometimes ago. If the sentence does not start with a capital letter, then it does not need a period at the end of the sentence. I can see both style in other specs. Updated to add the period. >>> 231: Might suggest some reason text for the >>> UnsupportedOperationException. >>> >> I think the exception name has say the exception clearly. I think it >> does not make sense to add additional message for it. I had a search in >> the packages of java.lang and java.uitl, most of the codes (39 of 42) >> use the default non-parameter constructor of >> UnsupportedOperationException. I will prefer to use the current style. > > No problem. > >>> sun/security/ssl/Utilities.java >>> =============================== >>> 46: Minor comment on method name, you might want to use >>> "addToSNIServerNameList" since you are adding. >>> >>> 84: Just wondering why you added this method here? This added a bit of >>> overhead in extra methods calls (well, maybe not with hotspot unrolling) >>> and added a few chars to the source. So given that you have added this, >>> why not update the remainder also? >>> EngineOutputRecord/InputRecord/OutputRecord. >>> >> Good point! > > Or do it the way you did. This just adds a little extra source overhead. > >>> See the below comment in SSLSocketImpl.java. If you decide to accept >>> it, you will want to remove the unmodifiable collection. >>> >> See the reply in SSLSocketImpl.java > > Ok. > >>> sun/security/ssl/Handshaker.java >>> ================================ >>> 291: The change to allow for setting of SNI information has opened up a >>> race condition. It's probably not too bad for SSLSocket, but might be >>> more for SSLEngine. When we create ClientHandshaker/ServerHandshakers, >>> we normally grab all the parameters necessary for the handshaker, and >>> any future parameter modifications will apply to the next handshake. In >>> the past, our SNI information would never change, so it wasn't necessary >>> to pass it in on creation. That assumption no longer holds. >>> >>> So you could see something like this: >>> >>> sslEngine.beginHandshake(); >>> SSLParameters sslp = new SSLParameters(); >>> sslp.setHostnames("example.com"); >>> sslEngine.setSSLParameters(sslp); >>> // do handshake... >>> >>> and you'll get the new value instead of old. >>> >> Good catch! >> >> Updated to store the local server name indication and matchers in >> Handshaker. > > Just a comment: > > 459/468: Currently you have serverNames and sniMatchers as package > private variables, so the ClientHandshaker/ServerHandshaker *could* > inherit these variables rather than have a separate get methods. Or you > could make them private and keep the get calls. > Good catch! >>> sun/security/ssl/HelloExtensions.java >>> ===================================== >>> 423: This behavior is currently underspecified. >> >> I think the behavior is specified in RFC 6066: >> >> ... If the server understood the ClientHello extension but >> does not recognize the server name, the server SHOULD take one of two >> actions: either abort the handshake by sending a fatal-level >> unrecognized_name(112) alert or continue the handshake. >> >> As means that the server will try to recognize every type of server >> name. > > I'm just not seeing why this implies that it requires *EVERY* name must > match. This just says we can do one of two things upon receipt of an > unrecognized hostname: continue on, or alert/close. We can be very > restrictive (ALL/AND) or less so (at least one/OR), and still be within > the RFC, I think. > I agree with your parser. >> In our spec, it is required that once a SNIMatcher is defined, it >> will be used to recognized the server name in the SNI extension. > > Where? We do say in SNIMatcher: > > Servers can use Server Name Indication (SNI) information to decide if > specific {@link SSLSocket} or {@link SSLEngine} instances should > accept a connection. > > But I don't think we have ever said that it MUST match or must match all > or even what the implementation must do if there is a match failure. Nor > should we specify that in the API, IMHO. That's implementation behavior. > I may have different options on this point. I think, it must be a specified behavior in Java. Otherwise, it is very confusing about how to use 1+ server names in server side. Let's start from the logic of the design. If the specification is not clear, I will rewrite the spec according to our agreement. Let's start from the requirement. I think once a SNIMatcher is defined in SSL parameters, it MUST be used to perform the match operations if the corresponding server name appears in the SNI extension. Otherwise, what will happens? See the example: 1. SNI extension contains HostName, "www.example.com". 2. Server side defines SNIMatcher for HostName, to accept "www.example.org". Server does not accept "www.example.com". 3. What's the result of the handshake? Is the SNI extension is accetable? If we do not define the spec about how to use SNIMatcher. The answer to #3 is unclear. Because if a SNIMatcher may be used to perform match operation, and may be not used to perform match operation, then the server may accept the SNI extension, may ignore the SNI extension, may reject the SNI extension. It is useless to define SNIMatcher. I think the requirement is clear that it is a must to use SNIMatcher to perform the match operation if the corresponding server name appears in the SNI extension. I think it is true for the case when there is only one server name type, at least. Let's look more about what happens when there is 1+ server name types in the SNI extension. Let's use the example in your previous mail. SNIHostname: "example.com" SNINickName: "www.example.com" SNIMatcher: "example.com" SNINickNameMatcher: "www1.example.com Suppose that the server is able to understand both HostName and NickName. In the above example, server is able to recognize HostName, but not NickName. Then should the server includes an extension of type "server_name" in the (extended) server hello? If the server_name extension is included, it is unclear for client side which one is accepted. Because the client side may need to use the server_name to do endpoint identification, it is not safe to use "www.example.com" to perform endpoint identification because the server side does not accept it. If the server_name extension is not included, it does not follow the spec when server side is able to recognize the server name. So, I will prefer that once a SNIMatcher is defined, it must be used to perform match operation if the corresponding server name type appears in the SNI extension. I think we need to adjust the spec to make the behavior more clear. I will adjust the spec of SNIMatcher a little: * the exact server that the client wants to access. Instances of this - * class can be used by a server to verify the acceptable server names + * class is used by a server to verify the acceptable server names * of a particular type, such as host names. And SSLParameters.getSNIMatchers() *

    * This method is only useful to {@link SSLSocket}s or * {@link SSLEngine}s operating in server mode. + *

    + * Every {@code SNIMatcher} in the returned {@link Collection} must + * be used to perform match operation if the corresponding name + * type appears in the SNI extension. *

    * For better interoperability, providers generally will not define * default matchers so that by default servers will ignore the SNI * extension and continue the handshake. What do you think? I may not need a new bug or CCC request because the update is minor. >> That's >> to say, every server name should be recognizable if the corresponding >> SNIMatcher is defined. I think the current spec is clear that SNIMather >> is used to match a particular server name type. > > Not seeing it, sorry. > > After this discussion, I think we are probably better off starting with > AND anyway, because it will be easier to loosen that condition than > starting with OR and having to tighten to AND. If you agree, can you > add a few words to that effect around 431? > Agree! See above. >>> Right now we have one >>> SNI match type, but eventually we might have more. Your current impl >>> requires that *ALL* SNI matchers match. What if you have more than one, >>> and more than one SNI hostnames are sent? >>> >>> SNIHostname: "example.com" >>> SNINickName: "www.example.com" >>> >>> SNIMatcher: "example.com" >>> SNINickNameMatcher: "www1.example.com >>> >>> Should this fail or succeed? That is, should it be an AND or an OR? >>> Whatever you decide, please document it at least here. Not sure if you >>> want to make the doc at the API level. >>> >> If it is a "OR", we need to doc the special behaviors in API level. But >> it is a "AND", I think the current API is clear that a defined >> SNIMatcher is used to match a particular server name type in SNI >> extension. I think the current spec is OK. > > I think we can leave it unspecified for now, but please add a quick note > here. Thanks. > See above. >>> sun/security/ssl/SSLSocketImpl.java >>> =================================== >>> 561: If I'm remembering and understanding this code right: >>> >>> this.host = sock.getLocalAddress().getHostName(); // in server >>> mode >>> >>> Don't ServerSockets generally creates Sockets with just local IP >>> addresses (no hostnames), so this getHostname() will trigger a reverse >>> hostname lookup? Is that right? >>> >> Right. >> >> It is not really necessary to set the "host" and "serverNames" >> variables, because in server mode the two variables are useless. I will >> remove the setting. > > Ok. > > 561: // In server mode, it is not necessary to set host and serverNames. > Can you add "...and would require a reverse DNS lookup" or something > similar? > Good. // In server mode, it is not necessary to set host and serverNames. // Otherwise, would require a reverse DNS lookup to get the hostname. >>> 2509: Something to investigate: you are depending on SSLParameters >>> returning an unmodifiable list. But a subclass might not do that. Can >>> you think of any situations where this might be a bad idea? If so, then >>> we might want to change the unmodifiable language in SSLParameters and >>> do regular cloning. This will have repercussions in other areas, like >>> around 2527/2532, where you'll need to pass a copy to the Handshaker. >>> >> Well, I understand that something bad would happen if the subclass does >> not follow the method spec while doing method implementation overriding. > > Yes, it was just something to think about. Of course, I'm trying to > think of exploit situations, since you're really just hurting yourself > if tweak this in the middle of a handshake. > > If I see Joe Darcy around, I'll check in with him. > Thanks! I really think we need to think about it more and carefully. The style (immutable returned value in none-final method) does impact the reliability of the APIs. >> Let's have the spec and implementation as it is. We can update the spec >> and implementation if we have strong concerns or a common solution for >> the issue before JDK 8 officially release. > > I'm fine with this. > >>> sun/security/ssl/X509TrustManagerImpl.java >>> ========================================== >>> OK >>> >> All of other comments are accepted. >> >> I think there is no major concerns so far. > > None still outstanding. I looked over the previous comments I've made > and what you've done to address them, and all looks good minus the > little points above. > Good! It seems that we only have one question, how to use SNIMatachers? See above. Thanks, Xuelei >> Thank you so much for the >> detailed evaluation and comments on both spec and implementation. TLS >> and its implementation is very complicated, your support is the critical >> success factor to deliver quality product. > > Thanks, and be sure to give yourself a lot of that credit. With all the > back/forth and development this feature has seen, I think you've done a > great job. > > Brad > From xuelei.fan at oracle.com Wed Oct 10 19:58:44 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 11 Oct 2012 10:58:44 +0800 Subject: Code review request: 7198507: [TEST_BUG] sun/security/tools/keytool/console.sh should be rewritten In-Reply-To: <5076271C.8030507@oracle.com> References: <5452358.1347959568853.JavaMail.sbladm@swsblss4-new.central.sun.com> <50583E3D.8020500@oracle.com> <5076271C.8030507@oracle.com> Message-ID: <507635E4.7000600@oracle.com> Looks fine to me. Xuelei On 10/11/2012 9:55 AM, Weijun Wang wrote: > Ping again. > > Thanks > Max > > On 09/18/2012 05:26 PM, Weijun Wang wrote: >> First, I'm very glad to see that we are running manual tests. >> >> Then, please take a look at >> >> http://cr.openjdk.java.net/~weijun/7198507/webrev.00 >> >> Nothing is changed in the real keytool command calls, only some small >> changes: >> >> 1. Better prompt >> 2. Keystore file now /tmp/kkk.$$, clean and no conflict >> 3. Exit wherever a keytool command fails >> 4. Remove "export". It causes an error on Solaris >> 5. Add a "k" after "read". Only this can stop the process >> >> Thanks >> Max >> >> -------- Original Message -------- >> 7198507: [TEST_BUG] sun/security/tools/keytool/console.sh should be >> rewritten >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198507 >> >> === *Description* >> ============================================================ >> test have 2 problems: >> 1. It failed on solaris platforms due incorrect shell syntax >> 2. It should be interactive but one always shows "passed" status on >> linux and windows while really additional variables should be set by >> user before running for successful execution and user should decide >> passed test or failed. There are no any messages for user when test >> running under jtreg. >> >> >> solaris log: >> ----------System.out:(0/0)---------- >> ----------System.err:(1/244)*---------- >> /net/stt-13.ru.oracle.com/export2/stt/newroot/regression/workspaces/1.8.0/1.8.0_fcsb55/j2se/test/sun/security/tools/keytool/console.sh: >> >> PASS=\\303\\244\\303\\266\\303\\244\\303\\266\\303\\244\\303\\266\\303\\244\\303\\266: >> >> is not an identifier >> result: Failed. Execution failed: exit code 1 >> >> >> linux log: >> ----------System.err:(22/3266)---------- >> rm: cannot remove `kkk': No such file or directory >> /net/stt-13.ru.oracle.com/export2/stt/newroot/regression/workspaces/1.8.0/1.8.0_fcsb55/j2se/test/sun/security/tools/keytool/console.sh: >> >> line 66: /bin/keytool: No such file or directory >> ..... From valerie.peng at oracle.com Wed Oct 10 20:16:28 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 10 Oct 2012 20:16:28 -0700 Subject: Code review request for JEP-121 In-Reply-To: <52B22704-F455-48F0-8BB4-810994D99D36@oracle.com> References: <4FC90790.5070109@oracle.com> <503E3333.7040100@oracle.com> <50401BCE.1010003@oracle.com> <504634B0.7000002@oracle.com> <52B22704-F455-48F0-8BB4-810994D99D36@oracle.com> Message-ID: <50763A0C.6060707@oracle.com> Hi, Vinnie, Here are my comments on the latest webrev 04. => looks fine. => Well, the fields contains the new cipherParam field needed for PBES2 cipher, but the encoding is still for the older PBES1 cipher. => Perhaps it's cleaner to use a separate class for parameters for PBES2 cipher. The ASN.1 syntax is defined in PCKS#5v2.1 Appendix A.2 and B.2 => fine, although as I previously mentioned that it'll be easier to maintain and understand if we can refactor the code with a non-CipherCore object, so that no special handling needed for RC4. Can we file a separate bug/rfe to keep track of this refactoring? => Well, the HmacPKCS12PBESHA1 class (which you renamed to "PBMAC1Core") implements the PKCS#12 v1 standard and is different from the PBMAC1 algorithms defined in PKCS#5 v2.1. So, the new comments at line 39-40 aren't correct. The two standards, i.e. PKCS#12 and PKCS#5, aren't consistent and have different ways on how the keys are derived. If you look at PKCS#5v2.1, it explicitly specified that the key shall be derived using PBKDF2 and the impl inside HmacPKCS12PBESHA1 relies on the PKCS12PBECipherCore.derive(...) method for deriving the keys. If the goal is about supporting "PBMAC1" function defined in PKCS#5v2.1, then we need to have separate classes which use PBKDF2. => The HmacPKCS12PBESHA1 class is used by PKCS12 keystore class. So, we still need to keep it and can't shift it to the impl defined by PKCS#5v2.1. Currently, PKCS#12 only uses SHA1. Well, but things are confusing as is already... => Given the above on PBMAC1Core, the "// PBMAC1" comment on line 678 isn't correct. I am still thinking about the changes on PBEKey and PBES2Core classes, but thought that I should send you above comments first while I sort my thoughts out. Thanks, Valerie On 10/04/12 03:50, Vincent Ryan wrote: > I've made further modifications including adding support to PBEParameterSpec > for an AlgorithmParameterSpec object. This is used to convey parameters > (in addition to salt and iteration count) to the underlying cipher. > > For example, AES requires an initialization vector so PBE algorithms that use > AES need a mechanism to supply an IV parameter. > > The latest webrev is at: > http://cr.openjdk.java.net/~vinnie/6383200/webrev.04/ > > > > On 4 Sep 2012, at 18:04, Vincent Ryan wrote: > >> Thanks Valerie. >> >> I'd addressed your comments except the first one. >> >> Since RC4 is a stream cipher and RC2 is a block cipher they are handled >> slightly differently. It would be possible to re-factor this code to >> simplify it but I'd like to leave that for later as I'm under pressure >> to meet the next promotion date. >> >> The latest webrev is at: >> http://cr.openjdk.java.net/~vinnie/6383200/webrev.03/ >> >> >> >> On 08/31/12 03:05 AM, Valerie (Yu-Ching) Peng wrote: >>> Vinnie, >>> >>> >>> 1. Is it possible to replace the CipherCore object w/ CipherSpi object >>> so to maximize the code re-use? The new code uses CipherSpi object for >>> RC4 and CipherCore for RC2. Perhaps by using CipherSpi for both RC4 and >>> RC2, we can have less code which would be easier to maintain... >>> >>> >>> 1. line 57, change the initial set size to 17 from 4? >>> >>> >>> 1. the impls of the two following engineInit() methods are inconsistent, >>> i.e. >>> engineInit(int, Key, AlgorithmParameterSpec, SecureRandom) - expects >>> IvParameterSpec >>> engineInit(int, Key, AlgorithmParameters, SecureRandom) - expects >>> objects created from PBEParameterSpec >>> 2. The impl of engineGetParameters() currently returns objects created >>> from PBEParameterSpec. It should return whatever is expected in the >>> engineInit(...) calls, I'd think. >>> >>> Will send you the rest of comments later, >>> Valerie >>> >>> On 08/29/12 08:20, Vincent Ryan wrote: >>>> On 06/ 1/12 07:18 PM, Vincent Ryan wrote: >>>>> Hello Valerie, >>>>> >>>>> Could you please review these changes for JEP-121: >>>>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.00/ >>>>> >>>>> Thanks. >>>>> >>>> The latest webrev is now available at: >>>> >>>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.02/ >>>> >>>> I've incorporated review comments and made some fixes >>>> to the implementation of AES-based PBE algorithms. >>>> >>>> Thanks. From bradford.wetmore at oracle.com Wed Oct 10 21:21:11 2012 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 10 Oct 2012 21:21:11 -0700 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <507634F3.9060703@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> Message-ID: <50764937.3080807@oracle.com> On 10/10/2012 7:54 PM, Xuelei Fan wrote: > No new webrev. I need a review of how to use SNIMatcher. See bellow > inline comments. > > On 10/11/2012 7:38 AM, Brad Wetmore wrote: >> >> >> On 10/10/2012 5:47 AM, Xuelei Fan wrote: >>> new webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.13/ >> >> I guess you didn't need to have me as reviewer before going final with >> the CCC? >> > The CCC has been finalized. ;-) I though you have done with spec review. > Anyway, we still can make updates on specification within new bugs. > >>>> javax/net/ssl/SSLSocketFactory.java >>>> =================================== >>>> Change look good. >>>> >>>> 216: I think you need a period at end of sentence here. >> >> You got the others, but missed this one. >> > I think we discussed the style sometimes ago. If the sentence does not > start with a capital letter, then it does not need a period at the end > of the sentence. I can see both style in other specs. > > Updated to add the period. Sorry, I meant to say copyright change. Boy, did I goof on that one. One of the copyright dates wasn't right, but the rest were. I'll respond to the rest tomorrow. I have a sick PC to diagnose. :( Brad >>>> 231: Might suggest some reason text for the >>>> UnsupportedOperationException. >>>> >>> I think the exception name has say the exception clearly. I think it >>> does not make sense to add additional message for it. I had a search in >>> the packages of java.lang and java.uitl, most of the codes (39 of 42) >>> use the default non-parameter constructor of >>> UnsupportedOperationException. I will prefer to use the current style. >> >> No problem. >> >>>> sun/security/ssl/Utilities.java >>>> =============================== >>>> 46: Minor comment on method name, you might want to use >>>> "addToSNIServerNameList" since you are adding. >>>> >>>> 84: Just wondering why you added this method here? This added a bit of >>>> overhead in extra methods calls (well, maybe not with hotspot unrolling) >>>> and added a few chars to the source. So given that you have added this, >>>> why not update the remainder also? >>>> EngineOutputRecord/InputRecord/OutputRecord. >>>> >>> Good point! >> >> Or do it the way you did. This just adds a little extra source overhead. >> >>>> See the below comment in SSLSocketImpl.java. If you decide to accept >>>> it, you will want to remove the unmodifiable collection. >>>> >>> See the reply in SSLSocketImpl.java >> >> Ok. >> >>>> sun/security/ssl/Handshaker.java >>>> ================================ >>>> 291: The change to allow for setting of SNI information has opened up a >>>> race condition. It's probably not too bad for SSLSocket, but might be >>>> more for SSLEngine. When we create ClientHandshaker/ServerHandshakers, >>>> we normally grab all the parameters necessary for the handshaker, and >>>> any future parameter modifications will apply to the next handshake. In >>>> the past, our SNI information would never change, so it wasn't necessary >>>> to pass it in on creation. That assumption no longer holds. >>>> >>>> So you could see something like this: >>>> >>>> sslEngine.beginHandshake(); >>>> SSLParameters sslp = new SSLParameters(); >>>> sslp.setHostnames("example.com"); >>>> sslEngine.setSSLParameters(sslp); >>>> // do handshake... >>>> >>>> and you'll get the new value instead of old. >>>> >>> Good catch! >>> >>> Updated to store the local server name indication and matchers in >>> Handshaker. >> >> Just a comment: >> >> 459/468: Currently you have serverNames and sniMatchers as package >> private variables, so the ClientHandshaker/ServerHandshaker *could* >> inherit these variables rather than have a separate get methods. Or you >> could make them private and keep the get calls. >> > Good catch! > >>>> sun/security/ssl/HelloExtensions.java >>>> ===================================== >>>> 423: This behavior is currently underspecified. >>> >>> I think the behavior is specified in RFC 6066: >>> >>> ... If the server understood the ClientHello extension but >>> does not recognize the server name, the server SHOULD take one of two >>> actions: either abort the handshake by sending a fatal-level >>> unrecognized_name(112) alert or continue the handshake. >>> >>> As means that the server will try to recognize every type of server >>> name. >> >> I'm just not seeing why this implies that it requires *EVERY* name must >> match. This just says we can do one of two things upon receipt of an >> unrecognized hostname: continue on, or alert/close. We can be very >> restrictive (ALL/AND) or less so (at least one/OR), and still be within >> the RFC, I think. >> > I agree with your parser. > >>> In our spec, it is required that once a SNIMatcher is defined, it >>> will be used to recognized the server name in the SNI extension. >> >> Where? We do say in SNIMatcher: >> >> Servers can use Server Name Indication (SNI) information to decide if >> specific {@link SSLSocket} or {@link SSLEngine} instances should >> accept a connection. >> >> But I don't think we have ever said that it MUST match or must match all >> or even what the implementation must do if there is a match failure. Nor >> should we specify that in the API, IMHO. That's implementation behavior. >> > I may have different options on this point. I think, it must be a > specified behavior in Java. Otherwise, it is very confusing about how to > use 1+ server names in server side. > > Let's start from the logic of the design. If the specification is not > clear, I will rewrite the spec according to our agreement. > > Let's start from the requirement. I think once a SNIMatcher is defined > in SSL parameters, it MUST be used to perform the match operations if > the corresponding server name appears in the SNI extension. Otherwise, > what will happens? See the example: > 1. SNI extension contains HostName, "www.example.com". > 2. Server side defines SNIMatcher for HostName, to accept > "www.example.org". Server does not accept "www.example.com". > 3. What's the result of the handshake? Is the SNI extension is accetable? > > If we do not define the spec about how to use SNIMatcher. The answer to > #3 is unclear. Because if a SNIMatcher may be used to perform match > operation, and may be not used to perform match operation, then the > server may accept the SNI extension, may ignore the SNI extension, may > reject the SNI extension. It is useless to define SNIMatcher. > > I think the requirement is clear that it is a must to use SNIMatcher to > perform the match operation if the corresponding server name appears in > the SNI extension. I think it is true for the case when there is only > one server name type, at least. > > Let's look more about what happens when there is 1+ server name types in > the SNI extension. Let's use the example in your previous mail. > > SNIHostname: "example.com" > SNINickName: "www.example.com" > > SNIMatcher: "example.com" > SNINickNameMatcher: "www1.example.com > > Suppose that the server is able to understand both HostName and > NickName. In the above example, server is able to recognize HostName, > but not NickName. Then should the server includes an extension of type > "server_name" in the (extended) server hello? > > If the server_name extension is included, it is unclear for client side > which one is accepted. Because the client side may need to use the > server_name to do endpoint identification, it is not safe to use > "www.example.com" to perform endpoint identification because the server > side does not accept it. > > If the server_name extension is not included, it does not follow the > spec when server side is able to recognize the server name. > > So, I will prefer that once a SNIMatcher is defined, it must be used to > perform match operation if the corresponding server name type appears in > the SNI extension. > > I think we need to adjust the spec to make the behavior more clear. I > will adjust the spec of SNIMatcher a little: > * the exact server that the client wants to access. Instances of this > - * class can be used by a server to verify the acceptable server names > + * class is used by a server to verify the acceptable server names > * of a particular type, such as host names. > > And SSLParameters.getSNIMatchers() > *

    > * This method is only useful to {@link SSLSocket}s or > * {@link SSLEngine}s operating in server mode. > + *

    > + * Every {@code SNIMatcher} in the returned {@link Collection} must > + * be used to perform match operation if the corresponding name > + * type appears in the SNI extension. > *

    > * For better interoperability, providers generally will not define > * default matchers so that by default servers will ignore the SNI > * extension and continue the handshake. > > What do you think? I may not need a new bug or CCC request because the > update is minor. > > >>> That's >>> to say, every server name should be recognizable if the corresponding >>> SNIMatcher is defined. I think the current spec is clear that SNIMather >>> is used to match a particular server name type. >> >> Not seeing it, sorry. >> >> After this discussion, I think we are probably better off starting with >> AND anyway, because it will be easier to loosen that condition than >> starting with OR and having to tighten to AND. If you agree, can you >> add a few words to that effect around 431? >> > Agree! See above. > >>>> Right now we have one >>>> SNI match type, but eventually we might have more. Your current impl >>>> requires that *ALL* SNI matchers match. What if you have more than one, >>>> and more than one SNI hostnames are sent? >>>> >>>> SNIHostname: "example.com" >>>> SNINickName: "www.example.com" >>>> >>>> SNIMatcher: "example.com" >>>> SNINickNameMatcher: "www1.example.com >>>> >>>> Should this fail or succeed? That is, should it be an AND or an OR? >>>> Whatever you decide, please document it at least here. Not sure if you >>>> want to make the doc at the API level. >>>> >>> If it is a "OR", we need to doc the special behaviors in API level. But >>> it is a "AND", I think the current API is clear that a defined >>> SNIMatcher is used to match a particular server name type in SNI >>> extension. I think the current spec is OK. >> >> I think we can leave it unspecified for now, but please add a quick note >> here. Thanks. >> > See above. > >>>> sun/security/ssl/SSLSocketImpl.java >>>> =================================== >>>> 561: If I'm remembering and understanding this code right: >>>> >>>> this.host = sock.getLocalAddress().getHostName(); // in server >>>> mode >>>> >>>> Don't ServerSockets generally creates Sockets with just local IP >>>> addresses (no hostnames), so this getHostname() will trigger a reverse >>>> hostname lookup? Is that right? >>>> >>> Right. >>> >>> It is not really necessary to set the "host" and "serverNames" >>> variables, because in server mode the two variables are useless. I will >>> remove the setting. >> >> Ok. >> >> 561: // In server mode, it is not necessary to set host and serverNames. >> Can you add "...and would require a reverse DNS lookup" or something >> similar? >> > Good. > > // In server mode, it is not necessary to set host and serverNames. > // Otherwise, would require a reverse DNS lookup to get the hostname. > > >>>> 2509: Something to investigate: you are depending on SSLParameters >>>> returning an unmodifiable list. But a subclass might not do that. Can >>>> you think of any situations where this might be a bad idea? If so, then >>>> we might want to change the unmodifiable language in SSLParameters and >>>> do regular cloning. This will have repercussions in other areas, like >>>> around 2527/2532, where you'll need to pass a copy to the Handshaker. >>>> >>> Well, I understand that something bad would happen if the subclass does >>> not follow the method spec while doing method implementation overriding. >> >> Yes, it was just something to think about. Of course, I'm trying to >> think of exploit situations, since you're really just hurting yourself >> if tweak this in the middle of a handshake. >> >> If I see Joe Darcy around, I'll check in with him. >> > Thanks! I really think we need to think about it more and carefully. The > style (immutable returned value in none-final method) does impact the > reliability of the APIs. > >>> Let's have the spec and implementation as it is. We can update the spec >>> and implementation if we have strong concerns or a common solution for >>> the issue before JDK 8 officially release. >> >> I'm fine with this. >> >>>> sun/security/ssl/X509TrustManagerImpl.java >>>> ========================================== >>>> OK >>>> >>> All of other comments are accepted. >>> >>> I think there is no major concerns so far. >> >> None still outstanding. I looked over the previous comments I've made >> and what you've done to address them, and all looks good minus the >> little points above. >> > Good! It seems that we only have one question, how to use SNIMatachers? > See above. > > Thanks, > Xuelei > > >>> Thank you so much for the >>> detailed evaluation and comments on both spec and implementation. TLS >>> and its implementation is very complicated, your support is the critical >>> success factor to deliver quality product. >> >> Thanks, and be sure to give yourself a lot of that credit. With all the >> back/forth and development this feature has seen, I think you've done a >> great job. >> >> Brad >> > From xuelei.fan at oracle.com Wed Oct 10 22:11:35 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 11 Oct 2012 13:11:35 +0800 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <50764937.3080807@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> <50764937.3080807@oracle.com> Message-ID: <50765507.8030801@oracle.com> On 10/11/2012 12:21 PM, Bradford Wetmore wrote: > > > On 10/10/2012 7:54 PM, Xuelei Fan wrote: >> No new webrev. I need a review of how to use SNIMatcher. See bellow >> inline comments. >> >> On 10/11/2012 7:38 AM, Brad Wetmore wrote: >>> >>> >>> On 10/10/2012 5:47 AM, Xuelei Fan wrote: >>>> new webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.13/ >>> >>> I guess you didn't need to have me as reviewer before going final with >>> the CCC? >>> >> The CCC has been finalized. ;-) I though you have done with spec review. >> Anyway, we still can make updates on specification within new bugs. >> >>>>> javax/net/ssl/SSLSocketFactory.java >>>>> =================================== >>>>> Change look good. >>>>> >>>>> 216: I think you need a period at end of sentence here. >>> >>> You got the others, but missed this one. >>> >> I think we discussed the style sometimes ago. If the sentence does not >> start with a capital letter, then it does not need a period at the end >> of the sentence. I can see both style in other specs. >> >> Updated to add the period. > > Sorry, I meant to say copyright change. Boy, did I goof on that one. > One of the copyright dates wasn't right, but the rest were. Oops, right, I missed the copyright dates. I double checked the copyright yesterday, but still missed this one. ;-) Xuelei From alan.bateman at oracle.com Thu Oct 11 03:48:55 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 11 Oct 2012 10:48:55 +0000 Subject: hg: jdk8/tl/jdk: 7186817: Remove Windows 95/98/ME Support Message-ID: <20121011104917.8EB17472B5@hg.openjdk.java.net> Changeset: c2be39b27e1c Author: dxu Date: 2012-10-11 11:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2be39b27e1c 7186817: Remove Windows 95/98/ME Support Reviewed-by: alanb ! make/java/java/Makefile ! makefiles/CompileNativeLibraries.gmk - src/windows/classes/java/io/Win32FileSystem.java ! src/windows/classes/java/io/WinNTFileSystem.java ! src/windows/native/java/io/FileSystem_md.c - src/windows/native/java/io/Win32FileSystem_md.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/util/TimeZone_md.c ! test/java/io/pathNames/win32/bug6344646.java From vincent.x.ryan at oracle.com Thu Oct 11 05:07:40 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 11 Oct 2012 13:07:40 +0100 Subject: Code review request for JEP-121 In-Reply-To: <50763A0C.6060707@oracle.com> References: <4FC90790.5070109@oracle.com> <503E3333.7040100@oracle.com> <50401BCE.1010003@oracle.com> <504634B0.7000002@oracle.com> <52B22704-F455-48F0-8BB4-810994D99D36@oracle.com> <50763A0C.6060707@oracle.com> Message-ID: <5076B68C.6010706@oracle.com> Thanks for this latest review. Comments below. On 11/10/2012 04:16, Valerie (Yu-Ching) Peng wrote: > Hi, Vinnie, > > Here are my comments on the latest webrev 04. > > > > > > > > => looks fine. > > > => Well, the fields contains the new cipherParam field needed for PBES2 > cipher, but the encoding is still for the older PBES1 cipher. > => Perhaps it's cleaner to use a separate class for parameters for PBES2 > cipher. The ASN.1 syntax is defined in PCKS#5v2.1 Appendix A.2 and B.2 Right. I've overlooked the ASN.1 encoding issue. I'll create a new PBES2Parameters class as you suggest. > > > => fine, although as I previously mentioned that it'll be easier to > maintain and understand if we can refactor the code with a > non-CipherCore object, so that no special handling needed for RC4. Can > we file a separate bug/rfe to keep track of this refactoring? I'll file a bug on that. > > > => Well, the HmacPKCS12PBESHA1 class (which you renamed to "PBMAC1Core") > implements the PKCS#12 v1 standard and is different from the PBMAC1 > algorithms defined in PKCS#5 v2.1. So, the new comments at line 39-40 > aren't correct. The two standards, i.e. PKCS#12 and PKCS#5, aren't > consistent and have different ways on how the keys are derived. If you > look at PKCS#5v2.1, it explicitly specified that the key shall be > derived using PBKDF2 and the impl inside HmacPKCS12PBESHA1 relies on the > PKCS12PBECipherCore.derive(...) method for deriving the keys. If the > goal is about supporting "PBMAC1" function defined in PKCS#5v2.1, then > we need to have separate classes which use PBKDF2. > => The HmacPKCS12PBESHA1 class is used by PKCS12 keystore class. So, we > still need to keep it and can't shift it to the impl defined by > PKCS#5v2.1. Currently, PKCS#12 only uses SHA1. Well, but things are > confusing as is already... > I'll re-instate HmacPKCS12PBESHA1 and define a separate implementation class for PBMAC1. > > => Given the above on PBMAC1Core, the "// PBMAC1" comment on line 678 > isn't correct. > > I am still thinking about the changes on PBEKey and PBES2Core classes, > but thought that I should send you above comments first while I sort my > thoughts out. > > Thanks, > Valerie > > On 10/04/12 03:50, Vincent Ryan wrote: >> I've made further modifications including adding support to >> PBEParameterSpec >> for an AlgorithmParameterSpec object. This is used to convey parameters >> (in addition to salt and iteration count) to the underlying cipher. >> >> For example, AES requires an initialization vector so PBE algorithms >> that use >> AES need a mechanism to supply an IV parameter. >> >> The latest webrev is at: >> http://cr.openjdk.java.net/~vinnie/6383200/webrev.04/ >> >> >> >> On 4 Sep 2012, at 18:04, Vincent Ryan wrote: >> >>> Thanks Valerie. >>> >>> I'd addressed your comments except the first one. >>> >>> Since RC4 is a stream cipher and RC2 is a block cipher they are handled >>> slightly differently. It would be possible to re-factor this code to >>> simplify it but I'd like to leave that for later as I'm under pressure >>> to meet the next promotion date. >>> >>> The latest webrev is at: >>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.03/ >>> >>> >>> >>> On 08/31/12 03:05 AM, Valerie (Yu-Ching) Peng wrote: >>>> Vinnie, >>>> >>>> >>>> 1. Is it possible to replace the CipherCore object w/ CipherSpi object >>>> so to maximize the code re-use? The new code uses CipherSpi object for >>>> RC4 and CipherCore for RC2. Perhaps by using CipherSpi for both RC4 and >>>> RC2, we can have less code which would be easier to maintain... >>>> >>>> >>>> 1. line 57, change the initial set size to 17 from 4? >>>> >>>> >>>> 1. the impls of the two following engineInit() methods are >>>> inconsistent, >>>> i.e. >>>> engineInit(int, Key, AlgorithmParameterSpec, SecureRandom) - expects >>>> IvParameterSpec >>>> engineInit(int, Key, AlgorithmParameters, SecureRandom) - expects >>>> objects created from PBEParameterSpec >>>> 2. The impl of engineGetParameters() currently returns objects created >>>> from PBEParameterSpec. It should return whatever is expected in the >>>> engineInit(...) calls, I'd think. >>>> >>>> Will send you the rest of comments later, >>>> Valerie >>>> >>>> On 08/29/12 08:20, Vincent Ryan wrote: >>>>> On 06/ 1/12 07:18 PM, Vincent Ryan wrote: >>>>>> Hello Valerie, >>>>>> >>>>>> Could you please review these changes for JEP-121: >>>>>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.00/ >>>>>> >>>>>> Thanks. >>>>>> >>>>> The latest webrev is now available at: >>>>> >>>>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.02/ >>>>> >>>>> I've incorporated review comments and made some fixes >>>>> to the implementation of AES-based PBE algorithms. >>>>> >>>>> Thanks. > From rob.mckenna at oracle.com Thu Oct 11 10:22:05 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Thu, 11 Oct 2012 17:22:05 +0000 Subject: hg: jdk8/tl/jdk: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol] Message-ID: <20121011172249.A4DF2472C4@hg.openjdk.java.net> Changeset: 7c2f5e52863c Author: robm Date: 2012-10-11 18:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c2f5e52863c 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol] Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Basic.java From lance.andersen at oracle.com Thu Oct 11 15:46:48 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 11 Oct 2012 22:46:48 +0000 Subject: hg: jdk8/tl/jdk: 8000763: use XXX.valueOf methods instead of constructors Message-ID: <20121011224713.E2717472FA@hg.openjdk.java.net> Changeset: daabaafd6798 Author: lancea Date: 2012-10-11 18:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/daabaafd6798 8000763: use XXX.valueOf methods instead of constructors Reviewed-by: mchung, forax ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java From lana.steuck at oracle.com Fri Oct 12 15:27:56 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Oct 2012 22:27:56 +0000 Subject: hg: jdk8/tl: 6 new changesets Message-ID: <20121012222757.3269A4733F@hg.openjdk.java.net> Changeset: dae9821589cc Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dae9821589cc Added tag jdk8-b58 for changeset 936702480487 ! .hgtags Changeset: b9d574659206 Author: katleman Date: 2012-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b9d574659206 Added tag jdk8-b59 for changeset dae9821589cc ! .hgtags Changeset: 4b54d77a6831 Author: dholmes Date: 2012-10-09 02:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4b54d77a6831 8000461: Top level build doesn't pass OPENJDK=true through to the hotspot build Summary: Add OPENJDK to the COMMON_BUILD_ARGUMENTS Reviewed-by: tbell ! make/Defs-internal.gmk Changeset: e07f499b9dcc Author: katleman Date: 2012-10-10 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e07f499b9dcc Merge Changeset: 20ff117b5090 Author: katleman Date: 2012-10-11 09:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/20ff117b5090 Added tag jdk8-b60 for changeset e07f499b9dcc ! .hgtags Changeset: ce2b111ee869 Author: lana Date: 2012-10-12 14:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ce2b111ee869 Merge From lana.steuck at oracle.com Fri Oct 12 15:28:04 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Oct 2012 22:28:04 +0000 Subject: hg: jdk8/tl/corba: 6 new changesets Message-ID: <20121012222808.64F7847340@hg.openjdk.java.net> Changeset: d54dc53e223e Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d54dc53e223e Added tag jdk8-b58 for changeset 18462a19f7bd ! .hgtags Changeset: 207ef43ba69e Author: katleman Date: 2012-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/207ef43ba69e Added tag jdk8-b59 for changeset d54dc53e223e ! .hgtags Changeset: 41bb9e606efd Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/41bb9e606efd Added tag jdk8-b60 for changeset 207ef43ba69e ! .hgtags Changeset: d9c1dab1515b Author: lana Date: 2012-10-08 15:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d9c1dab1515b Merge Changeset: 0e08ba7648fb Author: lana Date: 2012-10-11 16:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0e08ba7648fb Merge Changeset: 706684c5a058 Author: lana Date: 2012-10-12 14:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/706684c5a058 Merge From lana.steuck at oracle.com Fri Oct 12 15:30:09 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Oct 2012 22:30:09 +0000 Subject: hg: jdk8/tl/hotspot: 68 new changesets Message-ID: <20121012223233.15DB147342@hg.openjdk.java.net> Changeset: 04ed664b7e30 Author: amurillo Date: 2012-09-21 14:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04ed664b7e30 7200236: new hotspot build - hs25-b03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: fac3dd92ebaf Author: bpittore Date: 2012-09-19 17:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fac3dd92ebaf 7195372: Wrong copyright in new files Summary: Fixed copyrights Reviewed-by: dholmes Contributed-by: Bill Pittore ! agent/make/saenv.sh ! agent/make/start-debug-server-proc.sh ! agent/src/share/classes/sun/jvm/hotspot/debugger/ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/amd64/AMD64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ia64/IA64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/sparc/SPARCThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/x86/X86ThreadContext.java ! make/linux/makefiles/sa.make Changeset: ef7fe63a2d39 Author: vladidan Date: 2012-09-24 19:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef7fe63a2d39 Merge Changeset: 15ba0e7a3ff4 Author: sla Date: 2012-09-17 11:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15ba0e7a3ff4 7193201: [OS X] The development launcher should be signed and given task_for_pid privileges Reviewed-by: sspitsyn, nloodin, mgronlun, coleenp ! make/bsd/makefiles/launcher.make + src/os/bsd/launcher/Info-privileged.plist Changeset: a7509aff1b06 Author: dholmes Date: 2012-09-17 07:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a7509aff1b06 7194254: jstack reports wrong thread priorities Reviewed-by: dholmes, sla, fparain Contributed-by: Dmytro Sheyko ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp + test/runtime/7194254/Test7194254.java Changeset: 7b41bee02500 Author: dholmes Date: 2012-09-17 08:44 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b41bee02500 Merge Changeset: 716e6ef4482a Author: zgu Date: 2012-09-17 10:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/716e6ef4482a 7190089: NMT ON: NMT failed assertion on thread's stack base address Summary: Solaris only, record stack info to NMT after stack size adjustment was made for primordial threads Reviewed-by: kvn, acorn, coleenp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: c088e2e95e69 Author: zgu Date: 2012-09-17 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c088e2e95e69 Merge ! src/share/vm/runtime/thread.cpp Changeset: 9a86ddfc6c8f Author: zgu Date: 2012-09-17 16:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a86ddfc6c8f 7188594: Print statistic collected by NMT with VM flag Summary: Print out statistics of collected NMT data if it is on at VM exits Reviewed-by: kvn, coleenp, twisti ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/services/memTracker.hpp Changeset: 45f22ba9348d Author: zgu Date: 2012-09-18 11:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/45f22ba9348d Merge Changeset: 1cb8583c3da8 Author: minqi Date: 2012-09-18 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cb8583c3da8 7191786: retransformClasses() does not pass in LocalVariableTypeTable of a method Summary: JVMTI REtruncformClasses must support LocalVariableTypeTable attribute Reviewed-by: dcubed, dsamersoff, rbackman Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: 26994b6e10d5 Author: minqi Date: 2012-09-19 08:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26994b6e10d5 Merge Changeset: 989cf02ca531 Author: ihse Date: 2012-09-17 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/989cf02ca531 7172012: Make test-in-build an option (Queens) Reviewed-by: ohair, dholmes ! make/bsd/Makefile ! make/defs.make ! make/linux/Makefile ! make/solaris/Makefile Changeset: 06be7f06c2de Author: ohair Date: 2012-09-18 10:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06be7f06c2de Merge Changeset: 37518f191ddb Author: ohair Date: 2012-09-18 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37518f191ddb 7198329: Add $(sort) to object files used in links makes binarties more consistent Reviewed-by: dholmes, tbell, erikj, ihse, ohrstrom ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/vm.make Changeset: 0e5be2138cd6 Author: jcoomes Date: 2012-09-18 19:44 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0e5be2138cd6 Merge Changeset: 2c527daec02c Author: jcoomes Date: 2012-09-19 16:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c527daec02c Merge Changeset: 6af8f3562069 Author: kevinw Date: 2012-09-19 15:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6af8f3562069 7196045: Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API. Reviewed-by: sspitsyn, dholmes ! src/share/vm/services/management.cpp + test/runtime/7196045/Test7196045.java Changeset: 8440414b0fd8 Author: kevinw Date: 2012-09-20 03:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8440414b0fd8 Merge Changeset: b711844284e2 Author: nloodin Date: 2012-09-21 10:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b711844284e2 7200092: Make NMT a bit friendlier to work with Reviewed-by: kvn, ysr, azeemj ! src/share/vm/services/memTracker.cpp Changeset: 5a98bf7d847b Author: minqi Date: 2012-09-24 12:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a98bf7d847b 6879063: SA should use hsdis for disassembly Summary: We should in SA to use hsdis for it like the JVM does to replace the current java based disassembler. Reviewed-by: twisti, jrose, sla Contributed-by: yumin.qi at oracle.com - agent/make/ClosureFinder.java ! agent/make/Makefile ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/linux/Makefile ! agent/src/os/linux/mapfile ! agent/src/os/solaris/proc/Makefile ! agent/src/os/solaris/proc/mapfile ! agent/src/os/win32/windbg/Makefile ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java ! agent/src/share/classes/sun/jvm/hotspot/asm/InstructionVisitor.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/SADebugServer.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RegisterMap.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js + agent/src/share/native/sadis.c ! agent/test/jdi/jstack.sh ! agent/test/jdi/jstack64.sh ! agent/test/jdi/runsa.sh ! agent/test/jdi/sasanity.sh ! agent/test/libproc/libproctest.sh ! agent/test/libproc/libproctest64.sh ! make/bsd/makefiles/sa.make ! make/bsd/makefiles/saproc.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! make/sa.files ! make/solaris/makefiles/sa.make ! make/solaris/makefiles/saproc.make ! make/windows/makefiles/sa.make ! src/share/tools/hsdis/Makefile ! src/share/tools/hsdis/README ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/tools/hsdis/hsdis.h ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp Changeset: 3d739d45d9fd Author: minqi Date: 2012-09-24 20:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3d739d45d9fd Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java Changeset: 45535ab90688 Author: dholmes Date: 2012-09-25 07:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/45535ab90688 7200065: Cross-compilation changes to support the new-build Reviewed-by: dholmes, ohair Contributed-by: Fredrik Ohrstrom ! make/linux/makefiles/adlc.make ! make/linux/makefiles/defs.make Changeset: b86575d092a2 Author: dsamersoff Date: 2012-09-27 20:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b86575d092a2 Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java ! make/linux/makefiles/sa.make ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 5baec2e69518 Author: jmasa Date: 2012-09-25 07:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5baec2e69518 7200615: NPG: optimized VM build is broken Reviewed-by: kvn ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/memory/metaspace.cpp Changeset: 8966c2d65d96 Author: brutisso Date: 2012-09-25 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8966c2d65d96 7200470: KeepAliveClosure not needed in CodeCache::do_unloading Summary: Removed the unused keep_alive parameter Reviewed-by: stefank, dholmes, kamg, coleenp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: 7c2fd5948145 Author: brutisso Date: 2012-09-25 18:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c2fd5948145 Merge Changeset: 15fba4382765 Author: stefank Date: 2012-09-28 14:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15fba4382765 Merge Changeset: 2cb2f30450c7 Author: twisti Date: 2012-09-17 12:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2cb2f30450c7 7196262: JSR 292: java/lang/invoke/PrivateInvokeTest.java fails on solaris-sparc Reviewed-by: kvn, jrose, bdelsart ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/asm/register.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 8d3cc6612bd1 Author: kvn Date: 2012-09-17 17:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d3cc6612bd1 7197033: missing ResourceMark for assert in Method::bci_from() Summary: Added missing ResourceMark. Reviewed-by: dholmes, coleenp, jmasa ! src/share/vm/oops/method.cpp Changeset: 137868b7aa6f Author: kvn Date: 2012-09-17 19:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/137868b7aa6f 7196199: java/text/Bidi/Bug6665028.java failed: Bidi run count incorrect Summary: Save whole XMM/YMM registers in safepoint interrupt handler. Reviewed-by: roland, twisti ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/x86.ad ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp + test/compiler/7196199/Test7196199.java Changeset: 9d89c76b0505 Author: twisti Date: 2012-09-19 10:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d89c76b0505 7198499: TraceTypeProfile as diagnostic option Reviewed-by: kvn Contributed-by: Aleksey Shipilev ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/doCall.cpp Changeset: 8ae8f9dd7099 Author: kvn Date: 2012-09-19 16:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ae8f9dd7099 7199010: incorrect vector alignment Summary: Fixed vectors alignment when several arrays are accessed in one loop. Reviewed-by: roland, twisti ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp Changeset: 7eca5de9e0b6 Author: roland Date: 2012-09-20 16:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7eca5de9e0b6 7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement() Summary: use shorter instruction sequences for atomic add and atomic exchange when possible. Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: b31471cdc53e Author: kvn Date: 2012-09-24 10:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b31471cdc53e 7200163: add CodeComments functionality to assember stubs Summary: Pass the codeBuffer to the Stub constructor, and adapts the disassembler to print the comments. Reviewed-by: jrose, kvn, twisti Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 3a327d0b8586 Author: twisti Date: 2012-09-24 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a327d0b8586 7188176: The JVM should differentiate between T and M series and adjust GC ergonomics Reviewed-by: kvn Contributed-by: Tao Mao ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp Changeset: f7c1f489db55 Author: twisti Date: 2012-09-24 12:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7c1f489db55 Merge Changeset: c92f43386117 Author: kvn Date: 2012-09-24 14:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c92f43386117 Merge ! src/share/vm/classfile/vmSymbols.hpp Changeset: 9191895df19d Author: twisti Date: 2012-09-24 17:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9191895df19d 7200001: failed C1 OSR compile doesn't get recompiled with C2 Reviewed-by: kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/accessFlags.hpp Changeset: 1a9b9cfcef41 Author: neliasso Date: 2012-03-29 16:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a9b9cfcef41 7163863: Updated projectcreator Summary: Enable source browsing for all platform dependent code Reviewed-by: brutisso, coleenp ! make/windows/makefiles/projectcreator.make ! src/share/tools/ProjectCreator/BuildConfig.java - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java + src/share/tools/ProjectCreator/FileTreeCreator.java + src/share/tools/ProjectCreator/FileTreeCreatorVC10.java + src/share/tools/ProjectCreator/FileTreeCreatorVC7.java ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/tools/ProjectCreator/Util.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java Changeset: 0702f188baeb Author: kvn Date: 2012-09-25 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0702f188baeb 7200233: C2: can't use expand rules for vector instruction rules Summary: Added missed _bottom_type set in ArchDesc::defineExpand() and missed vector nodes in MatchRule::is_vector(). Reviewed-by: twisti, roland, dlong ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 06f52c4d0e18 Author: kvn Date: 2012-09-25 15:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06f52c4d0e18 7200264: 7192963 changes disabled shift vectors Summary: Replaced is_vector_use() call with explicit check for vector shift's count. Reviewed-by: twisti, roland, dlong, vlivanov ! src/share/vm/opto/superword.cpp + test/compiler/7200264/Test7200264.sh + test/compiler/7200264/TestIntVect.java Changeset: e626685e9f6c Author: kvn Date: 2012-09-27 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e626685e9f6c 7193318: C2: remove number of inputs requirement from Node's new operator Summary: Deleted placement new operator of Node - node(size_t, Compile *, int). Reviewed-by: kvn, twisti Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp Changeset: 69fb89ec6fa7 Author: kvn Date: 2012-09-27 15:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69fb89ec6fa7 7198084: NPG: distance is too big for short branches in test_invocation_counter_for_mdp() Summary: use long branches in test_invocation_counter_for_mdp() Reviewed-by: twisti ! src/cpu/sparc/vm/interp_masm_sparc.cpp Changeset: f2e12eb74117 Author: kvn Date: 2012-09-28 10:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2e12eb74117 Merge - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp Changeset: 9f008ad79470 Author: amurillo Date: 2012-09-28 13:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f008ad79470 Added tag hs25-b03 for changeset f2e12eb74117 ! .hgtags Changeset: 2dd08e86a2bf Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2dd08e86a2bf Added tag jdk8-b58 for changeset 6bb378c50828 ! .hgtags Changeset: 8a1a6b9b4f20 Author: katleman Date: 2012-10-03 15:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a1a6b9b4f20 Merge ! .hgtags - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java Changeset: a3fd4914ac81 Author: katleman Date: 2012-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a3fd4914ac81 Added tag jdk8-b59 for changeset 8a1a6b9b4f20 ! .hgtags Changeset: 1b582b1bf7cb Author: amurillo Date: 2012-09-28 14:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b582b1bf7cb 8000251: new hotspot build - hs25-b04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 988bf00cc564 Author: johnc Date: 2012-09-27 15:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/988bf00cc564 7200261: G1: Liveness counting inconsistencies during marking verification Summary: The clipping code in the routine that sets the bits for a range of cards, in the liveness accounting verification code was incorrect. It set all the bits in the card bitmap from the given starting index which would lead to spurious marking verification failures. Reviewed-by: brutisso, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp Changeset: 5c8fbbfed964 Author: stefank Date: 2012-10-01 11:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c8fbbfed964 Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java Changeset: 85f1cded9793 Author: stefank Date: 2012-09-28 15:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85f1cded9793 8000230: Change os::print_location to be more descriptive when a location is pointing into an object Reviewed-by: mgerdin, twisti ! src/share/vm/runtime/os.cpp Changeset: 86af3dacab81 Author: stefank Date: 2012-10-01 13:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86af3dacab81 8000227: [obj|type]ArrayKlass::oop_print_on prints one line to tty instead of the provided output stream Reviewed-by: brutisso, sla, jmasa, coleenp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp Changeset: 87ac5c0a404d Author: stefank Date: 2012-10-01 13:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/87ac5c0a404d 8000228: Missing call to cr() when printing entry_point in nmethod, in os::print_location Reviewed-by: brutisso, neliasso ! src/share/vm/runtime/os.cpp Changeset: f81a7c0c618d Author: jmasa Date: 2012-10-03 08:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f81a7c0c618d 7199349: NPG: PS: Crash seen in jprt Reviewed-by: johnc ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/runtime/globals.hpp Changeset: 22b8d3d181d9 Author: jwilhelm Date: 2012-10-03 20:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22b8d3d181d9 8000351: Tenuring threshold should be unsigned Summary: Change the flags and variables related to tenuring threshold to be unsigned Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 2e6857353b2c Author: johnc Date: 2012-10-04 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e6857353b2c 8000311: G1: ParallelGCThreads==0 broken Summary: Divide by zero error, if ParallelGCThreads is 0, when adjusting the PLAB size. Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp Changeset: 097d78aaf2b5 Author: jmasa Date: 2012-10-04 10:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/097d78aaf2b5 7198873: NPG: VM Does not unload classes with UseConcMarkSweepGC Reviewed-by: johnc, mgerdin, jwilhelm ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: ca70b919819f Author: jmasa Date: 2012-10-04 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca70b919819f Merge Changeset: f6b0eb4e44cf Author: twisti Date: 2012-10-01 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6b0eb4e44cf 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path Reviewed-by: jrose, kvn ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciClassList.hpp + src/share/vm/ci/ciMethodType.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp Changeset: 859c45fb8cea Author: kvn Date: 2012-10-02 12:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/859c45fb8cea 7201026: add vector for shift count Summary: Add generation of vectors for scalar shift count. Reviewed-by: roland, twisti, dlong ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp ! test/compiler/7200264/Test7200264.sh Changeset: f13867c41f73 Author: kvn Date: 2012-10-02 14:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f13867c41f73 7199742: A lot of C2 OSR compilations of the same method's bci Summary: Don't clone head of OSR loop. Reviewed-by: jrose, twisti ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/opto/parse1.cpp + test/compiler/7199742/Test7199742.java Changeset: bf2edd3c9b0f Author: neliasso Date: 2012-10-04 06:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf2edd3c9b0f 8000102: Resolve include conflicts Summary: Removing include of c1/c1_runtime.hpp and opto/runtime.hpp from all os-files. Reviewed-by: kvn Contributed-by: nils.eliasson at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp Changeset: 685457683e86 Author: kvn Date: 2012-10-05 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/685457683e86 Merge Changeset: 1cc7a2a11d00 Author: amurillo Date: 2012-10-05 13:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cc7a2a11d00 Merge Changeset: 3cfd05b2219a Author: amurillo Date: 2012-10-05 13:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3cfd05b2219a Added tag hs25-b04 for changeset 1cc7a2a11d00 ! .hgtags Changeset: 0cc77f9b31ad Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0cc77f9b31ad Added tag jdk8-b60 for changeset 3cfd05b2219a ! .hgtags From lana.steuck at oracle.com Fri Oct 12 15:35:02 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Oct 2012 22:35:02 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20121012223514.05DCF47344@hg.openjdk.java.net> Changeset: af9e8b0f1900 Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/af9e8b0f1900 Added tag jdk8-b58 for changeset 1cb19abb3f7b ! .hgtags Changeset: 2d1dff5310da Author: katleman Date: 2012-10-04 14:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2d1dff5310da Added tag jdk8-b59 for changeset af9e8b0f1900 ! .hgtags Changeset: 6b1db0b41d2f Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6b1db0b41d2f Added tag jdk8-b60 for changeset 2d1dff5310da ! .hgtags Changeset: b545c99e4f5e Author: lana Date: 2012-10-12 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b545c99e4f5e Merge From lana.steuck at oracle.com Fri Oct 12 15:35:19 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Oct 2012 22:35:19 +0000 Subject: hg: jdk8/tl/jaxws: 3 new changesets Message-ID: <20121012223526.DD16847346@hg.openjdk.java.net> Changeset: ae107401be11 Author: katleman Date: 2012-09-27 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ae107401be11 Added tag jdk8-b58 for changeset cac4c3937063 ! .hgtags Changeset: 5c5a65ad5291 Author: katleman Date: 2012-10-04 14:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/5c5a65ad5291 Added tag jdk8-b59 for changeset ae107401be11 ! .hgtags Changeset: 97e5e74e2a34 Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/97e5e74e2a34 Added tag jdk8-b60 for changeset 5c5a65ad5291 ! .hgtags From lana.steuck at oracle.com Fri Oct 12 15:36:28 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Oct 2012 22:36:28 +0000 Subject: hg: jdk8/tl/jdk: 22 new changesets Message-ID: <20121012224050.66FFF47347@hg.openjdk.java.net> Changeset: abad1f417bd3 Author: katleman Date: 2012-09-27 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abad1f417bd3 Added tag jdk8-b58 for changeset d94613ac03d8 ! .hgtags Changeset: cec8fa02f156 Author: katleman Date: 2012-10-04 14:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cec8fa02f156 Added tag jdk8-b59 for changeset abad1f417bd3 ! .hgtags Changeset: 869519bc17ce Author: katleman Date: 2012-10-11 09:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/869519bc17ce Added tag jdk8-b60 for changeset cec8fa02f156 ! .hgtags Changeset: 4d8b411a2bc1 Author: jgodinez Date: 2012-09-25 09:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d8b411a2bc1 7158350: [macosx] Strange results of SwingUIText printing Reviewed-by: bae, prr ! src/macosx/native/sun/awt/CTextPipe.m Changeset: 5aff878baaf6 Author: lana Date: 2012-09-28 11:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5aff878baaf6 Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 8dd4cae72975 Author: ceisserer Date: 2012-10-01 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8dd4cae72975 7188093: closed/sun/java2d/pipe/ScaleQualityTest.java fails Reviewed-by: prr, flar ! src/solaris/classes/sun/java2d/xr/XRDrawImage.java Changeset: 89a1094e384f Author: bae Date: 2012-10-05 16:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89a1094e384f 8000176: Need automated test for checking scale quality Reviewed-by: prr, bae Contributed-by: Vadim Pakhnushev + test/sun/java2d/pipe/InterpolationQualityTest.java Changeset: 2bc7669294cc Author: lana Date: 2012-10-08 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bc7669294cc Merge Changeset: 9aa37a39cf39 Author: zhouyx Date: 2012-09-20 17:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9aa37a39cf39 7194184: JColorChooser swatch cannot accessed from keyboard Reviewed-by: rupashka, alexsch ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java + test/javax/swing/JColorChooser/Test7194184.java Changeset: 4f519691520c Author: vkarnauk Date: 2012-09-20 17:55 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f519691520c 7123767: Wrong tooltip location in Multi-Monitor configurations Reviewed-by: rupashka ! src/share/classes/javax/swing/ToolTipManager.java + test/javax/swing/ToolTipManager/7123767/bug7123767.java Changeset: adddc599e551 Author: alexsch Date: 2012-09-21 13:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/adddc599e551 7199180: [macosx] Dead keys handling for input methods Reviewed-by: kizune, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/AWTView.m + test/java/awt/event/KeyEvent/DeadKey/DeadKeyMacOSXInputText.java Changeset: 88048b34405e Author: leonidr Date: 2012-09-24 15:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88048b34405e 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper Reviewed-by: anthony ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/osxapp/NSApplicationAWT.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m Changeset: d6cba7bfbb3d Author: leonidr Date: 2012-09-24 18:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6cba7bfbb3d 7179349: [macosx] Java processes on Mac should not use default Apple icon Reviewed-by: anthony ! make/sun/osxapp/Makefile + make/sun/osxapp/ToBin.java ! src/macosx/native/sun/osxapp/NSApplicationAWT.m + src/macosx/native/sun/osxapp/resource/icons/JavaApp.icns Changeset: 39227bb92978 Author: serb Date: 2012-09-24 21:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39227bb92978 7160627: [macosx] TextArea has wrong initial size 7124213: [macosx] pack() does ignore size of a component; doesn't on the other platforms Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWContainerPeer.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWPanelPeer.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java + test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java + test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java Changeset: c8da47a4d441 Author: alexsch Date: 2012-09-26 18:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8da47a4d441 7124515: [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) Reviewed-by: serb, anthony + test/java/awt/List/EmptyListEventTest/EmptyListEventTest.java Changeset: ad467dee852a Author: alexsch Date: 2012-09-28 14:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad467dee852a 7197619: Using modifiers for the dead key detection on Windows Reviewed-by: bagiras, leonidr ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h Changeset: 4b8bb77fdda9 Author: lana Date: 2012-09-28 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b8bb77fdda9 Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 3ac112755bb5 Author: bagiras Date: 2012-10-03 21:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ac112755bb5 7171412: awt Choice doesn't fire ItemStateChange when selecting item after select() call Reviewed-by: art, denis ! src/macosx/native/sun/awt/InitIDs.m ! src/share/classes/java/awt/Choice.java ! src/solaris/native/sun/awt/initIDs.c ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h + test/java/awt/Choice/ItemStateChangeTest/ItemStateChangeTest.java Changeset: 27ee94051373 Author: lana Date: 2012-10-08 15:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27ee94051373 Merge Changeset: d8581143e11d Author: lana Date: 2012-10-08 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8581143e11d Merge - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: 61ddb3fd000a Author: lana Date: 2012-10-11 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61ddb3fd000a Merge - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: e23f8e0a1d89 Author: lana Date: 2012-10-12 14:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e23f8e0a1d89 Merge From lana.steuck at oracle.com Fri Oct 12 15:44:23 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Oct 2012 22:44:23 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20121012224440.3214447348@hg.openjdk.java.net> Changeset: f299927fc316 Author: katleman Date: 2012-09-27 11:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f299927fc316 Added tag jdk8-b58 for changeset 804a3fbc86e2 ! .hgtags Changeset: 3d2b98ffcb53 Author: katleman Date: 2012-10-04 14:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d2b98ffcb53 Added tag jdk8-b59 for changeset f299927fc316 ! .hgtags Changeset: 67f7408d935e Author: katleman Date: 2012-10-11 09:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/67f7408d935e Added tag jdk8-b60 for changeset 3d2b98ffcb53 ! .hgtags Changeset: aa3ef5c09b1b Author: lana Date: 2012-10-08 15:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aa3ef5c09b1b Merge Changeset: 26020b247ad3 Author: lana Date: 2012-10-11 17:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/26020b247ad3 Merge Changeset: 0d1818e9d4ae Author: lana Date: 2012-10-12 14:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d1818e9d4ae Merge From bradford.wetmore at oracle.com Fri Oct 12 17:00:55 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 12 Oct 2012 17:00:55 -0700 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <507634F3.9060703@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> Message-ID: <5078AF37.1080208@oracle.com> >> I guess you didn't need to have me as reviewer before going final with >> the CCC? >> > The CCC has been finalized. ;-) I though you have done with spec review. > Anyway, we still can make updates on specification within new bugs. That's fine, I just wasn't sure if you needed someone to "approve" the "final" version of the spec to move it to the next state. >> Just a comment: >> >> 459/468: Currently you have serverNames and sniMatchers as package >> private variables, so the ClientHandshaker/ServerHandshaker *could* >> inherit these variables rather than have a separate get methods. Or you >> could make them private and keep the get calls. >> > Good catch! I can look at your latest if you like, but probably not necessary. >> I'm just not seeing why this implies that it requires *EVERY* name must >> match. This just says we can do one of two things upon receipt of an >> unrecognized hostname: continue on, or alert/close. We can be very >> restrictive (ALL/AND) or less so (at least one/OR), and still be within >> the RFC, I think. >> > I agree with your parser. > >>> In our spec, it is required that once a SNIMatcher is defined, it >>> will be used to recognized the server name in the SNI extension. >> >> Where? We do say in SNIMatcher: >> >> Servers can use Server Name Indication (SNI) information to decide if >> specific {@link SSLSocket} or {@link SSLEngine} instances should >> accept a connection. >> >> But I don't think we have ever said that it MUST match or must match all >> or even what the implementation must do if there is a match failure. Nor >> should we specify that in the API, IMHO. That's implementation behavior. >> > I may have different options on this point. I think, it must be a > specified behavior in Java. Otherwise, it is very confusing about how to > use 1+ server names in server side. I am going suggest we ask for guidance from IETF about this. It is not clear from RFC 6066 how to handle multiple SNI types, even reading very generously between the lines. See below. > Let's start from the logic of the design. If the specification is not > clear, I will rewrite the spec according to our agreement. > > Let's start from the requirement. I think once a SNIMatcher is defined > in SSL parameters, it MUST be used to perform the match operations if > the corresponding server name appears in the SNI extension. Otherwise, > what will happens? See the example: > 1. SNI extension contains HostName, "www.example.com". > 2. Server side defines SNIMatcher for HostName, to accept > "www.example.org". Server does not accept "www.example.com". > 3. What's the result of the handshake? Is the SNI extension is accetable? www.example.org != www.example.com. I would say fail handshake with unknown_hostname. > If we do not define the spec about how to use SNIMatcher. The answer to > #3 is unclear. Because if a SNIMatcher may be used to perform match > operation, and may be not used to perform match operation, then the > server may accept the SNI extension, may ignore the SNI extension, may > reject the SNI extension. It is useless to define SNIMatcher. > > I think the requirement is clear that it is a must to use SNIMatcher to > perform the match operation if the corresponding server name appears in > the SNI extension. I think it is true for the case when there is only > one server name type, at least. I completely agree. > Let's look more about what happens when there is 1+ server name types in > the SNI extension. Let's use the example in your previous mail. > > SNIHostname: "example.com" > SNINickName: "www.example.com" > > SNIMatcher: "example.com" > SNINickNameMatcher: "www1.example.com > > Suppose that the server is able to understand both HostName and > NickName. In the above example, server is able to recognize HostName, > but not NickName. Then should the server includes an extension of type > "server_name" in the (extended) server hello? > > If the server_name extension is included, it is unclear for client side > which one is accepted. The presence of a server's server_name extension indicates that an SNI value was used to guide the selection of an appropriate cert. It seems ambiguous in RFC 6066 as to whether this extension indicated "ALL" or "AT LEAST ONE" SNI value guided the selection. I might lean towards ALL since RFC 6066 says "The 'extension_data' field of this extension SHALL be empty". If it AT LEAST ONE were meant, there is no way of indicating *which* extension was used, or if multiple ones were used. As an aside, we have no API for the KeyManagers's to indicate whether they actually used a SNI extension, so I think you are currently sending a server server_name extension if any cert was selected. I don't think this is a major problem given our current APIs. Because the client side may need to use the > server_name to do endpoint identification, it is not safe to use > "www.example.com" to perform endpoint identification because the server > side does not accept it. > > If the server_name extension is not included, it does not follow the > spec when server side is able to recognize the server name. > > So, I will prefer that once a SNIMatcher is defined, it must be used to > perform match operation if the corresponding server name type appears in > the SNI extension. > > I think we need to adjust the spec to make the behavior more clear. I > will adjust the spec of SNIMatcher a little: > * the exact server that the client wants to access. Instances of this > - * class can be used by a server to verify the acceptable server names > + * class is used by a server to verify the acceptable server names I think I still prefer "can be used" because some servers won't accept SNI info, and this indicates to me that it absolutely will be used in all situations. Unless you said something like "are used by servers which recognize the extension..." But that gets wordy. > * of a particular type, such as host names. > > And SSLParameters.getSNIMatchers() > *

    > * This method is only useful to {@link SSLSocket}s or > * {@link SSLEngine}s operating in server mode. > + *

    > + * Every {@code SNIMatcher} in the returned {@link Collection} must > + * be used to perform match operation if the corresponding name > + * type appears in the SNI extension. > *

    > * For better interoperability, providers generally will not define > * default matchers so that by default servers will ignore the SNI > * extension and continue the handshake. > > What do you think? I think what you had is fine, and I suggest we go with it for now. I think we can and should ask for clarification at IETF as to the intent, and we add this new paragraph as an enhancement if they are in agreement. If there is no agreement there, then we could just call it a implementation detail and continue using AND. > I may not need a new bug or CCC request because the > update is minor. Actually, I think this is a little more than a minor change. Which reminds me, is your server code sending SNI extensions for anonymous suites? >>>> 2509: Something to investigate: you are depending on SSLParameters >>>> returning an unmodifiable list. But a subclass might not do that. Can >>>> you think of any situations where this might be a bad idea? If so, then >>>> we might want to change the unmodifiable language in SSLParameters and >>>> do regular cloning. This will have repercussions in other areas, like >>>> around 2527/2532, where you'll need to pass a copy to the Handshaker. >>>> >>> Well, I understand that something bad would happen if the subclass does >>> not follow the method spec while doing method implementation overriding. >> >> Yes, it was just something to think about. Of course, I'm trying to >> think of exploit situations, since you're really just hurting yourself >> if tweak this in the middle of a handshake. >> >> If I see Joe Darcy around, I'll check in with him. >> > Thanks! I really think we need to think about it more and carefully. The > style (immutable returned value in none-final method) does impact the > reliability of the APIs. I talked to Joe, and it's one of those grey areas. It's ultimately your own fault if you misuse the API like this. However, if there were potential vulnerability issues, that would be different. Given what this API does, I don't see anything like that here. But you're right, it's not reliable which is why I brought it up. Brad >>> Let's have the spec and implementation as it is. We can update the spec >>> and implementation if we have strong concerns or a common solution for >>> the issue before JDK 8 officially release. >> >> I'm fine with this. >> >>>> sun/security/ssl/X509TrustManagerImpl.java >>>> ========================================== >>>> OK >>>> >>> All of other comments are accepted. >>> >>> I think there is no major concerns so far. >> >> None still outstanding. I looked over the previous comments I've made >> and what you've done to address them, and all looks good minus the >> little points above. >> > Good! It seems that we only have one question, how to use SNIMatachers? > See above. > > Thanks, > Xuelei > > >>> Thank you so much for the >>> detailed evaluation and comments on both spec and implementation. TLS >>> and its implementation is very complicated, your support is the critical >>> success factor to deliver quality product. >> >> Thanks, and be sure to give yourself a lot of that credit. With all the >> back/forth and development this feature has seen, I think you've done a >> great job. >> >> Brad >> > From Xuelei.Fan at Oracle.Com Fri Oct 12 19:17:45 2012 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Sat, 13 Oct 2012 10:17:45 +0800 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <5078AF37.1080208@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> <5078AF37.1080208@oracle.com> Message-ID: <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> I have no access to office network, just a quick reply. I want add final keyword for the new methods in SSLParameters. See below. Sent from my iPad On Oct 13, 2012, at 8:00 AM, Brad Wetmore wrote: > >>> I guess you didn't need to have me as reviewer before going final with >>> the CCC? >> The CCC has been finalized. ;-) I though you have done with spec review. >> Anyway, we still can make updates on specification within new bugs. > > That's fine, I just wasn't sure if you needed someone to "approve" the "final" version of the spec to move it to the next state. > >>> Just a comment: >>> >>> 459/468: Currently you have serverNames and sniMatchers as package >>> private variables, so the ClientHandshaker/ServerHandshaker *could* >>> inherit these variables rather than have a separate get methods. Or you >>> could make them private and keep the get calls. >> Good catch! > > I can look at your latest if you like, but probably not necessary. > I will send the new webrev tonight my time. >>> I'm just not seeing why this implies that it requires *EVERY* name must >>> match. This just says we can do one of two things upon receipt of an >>> unrecognized hostname: continue on, or alert/close. We can be very >>> restrictive (ALL/AND) or less so (at least one/OR), and still be within >>> the RFC, I think. >> I agree with your parser. >> >>>> In our spec, it is required that once a SNIMatcher is defined, it >>>> will be used to recognized the server name in the SNI extension. >>> >>> Where? We do say in SNIMatcher: >>> >>> Servers can use Server Name Indication (SNI) information to decide if >>> specific {@link SSLSocket} or {@link SSLEngine} instances should >>> accept a connection. >>> >>> But I don't think we have ever said that it MUST match or must match all >>> or even what the implementation must do if there is a match failure. Nor >>> should we specify that in the API, IMHO. That's implementation behavior. >> I may have different options on this point. I think, it must be a >> specified behavior in Java. Otherwise, it is very confusing about how to >> use 1+ server names in server side. > > I am going suggest we ask for guidance from IETF about this. It is not clear from RFC 6066 how to handle multiple SNI types, even reading very generously between the lines. See below. > >> Let's start from the logic of the design. If the specification is not >> clear, I will rewrite the spec according to our agreement. >> >> Let's start from the requirement. I think once a SNIMatcher is defined >> in SSL parameters, it MUST be used to perform the match operations if >> the corresponding server name appears in the SNI extension. Otherwise, >> what will happens? See the example: >> 1. SNI extension contains HostName, "www.example.com". >> 2. Server side defines SNIMatcher for HostName, to accept >> "www.example.org". Server does not accept "www.example.com". >> 3. What's the result of the handshake? Is the SNI extension is accetable? > > www.example.org != www.example.com. I would say fail handshake with unknown_hostname. > >> If we do not define the spec about how to use SNIMatcher. The answer to >> #3 is unclear. Because if a SNIMatcher may be used to perform match >> operation, and may be not used to perform match operation, then the >> server may accept the SNI extension, may ignore the SNI extension, may >> reject the SNI extension. It is useless to define SNIMatcher. >> >> I think the requirement is clear that it is a must to use SNIMatcher to >> perform the match operation if the corresponding server name appears in >> the SNI extension. I think it is true for the case when there is only >> one server name type, at least. > > I completely agree. > >> Let's look more about what happens when there is 1+ server name types in >> the SNI extension. Let's use the example in your previous mail. >> >> SNIHostname: "example.com" >> SNINickName: "www.example.com" >> >> SNIMatcher: "example.com" >> SNINickNameMatcher: "www1.example.com >> >> Suppose that the server is able to understand both HostName and >> NickName. In the above example, server is able to recognize HostName, >> but not NickName. Then should the server includes an extension of type >> "server_name" in the (extended) server hello? >> >> If the server_name extension is included, it is unclear for client side >> which one is accepted. > > The presence of a server's server_name extension indicates that an SNI value was used to guide the selection of an appropriate cert. It seems ambiguous in RFC 6066 as to whether this extension indicated "ALL" or "AT LEAST ONE" SNI value guided the selection. I might lean towards ALL since RFC 6066 says "The 'extension_data' field of this extension SHALL be empty". If it AT LEAST ONE were meant, there is no way of indicating *which* extension was used, or if multiple ones were used. > > As an aside, we have no API for the KeyManagers's to indicate whether they actually used a SNI extension, so I think you are currently sending a server server_name extension if any cert was selected. I don't think this is a major problem given our current APIs. > A server name indication extension will be sent whenever the name is recognizable by the matches. I did not check for the types of cipher suites. I think it is the proper approach because although for anonymous cipher cuties, there is not certificates, but the ssl context may be different, so it is still can be regarded as the server do something different related to the specified SNI. > Because the client side may need to use the >> server_name to do endpoint identification, it is not safe to use >> "www.example.com" to perform endpoint identification because the server >> side does not accept it. >> >> If the server_name extension is not included, it does not follow the >> spec when server side is able to recognize the server name. >> >> So, I will prefer that once a SNIMatcher is defined, it must be used to >> perform match operation if the corresponding server name type appears in >> the SNI extension. >> >> I think we need to adjust the spec to make the behavior more clear. I >> will adjust the spec of SNIMatcher a little: >> * the exact server that the client wants to access. Instances of this >> - * class can be used by a server to verify the acceptable server names >> + * class is used by a server to verify the acceptable server names > > I think I still prefer "can be used" because some servers won't accept SNI info, and this indicates to me that it absolutely will be used in all situations. Unless you said something like "are used by servers which recognize the extension..." But that gets wordy. > >> * of a particular type, such as host names. >> >> And SSLParameters.getSNIMatchers() >> *

    >> * This method is only useful to {@link SSLSocket}s or >> * {@link SSLEngine}s operating in server mode. >> + *

    >> + * Every {@code SNIMatcher} in the returned {@link Collection} must >> + * be used to perform match operation if the corresponding name >> + * type appears in the SNI extension. >> *

    >> * For better interoperability, providers generally will not define >> * default matchers so that by default servers will ignore the SNI >> * extension and continue the handshake. >> >> What do you think? > > I think what you had is fine, and I suggest we go with it for now. I think we can and should ask for clarification at IETF as to the intent, and we add this new paragraph as an enhancement if they are in agreement. If there is no agreement there, then we could just call it a implementation detail and continue using AND. > Ok. Let's go with the current spec. >> I may not need a new bug or CCC request because the >> update is minor. > > Actually, I think this is a little more than a minor change. > > Which reminds me, is your server code sending SNI extensions for anonymous suites? > Yes. See above. >>>>> 2509: Something to investigate: you are depending on SSLParameters >>>>> returning an unmodifiable list. But a subclass might not do that. Can >>>>> you think of any situations where this might be a bad idea? If so, then >>>>> we might want to change the unmodifiable language in SSLParameters and >>>>> do regular cloning. This will have repercussions in other areas, like >>>>> around 2527/2532, where you'll need to pass a copy to the Handshaker. >>>> Well, I understand that something bad would happen if the subclass does >>>> not follow the method spec while doing method implementation overriding. >>> >>> Yes, it was just something to think about. Of course, I'm trying to >>> think of exploit situations, since you're really just hurting yourself >>> if tweak this in the middle of a handshake. >>> >>> If I see Joe Darcy around, I'll check in with him. >> Thanks! I really think we need to think about it more and carefully. The >> style (immutable returned value in none-final method) does impact the >> reliability of the APIs. > > I talked to Joe, and it's one of those grey areas. It's ultimately your own fault if you misuse the API like this. However, if there were potential vulnerability issues, that would be different. Given what this API does, I don't see anything like that here. But you're right, it's not reliable which is why I brought it up. > According to effective java, I would prefer to use final keyword for the new methods. I did not see clear requirements that customers need to override the methods. So I would like a stricter restriction for the new methods in case of any mis-use. Does it make sense to you? Xuelei > Brad > > > >>>> Let's have the spec and implementation as it is. We can update the spec >>>> and implementation if we have strong concerns or a common solution for >>>> the issue before JDK 8 officially release. >>> >>> I'm fine with this. >>> >>>>> sun/security/ssl/X509TrustManagerImpl.java >>>>> ========================================== >>>>> OK >>>> All of other comments are accepted. >>>> >>>> I think there is no major concerns so far. >>> >>> None still outstanding. I looked over the previous comments I've made >>> and what you've done to address them, and all looks good minus the >>> little points above. >> Good! It seems that we only have one question, how to use SNIMatachers? >> See above. >> >> Thanks, >> Xuelei >> >> >>>> Thank you so much for the >>>> detailed evaluation and comments on both spec and implementation. TLS >>>> and its implementation is very complicated, your support is the critical >>>> success factor to deliver quality product. >>> >>> Thanks, and be sure to give yourself a lot of that credit. With all the >>> back/forth and development this feature has seen, I think you've done a >>> great job. >>> >>> Brad >> From alan.bateman at oracle.com Sat Oct 13 02:16:08 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 13 Oct 2012 09:16:08 +0000 Subject: hg: jdk8/tl/jdk: 7146552: java/util/logging/LoggingMXBeanTest.java failing intermittently Message-ID: <20121013091652.5534847359@hg.openjdk.java.net> Changeset: ff641c5b329b Author: jgish Date: 2012-10-13 10:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff641c5b329b 7146552: java/util/logging/LoggingMXBeanTest.java failing intermittently Reviewed-by: alanb, mchung ! test/java/util/logging/LoggingMXBeanTest.java ! test/java/util/logging/LoggingMXBeanTest2.java From xuelei.fan at oracle.com Sat Oct 13 06:26:26 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 13 Oct 2012 21:26:26 +0800 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> <5078AF37.1080208@oracle.com> <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> Message-ID: <50796C02.6010703@oracle.com> New webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.14/ The main update is to add "final" keyword to the new methods in SSLParamaters. I prefer to use the final because I don't see a requirement to override them. But I can go with the version with or without the "final" keyword. I think you properly don't need to review other parts of the webrev any more, no other major update. Thanks, Xuelei On 10/13/2012 10:17 AM, Xuelei Fan wrote: > I have no access to office network, just a quick reply. I want add final keyword for the new methods in SSLParameters. See below. > > Sent from my iPad > > On Oct 13, 2012, at 8:00 AM, Brad Wetmore wrote: > >> >>>> I guess you didn't need to have me as reviewer before going final with >>>> the CCC? >>> The CCC has been finalized. ;-) I though you have done with spec review. >>> Anyway, we still can make updates on specification within new bugs. >> >> That's fine, I just wasn't sure if you needed someone to "approve" the "final" version of the spec to move it to the next state. >> >>>> Just a comment: >>>> >>>> 459/468: Currently you have serverNames and sniMatchers as package >>>> private variables, so the ClientHandshaker/ServerHandshaker *could* >>>> inherit these variables rather than have a separate get methods. Or you >>>> could make them private and keep the get calls. >>> Good catch! >> >> I can look at your latest if you like, but probably not necessary. >> > I will send the new webrev tonight my time. > >>>> I'm just not seeing why this implies that it requires *EVERY* name must >>>> match. This just says we can do one of two things upon receipt of an >>>> unrecognized hostname: continue on, or alert/close. We can be very >>>> restrictive (ALL/AND) or less so (at least one/OR), and still be within >>>> the RFC, I think. >>> I agree with your parser. >>> >>>>> In our spec, it is required that once a SNIMatcher is defined, it >>>>> will be used to recognized the server name in the SNI extension. >>>> >>>> Where? We do say in SNIMatcher: >>>> >>>> Servers can use Server Name Indication (SNI) information to decide if >>>> specific {@link SSLSocket} or {@link SSLEngine} instances should >>>> accept a connection. >>>> >>>> But I don't think we have ever said that it MUST match or must match all >>>> or even what the implementation must do if there is a match failure. Nor >>>> should we specify that in the API, IMHO. That's implementation behavior. >>> I may have different options on this point. I think, it must be a >>> specified behavior in Java. Otherwise, it is very confusing about how to >>> use 1+ server names in server side. >> >> I am going suggest we ask for guidance from IETF about this. It is not clear from RFC 6066 how to handle multiple SNI types, even reading very generously between the lines. See below. >> >>> Let's start from the logic of the design. If the specification is not >>> clear, I will rewrite the spec according to our agreement. >>> >>> Let's start from the requirement. I think once a SNIMatcher is defined >>> in SSL parameters, it MUST be used to perform the match operations if >>> the corresponding server name appears in the SNI extension. Otherwise, >>> what will happens? See the example: >>> 1. SNI extension contains HostName, "www.example.com". >>> 2. Server side defines SNIMatcher for HostName, to accept >>> "www.example.org". Server does not accept "www.example.com". >>> 3. What's the result of the handshake? Is the SNI extension is accetable? >> >> www.example.org != www.example.com. I would say fail handshake with unknown_hostname. >> >>> If we do not define the spec about how to use SNIMatcher. The answer to >>> #3 is unclear. Because if a SNIMatcher may be used to perform match >>> operation, and may be not used to perform match operation, then the >>> server may accept the SNI extension, may ignore the SNI extension, may >>> reject the SNI extension. It is useless to define SNIMatcher. >>> >>> I think the requirement is clear that it is a must to use SNIMatcher to >>> perform the match operation if the corresponding server name appears in >>> the SNI extension. I think it is true for the case when there is only >>> one server name type, at least. >> >> I completely agree. >> >>> Let's look more about what happens when there is 1+ server name types in >>> the SNI extension. Let's use the example in your previous mail. >>> >>> SNIHostname: "example.com" >>> SNINickName: "www.example.com" >>> >>> SNIMatcher: "example.com" >>> SNINickNameMatcher: "www1.example.com >>> >>> Suppose that the server is able to understand both HostName and >>> NickName. In the above example, server is able to recognize HostName, >>> but not NickName. Then should the server includes an extension of type >>> "server_name" in the (extended) server hello? >>> >>> If the server_name extension is included, it is unclear for client side >>> which one is accepted. >> >> The presence of a server's server_name extension indicates that an SNI value was used to guide the selection of an appropriate cert. It seems ambiguous in RFC 6066 as to whether this extension indicated "ALL" or "AT LEAST ONE" SNI value guided the selection. I might lean towards ALL since RFC 6066 says "The 'extension_data' field of this extension SHALL be empty". If it AT LEAST ONE were meant, there is no way of indicating *which* extension was used, or if multiple ones were used. >> >> As an aside, we have no API for the KeyManagers's to indicate whether they actually used a SNI extension, so I think you are currently sending a server server_name extension if any cert was selected. I don't think this is a major problem given our current APIs. >> > A server name indication extension will be sent whenever the name is recognizable by the matches. I did not check for the types of cipher suites. I think it is the proper approach because although for anonymous cipher cuties, there is not certificates, but the ssl context may be different, so it is still can be regarded as the server do something different related to the specified SNI. > >> Because the client side may need to use the >>> server_name to do endpoint identification, it is not safe to use >>> "www.example.com" to perform endpoint identification because the server >>> side does not accept it. >>> >>> If the server_name extension is not included, it does not follow the >>> spec when server side is able to recognize the server name. >>> >>> So, I will prefer that once a SNIMatcher is defined, it must be used to >>> perform match operation if the corresponding server name type appears in >>> the SNI extension. >>> >>> I think we need to adjust the spec to make the behavior more clear. I >>> will adjust the spec of SNIMatcher a little: >>> * the exact server that the client wants to access. Instances of this >>> - * class can be used by a server to verify the acceptable server names >>> + * class is used by a server to verify the acceptable server names >> >> I think I still prefer "can be used" because some servers won't accept SNI info, and this indicates to me that it absolutely will be used in all situations. Unless you said something like "are used by servers which recognize the extension..." But that gets wordy. >> >>> * of a particular type, such as host names. >>> >>> And SSLParameters.getSNIMatchers() >>> *

    >>> * This method is only useful to {@link SSLSocket}s or >>> * {@link SSLEngine}s operating in server mode. >>> + *

    >>> + * Every {@code SNIMatcher} in the returned {@link Collection} must >>> + * be used to perform match operation if the corresponding name >>> + * type appears in the SNI extension. >>> *

    >>> * For better interoperability, providers generally will not define >>> * default matchers so that by default servers will ignore the SNI >>> * extension and continue the handshake. >>> >>> What do you think? >> >> I think what you had is fine, and I suggest we go with it for now. I think we can and should ask for clarification at IETF as to the intent, and we add this new paragraph as an enhancement if they are in agreement. If there is no agreement there, then we could just call it a implementation detail and continue using AND. >> > Ok. Let's go with the current spec. > >>> I may not need a new bug or CCC request because the >>> update is minor. >> >> Actually, I think this is a little more than a minor change. >> >> Which reminds me, is your server code sending SNI extensions for anonymous suites? >> > Yes. See above. > >>>>>> 2509: Something to investigate: you are depending on SSLParameters >>>>>> returning an unmodifiable list. But a subclass might not do that. Can >>>>>> you think of any situations where this might be a bad idea? If so, then >>>>>> we might want to change the unmodifiable language in SSLParameters and >>>>>> do regular cloning. This will have repercussions in other areas, like >>>>>> around 2527/2532, where you'll need to pass a copy to the Handshaker. >>>>> Well, I understand that something bad would happen if the subclass does >>>>> not follow the method spec while doing method implementation overriding. >>>> >>>> Yes, it was just something to think about. Of course, I'm trying to >>>> think of exploit situations, since you're really just hurting yourself >>>> if tweak this in the middle of a handshake. >>>> >>>> If I see Joe Darcy around, I'll check in with him. >>> Thanks! I really think we need to think about it more and carefully. The >>> style (immutable returned value in none-final method) does impact the >>> reliability of the APIs. >> >> I talked to Joe, and it's one of those grey areas. It's ultimately your own fault if you misuse the API like this. However, if there were potential vulnerability issues, that would be different. Given what this API does, I don't see anything like that here. But you're right, it's not reliable which is why I brought it up. >> > According to effective java, I would prefer to use final keyword for the new methods. I did not see clear requirements that customers need to override the methods. So I would like a stricter restriction for the new methods in case of any mis-use. Does it make sense to you? > > Xuelei > >> Brad >> >> >> >>>>> Let's have the spec and implementation as it is. We can update the spec >>>>> and implementation if we have strong concerns or a common solution for >>>>> the issue before JDK 8 officially release. >>>> >>>> I'm fine with this. >>>> >>>>>> sun/security/ssl/X509TrustManagerImpl.java >>>>>> ========================================== >>>>>> OK >>>>> All of other comments are accepted. >>>>> >>>>> I think there is no major concerns so far. >>>> >>>> None still outstanding. I looked over the previous comments I've made >>>> and what you've done to address them, and all looks good minus the >>>> little points above. >>> Good! It seems that we only have one question, how to use SNIMatachers? >>> See above. >>> >>> Thanks, >>> Xuelei >>> >>> >>>>> Thank you so much for the >>>>> detailed evaluation and comments on both spec and implementation. TLS >>>>> and its implementation is very complicated, your support is the critical >>>>> success factor to deliver quality product. >>>> >>>> Thanks, and be sure to give yourself a lot of that credit. With all the >>>> back/forth and development this feature has seen, I think you've done a >>>> great job. >>>> >>>> Brad >>> From alan.bateman at oracle.com Sun Oct 14 15:06:58 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 14 Oct 2012 22:06:58 +0000 Subject: hg: jdk8/tl/jdk: 7194449: String resources for Key Tool and Policy Tool should be in their respective packages Message-ID: <20121014220728.6528947369@hg.openjdk.java.net> Changeset: fe28e0b035e7 Author: sflores Date: 2012-10-14 22:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe28e0b035e7 7194449: String resources for Key Tool and Policy Tool should be in their respective packages Reviewed-by: alanb, weijun, mullan ! make/common/Release.gmk ! make/launchers/Makefile ! make/sun/security/tools/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/tools/KeyStoreUtil.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java + src/share/classes/sun/security/tools/jarsigner/Main.java + src/share/classes/sun/security/tools/jarsigner/Resources.java + src/share/classes/sun/security/tools/jarsigner/Resources_ja.java + src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java + src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java + src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java + src/share/classes/sun/security/tools/keytool/Main.java + src/share/classes/sun/security/tools/keytool/Resources.java + src/share/classes/sun/security/tools/keytool/Resources_de.java + src/share/classes/sun/security/tools/keytool/Resources_es.java + src/share/classes/sun/security/tools/keytool/Resources_fr.java + src/share/classes/sun/security/tools/keytool/Resources_it.java + src/share/classes/sun/security/tools/keytool/Resources_ja.java + src/share/classes/sun/security/tools/keytool/Resources_ko.java + src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java + src/share/classes/sun/security/tools/keytool/Resources_sv.java + src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java + src/share/classes/sun/security/tools/keytool/Resources_zh_HK.java + src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java + src/share/classes/sun/security/tools/policytool/Resources.java + src/share/classes/sun/security/tools/policytool/Resources_de.java + src/share/classes/sun/security/tools/policytool/Resources_es.java + src/share/classes/sun/security/tools/policytool/Resources_fr.java + src/share/classes/sun/security/tools/policytool/Resources_it.java + src/share/classes/sun/security/tools/policytool/Resources_ja.java + src/share/classes/sun/security/tools/policytool/Resources_ko.java + src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java + src/share/classes/sun/security/tools/policytool/Resources_sv.java + src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java + src/share/classes/sun/security/tools/policytool/Resources_zh_HK.java + src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java ! src/share/classes/sun/security/util/Resources.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/tools/jarsigner/JarSigningNonAscii.java ! test/sun/security/tools/jarsigner/LargeJarEntry.java ! test/sun/security/tools/keytool/CloseFile.java ! test/sun/security/tools/keytool/KeyToolTest.java ! test/sun/security/tools/keytool/NewSize7.java ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/tools/keytool/UnknownAndUnparseable.java ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/util/Resources/Format.java ! test/sun/security/util/Resources/NewNamesFormat.java ! test/sun/security/util/Resources/NewResourcesNames.java ! test/sun/security/x509/AlgorithmId/NonStandardNames.java From rob.mckenna at oracle.com Sun Oct 14 19:23:18 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Mon, 15 Oct 2012 02:23:18 +0000 Subject: hg: jdk8/tl/jdk: 8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java Message-ID: <20121015022331.216EF4736C@hg.openjdk.java.net> Changeset: 7055257a25c4 Author: robm Date: 2012-10-15 03:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7055257a25c4 8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java Reviewed-by: alanb, martin ! test/java/lang/ProcessBuilder/Basic.java From Alan.Bateman at oracle.com Mon Oct 15 05:17:24 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Oct 2012 13:17:24 +0100 Subject: jsse.jar still needed? Message-ID: <507BFED4.9030709@oracle.com> This might be a silly question but is jsse.jar needed any more? I think, but might be wrong, that it dates back to when JSSE was a extension. I'm curious if it would matter if the classes were moved to rt.jar? I'm also interested to understand why jsse.jar has sun.security.provider.Sun and sun.security.rsa.SunRsaSign. This creates the odd situation where most of the types in those packages are in rt.jar but it's just these two classes that are in jsse.jar. Thanks, -Alan From rob.mckenna at oracle.com Mon Oct 15 14:32:40 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Mon, 15 Oct 2012 21:32:40 +0000 Subject: hg: jdk8/tl/jdk: 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout Message-ID: <20121015213301.C26CB47388@hg.openjdk.java.net> Changeset: c0736b62160e Author: robm Date: 2012-10-15 22:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0736b62160e 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java + test/com/sun/jndi/ldap/LdapTimeoutTest.java - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java From bradford.wetmore at oracle.com Mon Oct 15 15:03:57 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 15 Oct 2012 15:03:57 -0700 Subject: jsse.jar still needed? In-Reply-To: <507BFED4.9030709@oracle.com> References: <507BFED4.9030709@oracle.com> Message-ID: <507C884D.7080400@oracle.com> On 10/15/2012 5:17 AM, Alan Bateman wrote: > > This might be a silly question but is jsse.jar needed any more? I think, > but might be wrong, that it dates back to when JSSE was a extension. I'm > curious if it would matter if the classes were moved to rt.jar? There are source licensee issues here. I'll talk to you about this offline. Brad > I'm also interested to understand why jsse.jar has > sun.security.provider.Sun and sun.security.rsa.SunRsaSign. This creates > the odd situation where most of the types in those packages are in > rt.jar but it's just these two classes that are in jsse.jar. > > Thanks, > > -Alan From bradford.wetmore at oracle.com Mon Oct 15 15:47:39 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 15 Oct 2012 15:47:39 -0700 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> <5078AF37.1080208@oracle.com> <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> Message-ID: <507C928B.6070809@oracle.com> > A server name indication extension will be sent whenever the name is > recognizable by the matches. I did not check for the types of > cipher suites. I think it is the proper approach because although for > anonymous cipher cuties, there is not certificates, but the ssl context > may be different, so it is still can be regarded as the server do something > different related to the specified SNI. True! > According to effective java, Item 15? It doesn't specifically talk about final methods, but I think I see where you are coming from since this class was originally non-final. > I would prefer to use final keyword for > the new methods. I did not see clear requirements that customers > need to override the methods. So I would like a stricter restriction > for the new methods in case of any mis-use. Does it make sense to you? Yes. I can't really think of why not, other than for potential extendability. Brad From bradford.wetmore at oracle.com Mon Oct 15 16:12:32 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 15 Oct 2012 16:12:32 -0700 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <50796C02.6010703@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> <5078AF37.1080208@oracle.com> <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> <50796C02.6010703@oracle.com> Message-ID: <507C9860.1060103@oracle.com> Looks good. > The main update is to add "final" keyword to the new methods in > SSLParamaters. I prefer to use the final because I don't see a > requirement to override them. Let me know when the new CCC is ready, I'll approve it. Are you going to contact IETF? Almost there. Brad On 10/13/2012 6:26 AM, Xuelei Fan wrote: > New webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.14/ > > The main update is to add "final" keyword to the new methods in > SSLParamaters. I prefer to use the final because I don't see a > requirement to override them. But I can go with the version with or > without the "final" keyword. I think you properly don't need to review > other parts of the webrev any more, no other major update. > > Thanks, > Xuelei > > > On 10/13/2012 10:17 AM, Xuelei Fan wrote: >> I have no access to office network, just a quick reply. I want add final keyword for the new methods in SSLParameters. See below. >> >> Sent from my iPad >> >> On Oct 13, 2012, at 8:00 AM, Brad Wetmore wrote: >> >>> >>>>> I guess you didn't need to have me as reviewer before going final with >>>>> the CCC? >>>> The CCC has been finalized. ;-) I though you have done with spec review. >>>> Anyway, we still can make updates on specification within new bugs. >>> >>> That's fine, I just wasn't sure if you needed someone to "approve" the "final" version of the spec to move it to the next state. >>> >>>>> Just a comment: >>>>> >>>>> 459/468: Currently you have serverNames and sniMatchers as package >>>>> private variables, so the ClientHandshaker/ServerHandshaker *could* >>>>> inherit these variables rather than have a separate get methods. Or you >>>>> could make them private and keep the get calls. >>>> Good catch! >>> >>> I can look at your latest if you like, but probably not necessary. >>> >> I will send the new webrev tonight my time. >> >>>>> I'm just not seeing why this implies that it requires *EVERY* name must >>>>> match. This just says we can do one of two things upon receipt of an >>>>> unrecognized hostname: continue on, or alert/close. We can be very >>>>> restrictive (ALL/AND) or less so (at least one/OR), and still be within >>>>> the RFC, I think. >>>> I agree with your parser. >>>> >>>>>> In our spec, it is required that once a SNIMatcher is defined, it >>>>>> will be used to recognized the server name in the SNI extension. >>>>> >>>>> Where? We do say in SNIMatcher: >>>>> >>>>> Servers can use Server Name Indication (SNI) information to decide if >>>>> specific {@link SSLSocket} or {@link SSLEngine} instances should >>>>> accept a connection. >>>>> >>>>> But I don't think we have ever said that it MUST match or must match all >>>>> or even what the implementation must do if there is a match failure. Nor >>>>> should we specify that in the API, IMHO. That's implementation behavior. >>>> I may have different options on this point. I think, it must be a >>>> specified behavior in Java. Otherwise, it is very confusing about how to >>>> use 1+ server names in server side. >>> >>> I am going suggest we ask for guidance from IETF about this. It is not clear from RFC 6066 how to handle multiple SNI types, even reading very generously between the lines. See below. >>> >>>> Let's start from the logic of the design. If the specification is not >>>> clear, I will rewrite the spec according to our agreement. >>>> >>>> Let's start from the requirement. I think once a SNIMatcher is defined >>>> in SSL parameters, it MUST be used to perform the match operations if >>>> the corresponding server name appears in the SNI extension. Otherwise, >>>> what will happens? See the example: >>>> 1. SNI extension contains HostName, "www.example.com". >>>> 2. Server side defines SNIMatcher for HostName, to accept >>>> "www.example.org". Server does not accept "www.example.com". >>>> 3. What's the result of the handshake? Is the SNI extension is accetable? >>> >>> www.example.org != www.example.com. I would say fail handshake with unknown_hostname. >>> >>>> If we do not define the spec about how to use SNIMatcher. The answer to >>>> #3 is unclear. Because if a SNIMatcher may be used to perform match >>>> operation, and may be not used to perform match operation, then the >>>> server may accept the SNI extension, may ignore the SNI extension, may >>>> reject the SNI extension. It is useless to define SNIMatcher. >>>> >>>> I think the requirement is clear that it is a must to use SNIMatcher to >>>> perform the match operation if the corresponding server name appears in >>>> the SNI extension. I think it is true for the case when there is only >>>> one server name type, at least. >>> >>> I completely agree. >>> >>>> Let's look more about what happens when there is 1+ server name types in >>>> the SNI extension. Let's use the example in your previous mail. >>>> >>>> SNIHostname: "example.com" >>>> SNINickName: "www.example.com" >>>> >>>> SNIMatcher: "example.com" >>>> SNINickNameMatcher: "www1.example.com >>>> >>>> Suppose that the server is able to understand both HostName and >>>> NickName. In the above example, server is able to recognize HostName, >>>> but not NickName. Then should the server includes an extension of type >>>> "server_name" in the (extended) server hello? >>>> >>>> If the server_name extension is included, it is unclear for client side >>>> which one is accepted. >>> >>> The presence of a server's server_name extension indicates that an SNI value was used to guide the selection of an appropriate cert. It seems ambiguous in RFC 6066 as to whether this extension indicated "ALL" or "AT LEAST ONE" SNI value guided the selection. I might lean towards ALL since RFC 6066 says "The 'extension_data' field of this extension SHALL be empty". If it AT LEAST ONE were meant, there is no way of indicating *which* extension was used, or if multiple ones were used. >>> >>> As an aside, we have no API for the KeyManagers's to indicate whether they actually used a SNI extension, so I think you are currently sending a server server_name extension if any cert was selected. I don't think this is a major problem given our current APIs. >>> >> A server name indication extension will be sent whenever the name is recognizable by the matches. I did not check for the types of cipher suites. I think it is the proper approach because although for anonymous cipher cuties, there is not certificates, but the ssl context may be different, so it is still can be regarded as the server do something different related to the specified SNI. >> >>> Because the client side may need to use the >>>> server_name to do endpoint identification, it is not safe to use >>>> "www.example.com" to perform endpoint identification because the server >>>> side does not accept it. >>>> >>>> If the server_name extension is not included, it does not follow the >>>> spec when server side is able to recognize the server name. >>>> >>>> So, I will prefer that once a SNIMatcher is defined, it must be used to >>>> perform match operation if the corresponding server name type appears in >>>> the SNI extension. >>>> >>>> I think we need to adjust the spec to make the behavior more clear. I >>>> will adjust the spec of SNIMatcher a little: >>>> * the exact server that the client wants to access. Instances of this >>>> - * class can be used by a server to verify the acceptable server names >>>> + * class is used by a server to verify the acceptable server names >>> >>> I think I still prefer "can be used" because some servers won't accept SNI info, and this indicates to me that it absolutely will be used in all situations. Unless you said something like "are used by servers which recognize the extension..." But that gets wordy. >>> >>>> * of a particular type, such as host names. >>>> >>>> And SSLParameters.getSNIMatchers() >>>> *

    >>>> * This method is only useful to {@link SSLSocket}s or >>>> * {@link SSLEngine}s operating in server mode. >>>> + *

    >>>> + * Every {@code SNIMatcher} in the returned {@link Collection} must >>>> + * be used to perform match operation if the corresponding name >>>> + * type appears in the SNI extension. >>>> *

    >>>> * For better interoperability, providers generally will not define >>>> * default matchers so that by default servers will ignore the SNI >>>> * extension and continue the handshake. >>>> >>>> What do you think? >>> >>> I think what you had is fine, and I suggest we go with it for now. I think we can and should ask for clarification at IETF as to the intent, and we add this new paragraph as an enhancement if they are in agreement. If there is no agreement there, then we could just call it a implementation detail and continue using AND. >>> >> Ok. Let's go with the current spec. >> >>>> I may not need a new bug or CCC request because the >>>> update is minor. >>> >>> Actually, I think this is a little more than a minor change. >>> >>> Which reminds me, is your server code sending SNI extensions for anonymous suites? >>> >> Yes. See above. >> >>>>>>> 2509: Something to investigate: you are depending on SSLParameters >>>>>>> returning an unmodifiable list. But a subclass might not do that. Can >>>>>>> you think of any situations where this might be a bad idea? If so, then >>>>>>> we might want to change the unmodifiable language in SSLParameters and >>>>>>> do regular cloning. This will have repercussions in other areas, like >>>>>>> around 2527/2532, where you'll need to pass a copy to the Handshaker. >>>>>> Well, I understand that something bad would happen if the subclass does >>>>>> not follow the method spec while doing method implementation overriding. >>>>> >>>>> Yes, it was just something to think about. Of course, I'm trying to >>>>> think of exploit situations, since you're really just hurting yourself >>>>> if tweak this in the middle of a handshake. >>>>> >>>>> If I see Joe Darcy around, I'll check in with him. >>>> Thanks! I really think we need to think about it more and carefully. The >>>> style (immutable returned value in none-final method) does impact the >>>> reliability of the APIs. >>> >>> I talked to Joe, and it's one of those grey areas. It's ultimately your own fault if you misuse the API like this. However, if there were potential vulnerability issues, that would be different. Given what this API does, I don't see anything like that here. But you're right, it's not reliable which is why I brought it up. >>> >> According to effective java, I would prefer to use final keyword for the new methods. I did not see clear requirements that customers need to override the methods. So I would like a stricter restriction for the new methods in case of any mis-use. Does it make sense to you? >> >> Xuelei >> >>> Brad >>> >>> >>> >>>>>> Let's have the spec and implementation as it is. We can update the spec >>>>>> and implementation if we have strong concerns or a common solution for >>>>>> the issue before JDK 8 officially release. >>>>> >>>>> I'm fine with this. >>>>> >>>>>>> sun/security/ssl/X509TrustManagerImpl.java >>>>>>> ========================================== >>>>>>> OK >>>>>> All of other comments are accepted. >>>>>> >>>>>> I think there is no major concerns so far. >>>>> >>>>> None still outstanding. I looked over the previous comments I've made >>>>> and what you've done to address them, and all looks good minus the >>>>> little points above. >>>> Good! It seems that we only have one question, how to use SNIMatachers? >>>> See above. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> >>>>>> Thank you so much for the >>>>>> detailed evaluation and comments on both spec and implementation. TLS >>>>>> and its implementation is very complicated, your support is the critical >>>>>> success factor to deliver quality product. >>>>> >>>>> Thanks, and be sure to give yourself a lot of that credit. With all the >>>>> back/forth and development this feature has seen, I think you've done a >>>>> great job. >>>>> >>>>> Brad >>>> > From jonathan.gibbons at oracle.com Mon Oct 15 17:08:34 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 16 Oct 2012 00:08:34 +0000 Subject: hg: jdk8/tl/langtools: 8000666: javadoc should write directly to Writer instead of composing strings Message-ID: <20121016000836.D6EDF4738B@hg.openjdk.java.net> Changeset: 8db45b13526e Author: jjg Date: 2012-10-15 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8db45b13526e 8000666: javadoc should write directly to Writer instead of composing strings Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java From xuelei.fan at oracle.com Mon Oct 15 18:27:56 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 16 Oct 2012 09:27:56 +0800 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <507C9860.1060103@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> <5078AF37.1080208@oracle.com> <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> <50796C02.6010703@oracle.com> <507C9860.1060103@oracle.com> Message-ID: <507CB81C.4080207@oracle.com> On 10/16/2012 7:12 AM, Brad Wetmore wrote: > Looks good. > >> The main update is to add "final" keyword to the new methods in >> SSLParamaters. I prefer to use the final because I don't see a >> requirement to override them. > > Let me know when the new CCC is ready, I'll approve it. > The CCC for this fix, 7068321 has been finalized. I submitted a new CCC to add the final keyword: https://jbs.oracle.com/bugs/browse/JDK-8000954 I will fill the new CCC after the push of 7068321. > Are you going to contact IETF? > Yes, I will. > Almost there. > I think we get all spec review, code review done. I will push the changeset after the CCC get approved, and pay more time on CPU bugs. Thanks, Xuelei > Brad > > > On 10/13/2012 6:26 AM, Xuelei Fan wrote: >> New webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.14/ >> >> The main update is to add "final" keyword to the new methods in >> SSLParamaters. I prefer to use the final because I don't see a >> requirement to override them. But I can go with the version with or >> without the "final" keyword. I think you properly don't need to review >> other parts of the webrev any more, no other major update. >> >> Thanks, >> Xuelei >> >> >> On 10/13/2012 10:17 AM, Xuelei Fan wrote: >>> I have no access to office network, just a quick reply. I want add >>> final keyword for the new methods in SSLParameters. See below. >>> >>> Sent from my iPad >>> >>> On Oct 13, 2012, at 8:00 AM, Brad Wetmore >>> wrote: >>> >>>> >>>>>> I guess you didn't need to have me as reviewer before going final >>>>>> with >>>>>> the CCC? >>>>> The CCC has been finalized. ;-) I though you have done with spec >>>>> review. >>>>> Anyway, we still can make updates on specification within new bugs. >>>> >>>> That's fine, I just wasn't sure if you needed someone to "approve" >>>> the "final" version of the spec to move it to the next state. >>>> >>>>>> Just a comment: >>>>>> >>>>>> 459/468: Currently you have serverNames and sniMatchers as package >>>>>> private variables, so the ClientHandshaker/ServerHandshaker *could* >>>>>> inherit these variables rather than have a separate get methods. >>>>>> Or you >>>>>> could make them private and keep the get calls. >>>>> Good catch! >>>> >>>> I can look at your latest if you like, but probably not necessary. >>>> >>> I will send the new webrev tonight my time. >>> >>>>>> I'm just not seeing why this implies that it requires *EVERY* name >>>>>> must >>>>>> match. This just says we can do one of two things upon receipt of an >>>>>> unrecognized hostname: continue on, or alert/close. We can be very >>>>>> restrictive (ALL/AND) or less so (at least one/OR), and still be >>>>>> within >>>>>> the RFC, I think. >>>>> I agree with your parser. >>>>> >>>>>>> In our spec, it is required that once a SNIMatcher is defined, it >>>>>>> will be used to recognized the server name in the SNI extension. >>>>>> >>>>>> Where? We do say in SNIMatcher: >>>>>> >>>>>> Servers can use Server Name Indication (SNI) information to >>>>>> decide if >>>>>> specific {@link SSLSocket} or {@link SSLEngine} instances should >>>>>> accept a connection. >>>>>> >>>>>> But I don't think we have ever said that it MUST match or must >>>>>> match all >>>>>> or even what the implementation must do if there is a match >>>>>> failure. Nor >>>>>> should we specify that in the API, IMHO. That's implementation >>>>>> behavior. >>>>> I may have different options on this point. I think, it must be a >>>>> specified behavior in Java. Otherwise, it is very confusing about >>>>> how to >>>>> use 1+ server names in server side. >>>> >>>> I am going suggest we ask for guidance from IETF about this. It is >>>> not clear from RFC 6066 how to handle multiple SNI types, even >>>> reading very generously between the lines. See below. >>>> >>>>> Let's start from the logic of the design. If the specification is not >>>>> clear, I will rewrite the spec according to our agreement. >>>>> >>>>> Let's start from the requirement. I think once a SNIMatcher is defined >>>>> in SSL parameters, it MUST be used to perform the match operations if >>>>> the corresponding server name appears in the SNI extension. >>>>> Otherwise, >>>>> what will happens? See the example: >>>>> 1. SNI extension contains HostName, "www.example.com". >>>>> 2. Server side defines SNIMatcher for HostName, to accept >>>>> "www.example.org". Server does not accept "www.example.com". >>>>> 3. What's the result of the handshake? Is the SNI extension is >>>>> accetable? >>>> >>>> www.example.org != www.example.com. I would say fail handshake with >>>> unknown_hostname. >>>> >>>>> If we do not define the spec about how to use SNIMatcher. The >>>>> answer to >>>>> #3 is unclear. Because if a SNIMatcher may be used to perform match >>>>> operation, and may be not used to perform match operation, then the >>>>> server may accept the SNI extension, may ignore the SNI extension, may >>>>> reject the SNI extension. It is useless to define SNIMatcher. >>>>> >>>>> I think the requirement is clear that it is a must to use >>>>> SNIMatcher to >>>>> perform the match operation if the corresponding server name >>>>> appears in >>>>> the SNI extension. I think it is true for the case when there is only >>>>> one server name type, at least. >>>> >>>> I completely agree. >>>> >>>>> Let's look more about what happens when there is 1+ server name >>>>> types in >>>>> the SNI extension. Let's use the example in your previous mail. >>>>> >>>>> SNIHostname: "example.com" >>>>> SNINickName: "www.example.com" >>>>> >>>>> SNIMatcher: "example.com" >>>>> SNINickNameMatcher: "www1.example.com >>>>> >>>>> Suppose that the server is able to understand both HostName and >>>>> NickName. In the above example, server is able to recognize HostName, >>>>> but not NickName. Then should the server includes an extension of >>>>> type >>>>> "server_name" in the (extended) server hello? >>>>> >>>>> If the server_name extension is included, it is unclear for client >>>>> side >>>>> which one is accepted. >>>> >>>> The presence of a server's server_name extension indicates that an >>>> SNI value was used to guide the selection of an appropriate cert. >>>> It seems ambiguous in RFC 6066 as to whether this extension >>>> indicated "ALL" or "AT LEAST ONE" SNI value guided the selection. I >>>> might lean towards ALL since RFC 6066 says "The 'extension_data' >>>> field of this extension SHALL be empty". If it AT LEAST ONE were >>>> meant, there is no way of indicating *which* extension was used, or >>>> if multiple ones were used. >>>> >>>> As an aside, we have no API for the KeyManagers's to indicate >>>> whether they actually used a SNI extension, so I think you are >>>> currently sending a server server_name extension if any cert was >>>> selected. I don't think this is a major problem given our current >>>> APIs. >>>> >>> A server name indication extension will be sent whenever the name is >>> recognizable by the matches. I did not check for the types of cipher >>> suites. I think it is the proper approach because although for >>> anonymous cipher cuties, there is not certificates, but the ssl >>> context may be different, so it is still can be regarded as the >>> server do something different related to the specified SNI. >>> >>>> Because the client side may need to use the >>>>> server_name to do endpoint identification, it is not safe to use >>>>> "www.example.com" to perform endpoint identification because the >>>>> server >>>>> side does not accept it. >>>>> >>>>> If the server_name extension is not included, it does not follow the >>>>> spec when server side is able to recognize the server name. >>>>> >>>>> So, I will prefer that once a SNIMatcher is defined, it must be >>>>> used to >>>>> perform match operation if the corresponding server name type >>>>> appears in >>>>> the SNI extension. >>>>> >>>>> I think we need to adjust the spec to make the behavior more clear. I >>>>> will adjust the spec of SNIMatcher a little: >>>>> * the exact server that the client wants to access. Instances >>>>> of this >>>>> - * class can be used by a server to verify the acceptable server >>>>> names >>>>> + * class is used by a server to verify the acceptable server names >>>> >>>> I think I still prefer "can be used" because some servers won't >>>> accept SNI info, and this indicates to me that it absolutely will be >>>> used in all situations. Unless you said something like "are used by >>>> servers which recognize the extension..." But that gets wordy. >>>> >>>>> * of a particular type, such as host names. >>>>> >>>>> And SSLParameters.getSNIMatchers() >>>>> *

    >>>>> * This method is only useful to {@link SSLSocket}s or >>>>> * {@link SSLEngine}s operating in server mode. >>>>> + *

    >>>>> + * Every {@code SNIMatcher} in the returned {@link Collection} >>>>> must >>>>> + * be used to perform match operation if the corresponding name >>>>> + * type appears in the SNI extension. >>>>> *

    >>>>> * For better interoperability, providers generally will not >>>>> define >>>>> * default matchers so that by default servers will ignore the >>>>> SNI >>>>> * extension and continue the handshake. >>>>> >>>>> What do you think? >>>> >>>> I think what you had is fine, and I suggest we go with it for now. >>>> I think we can and should ask for clarification at IETF as to the >>>> intent, and we add this new paragraph as an enhancement if they are >>>> in agreement. If there is no agreement there, then we could just >>>> call it a implementation detail and continue using AND. >>>> >>> Ok. Let's go with the current spec. >>> >>>>> I may not need a new bug or CCC request because the >>>>> update is minor. >>>> >>>> Actually, I think this is a little more than a minor change. >>>> >>>> Which reminds me, is your server code sending SNI extensions for >>>> anonymous suites? >>>> >>> Yes. See above. >>> >>>>>>>> 2509: Something to investigate: you are depending on SSLParameters >>>>>>>> returning an unmodifiable list. But a subclass might not do >>>>>>>> that. Can >>>>>>>> you think of any situations where this might be a bad idea? If >>>>>>>> so, then >>>>>>>> we might want to change the unmodifiable language in >>>>>>>> SSLParameters and >>>>>>>> do regular cloning. This will have repercussions in other >>>>>>>> areas, like >>>>>>>> around 2527/2532, where you'll need to pass a copy to the >>>>>>>> Handshaker. >>>>>>> Well, I understand that something bad would happen if the >>>>>>> subclass does >>>>>>> not follow the method spec while doing method implementation >>>>>>> overriding. >>>>>> >>>>>> Yes, it was just something to think about. Of course, I'm trying to >>>>>> think of exploit situations, since you're really just hurting >>>>>> yourself >>>>>> if tweak this in the middle of a handshake. >>>>>> >>>>>> If I see Joe Darcy around, I'll check in with him. >>>>> Thanks! I really think we need to think about it more and >>>>> carefully. The >>>>> style (immutable returned value in none-final method) does impact the >>>>> reliability of the APIs. >>>> >>>> I talked to Joe, and it's one of those grey areas. It's ultimately >>>> your own fault if you misuse the API like this. However, if there >>>> were potential vulnerability issues, that would be different. Given >>>> what this API does, I don't see anything like that here. But you're >>>> right, it's not reliable which is why I brought it up. >>>> >>> According to effective java, I would prefer to use final keyword for >>> the new methods. I did not see clear requirements that customers >>> need to override the methods. So I would like a stricter restriction >>> for the new methods in case of any mis-use. Does it make sense to you? >>> >>> Xuelei >>> >>>> Brad >>>> >>>> >>>> >>>>>>> Let's have the spec and implementation as it is. We can update >>>>>>> the spec >>>>>>> and implementation if we have strong concerns or a common >>>>>>> solution for >>>>>>> the issue before JDK 8 officially release. >>>>>> >>>>>> I'm fine with this. >>>>>> >>>>>>>> sun/security/ssl/X509TrustManagerImpl.java >>>>>>>> ========================================== >>>>>>>> OK >>>>>>> All of other comments are accepted. >>>>>>> >>>>>>> I think there is no major concerns so far. >>>>>> >>>>>> None still outstanding. I looked over the previous comments I've >>>>>> made >>>>>> and what you've done to address them, and all looks good minus the >>>>>> little points above. >>>>> Good! It seems that we only have one question, how to use >>>>> SNIMatachers? >>>>> See above. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> >>>>>>> Thank you so much for the >>>>>>> detailed evaluation and comments on both spec and >>>>>>> implementation. TLS >>>>>>> and its implementation is very complicated, your support is the >>>>>>> critical >>>>>>> success factor to deliver quality product. >>>>>> >>>>>> Thanks, and be sure to give yourself a lot of that credit. With >>>>>> all the >>>>>> back/forth and development this feature has seen, I think you've >>>>>> done a >>>>>> great job. >>>>>> >>>>>> Brad >>>>> >> From vincent.x.ryan at oracle.com Tue Oct 16 05:55:52 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 16 Oct 2012 13:55:52 +0100 Subject: Code review request: 7197652: Impossible to run any signed JNLP applications or applets, OCSP off by default In-Reply-To: <507D3C76.40901@zafena.se> References: <507D3C76.40901@zafena.se> Message-ID: We used to have automated tests that accessed live OCSP responders but results were often unreliable because of intermittent network and proxy issues. I am developing an automated test that uses a cached OCSP response which will be more robust. On 16 Oct 2012, at 11:52, Xerxes R?nby wrote: > 2012-10-01 04:30, Vincent Ryan wrote: >> Please review these changes for JDK 7 to correct the trust decision when examining the signer certificate of an OCSP response. When matching two certificates the key identifiers should only be checked if present in both. >> >> http://cr.openjdk.java.net/~vinnie/7197652/webrev.00/ >> >> Thanks. > > Is this code covered by any of the existing JDK 7 jtreg tests? > If not then please add a new jtreg test to help with testing and verification. > > Cheers > Xerxes From Alan.Bateman at oracle.com Tue Oct 16 06:55:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Oct 2012 14:55:27 +0100 Subject: configuration files in ${java.home}/lib/security Message-ID: <507D674F.8040303@oracle.com> As part of preparing for modules in the future [1], we need to look at configuration (and other) files in the JDK and see whether such files could eventually move to module-private locations. There are several files in ${java.home}/lib/security and I'm trying to get a feel for how common it is for developers or customers to edit them. The specification for java.security.Policy and java.security.KeyStore define the name/location of java.security and we need to decide whether these can be changed to non-normative references. I know from discussion with Sean on jigsaw-dev and elsewhere that some customers may change the preference order of providers but this is something that needs to be re-examined anyway as part of deploying security providers as service providers. I'm mostly interested in the other settings at this time and whether it is common or not to change them. Also the other files, including java.policy. I realize we might not have actual data but as such files are in the JDK image then I could imagine it being problematic when upgrading the JDK. Thanks, -Alan. [1] http://openjdk.java.net/jeps/162 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20121016/0262981d/attachment.html From sean.mullan at oracle.com Tue Oct 16 10:45:22 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 Oct 2012 13:45:22 -0400 Subject: configuration files in ${java.home}/lib/security In-Reply-To: <507D674F.8040303@oracle.com> References: <507D674F.8040303@oracle.com> Message-ID: <507D9D32.3030001@oracle.com> On 10/16/2012 09:55 AM, Alan Bateman wrote: > As part of preparing for modules in the future [1], we need to look at > configuration (and other) files in the JDK and see whether such files > could eventually move to module-private locations. > > There are several files in ${java.home}/lib/security and I'm trying to > get a feel for how common it is for developers or customers to edit > them. The specification for java.security.Policy and > java.security.KeyStore define the name/location of java.security and we > need to decide whether these can be changed to non-normative references. > I know from discussion with Sean on jigsaw-dev and elsewhere that some > customers may change the preference order of providers but this is > something that needs to be re-examined anyway as part of deploying > security providers as service providers. I'm mostly interested in the > other settings at this time and whether it is common or not to change > them. Also the other files, including java.policy. I realize we might > not have actual data but as such files are in the JDK image then I could > imagine it being problematic when upgrading the JDK. Right, any modifications that are made to these files will be overwritten when you upgrade. There is a way to avoid doing that by specifying an alternate java.security file using the java.security.properties system property, or alternatively you can use the java.security.Security API to override the values of these properties, but unlike system properties I don't think you can set them via the java command line. I have no real data, but I suspect the re-adjusting or adding new providers is probably the most common use case. The other properties are more obscure and use reasonable default values. For cacerts and java.policy, the same JDK upgrade issue applies and will clobber any changes you make, but if you are using Oracle's deployment tools, you can add new root certs and make system policy changes using deployment-specific files, so this is less of an issue. It might be worth asking the EE folks whether they change any of these properties. --Sean > > Thanks, > > -Alan. > > [1] http://openjdk.java.net/jeps/162 From naoto.sato at oracle.com Tue Oct 16 10:59:49 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 16 Oct 2012 17:59:49 +0000 Subject: hg: jdk8/tl/jdk: 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions; ... Message-ID: <20121016180011.C58AC473AF@hg.openjdk.java.net> Changeset: 32452042b781 Author: naoto Date: 2012-10-16 10:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32452042b781 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't transferred to the custom service provider 8000615: JRE adapter: timezone name of en_US is changed when extension directory is added Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java From bradford.wetmore at oracle.com Tue Oct 16 13:57:13 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 16 Oct 2012 13:57:13 -0700 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <507CB81C.4080207@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> <5078AF37.1080208@oracle.com> <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> <50796C02.6010703@oracle.com> <507C9860.1060103@oracle.com> <507CB81C.4080207@oracle.com> Message-ID: <507DCA29.7040206@oracle.com> BTW, both 7068321 and 8000954 are in Open, should be "In Progress". On 10/15/2012 6:27 PM, Xuelei Fan wrote: > On 10/16/2012 7:12 AM, Brad Wetmore wrote: >> Looks good. >> >>> The main update is to add "final" keyword to the new methods in >>> SSLParamaters. I prefer to use the final because I don't see a >>> requirement to override them. >> >> Let me know when the new CCC is ready, I'll approve it. >> > The CCC for this fix, 7068321 has been finalized. I submitted a new CCC > to add the final keyword: > https://jbs.oracle.com/bugs/browse/JDK-8000954 > > I will fill the new CCC after the push of 7068321. >> Are you going to contact IETF? >> > Yes, I will. > >> Almost there. >> > I think we get all spec review, code review done. I think so. > I will push the > changeset after the CCC get approved, and pay more time on CPU bugs. You could push both together and put everything in just one changeset, but of course up to you. I don't think there's anything else for me to do, let me know if you're waiting on something. Brad > > Thanks, > Xuelei > >> Brad >> >> >> On 10/13/2012 6:26 AM, Xuelei Fan wrote: >>> New webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.14/ >>> >>> The main update is to add "final" keyword to the new methods in >>> SSLParamaters. I prefer to use the final because I don't see a >>> requirement to override them. But I can go with the version with or >>> without the "final" keyword. I think you properly don't need to review >>> other parts of the webrev any more, no other major update. >>> >>> Thanks, >>> Xuelei >>> >>> >>> On 10/13/2012 10:17 AM, Xuelei Fan wrote: >>>> I have no access to office network, just a quick reply. I want add >>>> final keyword for the new methods in SSLParameters. See below. >>>> >>>> Sent from my iPad >>>> >>>> On Oct 13, 2012, at 8:00 AM, Brad Wetmore >>>> wrote: >>>> >>>>> >>>>>>> I guess you didn't need to have me as reviewer before going final >>>>>>> with >>>>>>> the CCC? >>>>>> The CCC has been finalized. ;-) I though you have done with spec >>>>>> review. >>>>>> Anyway, we still can make updates on specification within new bugs. >>>>> >>>>> That's fine, I just wasn't sure if you needed someone to "approve" >>>>> the "final" version of the spec to move it to the next state. >>>>> >>>>>>> Just a comment: >>>>>>> >>>>>>> 459/468: Currently you have serverNames and sniMatchers as package >>>>>>> private variables, so the ClientHandshaker/ServerHandshaker *could* >>>>>>> inherit these variables rather than have a separate get methods. >>>>>>> Or you >>>>>>> could make them private and keep the get calls. >>>>>> Good catch! >>>>> >>>>> I can look at your latest if you like, but probably not necessary. >>>>> >>>> I will send the new webrev tonight my time. >>>> >>>>>>> I'm just not seeing why this implies that it requires *EVERY* name >>>>>>> must >>>>>>> match. This just says we can do one of two things upon receipt of an >>>>>>> unrecognized hostname: continue on, or alert/close. We can be very >>>>>>> restrictive (ALL/AND) or less so (at least one/OR), and still be >>>>>>> within >>>>>>> the RFC, I think. >>>>>> I agree with your parser. >>>>>> >>>>>>>> In our spec, it is required that once a SNIMatcher is defined, it >>>>>>>> will be used to recognized the server name in the SNI extension. >>>>>>> >>>>>>> Where? We do say in SNIMatcher: >>>>>>> >>>>>>> Servers can use Server Name Indication (SNI) information to >>>>>>> decide if >>>>>>> specific {@link SSLSocket} or {@link SSLEngine} instances should >>>>>>> accept a connection. >>>>>>> >>>>>>> But I don't think we have ever said that it MUST match or must >>>>>>> match all >>>>>>> or even what the implementation must do if there is a match >>>>>>> failure. Nor >>>>>>> should we specify that in the API, IMHO. That's implementation >>>>>>> behavior. >>>>>> I may have different options on this point. I think, it must be a >>>>>> specified behavior in Java. Otherwise, it is very confusing about >>>>>> how to >>>>>> use 1+ server names in server side. >>>>> >>>>> I am going suggest we ask for guidance from IETF about this. It is >>>>> not clear from RFC 6066 how to handle multiple SNI types, even >>>>> reading very generously between the lines. See below. >>>>> >>>>>> Let's start from the logic of the design. If the specification is not >>>>>> clear, I will rewrite the spec according to our agreement. >>>>>> >>>>>> Let's start from the requirement. I think once a SNIMatcher is defined >>>>>> in SSL parameters, it MUST be used to perform the match operations if >>>>>> the corresponding server name appears in the SNI extension. >>>>>> Otherwise, >>>>>> what will happens? See the example: >>>>>> 1. SNI extension contains HostName, "www.example.com". >>>>>> 2. Server side defines SNIMatcher for HostName, to accept >>>>>> "www.example.org". Server does not accept "www.example.com". >>>>>> 3. What's the result of the handshake? Is the SNI extension is >>>>>> accetable? >>>>> >>>>> www.example.org != www.example.com. I would say fail handshake with >>>>> unknown_hostname. >>>>> >>>>>> If we do not define the spec about how to use SNIMatcher. The >>>>>> answer to >>>>>> #3 is unclear. Because if a SNIMatcher may be used to perform match >>>>>> operation, and may be not used to perform match operation, then the >>>>>> server may accept the SNI extension, may ignore the SNI extension, may >>>>>> reject the SNI extension. It is useless to define SNIMatcher. >>>>>> >>>>>> I think the requirement is clear that it is a must to use >>>>>> SNIMatcher to >>>>>> perform the match operation if the corresponding server name >>>>>> appears in >>>>>> the SNI extension. I think it is true for the case when there is only >>>>>> one server name type, at least. >>>>> >>>>> I completely agree. >>>>> >>>>>> Let's look more about what happens when there is 1+ server name >>>>>> types in >>>>>> the SNI extension. Let's use the example in your previous mail. >>>>>> >>>>>> SNIHostname: "example.com" >>>>>> SNINickName: "www.example.com" >>>>>> >>>>>> SNIMatcher: "example.com" >>>>>> SNINickNameMatcher: "www1.example.com >>>>>> >>>>>> Suppose that the server is able to understand both HostName and >>>>>> NickName. In the above example, server is able to recognize HostName, >>>>>> but not NickName. Then should the server includes an extension of >>>>>> type >>>>>> "server_name" in the (extended) server hello? >>>>>> >>>>>> If the server_name extension is included, it is unclear for client >>>>>> side >>>>>> which one is accepted. >>>>> >>>>> The presence of a server's server_name extension indicates that an >>>>> SNI value was used to guide the selection of an appropriate cert. >>>>> It seems ambiguous in RFC 6066 as to whether this extension >>>>> indicated "ALL" or "AT LEAST ONE" SNI value guided the selection. I >>>>> might lean towards ALL since RFC 6066 says "The 'extension_data' >>>>> field of this extension SHALL be empty". If it AT LEAST ONE were >>>>> meant, there is no way of indicating *which* extension was used, or >>>>> if multiple ones were used. >>>>> >>>>> As an aside, we have no API for the KeyManagers's to indicate >>>>> whether they actually used a SNI extension, so I think you are >>>>> currently sending a server server_name extension if any cert was >>>>> selected. I don't think this is a major problem given our current >>>>> APIs. >>>>> >>>> A server name indication extension will be sent whenever the name is >>>> recognizable by the matches. I did not check for the types of cipher >>>> suites. I think it is the proper approach because although for >>>> anonymous cipher cuties, there is not certificates, but the ssl >>>> context may be different, so it is still can be regarded as the >>>> server do something different related to the specified SNI. >>>> >>>>> Because the client side may need to use the >>>>>> server_name to do endpoint identification, it is not safe to use >>>>>> "www.example.com" to perform endpoint identification because the >>>>>> server >>>>>> side does not accept it. >>>>>> >>>>>> If the server_name extension is not included, it does not follow the >>>>>> spec when server side is able to recognize the server name. >>>>>> >>>>>> So, I will prefer that once a SNIMatcher is defined, it must be >>>>>> used to >>>>>> perform match operation if the corresponding server name type >>>>>> appears in >>>>>> the SNI extension. >>>>>> >>>>>> I think we need to adjust the spec to make the behavior more clear. I >>>>>> will adjust the spec of SNIMatcher a little: >>>>>> * the exact server that the client wants to access. Instances >>>>>> of this >>>>>> - * class can be used by a server to verify the acceptable server >>>>>> names >>>>>> + * class is used by a server to verify the acceptable server names >>>>> >>>>> I think I still prefer "can be used" because some servers won't >>>>> accept SNI info, and this indicates to me that it absolutely will be >>>>> used in all situations. Unless you said something like "are used by >>>>> servers which recognize the extension..." But that gets wordy. >>>>> >>>>>> * of a particular type, such as host names. >>>>>> >>>>>> And SSLParameters.getSNIMatchers() >>>>>> *

    >>>>>> * This method is only useful to {@link SSLSocket}s or >>>>>> * {@link SSLEngine}s operating in server mode. >>>>>> + *

    >>>>>> + * Every {@code SNIMatcher} in the returned {@link Collection} >>>>>> must >>>>>> + * be used to perform match operation if the corresponding name >>>>>> + * type appears in the SNI extension. >>>>>> *

    >>>>>> * For better interoperability, providers generally will not >>>>>> define >>>>>> * default matchers so that by default servers will ignore the >>>>>> SNI >>>>>> * extension and continue the handshake. >>>>>> >>>>>> What do you think? >>>>> >>>>> I think what you had is fine, and I suggest we go with it for now. >>>>> I think we can and should ask for clarification at IETF as to the >>>>> intent, and we add this new paragraph as an enhancement if they are >>>>> in agreement. If there is no agreement there, then we could just >>>>> call it a implementation detail and continue using AND. >>>>> >>>> Ok. Let's go with the current spec. >>>> >>>>>> I may not need a new bug or CCC request because the >>>>>> update is minor. >>>>> >>>>> Actually, I think this is a little more than a minor change. >>>>> >>>>> Which reminds me, is your server code sending SNI extensions for >>>>> anonymous suites? >>>>> >>>> Yes. See above. >>>> >>>>>>>>> 2509: Something to investigate: you are depending on SSLParameters >>>>>>>>> returning an unmodifiable list. But a subclass might not do >>>>>>>>> that. Can >>>>>>>>> you think of any situations where this might be a bad idea? If >>>>>>>>> so, then >>>>>>>>> we might want to change the unmodifiable language in >>>>>>>>> SSLParameters and >>>>>>>>> do regular cloning. This will have repercussions in other >>>>>>>>> areas, like >>>>>>>>> around 2527/2532, where you'll need to pass a copy to the >>>>>>>>> Handshaker. >>>>>>>> Well, I understand that something bad would happen if the >>>>>>>> subclass does >>>>>>>> not follow the method spec while doing method implementation >>>>>>>> overriding. >>>>>>> >>>>>>> Yes, it was just something to think about. Of course, I'm trying to >>>>>>> think of exploit situations, since you're really just hurting >>>>>>> yourself >>>>>>> if tweak this in the middle of a handshake. >>>>>>> >>>>>>> If I see Joe Darcy around, I'll check in with him. >>>>>> Thanks! I really think we need to think about it more and >>>>>> carefully. The >>>>>> style (immutable returned value in none-final method) does impact the >>>>>> reliability of the APIs. >>>>> >>>>> I talked to Joe, and it's one of those grey areas. It's ultimately >>>>> your own fault if you misuse the API like this. However, if there >>>>> were potential vulnerability issues, that would be different. Given >>>>> what this API does, I don't see anything like that here. But you're >>>>> right, it's not reliable which is why I brought it up. >>>>> >>>> According to effective java, I would prefer to use final keyword for >>>> the new methods. I did not see clear requirements that customers >>>> need to override the methods. So I would like a stricter restriction >>>> for the new methods in case of any mis-use. Does it make sense to you? >>>> >>>> Xuelei >>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>>>>> Let's have the spec and implementation as it is. We can update >>>>>>>> the spec >>>>>>>> and implementation if we have strong concerns or a common >>>>>>>> solution for >>>>>>>> the issue before JDK 8 officially release. >>>>>>> >>>>>>> I'm fine with this. >>>>>>> >>>>>>>>> sun/security/ssl/X509TrustManagerImpl.java >>>>>>>>> ========================================== >>>>>>>>> OK >>>>>>>> All of other comments are accepted. >>>>>>>> >>>>>>>> I think there is no major concerns so far. >>>>>>> >>>>>>> None still outstanding. I looked over the previous comments I've >>>>>>> made >>>>>>> and what you've done to address them, and all looks good minus the >>>>>>> little points above. >>>>>> Good! It seems that we only have one question, how to use >>>>>> SNIMatachers? >>>>>> See above. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> >>>>>>>> Thank you so much for the >>>>>>>> detailed evaluation and comments on both spec and >>>>>>>> implementation. TLS >>>>>>>> and its implementation is very complicated, your support is the >>>>>>>> critical >>>>>>>> success factor to deliver quality product. >>>>>>> >>>>>>> Thanks, and be sure to give yourself a lot of that credit. With >>>>>>> all the >>>>>>> back/forth and development this feature has seen, I think you've >>>>>>> done a >>>>>>> great job. >>>>>>> >>>>>>> Brad >>>>>> >>> > From xerxes at zafena.se Tue Oct 16 03:52:38 2012 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 16 Oct 2012 12:52:38 +0200 Subject: Code review request: 7197652: Impossible to run any signed JNLP applications or applets, OCSP off by default Message-ID: <507D3C76.40901@zafena.se> 2012-10-01 04:30, Vincent Ryan wrote: > Please review these changes for JDK 7 to correct the trust decision when examining the signer certificate of an OCSP response. When matching two certificates the key identifiers should only be checked if present in both. > > http://cr.openjdk.java.net/~vinnie/7197652/webrev.00/ > > Thanks. Is this code covered by any of the existing JDK 7 jtreg tests? If not then please add a new jtreg test to help with testing and verification. Cheers Xerxes From kurchi.subhra.hazra at oracle.com Tue Oct 16 15:23:47 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Tue, 16 Oct 2012 22:23:47 +0000 Subject: hg: jdk8/tl/jdk: 7198073: (prefs) user prefs not saved [macosx] Message-ID: <20121016222408.4153A473CF@hg.openjdk.java.net> Changeset: 3a6b76a468bd Author: khazra Date: 2012-10-16 15:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a6b76a468bd 7198073: (prefs) user prefs not saved [macosx] Summary: Using class member field to get node instead of argument Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java + test/java/util/prefs/CheckUserPrefFirst.java + test/java/util/prefs/CheckUserPrefLater.java + test/java/util/prefs/CheckUserPrefsStorage.sh From xuelei.fan at oracle.com Tue Oct 16 18:30:12 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 17 Oct 2012 09:30:12 +0800 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <507DCA29.7040206@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> <5078AF37.1080208@oracle.com> <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> <50796C02.6010703@oracle.com> <507C9860.1060103@oracle.com> <507CB81C.4080207@oracle.com> <507DCA29.7040206@oracle.com> Message-ID: <507E0A24.9020308@oracle.com> On 10/17/2012 4:57 AM, Brad Wetmore wrote: > You could push both together and put everything in just one changeset, > but of course up to you. > Good. Please review the CCC request, I will fast-track the request. > I don't think there's anything else for me to do, let me know if you're > waiting on something. I think you are done, ;-) except the above CCC review. I still need to wait for the approval of the CCCs. Thanks, Xuelei From xuelei.fan at oracle.com Tue Oct 16 18:30:43 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 17 Oct 2012 09:30:43 +0800 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <507E0A24.9020308@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> <5078AF37.1080208@oracle.com> <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> <50796C02.6010703@oracle.com> <507C9860.1060103@oracle.com> <507CB81C.4080207@oracle.com> <507DCA29.7040206@oracle.com> <507E0A24.9020308@oracle.com> Message-ID: <507E0A43.9090302@oracle.com> On 10/17/2012 9:30 AM, Xuelei Fan wrote: > On 10/17/2012 4:57 AM, Brad Wetmore wrote: >> You could push both together and put everything in just one changeset, >> but of course up to you. >> > Good. > > Please review the CCC request, I will fast-track the request. > http://ccc.us.oracle.com/8000954 >> I don't think there's anything else for me to do, let me know if you're >> waiting on something. > I think you are done, ;-) except the above CCC review. I still need to > wait for the approval of the CCCs. > > Thanks, > Xuelei > From bradford.wetmore at oracle.com Tue Oct 16 20:54:08 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 16 Oct 2012 20:54:08 -0700 Subject: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server In-Reply-To: <507E0A43.9090302@oracle.com> References: <5063199C.80908@oracle.com> <507377E8.2090604@oracle.com> <50744932.3060701@oracle.com> <5074C25B.3040703@oracle.com> <50756E7C.3020601@oracle.com> <5076070C.5010105@oracle.com> <507634F3.9060703@oracle.com> <5078AF37.1080208@oracle.com> <32D293B6-C773-4BEB-AA61-612CC16404BA@Oracle.Com> <50796C02.6010703@oracle.com> <507C9860.1060103@oracle.com> <507CB81C.4080207@oracle.com> <507DCA29.7040206@oracle.com> <507E0A24.9020308@oracle.com> <507E0A43.9090302@oracle.com> Message-ID: <507E2BE0.1010806@oracle.com> Approved. Brad On 10/16/2012 6:30 PM, Xuelei Fan wrote: > On 10/17/2012 9:30 AM, Xuelei Fan wrote: >> On 10/17/2012 4:57 AM, Brad Wetmore wrote: >>> You could push both together and put everything in just one changeset, >>> but of course up to you. >>> >> Good. >> >> Please review the CCC request, I will fast-track the request. >> > http://ccc.us.oracle.com/8000954 > >>> I don't think there's anything else for me to do, let me know if you're >>> waiting on something. >> I think you are done, ;-) except the above CCC review. I still need to >> wait for the approval of the CCCs. >> >> Thanks, >> Xuelei >> > From jonathan.gibbons at oracle.com Tue Oct 16 21:04:11 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 17 Oct 2012 04:04:11 +0000 Subject: hg: jdk8/tl/langtools: 8000673: remove dead code from HtmlWriter and subtypes Message-ID: <20121017040414.9AA73473D3@hg.openjdk.java.net> Changeset: 2013982bee34 Author: jjg Date: 2012-10-16 21:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2013982bee34 8000673: remove dead code from HtmlWriter and subtypes Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java From schlosna at gmail.com Tue Oct 16 21:37:21 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Wed, 17 Oct 2012 00:37:21 -0400 Subject: configuration files in ${java.home}/lib/security In-Reply-To: <507D9D32.3030001@oracle.com> References: <507D674F.8040303@oracle.com> <507D9D32.3030001@oracle.com> Message-ID: In my experience, altering the enabled security providers and precedence have been the primary reason for modifications and overrides of the ${JAVA_HOME}/lib/security/java.security file. Typically this has been in the context of removing unnecessary providers, as well as restricting algorithms and key sizes that do not conform to a given set of security requirements (e.g. FIPS 140-2, NIST 800-57 and 800-131A). On one occasion I did need to alter the login.configuration.provider property to use a custom implementation of javax.security.auth.login.Configuration to work around issues with a specific application server on certain platforms. - Dave On Tue, Oct 16, 2012 at 1:45 PM, Sean Mullan wrote: > On 10/16/2012 09:55 AM, Alan Bateman wrote: >> >> As part of preparing for modules in the future [1], we need to look at >> configuration (and other) files in the JDK and see whether such files >> could eventually move to module-private locations. >> >> There are several files in ${java.home}/lib/security and I'm trying to >> get a feel for how common it is for developers or customers to edit >> them. The specification for java.security.Policy and >> java.security.KeyStore define the name/location of java.security and we >> need to decide whether these can be changed to non-normative references. >> I know from discussion with Sean on jigsaw-dev and elsewhere that some >> customers may change the preference order of providers but this is >> something that needs to be re-examined anyway as part of deploying >> security providers as service providers. I'm mostly interested in the >> other settings at this time and whether it is common or not to change >> them. Also the other files, including java.policy. I realize we might >> not have actual data but as such files are in the JDK image then I could >> imagine it being problematic when upgrading the JDK. > > > Right, any modifications that are made to these files will be overwritten > when you upgrade. There is a way to avoid doing that by specifying an > alternate java.security file using the java.security.properties system > property, or alternatively you can use the java.security.Security API to > override the values of these properties, but unlike system properties I > don't think you can set them via the java command line. > > I have no real data, but I suspect the re-adjusting or adding new providers > is probably the most common use case. The other properties are more obscure > and use reasonable default values. For cacerts and java.policy, the same JDK > upgrade issue applies and will clobber any changes you make, but if you are > using Oracle's deployment tools, you can add new root certs and make system > policy changes using deployment-specific files, so this is less of an issue. > > It might be worth asking the EE folks whether they change any of these > properties. > > --Sean > > >> >> Thanks, >> >> -Alan. >> >> [1] http://openjdk.java.net/jeps/162 > > From weijun.wang at oracle.com Tue Oct 16 22:44:44 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Oct 2012 13:44:44 +0800 Subject: Request for comment: Supporting password expiration alert in JAAS In-Reply-To: <502E1A5D.7090009@oracle.com> References: <502E1A5D.7090009@oracle.com> Message-ID: <507E45CC.7050003@oracle.com> Ping again. On 08/17/2012 06:18 PM, Weijun Wang wrote: > Hi All > > I am working with an OpenJDK contributor (Steve Beaty) recently on this > feature. > > We often see messages like "Your password will expire in 5 days. Please > update ASAP" when we login to a system, and we are seeing if we could > also support this kind of alert in JAAS. > > We first starts with the Krb5LoginModule. In Kerberos, the KDC might > send a LastReq field in response to a ticket request. Normally, the > LastReq might contain: > > 1. The time the password will expire > 2. The time the account will expire. > > (It might contain other things like the last request time from the same > client, so the login module can show the user "Last login: Thu Aug 16 > 19:44:55 2012". That's also how the field is named). > > Out current idea is to create a new kind of Callback, say, > PasswordExpirationCallback for a login module, if a password/account > expiration message is found in the LastReq field received, some > user-defined method can be called. > > However, we cannot decide on what argument we should provide to this > method. Certainly, just passing the LastReq field is not very good, > since it's keberos-specific. Passing only the password expiration time? > I'm not sure if the information is too little. > > Are you familiar with all other styles of password expiration warnings? > What kind of message is generalized enough and also contains enough info? > > Any suggestion welcomed. > > Thanks > Max From alan.bateman at oracle.com Wed Oct 17 03:45:23 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 17 Oct 2012 10:45:23 +0000 Subject: hg: jdk8/tl/jdk: 8000685: (props) Properties.storeToXML/loadFromXML should only require UTF-8 and UTF-16 to be supported Message-ID: <20121017104559.88D6E473E0@hg.openjdk.java.net> Changeset: 14b9e294d049 Author: alanb Date: 2012-10-17 11:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/14b9e294d049 8000685: (props) Properties.storeToXML/loadFromXML should only require UTF-8 and UTF-16 to be supported Reviewed-by: mchung, chegar ! src/share/classes/java/util/Properties.java ! src/share/classes/sun/util/spi/XmlPropertiesProvider.java ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java ! test/java/util/Properties/LoadAndStoreXML.java From neil.richards at ngmr.net Wed Oct 17 05:41:20 2012 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Wed, 17 Oct 2012 12:41:20 +0000 Subject: hg: jdk8/tl/jdk: 8000955: Hashtable.Entry.hashCode() does not conform to Map.Entry.hashCode() defined behaviour Message-ID: <20121017124147.B851D473E1@hg.openjdk.java.net> Changeset: 5eed4a92ca8c Author: ngmr Date: 2012-10-17 13:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5eed4a92ca8c 8000955: Hashtable.Entry.hashCode() does not conform to Map.Entry.hashCode() defined behaviour Reviewed-by: mduigou, alanb ! src/share/classes/java/util/Hashtable.java + test/java/util/Map/EntryHashCode.java From xuelei.fan at oracle.com Wed Oct 17 07:01:29 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 17 Oct 2012 22:01:29 +0800 Subject: Request for comment: Supporting password expiration alert in JAAS In-Reply-To: <507E45CC.7050003@oracle.com> References: <502E1A5D.7090009@oracle.com> <507E45CC.7050003@oracle.com> Message-ID: <507EBA39.1030302@oracle.com> If the application know and pass the expiration time to the callback, it can do the warning in the application level. If the application does not know the expiration time, I was wondering that the login context may also not know the time. Does kerberos define expiration fileds? I think, it is not clear to me about the benefits to do it in JDK level. Xuelei On 10/17/2012 1:44 PM, Weijun Wang wrote: > Ping again. > > On 08/17/2012 06:18 PM, Weijun Wang wrote: >> Hi All >> >> I am working with an OpenJDK contributor (Steve Beaty) recently on this >> feature. >> >> We often see messages like "Your password will expire in 5 days. Please >> update ASAP" when we login to a system, and we are seeing if we could >> also support this kind of alert in JAAS. >> >> We first starts with the Krb5LoginModule. In Kerberos, the KDC might >> send a LastReq field in response to a ticket request. Normally, the >> LastReq might contain: >> >> 1. The time the password will expire >> 2. The time the account will expire. >> >> (It might contain other things like the last request time from the same >> client, so the login module can show the user "Last login: Thu Aug 16 >> 19:44:55 2012". That's also how the field is named). >> >> Out current idea is to create a new kind of Callback, say, >> PasswordExpirationCallback for a login module, if a password/account >> expiration message is found in the LastReq field received, some >> user-defined method can be called. >> >> However, we cannot decide on what argument we should provide to this >> method. Certainly, just passing the LastReq field is not very good, >> since it's keberos-specific. Passing only the password expiration time? >> I'm not sure if the information is too little. >> >> Are you familiar with all other styles of password expiration warnings? >> What kind of message is generalized enough and also contains enough info? >> >> Any suggestion welcomed. >> >> Thanks >> Max From weijun.wang at oracle.com Wed Oct 17 08:06:17 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Oct 2012 23:06:17 +0800 Subject: Request for comment: Supporting password expiration alert in JAAS In-Reply-To: <507EBA39.1030302@oracle.com> References: <502E1A5D.7090009@oracle.com> <507E45CC.7050003@oracle.com> <507EBA39.1030302@oracle.com> Message-ID: <507EC969.3030707@oracle.com> The application does not know it, but the KDC does. In this case, if a user's password is about to expire and he logins to the KDC, the AS-REP message will include a expiration warning (LastReq data). Currently we have no way to expose this info to the application. But if we define a new kind of Callback there is a way to do it. So it works something like this: LoginContext login = new LoginContext("c", new CallbackHandler() { public void handle(Callback[] cbs) { for (Callback cb: cbs) { if (nameCB) cb.setName("dummy"); else if (passwordCB) cb.setPass("pAss"); else if (passExpirationCB) alert(cb.???()); } }}); login.login(); We are just not sure what the cb.???() should look like. Thanks Max On 10/17/2012 10:01 PM, Xuelei Fan wrote: > If the application know and pass the expiration time to the callback, it > can do the warning in the application level. > > If the application does not know the expiration time, I was wondering > that the login context may also not know the time. Does kerberos define > expiration fileds? > > I think, it is not clear to me about the benefits to do it in JDK level. > > Xuelei > > On 10/17/2012 1:44 PM, Weijun Wang wrote: >> Ping again. >> >> On 08/17/2012 06:18 PM, Weijun Wang wrote: >>> Hi All >>> >>> I am working with an OpenJDK contributor (Steve Beaty) recently on this >>> feature. >>> >>> We often see messages like "Your password will expire in 5 days. Please >>> update ASAP" when we login to a system, and we are seeing if we could >>> also support this kind of alert in JAAS. >>> >>> We first starts with the Krb5LoginModule. In Kerberos, the KDC might >>> send a LastReq field in response to a ticket request. Normally, the >>> LastReq might contain: >>> >>> 1. The time the password will expire >>> 2. The time the account will expire. >>> >>> (It might contain other things like the last request time from the same >>> client, so the login module can show the user "Last login: Thu Aug 16 >>> 19:44:55 2012". That's also how the field is named). >>> >>> Out current idea is to create a new kind of Callback, say, >>> PasswordExpirationCallback for a login module, if a password/account >>> expiration message is found in the LastReq field received, some >>> user-defined method can be called. >>> >>> However, we cannot decide on what argument we should provide to this >>> method. Certainly, just passing the LastReq field is not very good, >>> since it's keberos-specific. Passing only the password expiration time? >>> I'm not sure if the information is too little. >>> >>> Are you familiar with all other styles of password expiration warnings? >>> What kind of message is generalized enough and also contains enough info? >>> >>> Any suggestion welcomed. >>> >>> Thanks >>> Max > From mstjohns at comcast.net Wed Oct 17 08:25:00 2012 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 17 Oct 2012 11:25:00 -0400 Subject: Request for comment: Supporting password expiration alert in JAAS In-Reply-To: <507E45CC.7050003@oracle.com> References: <502E1A5D.7090009@oracle.com> <507E45CC.7050003@oracle.com> Message-ID: <20121017152459.D93F0681F@mail.openjdk.java.net> This seems too specific to password based authentication. How about something like a "PrincipalAttributes" interface to go along with Refreshable and Destroyable? Properties getAttributes(); define a few names: accountExpiration, passwordExpiration, lastLoginTime etc and their default meanings. Do the login, grab the Subject, then grab the Principals, check for the interface and then do the appropriate actions. You generally don't actually want to return data to the user such as the above until AFTER you're authenticated, and doing this via a callback, by definition is going to happen DURING authentication. Later, Mike At 01:44 AM 10/17/2012, Weijun Wang wrote: >Ping again. > >On 08/17/2012 06:18 PM, Weijun Wang wrote: >>Hi All >> >>I am working with an OpenJDK contributor (Steve Beaty) recently on this >>feature. >> >>We often see messages like "Your password will expire in 5 days. Please >>update ASAP" when we login to a system, and we are seeing if we could >>also support this kind of alert in JAAS. >> >>We first starts with the Krb5LoginModule. In Kerberos, the KDC might >>send a LastReq field in response to a ticket request. Normally, the >>LastReq might contain: >> >>1. The time the password will expire >>2. The time the account will expire. >> >>(It might contain other things like the last request time from the same >>client, so the login module can show the user "Last login: Thu Aug 16 >>19:44:55 2012". That's also how the field is named). >> >>Out current idea is to create a new kind of Callback, say, >>PasswordExpirationCallback for a login module, if a password/account >>expiration message is found in the LastReq field received, some >>user-defined method can be called. >> >>However, we cannot decide on what argument we should provide to this >>method. Certainly, just passing the LastReq field is not very good, >>since it's keberos-specific. Passing only the password expiration time? >>I'm not sure if the information is too little. >> >>Are you familiar with all other styles of password expiration warnings? >>What kind of message is generalized enough and also contains enough info? >> >>Any suggestion welcomed. >> >>Thanks >>Max From mstjohns at comcast.net Wed Oct 17 08:26:56 2012 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 17 Oct 2012 11:26:56 -0400 Subject: Request for comment: Supporting password expiration alert in JAAS In-Reply-To: <7.1.0.9.2.20121017110352.09c640b8@comcast.net> References: <502E1A5D.7090009@oracle.com> <507E45CC.7050003@oracle.com> <7.1.0.9.2.20121017110352.09c640b8@comcast.net> Message-ID: <20121017152655.95E596820@mail.openjdk.java.net> *sigh* Not "Refreshable" and "Destroyable", but "Group" and "UserPrincipal"... Mike At 11:25 AM 10/17/2012, Michael StJohns wrote: >This seems too specific to password based authentication. > >How about something like a "PrincipalAttributes" interface to go along with Refreshable and Destroyable? > >Properties getAttributes(); > >define a few names: accountExpiration, passwordExpiration, lastLoginTime etc and their default meanings. > >Do the login, grab the Subject, then grab the Principals, check for the interface and then do the appropriate actions. > >You generally don't actually want to return data to the user such as the above until AFTER you're authenticated, and doing this via a callback, by definition is going to happen DURING authentication. > >Later, Mike > > > >At 01:44 AM 10/17/2012, Weijun Wang wrote: >>Ping again. >> >>On 08/17/2012 06:18 PM, Weijun Wang wrote: >>>Hi All >>> >>>I am working with an OpenJDK contributor (Steve Beaty) recently on this >>>feature. >>> >>>We often see messages like "Your password will expire in 5 days. Please >>>update ASAP" when we login to a system, and we are seeing if we could >>>also support this kind of alert in JAAS. >>> >>>We first starts with the Krb5LoginModule. In Kerberos, the KDC might >>>send a LastReq field in response to a ticket request. Normally, the >>>LastReq might contain: >>> >>>1. The time the password will expire >>>2. The time the account will expire. >>> >>>(It might contain other things like the last request time from the same >>>client, so the login module can show the user "Last login: Thu Aug 16 >>>19:44:55 2012". That's also how the field is named). >>> >>>Out current idea is to create a new kind of Callback, say, >>>PasswordExpirationCallback for a login module, if a password/account >>>expiration message is found in the LastReq field received, some >>>user-defined method can be called. >>> >>>However, we cannot decide on what argument we should provide to this >>>method. Certainly, just passing the LastReq field is not very good, >>>since it's keberos-specific. Passing only the password expiration time? >>>I'm not sure if the information is too little. >>> >>>Are you familiar with all other styles of password expiration warnings? >>>What kind of message is generalized enough and also contains enough info? >>> >>>Any suggestion welcomed. >>> >>>Thanks >>>Max From maurizio.cimadamore at oracle.com Wed Oct 17 08:43:48 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 17 Oct 2012 15:43:48 +0000 Subject: hg: jdk8/tl/langtools: 7192245: Add parser support for default methods Message-ID: <20121017154353.16E8E473E7@hg.openjdk.java.net> Changeset: 12cf6bfd8c05 Author: mcimadamore Date: 2012-10-17 16:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/12cf6bfd8c05 7192245: Add parser support for default methods Summary: Add support for 'default' keyword in modifier position Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java + test/tools/javac/diags/examples/DefaultMethodNotSupported.java From dmitry.samersoff at oracle.com Wed Oct 17 08:28:18 2012 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Wed, 17 Oct 2012 15:28:18 +0000 Subject: hg: jdk8/tl/jdk: 6809322: javax.management.timer.Timer does not fire all notifications Message-ID: <20121017152840.D794A473E6@hg.openjdk.java.net> Changeset: b2d8a99a049e Author: dsamersoff Date: 2012-10-17 18:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2d8a99a049e 6809322: javax.management.timer.Timer does not fire all notifications Summary: Some notifications get dropped due to ConcurrentModificationException thrown in Timer.notifyAlarmClock() method. Reviewed-by: dholmes, rbackman Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/timer/Timer.java + test/javax/management/timer/MissingNotificationTest.java From mandy.chung at oracle.com Wed Oct 17 12:03:37 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 17 Oct 2012 19:03:37 +0000 Subject: hg: jdk8/tl/jdk: 8001012: jdk8 SKIP_BUILD_CYCLE=false build fails with BUILD_JAXWS=false Message-ID: <20121017190401.7B317473EC@hg.openjdk.java.net> Changeset: 6156b9235758 Author: mchung Date: 2012-10-17 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6156b9235758 8001012: jdk8 SKIP_BUILD_CYCLE=false build fails with BUILD_JAXWS=false Reviewed-by: alanb, ohair ! make/common/internal/Defs-jaxws.gmk From alan.bateman at oracle.com Wed Oct 17 12:34:21 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 17 Oct 2012 19:34:21 +0000 Subject: hg: jdk8/tl/jdk: 7198496: (sl) ServiceLoader.load(Class, null) behavior differs from spec Message-ID: <20121017193446.0D5B6473EF@hg.openjdk.java.net> Changeset: 586028bbf885 Author: psandoz Date: 2012-10-17 20:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/586028bbf885 7198496: (sl) ServiceLoader.load(Class, null) behavior differs from spec Reviewed-by: dholmes, alanb ! src/share/classes/java/util/ServiceLoader.java ! test/java/util/ServiceLoader/Basic.java ! test/java/util/ServiceLoader/basic.sh From alan.bateman at oracle.com Wed Oct 17 13:13:49 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 17 Oct 2012 20:13:49 +0000 Subject: hg: jdk8/tl/jdk: 8000362: (pack200) Deprecate Packer/Unpacker addPropertyChangeLister and removePropertyChangeListener methods Message-ID: <20121017201412.EC0B5473F0@hg.openjdk.java.net> Changeset: b265ead7f331 Author: alanb Date: 2012-10-17 21:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b265ead7f331 8000362: (pack200) Deprecate Packer/Unpacker addPropertyChangeLister and removePropertyChangeListener methods Reviewed-by: lancea, chegar, mchung, ksrini ! src/share/classes/java/util/jar/Pack200.java From naoto.sato at oracle.com Wed Oct 17 13:23:38 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 17 Oct 2012 20:23:38 +0000 Subject: hg: jdk8/tl/jdk: 8001046: java/util/PluggableLocale/LocaleNameProviderTest.sh failing Message-ID: <20121017202352.DE3D2473F1@hg.openjdk.java.net> Changeset: 60994591be6b Author: naoto Date: 2012-10-17 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60994591be6b 8001046: java/util/PluggableLocale/LocaleNameProviderTest.sh failing Reviewed-by: okutsu ! test/java/util/PluggableLocale/barprovider.jar From weijun.wang at oracle.com Wed Oct 17 20:14:12 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Oct 2012 11:14:12 +0800 Subject: Code review request: 7110803: SASL service for multiple hostnames Message-ID: <507F7404.4030805@oracle.com> Hi All Please take a look at http://cr.openjdk.java.net/~weijun/7110803/webrev.00/ In Sasl.createSaslServer() method, the serverName argument is documented as "[t]he non-null fully qualified host name of the server". This means a SASL service must specify the exact hostname it is serving at (say, my.host.com). This is not true any more in today's virtualized world in which a service might be serving clients from different networks by exposing different service names. The RFE allows serverName to be set to null in Sasl.createSaslServer() and thus creates an unbound SASL server. This will be useful if the server can accept multiple server names (think of virtual hosts in an Apache HTTP server) or the name is configured in the underlying mechanism. It also provides a new negotiated property called BOUND_SERVER_NAME so that an unbound server has a chance to see its bound name after the auth exchange is completed. This patch includes the API change and trivial changes for some mechanisms. The patch for the GSSAPI mechanism is a little more complicated and will be addressed in a sub-bug. Thanks Max From xuelei.fan at oracle.com Thu Oct 18 01:15:04 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 18 Oct 2012 08:15:04 +0000 Subject: hg: jdk8/tl/jdk: 7068321: Support TLS Server Name Indication (SNI) Extension in JSSE Server Message-ID: <20121018081542.3F0824740F@hg.openjdk.java.net> Changeset: 3f62cfc4e83d Author: xuelei Date: 2012-10-18 01:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f62cfc4e83d 7068321: Support TLS Server Name Indication (SNI) Extension in JSSE Server Reviewed-by: mullan, weijun, wetmore ! src/share/classes/javax/net/ssl/ExtendedSSLSession.java ! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java + src/share/classes/javax/net/ssl/SNIHostName.java + src/share/classes/javax/net/ssl/SNIMatcher.java + src/share/classes/javax/net/ssl/SNIServerName.java ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLServerSocket.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java + src/share/classes/javax/net/ssl/StandardConstants.java ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SunJSSE.java + src/share/classes/sun/security/ssl/Utilities.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineService.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java + test/sun/security/ssl/templates/SSLCapabilities.java + test/sun/security/ssl/templates/SSLExplorer.java From sean.mullan at oracle.com Thu Oct 18 14:26:10 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 18 Oct 2012 17:26:10 -0400 Subject: bug fix for native kerberos libraries In-Reply-To: <20121018210243.DC05597124@rebar.astron.com> References: <20121018210243.DC05597124@rebar.astron.com> Message-ID: <508073F2.2020002@oracle.com> (Forwarding to security-dev as this should be discussed in that group, not core-libs). On 10/18/12 5:02 PM, christos at zoulas.com wrote: > Hello, > > This simple fix allows kerberos authentication to work with: > > -Dsun.security.jgss.native=true > > and microsoft's sqljdbc 4.0.2206.100 driver. > > Enjoy, > > christos > > --- a/java/src/sun/security/jgss/GSSUtil.java Mon Oct 15 17:43:08 2012 -0400 > +++ b/java/src/sun/security/jgss/GSSUtil.java Mon Oct 15 17:44:28 2012 -0400 > @@ -333,10 +333,19 @@ > Subject accSubj = Subject.getSubject(acc); > Vector result = null; > if (accSubj != null) { > - result = new Vector(); > Iterator iterator = > accSubj.getPrivateCredentials > (GSSCredentialImpl.class).iterator(); > + // GSSCredentialImpl is only implemented in > + // the non-native kerberos implementation, > + // so if we don't get any elements here > + // assume native and return null so that > + // searchSubject does not fail. A better > + // fix is to implement the code that handles > + // this in native java. > + if (!iterator.hasNext()) > + return null; > + result = new Vector(); > while (iterator.hasNext()) { > GSSCredentialImpl cred = iterator.next(); > debug("...Found cred" + cred); > From weijun.wang at oracle.com Thu Oct 18 18:11:33 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 19 Oct 2012 09:11:33 +0800 Subject: bug fix for native kerberos libraries In-Reply-To: <508073F2.2020002@oracle.com> References: <20121018210243.DC05597124@rebar.astron.com> <508073F2.2020002@oracle.com> Message-ID: <5080A8C5.2070902@oracle.com> Hi Christos You mean the exception thrown in NativeGSSFactory.java lines 52-60? Vector creds = GSSUtil.searchSubject (name, mech, initiate, GSSCredElement.class); // If Subject is present but no native creds available if (creds != null && creds.isEmpty()) { if (GSSUtil.useSubjectCredsOnly(caller)) { throw new GSSException(GSSException.NO_CRED); } } Why would you leave GSSUtil.useSubjectCredsOnly to be true? IMHO, there is no need to call JGSS through JAAS when you are using a native provider. Thanks Max On 10/19/2012 05:26 AM, Sean Mullan wrote: > > (Forwarding to security-dev as this should be discussed in that group, not > core-libs). > > On 10/18/12 5:02 PM, christos at zoulas.com wrote: >> Hello, >> >> This simple fix allows kerberos authentication to work with: >> >> -Dsun.security.jgss.native=true >> >> and microsoft's sqljdbc 4.0.2206.100 driver. >> >> Enjoy, >> >> christos >> >> --- a/java/src/sun/security/jgss/GSSUtil.java Mon Oct 15 17:43:08 2012 -0400 >> +++ b/java/src/sun/security/jgss/GSSUtil.java Mon Oct 15 17:44:28 2012 -0400 >> @@ -333,10 +333,19 @@ >> Subject accSubj = Subject.getSubject(acc); >> Vector result = null; >> if (accSubj != null) { >> - result = new Vector(); >> Iterator iterator = >> accSubj.getPrivateCredentials >> (GSSCredentialImpl.class).iterator(); >> + // GSSCredentialImpl is only implemented in >> + // the non-native kerberos implementation, >> + // so if we don't get any elements here >> + // assume native and return null so that >> + // searchSubject does not fail. A better >> + // fix is to implement the code that handles >> + // this in native java. >> + if (!iterator.hasNext()) >> + return null; >> + result = new Vector(); >> while (iterator.hasNext()) { >> GSSCredentialImpl cred = iterator.next(); >> debug("...Found cred" + cred); >> From chris.hegarty at oracle.com Fri Oct 19 04:24:54 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 19 Oct 2012 11:24:54 +0000 Subject: hg: jdk8/tl/jdk: 8000206: Uninitialized variable in PlainDatagramSocketImpl.c Message-ID: <20121019112603.0EF7E47452@hg.openjdk.java.net> Changeset: 27f854a1e5c5 Author: chegar Date: 2012-10-19 11:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27f854a1e5c5 8000206: Uninitialized variable in PlainDatagramSocketImpl.c Reviewed-by: dsamersoff, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/java/net/PlainDatagramSocketImpl.c From john.zavgren at oracle.com Fri Oct 19 13:28:41 2012 From: john.zavgren at oracle.com (John Zavgren) Date: Fri, 19 Oct 2012 13:28:41 -0700 (PDT) Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c Message-ID: <8713b072-01e0-4e2a-8dad-776cea3250e5@default> Greetings: The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t)); The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. Thanks! John Zavgren john.zavgren at oracle.com From christos at zoulas.com Fri Oct 19 05:50:48 2012 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 19 Oct 2012 08:50:48 -0400 Subject: bug fix for native kerberos libraries In-Reply-To: <5080A8C5.2070902@oracle.com> from Weijun Wang (Oct 19, 9:11am) Message-ID: <20121019125048.222A097124@rebar.astron.com> On Oct 19, 9:11am, weijun.wang at oracle.com (Weijun Wang) wrote: -- Subject: Re: bug fix for native kerberos libraries | Hi Christos | | You mean the exception thrown in NativeGSSFactory.java lines 52-60? | | Vector creds = GSSUtil.searchSubject | (name, mech, initiate, GSSCredElement.class); | | // If Subject is present but no native creds available | if (creds != null && creds.isEmpty()) { | if (GSSUtil.useSubjectCredsOnly(caller)) { | throw new GSSException(GSSException.NO_CRED); | } | } | | Why would you leave GSSUtil.useSubjectCredsOnly to be true? IMHO, there | is no need to call JGSS through JAAS when you are using a native provider. Yes, I guess this is new with JDK 7. Thanks I will try that! christos From christos at zoulas.com Fri Oct 19 08:17:12 2012 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 19 Oct 2012 11:17:12 -0400 Subject: bug fix for native kerberos libraries In-Reply-To: <20121019125048.222A097124@rebar.astron.com> from Christos Zoulas (Oct 19, 8:50am) Message-ID: <20121019151713.18A7597124@rebar.astron.com> On Oct 19, 8:50am, christos at zoulas.com (Christos Zoulas) wrote: -- Subject: Re: bug fix for native kerberos libraries Hi Weijun, I verified that setting -Djavax.security.auth.useSubjectCredsOnly=false fixes this issue, but then unless I brought in my other patch from jdk6, I get: javax.security.auth.login.LoginException: Unable to obtain Princpal Name for authentication Someone should fix the typo in the exception string, but also why do I need this? Thanks, christos --- bsd-port/jdk/src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java 2011-07-17 20:36:08.000000000 -0400 +++ ./Krb5LoginModule.java 2012-10-19 10:51:02.027729713 -0400 @@ -624,6 +624,29 @@ // ticketCacheName == null implies the default cache if (debug) System.out.println("Acquire TGT from Cache"); + if (ticketCacheName == null) { + /* + * http://docs.oracle.com/cd/E19082-01/819-2252/\ + * 6n4i8rtr3/index.html + */ + String krb5CCName = System.getenv("KRB5CCNAME"); + if (krb5CCName != null) { + final String filePrefix = "FILE:"; + final String memoryPrefix = "MEMORY:"; + if (krb5CCName.startsWith(filePrefix)) + ticketCacheName = krb5CCName.substring( + filePrefix.length()); + else if (krb5CCName.startsWith(memoryPrefix)) + ticketCacheName = krb5CCName.substring( + memoryPrefix.length()); + else + ticketCacheName = krb5CCName; + if (debug) + System.out.println("Located ticket cache " + + ticketCacheName + + " through environment variable KRB5CCNAME."); + } + } cred = Credentials.acquireTGTFromCache (principal, ticketCacheName); From bradford.wetmore at oracle.com Fri Oct 19 17:11:02 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 19 Oct 2012 17:11:02 -0700 Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c In-Reply-To: <8713b072-01e0-4e2a-8dad-776cea3250e5@default> References: <8713b072-01e0-4e2a-8dad-776cea3250e5@default> Message-ID: <5081EC16.902@oracle.com> Looks good, taken in isolation. Just to be sure, are there any other methods that might return some object that has to be freed. Brad On 10/19/2012 1:28 PM, John Zavgren wrote: > Greetings: > The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c > > http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ > > The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t)); > > The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. > > Thanks! > John Zavgren > john.zavgren at oracle.com > From john.zavgren at oracle.com Fri Oct 19 17:54:22 2012 From: john.zavgren at oracle.com (John Zavgren) Date: Fri, 19 Oct 2012 17:54:22 -0700 (PDT) Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c Message-ID: <97a22acc-6f4b-4dad-b1cd-577a195cb9b6@default> Brad: I'm not sure that I completely understand your question, because this is C code and there are no objects involved. Nevertheless, I read through the procedures that are defined in this particular file (Unix.c) and balanced their memory allocations (malloc(), calloc()) against their memory deallocations (free()) and they seem to balance out now. John ----- Original Message ----- From: bradford.wetmore at oracle.com To: john.zavgren at oracle.com Cc: security-dev at openjdk.java.net Sent: Friday, October 19, 2012 8:11:03 PM GMT -05:00 US/Canada Eastern Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c Looks good, taken in isolation. Just to be sure, are there any other methods that might return some object that has to be freed. Brad On 10/19/2012 1:28 PM, John Zavgren wrote: > Greetings: > The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c > > http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ > > The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t)); > > The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. > > Thanks! > John Zavgren > john.zavgren at oracle.com > From bradford.wetmore at oracle.com Fri Oct 19 19:27:55 2012 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 19 Oct 2012 19:27:55 -0700 Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c In-Reply-To: <97a22acc-6f4b-4dad-b1cd-577a195cb9b6@default> References: <97a22acc-6f4b-4dad-b1cd-577a195cb9b6@default> Message-ID: <50820C2B.1090607@oracle.com> Yes, that's what I meant. Just that none of the other functions alloc'd memory internally that you had to manually free. Thanks for checking. Brad On 10/19/2012 5:54 PM, John Zavgren wrote: > Brad: > I'm not sure that I completely understand your question, because this is C code and there are no objects involved. Nevertheless, I read through the procedures that are defined in this particular file (Unix.c) and balanced their memory allocations (malloc(), calloc()) against their memory deallocations (free()) and they seem to balance out now. > > John > > ----- Original Message ----- > From: bradford.wetmore at oracle.com > To: john.zavgren at oracle.com > Cc: security-dev at openjdk.java.net > Sent: Friday, October 19, 2012 8:11:03 PM GMT -05:00 US/Canada Eastern > Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c > > Looks good, taken in isolation. > > Just to be sure, are there any other methods that might return some > object that has to be freed. > > Brad > > > On 10/19/2012 1:28 PM, John Zavgren wrote: >> Greetings: >> The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c >> >> http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ >> >> The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t)); >> >> The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. >> >> Thanks! >> John Zavgren >> john.zavgren at oracle.com >> From xuelei.fan at oracle.com Fri Oct 19 20:39:29 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sat, 20 Oct 2012 03:39:29 +0000 Subject: hg: jdk8/tl/jdk: 8000954: Add final keyword to new method in SSLParameters Message-ID: <20121020033955.881164746A@hg.openjdk.java.net> Changeset: 21f1b88e68ce Author: xuelei Date: 2012-10-19 20:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21f1b88e68ce 8000954: Add final keyword to new method in SSLParameters Reviewed-by: wetmore ! src/share/classes/javax/net/ssl/SSLParameters.java From alan.bateman at oracle.com Sat Oct 20 13:07:58 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 20 Oct 2012 20:07:58 +0000 Subject: hg: jdk8/tl/jdk: 8000941: Remove ftp from the required list of protocol handlers Message-ID: <20121020200842.645E447477@hg.openjdk.java.net> Changeset: 93303f8a4a8e Author: alanb Date: 2012-10-20 21:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93303f8a4a8e 8000941: Remove ftp from the required list of protocol handlers Reviewed-by: chegar ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLStreamHandler.java ! src/share/classes/java/net/package.html From weijun.wang at oracle.com Sun Oct 21 17:17:38 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Oct 2012 08:17:38 +0800 Subject: bug fix for native kerberos libraries In-Reply-To: <20121019151713.18A7597124@rebar.astron.com> References: <20121019151713.18A7597124@rebar.astron.com> Message-ID: <508490A2.7030603@oracle.com> You are still using JAAS? There is no need to call Krb5LoginModule or read credentials cache yourself if you are using native kerberos. Just call JGSS APIs directly. Thanks Weijun On 10/19/2012 11:17 PM, christos at zoulas.com wrote: > On Oct 19, 8:50am, christos at zoulas.com (Christos Zoulas) wrote: > -- Subject: Re: bug fix for native kerberos libraries > > Hi Weijun, > > I verified that setting -Djavax.security.auth.useSubjectCredsOnly=false > fixes this issue, but then unless I brought in my other patch from jdk6, > I get: > javax.security.auth.login.LoginException: Unable to obtain Princpal Name for authentication > > Someone should fix the typo in the exception string, but also why do I need > this? > > Thanks, > > christos > > --- bsd-port/jdk/src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java 2011-07-17 20:36:08.000000000 -0400 > +++ ./Krb5LoginModule.java 2012-10-19 10:51:02.027729713 -0400 > @@ -624,6 +624,29 @@ > // ticketCacheName == null implies the default cache > if (debug) > System.out.println("Acquire TGT from Cache"); > + if (ticketCacheName == null) { > + /* > + * http://docs.oracle.com/cd/E19082-01/819-2252/\ > + * 6n4i8rtr3/index.html > + */ > + String krb5CCName = System.getenv("KRB5CCNAME"); > + if (krb5CCName != null) { > + final String filePrefix = "FILE:"; > + final String memoryPrefix = "MEMORY:"; > + if (krb5CCName.startsWith(filePrefix)) > + ticketCacheName = krb5CCName.substring( > + filePrefix.length()); > + else if (krb5CCName.startsWith(memoryPrefix)) > + ticketCacheName = krb5CCName.substring( > + memoryPrefix.length()); > + else > + ticketCacheName = krb5CCName; > + if (debug) > + System.out.println("Located ticket cache " > + + ticketCacheName > + + " through environment variable KRB5CCNAME."); > + } > + } > cred = Credentials.acquireTGTFromCache > (principal, ticketCacheName); > > From weijun.wang at oracle.com Sun Oct 21 17:34:22 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Oct 2012 08:34:22 +0800 Subject: Code review request: 8001204: typo: Unable to obtain Princpal Name for authentication Message-ID: <5084948E.8050606@oracle.com> A simple typo fix: http://cr.openjdk.java.net/~weijun/8001204/webrev.00/ It's just --- a/src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java +++ b/src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java @@ -802,7 +802,7 @@ if (doNotPrompt) { throw new LoginException - ("Unable to obtain Princpal Name for authentication "); + ("Unable to obtain Principal Name for authentication "); } else { if (callbackHandler == null) throw new LoginException("No CallbackHandler " I didn't remove the space at the end of string. The same trailing space appears multiple times in the same file and I don't want to change all those lines. Thanks Max From christos at zoulas.com Sun Oct 21 18:16:23 2012 From: christos at zoulas.com (Christos Zoulas) Date: Sun, 21 Oct 2012 21:16:23 -0400 Subject: bug fix for native kerberos libraries In-Reply-To: <508490A2.7030603@oracle.com> from Weijun Wang (Oct 22, 8:17am) Message-ID: <20121022011623.8F1FA97124@rebar.astron.com> On Oct 22, 8:17am, weijun.wang at oracle.com (Weijun Wang) wrote: -- Subject: Re: bug fix for native kerberos libraries | You are still using JAAS? There is no need to call Krb5LoginModule or | read credentials cache yourself if you are using native kerberos. Just | call JGSS APIs directly. | | Thanks | Weijun I am not doing anything with kerberos/gssapi directly. I am just using the Microsoft sql server java driver (*), and it is doing all the calls. While it works fine with the java implementation, it does not work with the native MIT libraries, and needs that fix. Best, christos (*) http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11774 From xuelei.fan at oracle.com Sun Oct 21 18:41:44 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 22 Oct 2012 09:41:44 +0800 Subject: Code review request: 8001204: typo: Unable to obtain Princpal Name for authentication In-Reply-To: <5084948E.8050606@oracle.com> References: <5084948E.8050606@oracle.com> Message-ID: <5084A458.1050209@oracle.com> Looks fine to me. Xuelei On 10/22/2012 8:34 AM, Weijun Wang wrote: > A simple typo fix: > > http://cr.openjdk.java.net/~weijun/8001204/webrev.00/ > > It's just > > --- a/src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java > +++ b/src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java > @@ -802,7 +802,7 @@ > > if (doNotPrompt) { > throw new LoginException > - ("Unable to obtain Princpal Name for authentication "); > + ("Unable to obtain Principal Name for authentication "); > } else { > if (callbackHandler == null) > throw new LoginException("No CallbackHandler " > > I didn't remove the space at the end of string. The same trailing space > appears multiple times in the same file and I don't want to change all > those lines. > > Thanks > Max From weijun.wang at oracle.com Sun Oct 21 18:59:44 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 22 Oct 2012 01:59:44 +0000 Subject: hg: jdk8/tl/jdk: 8001204: typo: Unable to obtain Princpal Name for authentication Message-ID: <20121022020007.160B247489@hg.openjdk.java.net> Changeset: b39ab9c6f4cb Author: weijun Date: 2012-10-22 09:59 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b39ab9c6f4cb 8001204: typo: Unable to obtain Princpal Name for authentication Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java From weijun.wang at oracle.com Sun Oct 21 19:54:39 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Oct 2012 10:54:39 +0800 Subject: bug fix for native kerberos libraries In-Reply-To: <20121022011623.8F1FA97124@rebar.astron.com> References: <20121022011623.8F1FA97124@rebar.astron.com> Message-ID: <5084B56F.6000503@oracle.com> I see. So it looks like the MS tool is calling JAAS. Is it asking you to prepare a JAAS login file like this? client { com.sun.security.auth.module.Krb5LoginModule required ...; }; You can put a key-value pair ticketCache=ccache_file inside it where ccache_file is the KRB5CCNAME env variable. This would assign the value to ticketCacheName and your patch won't be needed. In fact, whatever credentials you specified here will not be used by the final GSS mech at all (since it's native). So maybe we can just trick the MS tool that a login is there but do nothing. Please try this (jdk7 only) client { com.sun.security.auth.module.Krb5LoginModule required principal=nobody at NOWHERE useKeyTab=true isInitiator=false; }; If this work, you don't need to call kinit and save a ccache file somewhere. -Weijun On 10/22/2012 09:16 AM, christos at zoulas.com wrote: > On Oct 22, 8:17am, weijun.wang at oracle.com (Weijun Wang) wrote: > -- Subject: Re: bug fix for native kerberos libraries > > | You are still using JAAS? There is no need to call Krb5LoginModule or > | read credentials cache yourself if you are using native kerberos. Just > | call JGSS APIs directly. > | > | Thanks > | Weijun > > I am not doing anything with kerberos/gssapi directly. I am just using > the Microsoft sql server java driver (*), and it is doing all the calls. > While it works fine with the java implementation, it does not work with > the native MIT libraries, and needs that fix. > > Best, > > christos > > (*) http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11774 > From christos at zoulas.com Sun Oct 21 20:10:18 2012 From: christos at zoulas.com (Christos Zoulas) Date: Sun, 21 Oct 2012 23:10:18 -0400 Subject: bug fix for native kerberos libraries In-Reply-To: <5084B56F.6000503@oracle.com> from Weijun Wang (Oct 22, 10:54am) Message-ID: <20121022031018.B1A2197124@rebar.astron.com> On Oct 22, 10:54am, weijun.wang at oracle.com (Weijun Wang) wrote: -- Subject: Re: bug fix for native kerberos libraries | I see. So it looks like the MS tool is calling JAAS. Is it asking you to | prepare a JAAS login file like this? | | client { | com.sun.security.auth.module.Krb5LoginModule required | ...; | }; | | You can put a key-value pair ticketCache=ccache_file inside it where | ccache_file is the KRB5CCNAME env variable. This would assign the value | to ticketCacheName and your patch won't be needed. The value of the environment variable is not constant, so I will have to generate the login file at each program invocation which is highly invonvenient. For example when ssh propagates the ticket file from one host to another the filename changes (from /tmp/krb5cc_ to /tmp/krb5cc_uid_). | In fact, whatever credentials you specified here will not be used by the | final GSS mech at all (since it's native). So maybe we can just trick | the MS tool that a login is there but do nothing. Please try this (jdk7 | only) | | client { | com.sun.security.auth.module.Krb5LoginModule required | principal=nobody at NOWHERE | useKeyTab=true | isInitiator=false; | }; | | If this work, you don't need to call kinit and save a ccache file somewhere. I think that this is a good idea. I will try it and see if it works. On the other hand, it would be nice if the native and the non-native implementation behaved the same way. Requiring such a file for one and not the other is not the behavior expected by the user. I understand that my patch is not clean and that this has been brought up before (Bug ID: 6832353), but since this is not accessible anymore I don't know what was the resolution of it. Anyway thanks for the advise, I will try and get back to you. christos From weijun.wang at oracle.com Sun Oct 21 20:29:57 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Oct 2012 11:29:57 +0800 Subject: bug fix for native kerberos libraries In-Reply-To: <20121022031018.B1A2197124@rebar.astron.com> References: <20121022031018.B1A2197124@rebar.astron.com> Message-ID: <5084BDB5.1000807@oracle.com> On 10/22/2012 11:10 AM, christos at zoulas.com wrote: > On Oct 22, 10:54am, weijun.wang at oracle.com (Weijun Wang) wrote: > -- Subject: Re: bug fix for native kerberos libraries > > | I see. So it looks like the MS tool is calling JAAS. Is it asking you to > | prepare a JAAS login file like this? > | > | client { > | com.sun.security.auth.module.Krb5LoginModule required > | ...; > | }; > | > | You can put a key-value pair ticketCache=ccache_file inside it where > | ccache_file is the KRB5CCNAME env variable. This would assign the value > | to ticketCacheName and your patch won't be needed. > > The value of the environment variable is not constant, so I will > have to generate the login file at each program invocation which is > highly invonvenient. For example when ssh propagates the ticket file > from one host to another the filename changes (from /tmp/krb5cc_ > to /tmp/krb5cc_uid_). I see. > > | In fact, whatever credentials you specified here will not be used by the > | final GSS mech at all (since it's native). So maybe we can just trick > | the MS tool that a login is there but do nothing. Please try this (jdk7 > | only) > | > | client { > | com.sun.security.auth.module.Krb5LoginModule required > | principal=nobody at NOWHERE > | useKeyTab=true > | isInitiator=false; > | }; > | > | If this work, you don't need to call kinit and save a ccache file somewhere. > > I think that this is a good idea. I will try it and see if it works. On > the other hand, it would be nice if the native and the non-native > implementation behaved the same way. Requiring such a file for one and > not the other is not the behavior expected by the user. Well, the java krb5 and native krb5 mechs are so different that the later needs no JAAS at all. So even if you make the config file looking the same, it's still quite different inside. > I understand > that my patch is not clean and that this has been brought up before > (Bug ID: 6832353), but since this is not accessible anymore I don't know > what was the resolution of it. Oh, I forgot about that bug. It was integrated into jdk 7. Can you please add "-Dsun.security.krb5.debug=true" to your java command line? It will show something like >>>KinitOptions cache name is ... If the cache name shows your KRB5CCNAME it should be picked up. I haven't removed the FILE: prefix and maybe that is the problem. Since you are already playing with OpenJDK sources, can you try adding the prefix removing code around line 366 in the following file? http://hg.openjdk.java.net/jdk8/tl/jdk/file/79b63e8eceda/src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java If that works, I'll happily apply the change to jdk 7 and 8. Thanks Weijun > > Anyway thanks for the advise, I will try and get back to you. > > christos > From weijun.wang at oracle.com Sun Oct 21 20:33:00 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Oct 2012 11:33:00 +0800 Subject: bug fix for native kerberos libraries In-Reply-To: <5084BDB5.1000807@oracle.com> References: <20121022031018.B1A2197124@rebar.astron.com> <5084BDB5.1000807@oracle.com> Message-ID: <5084BE6C.7090603@oracle.com> I forgot to ask: Your patch mentioned MEMORY: ccache. What is the full string? Is that any document on it? Thanks Weijun On 10/22/2012 11:29 AM, Weijun Wang wrote: > > > On 10/22/2012 11:10 AM, christos at zoulas.com wrote: >> On Oct 22, 10:54am, weijun.wang at oracle.com (Weijun Wang) wrote: >> -- Subject: Re: bug fix for native kerberos libraries >> >> | I see. So it looks like the MS tool is calling JAAS. Is it asking >> you to >> | prepare a JAAS login file like this? >> | >> | client { >> | com.sun.security.auth.module.Krb5LoginModule required >> | ...; >> | }; >> | >> | You can put a key-value pair ticketCache=ccache_file inside it where >> | ccache_file is the KRB5CCNAME env variable. This would assign the value >> | to ticketCacheName and your patch won't be needed. >> >> The value of the environment variable is not constant, so I will >> have to generate the login file at each program invocation which is >> highly invonvenient. For example when ssh propagates the ticket file >> from one host to another the filename changes (from /tmp/krb5cc_ >> to /tmp/krb5cc_uid_). > > I see. > >> >> | In fact, whatever credentials you specified here will not be used by >> the >> | final GSS mech at all (since it's native). So maybe we can just trick >> | the MS tool that a login is there but do nothing. Please try this (jdk7 >> | only) >> | >> | client { >> | com.sun.security.auth.module.Krb5LoginModule required >> | principal=nobody at NOWHERE >> | useKeyTab=true >> | isInitiator=false; >> | }; >> | >> | If this work, you don't need to call kinit and save a ccache file >> somewhere. >> >> I think that this is a good idea. I will try it and see if it works. On >> the other hand, it would be nice if the native and the non-native >> implementation behaved the same way. Requiring such a file for one and >> not the other is not the behavior expected by the user. > > Well, the java krb5 and native krb5 mechs are so different that the > later needs no JAAS at all. So even if you make the config file looking > the same, it's still quite different inside. > >> I understand >> that my patch is not clean and that this has been brought up before >> (Bug ID: 6832353), but since this is not accessible anymore I don't know >> what was the resolution of it. > > Oh, I forgot about that bug. It was integrated into jdk 7. > > Can you please add "-Dsun.security.krb5.debug=true" to your java command > line? It will show something like > > >>>KinitOptions cache name is ... > > If the cache name shows your KRB5CCNAME it should be picked up. I > haven't removed the FILE: prefix and maybe that is the problem. Since > you are already playing with OpenJDK sources, can you try adding the > prefix removing code around line 366 in the following file? > > > http://hg.openjdk.java.net/jdk8/tl/jdk/file/79b63e8eceda/src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java > > > If that works, I'll happily apply the change to jdk 7 and 8. > > Thanks > Weijun > >> >> Anyway thanks for the advise, I will try and get back to you. >> >> christos >> From christos at zoulas.com Sun Oct 21 21:10:30 2012 From: christos at zoulas.com (Christos Zoulas) Date: Mon, 22 Oct 2012 00:10:30 -0400 Subject: bug fix for native kerberos libraries In-Reply-To: <5084BE6C.7090603@oracle.com> from Weijun Wang (Oct 22, 11:33am) Message-ID: <20121022041030.8F9E197124@rebar.astron.com> On Oct 22, 11:33am, weijun.wang at oracle.com (Weijun Wang) wrote: -- Subject: Re: bug fix for native kerberos libraries | I forgot to ask: | | Your patch mentioned MEMORY: ccache. What is the full string? Is that | any document on it? It was in my patch: > + * http://docs.oracle.com/cd/E19082-01/819-2252/\ > + * 6n4i8rtr3/index.html Best, christos From weijun.wang at oracle.com Sun Oct 21 22:06:01 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Oct 2012 13:06:01 +0800 Subject: bug fix for native kerberos libraries In-Reply-To: <20121022041030.8F9E197124@rebar.astron.com> References: <20121022041030.8F9E197124@rebar.astron.com> Message-ID: <5084D439.4050407@oracle.com> But are you using MEMORY: type ccache in your case? If I understand correctly, the substring after MEMORY: is not a normal file name. It's a tag that links to a block of bytes stored in the memory that must be accessed with native calls. I'll not support it at the moment. Thanks Weijun On 10/22/2012 12:10 PM, christos at zoulas.com wrote: > On Oct 22, 11:33am, weijun.wang at oracle.com (Weijun Wang) wrote: > -- Subject: Re: bug fix for native kerberos libraries > > | I forgot to ask: > | > | Your patch mentioned MEMORY: ccache. What is the full string? Is that > | any document on it? > > It was in my patch: > >> + * http://docs.oracle.com/cd/E19082-01/819-2252/\ >> + * 6n4i8rtr3/index.html > > Best, > > christos > From weijun.wang at oracle.com Sun Oct 21 23:38:20 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Oct 2012 14:38:20 +0800 Subject: Code review request: 8001208: Fix for KRB5CCNAME not complete Message-ID: <5084E9DC.70303@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/8001208/webrev.00/ An old test is enhanced to check for the fix. Honestly, it might be best to check for KRB5CCNAME outside FileCredentialsCache since the ccache type can be something other than FILE:. It will touch more files and I decide to delay this enhancement until we start supporting more real types. Also, I want to backport this fix to 7u, so it had better be simple. Thanks Max From weijun.wang at oracle.com Mon Oct 22 01:34:55 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Oct 2012 16:34:55 +0800 Subject: Add MaxRetries.java test to ProblemList Message-ID: <5085052F.5050209@oracle.com> Hi Alan There's been more than a week bug https://jbs.oracle.com/bugs/browse/JDK-8000439 was reassigned to hotspot and the test still fails for latest nightly at /net/sqenfs-1/export1/comp/vm/jdk/nightly/fastdebug/comp_baseline/solaris-sparcv9/ Therefore, I request it be added into ProblemList.java. A sub task is created at https://jbs.oracle.com/bugs/browse/JDK-8000624 and here is webrev: http://cr.openjdk.java.net/~weijun/8000624/webrev.00/ Thanks Max From Alan.Bateman at oracle.com Mon Oct 22 01:38:51 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Oct 2012 09:38:51 +0100 Subject: Add MaxRetries.java test to ProblemList In-Reply-To: <5085052F.5050209@oracle.com> References: <5085052F.5050209@oracle.com> Message-ID: <5085061B.400@oracle.com> On 22/10/2012 09:34, Weijun Wang wrote: > > > and here is webrev: > > http://cr.openjdk.java.net/~weijun/8000624/webrev.00/ It make sense to exclude the test until the hotspot issue is resolved. The change looks okay, assuming that "solaris-sparcv9" does indeed exclude it. -Alan From Dmitry.Samersoff at oracle.com Mon Oct 22 01:53:19 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 22 Oct 2012 12:53:19 +0400 Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c In-Reply-To: <8713b072-01e0-4e2a-8dad-776cea3250e5@default> References: <8713b072-01e0-4e2a-8dad-776cea3250e5@default> Message-ID: <5085097F.5050504@oracle.com> John, Sorry for being later. Again, it's not to your changes but as well as you are touching this code. 88, 103, 118: Type-o - we are checking for uid,gid,groups field, but exception says "invalid field: username" in all cases. It's better to fix it as well. ??: Does it make sense to abort after (*env)->ThrowNew(...) ? -Dmitry On 2012-10-20 00:28, John Zavgren wrote: > Greetings: > The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c > > http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ > > The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t));id > > The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. > > Thanks! > John Zavgren > john.zavgren at oracle.com > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From weijun.wang at oracle.com Mon Oct 22 02:00:08 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Oct 2012 17:00:08 +0800 Subject: Add MaxRetries.java test to ProblemList In-Reply-To: <5085061B.400@oracle.com> References: <5085052F.5050209@oracle.com> <5085061B.400@oracle.com> Message-ID: <50850B18.70507@oracle.com> On 10/22/2012 04:38 PM, Alan Bateman wrote: > On 22/10/2012 09:34, Weijun Wang wrote: >> >> >> and here is webrev: >> >> http://cr.openjdk.java.net/~weijun/8000624/webrev.00/ > It make sense to exclude the test until the hotspot issue is resolved. > The change looks okay, assuming that "solaris-sparcv9" does indeed > exclude it. Yes, I can see it in the excluded list when I try running gmake jdk_security3 on that machine. In fact, since test/Makefile simply uses egrep I believe it will be also excluded in the 32 bit test. I don't care about it now. -Max > > -Alan From weijun.wang at oracle.com Mon Oct 22 02:02:04 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 22 Oct 2012 09:02:04 +0000 Subject: hg: jdk8/tl/jdk: 8000624: Move MaxRetries.java to ProblemList for the moment Message-ID: <20121022090227.BDC7C4748F@hg.openjdk.java.net> Changeset: e19dc885da0d Author: weijun Date: 2012-10-22 17:01 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e19dc885da0d 8000624: Move MaxRetries.java to ProblemList for the moment Reviewed-by: alanb ! test/ProblemList.txt From john.zavgren at oracle.com Mon Oct 22 04:11:10 2012 From: john.zavgren at oracle.com (John Zavgren) Date: Mon, 22 Oct 2012 04:11:10 -0700 (PDT) Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c Message-ID: <6009570f-a12d-4fba-b958-063ad2fd57a4@default> Dmitry: I see what you mean, these error messages are quite misleading. I will change all three of them. I propose the following changes: 1.) line 88, change: "invalid field: username" to "invalid field: user ID". (In Unix a user ID is a numerical value, not a "name" or character string.) 2.) line 103, change: "invalid field: username" to "invalid field: user group ID" 3.) line 118, change: "invalid field: username" to "invalid field: groups" (Or maybe "invalid group object"????) And for your second point, "aborting" (actually returning) after (*env)->ThrowNew(...), lines 88, 103, and 118... that makes sense too. Consider the first case: if (fid == 0) { jclass newExcCls = (*env)->FindClass(env, "java/lang/IllegalArgumentException"); if (newExcCls == 0) { /* Unable to find the new exception class, give up. */ goto cleanUpAndReturn; } (*env)->ThrowNew(env, newExcCls, "invalid field: username"); } When "file ID equals zero" we return before the "ThrowNew()" call is made. Should this call be moved to immediately before the "goto" statement? I.e. if (fid == 0) { jclass newExcCls = (*env)->FindClass(env, "java/lang/IllegalArgumentException"); if (newExcCls == 0) { /* Unable to find the new exception class, give up. */ (*env)->ThrowNew(env, newExcCls, "invalid field: username"); goto cleanUpAndReturn; } } If I don't move the "ThrowNew()" statement then the calling code will never see the exception. Ideas? Thanks! John Zavgren ----- Original Message ----- From: Dmitry.Samersoff at oracle.com To: john.zavgren at oracle.com Cc: security-dev at openjdk.java.net Sent: Monday, October 22, 2012 4:53:56 AM GMT -05:00 US/Canada Eastern Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c John, Sorry for being later. Again, it's not to your changes but as well as you are touching this code. 88, 103, 118: Type-o - we are checking for uid,gid,groups field, but exception says "invalid field: username" in all cases. It's better to fix it as well. ??: Does it make sense to abort after (*env)->ThrowNew(...) ? -Dmitry On 2012-10-20 00:28, John Zavgren wrote: > Greetings: > The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c > > http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ > > The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t));id > > The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. > > Thanks! > John Zavgren > john.zavgren at oracle.com > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From xuelei.fan at oracle.com Mon Oct 22 04:30:55 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 22 Oct 2012 19:30:55 +0800 Subject: Code review request: 8001208: Fix for KRB5CCNAME not complete In-Reply-To: <5084E9DC.70303@oracle.com> References: <5084E9DC.70303@oracle.com> Message-ID: <50852E6F.10807@oracle.com> Looks fine to me. I would suggest you add a few lines about the prefix of KRB5CCNAME in the method comment. Xuelei On 10/22/2012 2:38 PM, Weijun Wang wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/8001208/webrev.00/ > > An old test is enhanced to check for the fix. > > Honestly, it might be best to check for KRB5CCNAME outside > FileCredentialsCache since the ccache type can be something other than > FILE:. It will touch more files and I decide to delay this enhancement > until we start supporting more real types. > > Also, I want to backport this fix to 7u, so it had better be simple. > > Thanks > Max From weijun.wang at oracle.com Mon Oct 22 04:34:17 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Oct 2012 19:34:17 +0800 Subject: Code review request: 8001208: Fix for KRB5CCNAME not complete In-Reply-To: <50852E6F.10807@oracle.com> References: <5084E9DC.70303@oracle.com> <50852E6F.10807@oracle.com> Message-ID: Thanks. Will add some comments. -Max ?? Oct 22, 2012??7:30 PM??Xuelei Fan ?????? > Looks fine to me. I would suggest you add a few lines about the prefix > of KRB5CCNAME in the method comment. > > Xuelei > > On 10/22/2012 2:38 PM, Weijun Wang wrote: >> Please take a look at >> >> http://cr.openjdk.java.net/~weijun/8001208/webrev.00/ >> >> An old test is enhanced to check for the fix. >> >> Honestly, it might be best to check for KRB5CCNAME outside >> FileCredentialsCache since the ccache type can be something other than >> FILE:. It will touch more files and I decide to delay this enhancement >> until we start supporting more real types. >> >> Also, I want to backport this fix to 7u, so it had better be simple. >> >> Thanks >> Max > From chris.hegarty at oracle.com Mon Oct 22 06:11:29 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 22 Oct 2012 14:11:29 +0100 Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c In-Reply-To: <6009570f-a12d-4fba-b958-063ad2fd57a4@default> References: <6009570f-a12d-4fba-b958-063ad2fd57a4@default> Message-ID: <50854601.3090804@oracle.com> > When "file ID equals zero" we return before the "ThrowNew()" call is made. Should this call be moved to immediately before the "goto" statement? I.e. > if (fid == 0) { > jclass newExcCls = > (*env)->FindClass(env, "java/lang/IllegalArgumentException"); > if (newExcCls == 0) { > /* Unable to find the new exception class, give up. */ > (*env)->ThrowNew(env, newExcCls, "invalid field: username"); > goto cleanUpAndReturn; > } > } We cannot do this since the we could pass a null reference to ThrowNew (through newExcCls). In fact a closer look shows that this code is very fragile. If GetFieldID returns null, then there will be a pending exception on the stack. It is an error/bad to call another JNI function if there is an exception on the stack. Also, isn't this the exact exception that should be thrown in this case? It is an error on the side of the JDK developer if any of these fields ID checks fail. We should simply do: fid = (*env)->GetFieldID(env, cls, "uid", "J"); if (fid == 0) goto cleanUpAndReturn; .. and forget the IAE lookup, etc.. -Chris. On 22/10/2012 12:11, John Zavgren wrote: > Dmitry: > > I see what you mean, these error messages are quite misleading. I will change all three of them. > I propose the following changes: > 1.) line 88, change: "invalid field: username" to "invalid field: user ID". (In Unix a user ID is a numerical value, not a "name" or character string.) > 2.) line 103, change: "invalid field: username" to "invalid field: user group ID" > 3.) line 118, change: "invalid field: username" to "invalid field: groups" (Or maybe "invalid group object"????) > > And for your second point, "aborting" (actually returning) after (*env)->ThrowNew(...), lines 88, 103, and 118... that makes sense too. > > > Consider the first case: > if (fid == 0) { > jclass newExcCls = > (*env)->FindClass(env, "java/lang/IllegalArgumentException"); > if (newExcCls == 0) { > /* Unable to find the new exception class, give up. */ > goto cleanUpAndReturn; > } > (*env)->ThrowNew(env, newExcCls, "invalid field: username"); > } > When "file ID equals zero" we return before the "ThrowNew()" call is made. Should this call be moved to immediately before the "goto" statement? I.e. > if (fid == 0) { > jclass newExcCls = > (*env)->FindClass(env, "java/lang/IllegalArgumentException"); > if (newExcCls == 0) { > /* Unable to find the new exception class, give up. */ > (*env)->ThrowNew(env, newExcCls, "invalid field: username"); > goto cleanUpAndReturn; > } > } > If I don't move the "ThrowNew()" statement then the calling code will never see the exception. > > Ideas? > Thanks! > John Zavgren > > ----- Original Message ----- > From: Dmitry.Samersoff at oracle.com > To: john.zavgren at oracle.com > Cc: security-dev at openjdk.java.net > Sent: Monday, October 22, 2012 4:53:56 AM GMT -05:00 US/Canada Eastern > Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c > > John, > > Sorry for being later. Again, it's not to your changes but as well as > you are touching this code. > > 88, 103, 118: Type-o - we are checking for uid,gid,groups field, > but exception says "invalid field: username" in all cases. > > It's better to fix it as well. > > ??: Does it make sense to abort after (*env)->ThrowNew(...) ? > > -Dmitry > > > On 2012-10-20 00:28, John Zavgren wrote: >> Greetings: >> The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c >> >> http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ >> >> The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t));id >> >> The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. >> >> Thanks! >> John Zavgren >> john.zavgren at oracle.com >> > > From john.zavgren at oracle.com Mon Oct 22 06:42:29 2012 From: john.zavgren at oracle.com (John Zavgren) Date: Mon, 22 Oct 2012 06:42:29 -0700 (PDT) Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c Message-ID: <6d0a8030-6dde-43fe-b4f8-3f5da2beefa4@default> So, the most good we can do here is to make the reasons for errors correct... when the exceptions are thrown, be sure that the corresponding explanations makes sense and are not misleading? John ----- Original Message ----- From: chris.hegarty at oracle.com To: john.zavgren at oracle.com Cc: Dmitry.Samersoff at oracle.com, security-dev at openjdk.java.net Sent: Monday, October 22, 2012 9:10:59 AM GMT -05:00 US/Canada Eastern Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c > When "file ID equals zero" we return before the "ThrowNew()" call is made. Should this call be moved to immediately before the "goto" statement? I.e. > if (fid == 0) { > jclass newExcCls = > (*env)->FindClass(env, "java/lang/IllegalArgumentException"); > if (newExcCls == 0) { > /* Unable to find the new exception class, give up. */ > (*env)->ThrowNew(env, newExcCls, "invalid field: username"); > goto cleanUpAndReturn; > } > } We cannot do this since the we could pass a null reference to ThrowNew (through newExcCls). In fact a closer look shows that this code is very fragile. If GetFieldID returns null, then there will be a pending exception on the stack. It is an error/bad to call another JNI function if there is an exception on the stack. Also, isn't this the exact exception that should be thrown in this case? It is an error on the side of the JDK developer if any of these fields ID checks fail. We should simply do: fid = (*env)->GetFieldID(env, cls, "uid", "J"); if (fid == 0) goto cleanUpAndReturn; .. and forget the IAE lookup, etc.. -Chris. On 22/10/2012 12:11, John Zavgren wrote: > Dmitry: > > I see what you mean, these error messages are quite misleading. I will change all three of them. > I propose the following changes: > 1.) line 88, change: "invalid field: username" to "invalid field: user ID". (In Unix a user ID is a numerical value, not a "name" or character string.) > 2.) line 103, change: "invalid field: username" to "invalid field: user group ID" > 3.) line 118, change: "invalid field: username" to "invalid field: groups" (Or maybe "invalid group object"????) > > And for your second point, "aborting" (actually returning) after (*env)->ThrowNew(...), lines 88, 103, and 118... that makes sense too. > > > Consider the first case: > if (fid == 0) { > jclass newExcCls = > (*env)->FindClass(env, "java/lang/IllegalArgumentException"); > if (newExcCls == 0) { > /* Unable to find the new exception class, give up. */ > goto cleanUpAndReturn; > } > (*env)->ThrowNew(env, newExcCls, "invalid field: username"); > } > When "file ID equals zero" we return before the "ThrowNew()" call is made. Should this call be moved to immediately before the "goto" statement? I.e. > if (fid == 0) { > jclass newExcCls = > (*env)->FindClass(env, "java/lang/IllegalArgumentException"); > if (newExcCls == 0) { > /* Unable to find the new exception class, give up. */ > (*env)->ThrowNew(env, newExcCls, "invalid field: username"); > goto cleanUpAndReturn; > } > } > If I don't move the "ThrowNew()" statement then the calling code will never see the exception. > > Ideas? > Thanks! > John Zavgren > > ----- Original Message ----- > From: Dmitry.Samersoff at oracle.com > To: john.zavgren at oracle.com > Cc: security-dev at openjdk.java.net > Sent: Monday, October 22, 2012 4:53:56 AM GMT -05:00 US/Canada Eastern > Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c > > John, > > Sorry for being later. Again, it's not to your changes but as well as > you are touching this code. > > 88, 103, 118: Type-o - we are checking for uid,gid,groups field, > but exception says "invalid field: username" in all cases. > > It's better to fix it as well. > > ??: Does it make sense to abort after (*env)->ThrowNew(...) ? > > -Dmitry > > > On 2012-10-20 00:28, John Zavgren wrote: >> Greetings: >> The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c >> >> http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ >> >> The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t));id >> >> The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. >> >> Thanks! >> John Zavgren >> john.zavgren at oracle.com >> > > From christos at zoulas.com Mon Oct 22 07:05:46 2012 From: christos at zoulas.com (Christos Zoulas) Date: Mon, 22 Oct 2012 10:05:46 -0400 Subject: bug fix for native kerberos libraries In-Reply-To: <5084D439.4050407@oracle.com> from Weijun Wang (Oct 22, 1:06pm) Message-ID: <20121022140547.020B297124@rebar.astron.com> On Oct 22, 1:06pm, weijun.wang at oracle.com (Weijun Wang) wrote: -- Subject: Re: bug fix for native kerberos libraries | But are you using MEMORY: type ccache in your case? If I understand | correctly, the substring after MEMORY: is not a normal file name. It's a | tag that links to a block of bytes stored in the memory that must be | accessed with native calls. I'll not support it at the moment. | Ok, I misread the spec. My type is always file. christos From chris.hegarty at oracle.com Mon Oct 22 07:11:21 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 22 Oct 2012 15:11:21 +0100 Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c In-Reply-To: <6d0a8030-6dde-43fe-b4f8-3f5da2beefa4@default> References: <6d0a8030-6dde-43fe-b4f8-3f5da2beefa4@default> Message-ID: <50855409.5000505@oracle.com> On 22/10/2012 14:42, John Zavgren wrote: > So, the most good we can do here is to make the reasons for errors correct... when the exceptions are thrown, be sure that the corresponding explanations makes sense and are not misleading? This is common practice where a Java library class some native implementation. If your native code tries to access a field that is not declared, then it is simply an error. Clean up any native resources and return quickly. The GetFieldID function will set a pending exception on the stack, this exception will be thrown during the transition back to Java-land. Anything else ( in this case ) would simply be wrong, and may hide, or make it more difficult to diagnose, a real bug. -Chris. > > John > > > ----- Original Message ----- > From: chris.hegarty at oracle.com > To: john.zavgren at oracle.com > Cc: Dmitry.Samersoff at oracle.com, security-dev at openjdk.java.net > Sent: Monday, October 22, 2012 9:10:59 AM GMT -05:00 US/Canada Eastern > Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c > > > When "file ID equals zero" we return before the "ThrowNew()" call is > made. Should this call be moved to immediately before the "goto" > statement? I.e. > > if (fid == 0) { > > jclass newExcCls = > > (*env)->FindClass(env, > "java/lang/IllegalArgumentException"); > > if (newExcCls == 0) { > > /* Unable to find the new exception class, give up. */ > > (*env)->ThrowNew(env, newExcCls, "invalid field: > username"); > > goto cleanUpAndReturn; > > } > > } > > We cannot do this since the we could pass a null reference to ThrowNew > (through newExcCls). > > In fact a closer look shows that this code is very fragile. If > GetFieldID returns null, then there will be a pending exception on the > stack. It is an error/bad to call another JNI function if there is an > exception on the stack. Also, isn't this the exact exception that should > be thrown in this case? It is an error on the side of the JDK developer > if any of these fields ID checks fail. > > We should simply do: > fid = (*env)->GetFieldID(env, cls, "uid", "J"); > if (fid == 0) > goto cleanUpAndReturn; > > .. and forget the IAE lookup, etc.. > > -Chris. > > > On 22/10/2012 12:11, John Zavgren wrote: >> Dmitry: >> >> I see what you mean, these error messages are quite misleading. I will change all three of them. >> I propose the following changes: >> 1.) line 88, change: "invalid field: username" to "invalid field: user ID". (In Unix a user ID is a numerical value, not a "name" or character string.) >> 2.) line 103, change: "invalid field: username" to "invalid field: user group ID" >> 3.) line 118, change: "invalid field: username" to "invalid field: groups" (Or maybe "invalid group object"????) >> >> And for your second point, "aborting" (actually returning) after (*env)->ThrowNew(...), lines 88, 103, and 118... that makes sense too. >> >> >> Consider the first case: >> if (fid == 0) { >> jclass newExcCls = >> (*env)->FindClass(env, "java/lang/IllegalArgumentException"); >> if (newExcCls == 0) { >> /* Unable to find the new exception class, give up. */ >> goto cleanUpAndReturn; >> } >> (*env)->ThrowNew(env, newExcCls, "invalid field: username"); >> } >> When "file ID equals zero" we return before the "ThrowNew()" call is made. Should this call be moved to immediately before the "goto" statement? I.e. >> if (fid == 0) { >> jclass newExcCls = >> (*env)->FindClass(env, "java/lang/IllegalArgumentException"); >> if (newExcCls == 0) { >> /* Unable to find the new exception class, give up. */ >> (*env)->ThrowNew(env, newExcCls, "invalid field: username"); >> goto cleanUpAndReturn; >> } >> } >> If I don't move the "ThrowNew()" statement then the calling code will never see the exception. >> >> Ideas? >> Thanks! >> John Zavgren >> >> ----- Original Message ----- >> From: Dmitry.Samersoff at oracle.com >> To: john.zavgren at oracle.com >> Cc: security-dev at openjdk.java.net >> Sent: Monday, October 22, 2012 4:53:56 AM GMT -05:00 US/Canada Eastern >> Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c >> >> John, >> >> Sorry for being later. Again, it's not to your changes but as well as >> you are touching this code. >> >> 88, 103, 118: Type-o - we are checking for uid,gid,groups field, >> but exception says "invalid field: username" in all cases. >> >> It's better to fix it as well. >> >> ??: Does it make sense to abort after (*env)->ThrowNew(...) ? >> >> -Dmitry >> >> >> On 2012-10-20 00:28, John Zavgren wrote: >>> Greetings: >>> The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c >>> >>> http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ >>> >>> The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t));id >>> >>> The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. >>> >>> Thanks! >>> John Zavgren >>> john.zavgren at oracle.com >>> >> >> From Dmitry.Samersoff at oracle.com Mon Oct 22 07:18:15 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 22 Oct 2012 18:18:15 +0400 Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c In-Reply-To: <50854601.3090804@oracle.com> References: <6009570f-a12d-4fba-b958-063ad2fd57a4@default> <50854601.3090804@oracle.com> Message-ID: <508555A7.5070602@oracle.com> Chris, On 2012-10-22 17:11, Chris Hegarty wrote: > We should simply do: > fid = (*env)->GetFieldID(env, cls, "uid", "J"); > if (fid == 0) > goto cleanUpAndReturn; > > .. and forget the IAE lookup, etc.. I'm second for simple code above if now spec requires IAE here. Also it's better to retrieve all fields first, before setting any values as it's good practice to don't modify client data on error. i.e. fid_username = (*env)->GetFieldID() if (fid_username == 0 ) goto cleanup_and_return; fid_uid = (*env)->GetFieldID() if (fid_uid == 0 ) goto cleanup_and_return; .... fid_gid = (*env)->GetFieldID() .... // Set all required fields here -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From christos at zoulas.com Mon Oct 22 07:25:15 2012 From: christos at zoulas.com (Christos Zoulas) Date: Mon, 22 Oct 2012 10:25:15 -0400 Subject: Code review request: 8001208: Fix for KRB5CCNAME not complete In-Reply-To: <5084E9DC.70303@oracle.com> from Weijun Wang (Oct 22, 2:38pm) Message-ID: <20121022142515.F245F97124@rebar.astron.com> On Oct 22, 2:38pm, weijun.wang at oracle.com (Weijun Wang) wrote: -- Subject: Code review request: 8001208: Fix for KRB5CCNAME not complete | Please take a look at | | http://cr.openjdk.java.net/~weijun/8001208/webrev.00/ | | An old test is enhanced to check for the fix. | | Honestly, it might be best to check for KRB5CCNAME outside | FileCredentialsCache since the ccache type can be something other than | FILE:. It will touch more files and I decide to delay this enhancement | until we start supporting more real types. | | Also, I want to backport this fix to 7u, so it had better be simple. Thanks, I verified that this fixes my issue! One less patch to maintain locally :-) I have only 1 to go now... christos From john.zavgren at oracle.com Mon Oct 22 07:35:38 2012 From: john.zavgren at oracle.com (John Zavgren) Date: Mon, 22 Oct 2012 07:35:38 -0700 (PDT) Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c Message-ID: Dmitry: You recommend that this procedure check the return value of the GetField() call and if there is an error (the return value is zero), clean up and return immediately and not try to create an instance of the exception class? The code that we have now will accept every possible return value of GetField() and set this value by calling: SetLongField() unless it can't create an exception object before it's able to actually call GetField(). This is what I was proposing: /* * set uid */ fid = (*env)->GetFieldID(env, cls, "uid", "J"); if (fid == 0) { jclass newExcCls = (*env)->FindClass(env, "java/lang/IllegalArgumentException"); if (newExcCls == 0) { /* Unable to find the new exception class, give up. */ goto cleanUpAndReturn; } (*env)->ThrowNew(env, newExcCls, "invalid field: user ID"); } (*env)->SetLongField(env, obj, fid, pwd->pw_uid); And, this is what I think you are proposing: /* * set uid */ fid = (*env)->GetFieldID(env, cls, "uid", "J"); if (fid == 0) { goto cleanUpAndReturn; } (*env)->SetLongField(env, obj, fid, pwd->pw_uid); Thanks, John ----- Original Message ----- From: Dmitry.Samersoff at oracle.com To: chris.hegarty at oracle.com Cc: john.zavgren at oracle.com, security-dev at openjdk.java.net Sent: Monday, October 22, 2012 10:18:56 AM GMT -05:00 US/Canada Eastern Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c Chris, On 2012-10-22 17:11, Chris Hegarty wrote: > We should simply do: > fid = (*env)->GetFieldID(env, cls, "uid", "J"); > if (fid == 0) > goto cleanUpAndReturn; > > .. and forget the IAE lookup, etc.. I'm second for simple code above if now spec requires IAE here. Also it's better to retrieve all fields first, before setting any values as it's good practice to don't modify client data on error. i.e. fid_username = (*env)->GetFieldID() if (fid_username == 0 ) goto cleanup_and_return; fid_uid = (*env)->GetFieldID() if (fid_uid == 0 ) goto cleanup_and_return; .... fid_gid = (*env)->GetFieldID() .... // Set all required fields here -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From chris.hegarty at oracle.com Mon Oct 22 07:39:37 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 22 Oct 2012 15:39:37 +0100 Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c In-Reply-To: References: Message-ID: <50855AA9.6090605@oracle.com> John, The existing/old code is actually wrong and would crash if the uid field did not exist. What Dmitry said in his last mail is the best approach. -Chris On 22/10/2012 15:35, John Zavgren wrote: > Dmitry: > > You recommend that this procedure check the return value of the GetField() call and if there is an error (the return value is zero), clean up and return immediately and not try to create an instance of the exception class? > > The code that we have now will accept every possible return value of GetField() and set this value by calling: SetLongField() unless it can't create an exception object before it's able to actually call GetField(). > > This is what I was proposing: > /* > * set uid > */ > fid = (*env)->GetFieldID(env, cls, "uid", "J"); > if (fid == 0) { > jclass newExcCls = > (*env)->FindClass(env, "java/lang/IllegalArgumentException"); > if (newExcCls == 0) { > /* Unable to find the new exception class, give up. */ > goto cleanUpAndReturn; > } > (*env)->ThrowNew(env, newExcCls, "invalid field: user ID"); > } > (*env)->SetLongField(env, obj, fid, pwd->pw_uid); > And, this is what I think you are proposing: > /* > * set uid > */ > fid = (*env)->GetFieldID(env, cls, "uid", "J"); > if (fid == 0) { > goto cleanUpAndReturn; > } > (*env)->SetLongField(env, obj, fid, pwd->pw_uid); > > Thanks, > John > ----- Original Message ----- > From: Dmitry.Samersoff at oracle.com > To: chris.hegarty at oracle.com > Cc: john.zavgren at oracle.com, security-dev at openjdk.java.net > Sent: Monday, October 22, 2012 10:18:56 AM GMT -05:00 US/Canada Eastern > Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c > > Chris, > > On 2012-10-22 17:11, Chris Hegarty wrote: >> We should simply do: >> fid = (*env)->GetFieldID(env, cls, "uid", "J"); >> if (fid == 0) >> goto cleanUpAndReturn; >> >> .. and forget the IAE lookup, etc.. > > > I'm second for simple code above if now spec requires IAE here. > > Also it's better to retrieve all fields first, before setting any values > as it's good practice to don't modify client data on error. > > i.e. > > fid_username = (*env)->GetFieldID() > if (fid_username == 0 ) > goto cleanup_and_return; > > fid_uid = (*env)->GetFieldID() > if (fid_uid == 0 ) > goto cleanup_and_return; > > .... > > fid_gid = (*env)->GetFieldID() > .... > > // Set all required fields here > > -Dmitry > > > From weijun.wang at oracle.com Mon Oct 22 19:02:39 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 23 Oct 2012 02:02:39 +0000 Subject: hg: jdk8/tl/jdk: 8001208: Fix for KRB5CCNAME not complete Message-ID: <20121023020303.85D3F474B6@hg.openjdk.java.net> Changeset: a1e77f7ed52b Author: weijun Date: 2012-10-23 10:02 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1e77f7ed52b 8001208: Fix for KRB5CCNAME not complete Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! test/sun/security/krb5/ccache/EmptyCC.java From john.zavgren at oracle.com Tue Oct 23 01:56:41 2012 From: john.zavgren at oracle.com (John Zavgren) Date: Tue, 23 Oct 2012 01:56:41 -0700 (PDT) Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c Message-ID: <70b6dc95-bd05-48da-9040-18f0466ab5e0@default> Greetings: I've modified the procedure "Java_com_sun_security_auth_module_UnixSystem_getUnixInfo" so that all four GetFieldID calls must be successful before it attempts to call "Set" methods. This new program logic ensures that this procedure returns successfully if and only if all the information about a user can be successfully retrieved. And, of course, the memory leak is fixed also. The new webrev is: http://cr.openjdk.java.net/~khazra/john/8000204/webrev.01/ Thanks! John Zavgren ----- Original Message ----- From: Dmitry.Samersoff at oracle.com To: john.zavgren at oracle.com Cc: security-dev at openjdk.java.net Sent: Monday, October 22, 2012 4:53:56 AM GMT -05:00 US/Canada Eastern Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c John, Sorry for being later. Again, it's not to your changes but as well as you are touching this code. 88, 103, 118: Type-o - we are checking for uid,gid,groups field, but exception says "invalid field: username" in all cases. It's better to fix it as well. ??: Does it make sense to abort after (*env)->ThrowNew(...) ? -Dmitry On 2012-10-20 00:28, John Zavgren wrote: > Greetings: > The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c > > http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ > > The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t));id > > The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. > > Thanks! > John Zavgren > john.zavgren at oracle.com > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Tue Oct 23 02:03:29 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 23 Oct 2012 13:03:29 +0400 Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c In-Reply-To: <70b6dc95-bd05-48da-9040-18f0466ab5e0@default> References: <70b6dc95-bd05-48da-9040-18f0466ab5e0@default> Message-ID: <50865D61.5050607@oracle.com> John, Good work! Thank you for doing it. Looks good for me! -Dmitry On 2012-10-23 12:56, John Zavgren wrote: > Greetings: > I've modified the procedure "Java_com_sun_security_auth_module_UnixSystem_getUnixInfo" so that all four GetFieldID calls must be successful before it attempts to call "Set" methods. This new program logic ensures that this procedure returns successfully if and only if all the information about a user can be successfully retrieved. And, of course, the memory leak is fixed also. > > The new webrev is: http://cr.openjdk.java.net/~khazra/john/8000204/webrev.01/ > > Thanks! > John Zavgren > > > ----- Original Message ----- > From: Dmitry.Samersoff at oracle.com > To: john.zavgren at oracle.com > Cc: security-dev at openjdk.java.net > Sent: Monday, October 22, 2012 4:53:56 AM GMT -05:00 US/Canada Eastern > Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c > > John, > > Sorry for being later. Again, it's not to your changes but as well as > you are touching this code. > > 88, 103, 118: Type-o - we are checking for uid,gid,groups field, > but exception says "invalid field: username" in all cases. > > It's better to fix it as well. > > ??: Does it make sense to abort after (*env)->ThrowNew(...) ? > > -Dmitry > > > On 2012-10-20 00:28, John Zavgren wrote: >> Greetings: >> The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c >> >> http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ >> >> The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t));id >> >> The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. >> >> Thanks! >> John Zavgren >> john.zavgren at oracle.com >> > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From chris.hegarty at oracle.com Tue Oct 23 02:13:57 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 23 Oct 2012 10:13:57 +0100 Subject: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c In-Reply-To: <50865D61.5050607@oracle.com> References: <70b6dc95-bd05-48da-9040-18f0466ab5e0@default> <50865D61.5050607@oracle.com> Message-ID: <50865FD5.2030202@oracle.com> On 10/23/2012 10:03 AM, Dmitry Samersoff wrote: > John, > > Good work! Thank you for doing it. Yes John, thanks for the extra effort, this is much cleaner ( and as you say also fixes the leak ). -Chris. > > Looks good for me! > > -Dmitry > > > On 2012-10-23 12:56, John Zavgren wrote: >> Greetings: >> I've modified the procedure "Java_com_sun_security_auth_module_UnixSystem_getUnixInfo" so that all four GetFieldID calls must be successful before it attempts to call "Set" methods. This new program logic ensures that this procedure returns successfully if and only if all the information about a user can be successfully retrieved. And, of course, the memory leak is fixed also. >> >> The new webrev is: http://cr.openjdk.java.net/~khazra/john/8000204/webrev.01/ >> >> Thanks! >> John Zavgren >> >> >> ----- Original Message ----- >> From: Dmitry.Samersoff at oracle.com >> To: john.zavgren at oracle.com >> Cc: security-dev at openjdk.java.net >> Sent: Monday, October 22, 2012 4:53:56 AM GMT -05:00 US/Canada Eastern >> Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c >> >> John, >> >> Sorry for being later. Again, it's not to your changes but as well as >> you are touching this code. >> >> 88, 103, 118: Type-o - we are checking for uid,gid,groups field, >> but exception says "invalid field: username" in all cases. >> >> It's better to fix it as well. >> >> ??: Does it make sense to abort after (*env)->ThrowNew(...) ? >> >> -Dmitry >> >> >> On 2012-10-20 00:28, John Zavgren wrote: >>> Greetings: >>> The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c >>> >>> http://cr.openjdk.java.net/~khazra/john/8000204/webrev/ >>> >>> The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t));id >>> >>> The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement. >>> >>> Thanks! >>> John Zavgren >>> john.zavgren at oracle.com >>> >> >> > > From chris.hegarty at oracle.com Tue Oct 23 03:58:33 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 23 Oct 2012 10:58:33 +0000 Subject: hg: jdk8/tl/jdk: 8000204: Memory leak in com/sun/security/auth/module/Unix.c Message-ID: <20121023105924.B3BF4474C8@hg.openjdk.java.net> Changeset: 29b58cb8e4fc Author: chegar Date: 2012-10-23 11:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29b58cb8e4fc 8000204: Memory leak in com/sun/security/auth/module/Unix.c Reviewed-by: dsamersoff, wetmore, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/com/sun/security/auth/module/Unix.c From john.zavgren at oracle.com Tue Oct 23 09:03:24 2012 From: john.zavgren at oracle.com (John Zavgren) Date: Tue, 23 Oct 2012 09:03:24 -0700 (PDT) Subject: RFR 8000476, miscellaneous leaks, access to uninitialized memory, etc Message-ID: Greetings: Please review the following webrev image that contains repairs for various sins against memory: leaks, access to uninitialized memory, etc. http://cr.openjdk.java.net/~chegar/8000476/webrev.00/ Thanks! John Zavgren john.zavgren at oracle.com From Dmitry.Samersoff at oracle.com Tue Oct 23 09:31:55 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 23 Oct 2012 20:31:55 +0400 Subject: RFR 8000476, miscellaneous leaks, access to uninitialized memory, etc In-Reply-To: References: Message-ID: <5086C67B.50501@oracle.com> John, java_md_solinux.c you probably need to add JLI_MemFree(newargv); before line 485 also. Otherwise looks good. -Dmitry On 2012-10-23 20:03, John Zavgren wrote: > Greetings: > > Please review the following webrev image that contains repairs for various sins against memory: leaks, access to uninitialized memory, etc. > > http://cr.openjdk.java.net/~chegar/8000476/webrev.00/ > > Thanks! > John Zavgren > john.zavgren at oracle.com > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From bradford.wetmore at oracle.com Tue Oct 23 12:39:55 2012 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Tue, 23 Oct 2012 19:39:55 +0000 Subject: hg: jdk8/tl/jdk: 7197071: Makefiles for various security providers aren't including the default manifest Message-ID: <20121023194007.3E062474D9@hg.openjdk.java.net> Changeset: 940c8cc5a5c4 Author: wetmore Date: 2012-10-23 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/940c8cc5a5c4 7197071: Makefiles for various security providers aren't including the default manifest Reviewed-by: valeriep, mullan, katleman ! make/com/oracle/security/ucrypto/Makefile ! make/javax/crypto/Defs-jce.gmk ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile + test/javax/crypto/sanity/CheckManifestForRelease.java From valerie.peng at oracle.com Tue Oct 23 12:51:39 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Tue, 23 Oct 2012 12:51:39 -0700 Subject: RFR 8000476, miscellaneous leaks, access to uninitialized memory, etc In-Reply-To: References: Message-ID: <5086F54B.3050607@oracle.com> For GSSLibStub.c, line 573, major should be assigned w/ 0. Although GSS_C_QOP_DEFAULT also has the same value, but it means something different. The PKCS11 changes look fine. Thanks, Valerie On 10/23/12 09:03, John Zavgren wrote: > Greetings: > > Please review the following webrev image that contains repairs for various sins against memory: leaks, access to uninitialized memory, etc. > > http://cr.openjdk.java.net/~chegar/8000476/webrev.00/ > > Thanks! > John Zavgren > john.zavgren at oracle.com From jonathan.gibbons at oracle.com Tue Oct 23 13:21:08 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 23 Oct 2012 20:21:08 +0000 Subject: hg: jdk8/tl/langtools: 8000741: refactor javadoc to use abstraction to handle relative paths Message-ID: <20121023202111.A030A474DA@hg.openjdk.java.net> Changeset: 78962d89f283 Author: jjg Date: 2012-10-23 13:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/78962d89f283 8000741: refactor javadoc to use abstraction to handle relative paths Reviewed-by: darcy ! src/share/classes/com/sun/javadoc/SerialFieldTag.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testPackagePage/TestPackagePage.java From jonathan.gibbons at oracle.com Tue Oct 23 14:00:44 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 23 Oct 2012 21:00:44 +0000 Subject: hg: jdk8/tl/langtools: 8000416: refactor javadoc to provide and use an abstraction for relative URIs Message-ID: <20121023210046.9501D474DB@hg.openjdk.java.net> Changeset: 4a1c57a1c410 Author: jjg Date: 2012-10-23 13:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a1c57a1c410 8000416: refactor javadoc to provide and use an abstraction for relative URIs Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocLink.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java From bradford.wetmore at oracle.com Tue Oct 23 15:50:27 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 23 Oct 2012 15:50:27 -0700 Subject: 8001419: Build the JCE portion of JDK-8000970 Message-ID: <50871F33.70808@oracle.com> I have stripped out the JCE portion of: http://mail.openjdk.java.net/pipermail/jdk8-dev/2012-October/001547.html and am integrating it for Fredrik, and doing the internal JCE builds. The work will be done under: 8001419: Build the JCE portion of JDK-8000970 Summary: Original code done by Fredrik Ohrstrom, separated/pushed by wetmore Reviewed-by: wetmore The codereview is: http://cr.openjdk.java.net/~wetmore/8001419/ Brad From bradford.wetmore at oracle.com Tue Oct 23 15:51:47 2012 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Tue, 23 Oct 2012 22:51:47 +0000 Subject: hg: jdk8/tl/jdk: 8001419: Build the JCE portion of JDK-8000970 Message-ID: <20121023225210.82459474E3@hg.openjdk.java.net> Changeset: 13b46e8eda33 Author: ohrstrom Date: 2012-10-23 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13b46e8eda33 8001419: Build the JCE portion of JDK-8000970 Summary: Original code done by Fredrik Ohrstrom, separated/pushed by wetmore Reviewed-by: wetmore ! src/share/classes/com/sun/crypto/provider/KeyProtector.java + src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java From xuelei.fan at oracle.com Wed Oct 24 06:26:18 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 24 Oct 2012 21:26:18 +0800 Subject: Code review request of JDK-8001466, Nightly regression test failure of SSLSocketSNISensitive.java Message-ID: <5087EC7A.2090501@oracle.com> webrev: http://cr.openjdk.java.net./~xuelei/8001466/webrev.00/ The bug has not been shown at bugs.sun.com. The bug is about a regression test failure of sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java. >From the test log, it looks like a timeout, but the real cause is unknown. sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java ------------------------------------------- test result: Error. Program `.../jdk/bin/java' interrupted! (timed out?) javatestOS=SunOS 5.10 (x86) This fix does not try fix the failure. It is a fix that trying to expose more failure information so that we can analysis the cause in the future. Thanks, Xuelei From xuelei.fan at oracle.com Wed Oct 24 08:26:28 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 24 Oct 2012 15:26:28 +0000 Subject: hg: jdk8/tl/jdk: 8001466: Nightly regression test failure of SSLSocketSNISensitive.java Message-ID: <20121024152727.6057F474FE@hg.openjdk.java.net> Changeset: e782f3c383fe Author: xuelei Date: 2012-10-24 08:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e782f3c383fe 8001466: Nightly regression test failure of SSLSocketSNISensitive.java Reviewed-by: weijun ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java From james.holmlund at oracle.com Sat Oct 20 14:50:48 2012 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Sat, 20 Oct 2012 21:50:48 +0000 Subject: hg: jdk8/tl/jdk: 7197401: Add a subset of the org.objectweb.asm packages to jdk8 Message-ID: <20121020215111.2BBD447478@hg.openjdk.java.net> Changeset: a40b0f51613b Author: jjh Date: 2012-10-20 22:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a40b0f51613b 7197401: Add a subset of the org.objectweb.asm packages to jdk8 Reviewed-by: ohair, briangoetz, erikj, iris ! THIRD_PARTY_README ! make/Makefile + make/jdk/Makefile + make/jdk/asm/Makefile + src/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Attribute.java + src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Edge.java + src/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Frame.java + src/share/classes/jdk/internal/org/objectweb/asm/Handle.java + src/share/classes/jdk/internal/org/objectweb/asm/Handler.java + src/share/classes/jdk/internal/org/objectweb/asm/Item.java + src/share/classes/jdk/internal/org/objectweb/asm/Label.java + src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java + src/share/classes/jdk/internal/org/objectweb/asm/Type.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/SimpleRemapper.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LabelNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Value.java + src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java + src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile + test/jdk/asm/AsmSanity.java From christian.thalinger at oracle.com Mon Oct 22 14:24:48 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 22 Oct 2012 21:24:48 +0000 Subject: hg: jdk8/tl/jdk: 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp Message-ID: <20121022212523.79B13474A9@hg.openjdk.java.net> Changeset: 2048ce5a12ff Author: twisti Date: 2012-10-22 14:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2048ce5a12ff 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp Reviewed-by: dholmes, mchung ! test/java/lang/ref/Basic.java From alan.bateman at oracle.com Wed Oct 24 12:43:53 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 24 Oct 2012 19:43:53 +0000 Subject: hg: jdk8/tl/jdk: 6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated Message-ID: <20121024194415.B51FD4750C@hg.openjdk.java.net> Changeset: 8e8fcd44b963 Author: jbachorik Date: 2012-10-24 20:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e8fcd44b963 6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated Reviewed-by: alanb ! test/javax/management/remote/mandatory/URLTest.java From chris.hegarty at oracle.com Wed Oct 24 14:55:30 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 24 Oct 2012 21:55:30 +0000 Subject: hg: jdk8/tl/jdk: 8000203: File descriptor leak in src/solaris/native/java/net/net_util_md.c Message-ID: <20121024215551.B858247525@hg.openjdk.java.net> Changeset: 909676adaefd Author: chegar Date: 2012-10-24 21:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/909676adaefd 8000203: File descriptor leak in src/solaris/native/java/net/net_util_md.c Reviewed-by: dsamersoff, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/java/net/net_util_md.c From xuelei.fan at oracle.com Thu Oct 25 05:50:01 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 25 Oct 2012 20:50:01 +0800 Subject: Code review request: 7184246: Simplify Config.get() of krb5 In-Reply-To: <502B9552.6030705@oracle.com> References: <14914072.1343818131183.JavaMail.sbladm@swsblss4-new.central.sun.com> <501A8B45.9070907@oracle.com> <502B9552.6030705@oracle.com> Message-ID: <50893579.7010608@oracle.com> >> If you want to get a value from inside krb5.conf, you can call >> getDefault(String). This might be good to get a value from the >> [libdefaults] section. However, the method was designed to be so >> smart that it can recursively search for key/value pairs no >> matter where and how deep it is. If you change the behaviors and want to look for the key-value pair strictly in the exact section. One end is the flexibility, and the other end is strictly levered. Krb5 configuration format is not strictly leveled (for example, the sample section of [appdefaults] in [1]. The format also applies to other sections.). I can see pros and corns on both sides. I think some serious compatibility issues might occur if we miss something, please consider the enhancement carefully. Based on the current implementation, I only have one comment as follow. Otherwise, looks fine to me. src/share/classes/sun/security/krb5/KdcComm.java ----------------------------------------------- - Config.getInstance().getDefault(key, realm); + Config.getInstance().get("realms", realm, key); The method spec say that the value can be defined inside [libdefaults] or [realms]. It seems that the update only able to get value from [realms]. Xuelei [1]: http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5/doc/krb5-admin/appdefaults.html#appdefaults On 8/15/2012 8:25 PM, Weijun Wang wrote: > Updated at > > http://cr.openjdk.java.net/~weijun/7184246/webrev.01 > > Changes: > > 1. String values (even if there is only one) for the same key are stored > in a vector. Two methods are provided: > > get(String... keys) returns the last value > getAll(String... keys) returns all values concatenated > > so if you see > > [realms] > R = { > kdc = k1 > kdc = k2 > } > > then get("realms","R","kdc") returns k2, getAll("realms","R","kdc") > returns "k1 k2". > > 2. SCDynamicStore is updated to be consistent with above. I also break > the getConfig() method into 2 so that I can write a test. > > Thanks > Max > > On 08/02/2012 10:14 PM, Weijun Wang wrote: >> Hi Valerie >> >> Please take a look at this >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184246 >> >> The code changes include: >> >> 1. Config.java: >> a. Retrieve settings using .get(String... keys) now >> b. Some changes to parsing. The sub-section depth can be at any >> level. For compatibility reasons, multiple values for the same key are >> only for [realms] and [capaths] sections. >> c. Still using Hashtable and Vector because I don't want to make >> changes to Mac's SCDynamicStoreConfig.m. >> >> 2. initStatic() methods in several classes that read krb5.conf settings >> to static fields >> >> 3. All other old calls to getDefault() methods. >> >> Thanks >> Max >> >> >> >> -------- Original Message -------- >> 7184246: Simplify Config.get() of krb5 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184246 >> >> === *Description* >> ============================================================ >> This is about the internal class sun.security.krb5.Config. >> >> If you want to get a value from inside krb5.conf, you can call >> getDefault(String). This might be good to get a value from the >> [libdefaults] section. However, the method was designed to be so smart >> that it can recursively search for key/value pairs no matter where and >> how deep it is. >> >> For example, given a krb5.conf >> >> [s1] >> a=b >> >> [s2] >> c=d >> >> [s3] >> e = { >> f = g >> } >> >> getDefault("a") = "b", getDefault("c") = "d", and astonishingly, >> getDefault("f") = "g". >> >> I don't think this is a good design, for several reasons: >> >> 1. It depends on the order of sections if there are key/value pairs with >> the same key in different sections. >> >> 2. It ignores wrong settings. For example, when doing a cross-realm >> auth, the Realm.getRealmsList(from,to) is used to get a path which >> should be defined in [capaths]. However, the method simply crawls >> recursively into any subsection it found and won't notice the [capaths] >> being mistakenly typed as [capath] >> >> 3. It lacks certain features. Because the function always return a >> String (same with the getDefault(String,String) method), getDefault("e") >> can only return a null. Therefore there is no way to find out the >> existence of the subsection e unless we also know it contains a key f. >> >> 4. The current Config class needs to know what subsections contains more >> subsections, and it hardcodes names like [capaths] and [realms]. >> >> In short, it's just too smart and becomes unsafe to use. I suggest >> removing all this smartness and a user must use the full paths to get a >> value, say, >> >> kdc = config.get("realms", "SUN.COM", "kdc") >> >> My proposed spec is: >> >> 1. The Config class should understand a krb5.conf without knowing any >> specific section names. All it maintains is a Value, which can be >> either of >> >> String >> List >> TreeMap >> >> Here I use TreeMap to preserve the order (might not be necessary). >> >> 2. The basic retrieval method will be >> >> Value get(String... key) >> >> 3. There are simpler methods if you already know what the type in your >> case is >> >> String getAsString(String... key) >> List getAsStringList(String... key) >> >> The compatibility risk will be low, and if there really comes a >> compatibility issue, most likely it will be because the caller had >> written his krb5.conf wrong. >> >> One of the advantages of the original design is that when a key is >> provided in both [libdefaults] and a given realm, the method can find it >> anyway. This will be useful for keys like kdc_timeout, max_retries. >> However, I think this automatic retrieval is confusing and error-prone, >> I'd rather manually call the get() method twice. >> From weijun.wang at oracle.com Thu Oct 25 07:04:51 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Oct 2012 22:04:51 +0800 Subject: Code review request: 7184246: Simplify Config.get() of krb5 In-Reply-To: <50893579.7010608@oracle.com> References: <14914072.1343818131183.JavaMail.sbladm@swsblss4-new.central.sun.com> <501A8B45.9070907@oracle.com> <502B9552.6030705@oracle.com> <50893579.7010608@oracle.com> Message-ID: <50894703.6000000@oracle.com> On 10/25/2012 08:50 PM, Xuelei Fan wrote: >>> If you want to get a value from inside krb5.conf, you can call >>> getDefault(String). This might be good to get a value from the >>> [libdefaults] section. However, the method was designed to be so >>> smart that it can recursively search for key/value pairs no >>> matter where and how deep it is. > > If you change the behaviors and want to look for the key-value pair > strictly in the exact section. One end is the flexibility, and the > other end is strictly levered. Krb5 configuration format is not > strictly leveled (for example, the sample section of [appdefaults] in > [1]. The format also applies to other sections.). I can see pros and > corns on both sides. I think some serious compatibility issues might > occur if we miss something, please consider the enhancement carefully. You are right. I will be very careful if I want to support reading [appdefaults]. Obviously, an ordered map will not suffice. > > Based on the current implementation, I only have one comment as follow. > Otherwise, looks fine to me. > > src/share/classes/sun/security/krb5/KdcComm.java > ----------------------------------------------- > - Config.getInstance().getDefault(key, realm); > + Config.getInstance().get("realms", realm, key); > > The method spec say that the value can be defined inside [libdefaults] > or [realms]. It seems that the update only able to get value from [realms]. Yes, a value can be defined for all realms, like this, [libdefaults] max_retries = 3 or for a specific realm, like this, [realms] THIS.REALM = { max_retries = 3 } As for the method spec of getRealmSpecificValue(), I think it's not only talking about this method, but for the overall process. The class first reads the global value into the static field defaultKdcRetryLimit, and then, when the realm is known, use this method to see if there is a specific value defined for that realm. The method itself does not understand the whole logic and it's only reading the realm-specific value. Therefore, I think it's equivalent to the new .get("realms", realm, key) call. Thanks Max > > > Xuelei > > [1]: > http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5/doc/krb5-admin/appdefaults.html#appdefaults > > > On 8/15/2012 8:25 PM, Weijun Wang wrote: >> Updated at >> >> http://cr.openjdk.java.net/~weijun/7184246/webrev.01 >> >> Changes: >> >> 1. String values (even if there is only one) for the same key are stored >> in a vector. Two methods are provided: >> >> get(String... keys) returns the last value >> getAll(String... keys) returns all values concatenated >> >> so if you see >> >> [realms] >> R = { >> kdc = k1 >> kdc = k2 >> } >> >> then get("realms","R","kdc") returns k2, getAll("realms","R","kdc") >> returns "k1 k2". >> >> 2. SCDynamicStore is updated to be consistent with above. I also break >> the getConfig() method into 2 so that I can write a test. >> >> Thanks >> Max >> >> On 08/02/2012 10:14 PM, Weijun Wang wrote: >>> Hi Valerie >>> >>> Please take a look at this >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184246 >>> >>> The code changes include: >>> >>> 1. Config.java: >>> a. Retrieve settings using .get(String... keys) now >>> b. Some changes to parsing. The sub-section depth can be at any >>> level. For compatibility reasons, multiple values for the same key are >>> only for [realms] and [capaths] sections. >>> c. Still using Hashtable and Vector because I don't want to make >>> changes to Mac's SCDynamicStoreConfig.m. >>> >>> 2. initStatic() methods in several classes that read krb5.conf settings >>> to static fields >>> >>> 3. All other old calls to getDefault() methods. >>> >>> Thanks >>> Max >>> >>> >>> >>> -------- Original Message -------- >>> 7184246: Simplify Config.get() of krb5 >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184246 >>> >>> === *Description* >>> ============================================================ >>> This is about the internal class sun.security.krb5.Config. >>> >>> If you want to get a value from inside krb5.conf, you can call >>> getDefault(String). This might be good to get a value from the >>> [libdefaults] section. However, the method was designed to be so smart >>> that it can recursively search for key/value pairs no matter where and >>> how deep it is. >>> >>> For example, given a krb5.conf >>> >>> [s1] >>> a=b >>> >>> [s2] >>> c=d >>> >>> [s3] >>> e = { >>> f = g >>> } >>> >>> getDefault("a") = "b", getDefault("c") = "d", and astonishingly, >>> getDefault("f") = "g". >>> >>> I don't think this is a good design, for several reasons: >>> >>> 1. It depends on the order of sections if there are key/value pairs with >>> the same key in different sections. >>> >>> 2. It ignores wrong settings. For example, when doing a cross-realm >>> auth, the Realm.getRealmsList(from,to) is used to get a path which >>> should be defined in [capaths]. However, the method simply crawls >>> recursively into any subsection it found and won't notice the [capaths] >>> being mistakenly typed as [capath] >>> >>> 3. It lacks certain features. Because the function always return a >>> String (same with the getDefault(String,String) method), getDefault("e") >>> can only return a null. Therefore there is no way to find out the >>> existence of the subsection e unless we also know it contains a key f. >>> >>> 4. The current Config class needs to know what subsections contains more >>> subsections, and it hardcodes names like [capaths] and [realms]. >>> >>> In short, it's just too smart and becomes unsafe to use. I suggest >>> removing all this smartness and a user must use the full paths to get a >>> value, say, >>> >>> kdc = config.get("realms", "SUN.COM", "kdc") >>> >>> My proposed spec is: >>> >>> 1. The Config class should understand a krb5.conf without knowing any >>> specific section names. All it maintains is a Value, which can be >>> either of >>> >>> String >>> List >>> TreeMap >>> >>> Here I use TreeMap to preserve the order (might not be necessary). >>> >>> 2. The basic retrieval method will be >>> >>> Value get(String... key) >>> >>> 3. There are simpler methods if you already know what the type in your >>> case is >>> >>> String getAsString(String... key) >>> List getAsStringList(String... key) >>> >>> The compatibility risk will be low, and if there really comes a >>> compatibility issue, most likely it will be because the caller had >>> written his krb5.conf wrong. >>> >>> One of the advantages of the original design is that when a key is >>> provided in both [libdefaults] and a given realm, the method can find it >>> anyway. This will be useful for keys like kdc_timeout, max_retries. >>> However, I think this automatic retrieval is confusing and error-prone, >>> I'd rather manually call the get() method twice. >>> > From xuelei.fan at oracle.com Thu Oct 25 07:37:42 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 25 Oct 2012 22:37:42 +0800 Subject: Code review request: 7184246: Simplify Config.get() of krb5 In-Reply-To: <50894703.6000000@oracle.com> References: <14914072.1343818131183.JavaMail.sbladm@swsblss4-new.central.sun.com> <501A8B45.9070907@oracle.com> <502B9552.6030705@oracle.com> <50893579.7010608@oracle.com> <50894703.6000000@oracle.com> Message-ID: <50894EB6.7070102@oracle.com> On 10/25/2012 10:04 PM, Weijun Wang wrote: > > > On 10/25/2012 08:50 PM, Xuelei Fan wrote: >>>> If you want to get a value from inside krb5.conf, you can call >>>> getDefault(String). This might be good to get a value from the >>>> [libdefaults] section. However, the method was designed to be so >>>> smart that it can recursively search for key/value pairs no >>>> matter where and how deep it is. >> >> If you change the behaviors and want to look for the key-value pair >> strictly in the exact section. One end is the flexibility, and the >> other end is strictly levered. Krb5 configuration format is not >> strictly leveled (for example, the sample section of [appdefaults] in >> [1]. The format also applies to other sections.). I can see pros and >> corns on both sides. I think some serious compatibility issues might >> occur if we miss something, please consider the enhancement carefully. > > You are right. I will be very careful if I want to support reading > [appdefaults]. Obviously, an ordered map will not suffice. > >> >> Based on the current implementation, I only have one comment as follow. >> Otherwise, looks fine to me. >> >> src/share/classes/sun/security/krb5/KdcComm.java >> ----------------------------------------------- >> - Config.getInstance().getDefault(key, realm); >> + Config.getInstance().get("realms", realm, key); >> >> The method spec say that the value can be defined inside [libdefaults] >> or [realms]. It seems that the update only able to get value from >> [realms]. > > Yes, a value can be defined for all realms, like this, > > [libdefaults] > max_retries = 3 > > or for a specific realm, like this, > > [realms] > THIS.REALM = { > max_retries = 3 > } > > As for the method spec of getRealmSpecificValue(), I think it's not only > talking about this method, but for the overall process. The class first > reads the global value into the static field defaultKdcRetryLimit, and > then, when the realm is known, use this method to see if there is a > specific value defined for that realm. The method itself does not > understand the whole logic and it's only reading the realm-specific > value. Therefore, I think it's equivalent to the new .get("realms", > realm, key) call. > OK. Thanks for the clarification. Xuelei > Thanks > Max > > >> >> >> Xuelei >> >> [1]: >> http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5/doc/krb5-admin/appdefaults.html#appdefaults >> >> >> >> On 8/15/2012 8:25 PM, Weijun Wang wrote: >>> Updated at >>> >>> http://cr.openjdk.java.net/~weijun/7184246/webrev.01 >>> >>> Changes: >>> >>> 1. String values (even if there is only one) for the same key are stored >>> in a vector. Two methods are provided: >>> >>> get(String... keys) returns the last value >>> getAll(String... keys) returns all values concatenated >>> >>> so if you see >>> >>> [realms] >>> R = { >>> kdc = k1 >>> kdc = k2 >>> } >>> >>> then get("realms","R","kdc") returns k2, getAll("realms","R","kdc") >>> returns "k1 k2". >>> >>> 2. SCDynamicStore is updated to be consistent with above. I also break >>> the getConfig() method into 2 so that I can write a test. >>> >>> Thanks >>> Max >>> >>> On 08/02/2012 10:14 PM, Weijun Wang wrote: >>>> Hi Valerie >>>> >>>> Please take a look at this >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184246 >>>> >>>> The code changes include: >>>> >>>> 1. Config.java: >>>> a. Retrieve settings using .get(String... keys) now >>>> b. Some changes to parsing. The sub-section depth can be at any >>>> level. For compatibility reasons, multiple values for the same key are >>>> only for [realms] and [capaths] sections. >>>> c. Still using Hashtable and Vector because I don't want to make >>>> changes to Mac's SCDynamicStoreConfig.m. >>>> >>>> 2. initStatic() methods in several classes that read krb5.conf settings >>>> to static fields >>>> >>>> 3. All other old calls to getDefault() methods. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> >>>> -------- Original Message -------- >>>> 7184246: Simplify Config.get() of krb5 >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184246 >>>> >>>> === *Description* >>>> ============================================================ >>>> This is about the internal class sun.security.krb5.Config. >>>> >>>> If you want to get a value from inside krb5.conf, you can call >>>> getDefault(String). This might be good to get a value from the >>>> [libdefaults] section. However, the method was designed to be so smart >>>> that it can recursively search for key/value pairs no matter where and >>>> how deep it is. >>>> >>>> For example, given a krb5.conf >>>> >>>> [s1] >>>> a=b >>>> >>>> [s2] >>>> c=d >>>> >>>> [s3] >>>> e = { >>>> f = g >>>> } >>>> >>>> getDefault("a") = "b", getDefault("c") = "d", and astonishingly, >>>> getDefault("f") = "g". >>>> >>>> I don't think this is a good design, for several reasons: >>>> >>>> 1. It depends on the order of sections if there are key/value pairs >>>> with >>>> the same key in different sections. >>>> >>>> 2. It ignores wrong settings. For example, when doing a cross-realm >>>> auth, the Realm.getRealmsList(from,to) is used to get a path which >>>> should be defined in [capaths]. However, the method simply crawls >>>> recursively into any subsection it found and won't notice the [capaths] >>>> being mistakenly typed as [capath] >>>> >>>> 3. It lacks certain features. Because the function always return a >>>> String (same with the getDefault(String,String) method), >>>> getDefault("e") >>>> can only return a null. Therefore there is no way to find out the >>>> existence of the subsection e unless we also know it contains a key f. >>>> >>>> 4. The current Config class needs to know what subsections contains >>>> more >>>> subsections, and it hardcodes names like [capaths] and [realms]. >>>> >>>> In short, it's just too smart and becomes unsafe to use. I suggest >>>> removing all this smartness and a user must use the full paths to get a >>>> value, say, >>>> >>>> kdc = config.get("realms", "SUN.COM", "kdc") >>>> >>>> My proposed spec is: >>>> >>>> 1. The Config class should understand a krb5.conf without knowing any >>>> specific section names. All it maintains is a Value, which can be >>>> either of >>>> >>>> String >>>> List >>>> TreeMap >>>> >>>> Here I use TreeMap to preserve the order (might not be necessary). >>>> >>>> 2. The basic retrieval method will be >>>> >>>> Value get(String... key) >>>> >>>> 3. There are simpler methods if you already know what the type in your >>>> case is >>>> >>>> String getAsString(String... key) >>>> List getAsStringList(String... key) >>>> >>>> The compatibility risk will be low, and if there really comes a >>>> compatibility issue, most likely it will be because the caller had >>>> written his krb5.conf wrong. >>>> >>>> One of the advantages of the original design is that when a key is >>>> provided in both [libdefaults] and a given realm, the method can >>>> find it >>>> anyway. This will be useful for keys like kdc_timeout, max_retries. >>>> However, I think this automatic retrieval is confusing and error-prone, >>>> I'd rather manually call the get() method twice. >>>> >> From jonathan.gibbons at oracle.com Thu Oct 25 11:10:26 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 25 Oct 2012 18:10:26 +0000 Subject: hg: jdk8/tl/langtools: 7200915: convert TypeTags from a series of small ints to an enum Message-ID: <20121025181031.6274847544@hg.openjdk.java.net> Changeset: c002fdee76fd Author: jjg Date: 2012-10-25 11:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c002fdee76fd 7200915: convert TypeTags from a series of small ints to an enum Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java + src/share/classes/com/sun/tools/javac/code/TypeTag.java - src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/Constants.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! test/tools/javac/6889255/T6889255.java ! test/tools/javac/tree/MakeLiteralTest.java From jonathan.gibbons at oracle.com Thu Oct 25 13:33:38 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 25 Oct 2012 20:33:38 +0000 Subject: hg: jdk8/tl/langtools: 6725230: Java Compilation with Jsr199 ignores Class-Path in manifest Message-ID: <20121025203343.BC83B47548@hg.openjdk.java.net> Changeset: ea2616a6bd01 Author: jjg Date: 2012-10-25 13:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ea2616a6bd01 6725230: Java Compilation with Jsr199 ignores Class-Path in manifest Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/file/Locations.java + test/tools/javac/Paths/TestCompileJARInClassPath.java From mandy.chung at oracle.com Thu Oct 25 15:11:57 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 25 Oct 2012 22:11:57 +0000 Subject: hg: jdk8/tl/jdk: 7159567: inconsistent configuration of MemoryHandler Message-ID: <20121025221209.B2FA44754A@hg.openjdk.java.net> Changeset: 37a4b4892e8e Author: jgish Date: 2012-10-25 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37a4b4892e8e 7159567: inconsistent configuration of MemoryHandler Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/SocketHandler.java ! src/share/classes/java/util/logging/StreamHandler.java + test/java/util/logging/MemoryHandlerTest.java + test/java/util/logging/MemoryHandlerTest.props From mandy.chung at oracle.com Thu Oct 25 15:43:13 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 25 Oct 2012 22:43:13 +0000 Subject: hg: jdk8/tl/jdk: 8001565: (fs) Typo Path.endsWith(String) javadoc Message-ID: <20121025224337.093FF47555@hg.openjdk.java.net> Changeset: 27677928a937 Author: dxu Date: 2012-10-25 15:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27677928a937 8001565: (fs) Typo Path.endsWith(String) javadoc Reviewed-by: mchung, jgish, lancea ! src/share/classes/java/nio/file/Path.java From alan.bateman at oracle.com Fri Oct 26 03:22:46 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 26 Oct 2012 10:22:46 +0000 Subject: hg: jdk8/tl/jdk: 4239752: FileSystem should be a platform-specific class to avoid native code Message-ID: <20121026102335.0C15F47585@hg.openjdk.java.net> Changeset: 0b52c87c39da Author: dxu Date: 2012-10-26 11:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b52c87c39da 4239752: FileSystem should be a platform-specific class to avoid native code Reviewed-by: alanb, dholmes, erikj, jgish ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/FILES_java.gmk ! make/java/java/mapfile-vers ! makefiles/CompileJavaClasses.gmk ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileSystem.java + src/solaris/classes/java/io/DefaultFileSystem.java - src/solaris/native/java/io/FileSystem_md.c + src/windows/classes/java/io/DefaultFileSystem.java - src/windows/native/java/io/FileSystem_md.c From jonathan.gibbons at oracle.com Fri Oct 26 13:11:00 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 26 Oct 2012 20:11:00 +0000 Subject: hg: jdk8/tl/langtools: 8001219: Clean up use of URLs in javadoc Extern class Message-ID: <20121026201102.1FB584759E@hg.openjdk.java.net> Changeset: 217c265158fe Author: jjg Date: 2012-10-26 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/217c265158fe 8001219: Clean up use of URLs in javadoc Extern class Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java From sean.mullan at oracle.com Fri Oct 26 13:32:30 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Oct 2012 16:32:30 -0400 Subject: Code review request of JDK-8001466, Nightly regression test failure of SSLSocketSNISensitive.java In-Reply-To: <5087EC7A.2090501@oracle.com> References: <5087EC7A.2090501@oracle.com> Message-ID: <508AF35E.9070103@oracle.com> Looks fine to me. --Sean On 10/24/12 9:26 AM, Xuelei Fan wrote: > webrev: http://cr.openjdk.java.net./~xuelei/8001466/webrev.00/ > > The bug has not been shown at bugs.sun.com. The bug is about a > regression test failure of > sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java. >>From the test log, it looks like a timeout, but the real cause is unknown. > > sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java > ------------------------------------------- > test result: Error. Program `.../jdk/bin/java' interrupted! (timed out?) > javatestOS=SunOS 5.10 (x86) > > > This fix does not try fix the failure. It is a fix that trying to expose > more failure information so that we can analysis the cause in the future. > > Thanks, > Xuelei > From chris.hegarty at oracle.com Fri Oct 26 13:40:49 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 26 Oct 2012 20:40:49 +0000 Subject: hg: jdk8/tl/jdk: 8001575: Minor/sync/cleanup j.u.c with Dougs CVS - Oct 2012 Message-ID: <20121026204109.391A54759F@hg.openjdk.java.net> Changeset: 3fc5457cf779 Author: dl Date: 2012-10-26 21:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fc5457cf779 8001575: Minor/sync/cleanup j.u.c with Dougs CVS - Oct 2012 Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/BrokenBarrierException.java ! src/share/classes/java/util/concurrent/CompletionService.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/CountDownLatch.java ! src/share/classes/java/util/concurrent/CyclicBarrier.java ! src/share/classes/java/util/concurrent/Delayed.java ! src/share/classes/java/util/concurrent/ExecutionException.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/RejectedExecutionException.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/Semaphore.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/ThreadFactory.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/package-info.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! src/share/classes/java/util/concurrent/locks/Lock.java ! src/share/classes/java/util/concurrent/locks/LockSupport.java ! src/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! src/share/classes/java/util/concurrent/package-info.java From robert.field at oracle.com Thu Oct 25 17:34:52 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 26 Oct 2012 00:34:52 +0000 Subject: hg: jdk8/tl/jdk: 8000806: Implement runtime lambda metafactory Message-ID: <20121026003504.1750D4755C@hg.openjdk.java.net> Changeset: 6302932b7380 Author: rfield Date: 2012-10-25 17:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6302932b7380 8000806: Implement runtime lambda metafactory Summary: Implement lambda invokedynamic bootstrap by generating at runtime an inner class that implements the functional interface Reviewed-by: twisti + src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + src/share/classes/java/lang/invoke/LambdaConversionException.java + src/share/classes/java/lang/invoke/LambdaMetafactory.java + src/share/classes/java/lang/invoke/MagicLambdaImpl.java + src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java From valerie.peng at oracle.com Fri Oct 26 16:18:53 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 26 Oct 2012 16:18:53 -0700 Subject: Code review request for JEP-121 In-Reply-To: <5076B68C.6010706@oracle.com> References: <4FC90790.5070109@oracle.com> <503E3333.7040100@oracle.com> <50401BCE.1010003@oracle.com> <504634B0.7000002@oracle.com> <52B22704-F455-48F0-8BB4-810994D99D36@oracle.com> <50763A0C.6060707@oracle.com> <5076B68C.6010706@oracle.com> Message-ID: <508B1A5D.2010107@oracle.com> Vinnie, The last mile is the hardest...sorry for the delay. 1. I am not sure about having the ivSpec field. It seems that this can be done without since it should be same as what's returned by cipher.getIV() since that's what you use for engineGetIV() call. 2. in getParameters(), since we are generating default value for salt and ic, perhaps we should also handle iv as well. 3. Hmm, I don't quite understand why do we have to require the key must be an instance of PBEKey. Well, the current types for PBE keys can be way more complex than other cipher algorithms such as AES, so we may want to make sure we cover as much usage scenarios as possible. For older PBE algorithms, it will take any Key objects with "PBEXXX" algorithm and PBEParameterSpec (or the corresponding parameters). For this newer PBE algorithms, at a minimum, it needs Key object w/ "PBEXXX" algorithm and (new) PBEParameterSpec (or the corresponding parameters). If no parameters are supplied and the specified key object is of type PBEKey, then we may use the salt and ic count from the PBEKey object as default values. 4. The engineInit code starting at line171 seems quite complicated. If possible, can we consolidate the validity checking on salt, ic, to one place? Currently they are separated into many if-then-else blocks. Same goes for the part about generating default iv for encryption/wrap mode, i.e. line 207-213 + line 244-250, can be done if none are found in the supplied values. 1. Well, changing this class to implementing the javax.crypto.interfaces.PBEKey which contains additional salt, ic info which aren't used in hashCode(). equals(..) seem confusing to me. Since PBE ciphers can get salt, ic, and iv from the PBEParameterSpec (and its corresponding parameters), I feel it's probably simpler to just leave it unchanged. Thanks, Valerie On 10/11/12 05:07, Vincent Ryan wrote: > Thanks for this latest review. Comments below. > > > On 11/10/2012 04:16, Valerie (Yu-Ching) Peng wrote: >> Hi, Vinnie, >> >> Here are my comments on the latest webrev 04. >> >> >> >> >> >> >> >> => looks fine. >> >> >> => Well, the fields contains the new cipherParam field needed for PBES2 >> cipher, but the encoding is still for the older PBES1 cipher. >> => Perhaps it's cleaner to use a separate class for parameters for PBES2 >> cipher. The ASN.1 syntax is defined in PCKS#5v2.1 Appendix A.2 and B.2 > > Right. I've overlooked the ASN.1 encoding issue. I'll create a new > PBES2Parameters class as you suggest. > > >> >> >> => fine, although as I previously mentioned that it'll be easier to >> maintain and understand if we can refactor the code with a >> non-CipherCore object, so that no special handling needed for RC4. Can >> we file a separate bug/rfe to keep track of this refactoring? > > I'll file a bug on that. > > >> >> >> => Well, the HmacPKCS12PBESHA1 class (which you renamed to "PBMAC1Core") >> implements the PKCS#12 v1 standard and is different from the PBMAC1 >> algorithms defined in PKCS#5 v2.1. So, the new comments at line 39-40 >> aren't correct. The two standards, i.e. PKCS#12 and PKCS#5, aren't >> consistent and have different ways on how the keys are derived. If you >> look at PKCS#5v2.1, it explicitly specified that the key shall be >> derived using PBKDF2 and the impl inside HmacPKCS12PBESHA1 relies on the >> PKCS12PBECipherCore.derive(...) method for deriving the keys. If the >> goal is about supporting "PBMAC1" function defined in PKCS#5v2.1, then >> we need to have separate classes which use PBKDF2. >> => The HmacPKCS12PBESHA1 class is used by PKCS12 keystore class. So, we >> still need to keep it and can't shift it to the impl defined by >> PKCS#5v2.1. Currently, PKCS#12 only uses SHA1. Well, but things are >> confusing as is already... >> > > I'll re-instate HmacPKCS12PBESHA1 and define a separate implementation > class for PBMAC1. > > >> >> => Given the above on PBMAC1Core, the "// PBMAC1" comment on line 678 >> isn't correct. >> >> I am still thinking about the changes on PBEKey and PBES2Core classes, >> but thought that I should send you above comments first while I sort my >> thoughts out. >> >> Thanks, >> Valerie >> >> On 10/04/12 03:50, Vincent Ryan wrote: >>> I've made further modifications including adding support to >>> PBEParameterSpec >>> for an AlgorithmParameterSpec object. This is used to convey parameters >>> (in addition to salt and iteration count) to the underlying cipher. >>> >>> For example, AES requires an initialization vector so PBE algorithms >>> that use >>> AES need a mechanism to supply an IV parameter. >>> >>> The latest webrev is at: >>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.04/ >>> >>> >>> >>> On 4 Sep 2012, at 18:04, Vincent Ryan wrote: >>> >>>> Thanks Valerie. >>>> >>>> I'd addressed your comments except the first one. >>>> >>>> Since RC4 is a stream cipher and RC2 is a block cipher they are >>>> handled >>>> slightly differently. It would be possible to re-factor this code to >>>> simplify it but I'd like to leave that for later as I'm under pressure >>>> to meet the next promotion date. >>>> >>>> The latest webrev is at: >>>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.03/ >>>> >>>> >>>> >>>> On 08/31/12 03:05 AM, Valerie (Yu-Ching) Peng wrote: >>>>> Vinnie, >>>>> >>>>> >>>>> 1. Is it possible to replace the CipherCore object w/ CipherSpi >>>>> object >>>>> so to maximize the code re-use? The new code uses CipherSpi object >>>>> for >>>>> RC4 and CipherCore for RC2. Perhaps by using CipherSpi for both >>>>> RC4 and >>>>> RC2, we can have less code which would be easier to maintain... >>>>> >>>>> >>>>> 1. line 57, change the initial set size to 17 from 4? >>>>> >>>>> >>>>> 1. the impls of the two following engineInit() methods are >>>>> inconsistent, >>>>> i.e. >>>>> engineInit(int, Key, AlgorithmParameterSpec, SecureRandom) - expects >>>>> IvParameterSpec >>>>> engineInit(int, Key, AlgorithmParameters, SecureRandom) - expects >>>>> objects created from PBEParameterSpec >>>>> 2. The impl of engineGetParameters() currently returns objects >>>>> created >>>>> from PBEParameterSpec. It should return whatever is expected in the >>>>> engineInit(...) calls, I'd think. >>>>> >>>>> Will send you the rest of comments later, >>>>> Valerie >>>>> >>>>> On 08/29/12 08:20, Vincent Ryan wrote: >>>>>> On 06/ 1/12 07:18 PM, Vincent Ryan wrote: >>>>>>> Hello Valerie, >>>>>>> >>>>>>> Could you please review these changes for JEP-121: >>>>>>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.00/ >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>> The latest webrev is now available at: >>>>>> >>>>>> http://cr.openjdk.java.net/~vinnie/6383200/webrev.02/ >>>>>> >>>>>> I've incorporated review comments and made some fixes >>>>>> to the implementation of AES-based PBE algorithms. >>>>>> >>>>>> Thanks. >> > From jonathan.gibbons at oracle.com Fri Oct 26 16:41:48 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 26 Oct 2012 23:41:48 +0000 Subject: hg: jdk8/tl/langtools: 8001229: refactor javac so that ct.sym is just used for javac, not all clients of JavacFileManager Message-ID: <20121026234153.3B355475C2@hg.openjdk.java.net> Changeset: e6cb81683ffe Author: jjg Date: 2012-10-26 16:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e6cb81683ffe 8001229: refactor javac so that ct.sym is just used for javac, not all clients of JavacFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javah/JavahFileManager.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javap/JavapFileManager.java From jonathan.gibbons at oracle.com Fri Oct 26 17:18:06 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 27 Oct 2012 00:18:06 +0000 Subject: hg: jdk8/tl/langtools: 8001714: add missing tests for 7199925 Message-ID: <20121027001809.24D5A475C4@hg.openjdk.java.net> Changeset: 64fce9f95b1d Author: jjg Date: 2012-10-26 17:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64fce9f95b1d 8001714: add missing tests for 7199925 Reviewed-by: darcy + test/tools/javac/annotations/repeatingAnnotations/ClassReaderDefault.java + test/tools/javac/annotations/repeatingAnnotations/SeparateCompile.java From jonathan.gibbons at oracle.com Fri Oct 26 18:40:48 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 27 Oct 2012 01:40:48 +0000 Subject: hg: jdk8/tl/langtools: 8001717: TypeTags cleanup breaks GenStubs Message-ID: <20121027014050.4FBB6475CA@hg.openjdk.java.net> Changeset: 384f7a4beae7 Author: jjg Date: 2012-10-26 18:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/384f7a4beae7 8001717: TypeTags cleanup breaks GenStubs Reviewed-by: jjh ! make/tools/genstubs/GenStubs.java From alan.bateman at oracle.com Sat Oct 27 03:26:14 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 27 Oct 2012 10:26:14 +0000 Subject: hg: jdk8/tl/jdk: 7176225: Remove JDBC-ODBC Bridge Message-ID: <20121027102657.1AC6847626@hg.openjdk.java.net> Changeset: 615af31cfccc Author: alanb Date: 2012-10-27 09:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/615af31cfccc 7176225: Remove JDBC-ODBC Bridge Reviewed-by: lancea, ohair, tbell ! make/common/Sanity.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Sanity.gmk ! make/sun/Makefile - make/sun/jdbc/Makefile ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk From weijun.wang at oracle.com Sun Oct 28 23:15:10 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 29 Oct 2012 06:15:10 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20121029061542.A54FA4763F@hg.openjdk.java.net> Changeset: 33e29fbc3e5b Author: weijun Date: 2012-10-29 14:14 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33e29fbc3e5b 7184246: Simplify Config.get() of krb5 Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Checksum.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/krb5/internal/KDCOptions.java ! src/share/classes/sun/security/krb5/internal/KerberosTime.java ! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/DnsFallback.java ! test/sun/security/krb5/ParseConfig.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/MaxRetries.java + test/sun/security/krb5/config/Duplicates.java + test/sun/security/krb5/config/SCDynamicConfigTest.java + test/sun/security/krb5/config/k1.conf Changeset: cb70077c6370 Author: weijun Date: 2012-10-29 14:14 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb70077c6370 7195426: kdc_default_options not supported correctly Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/KDCOptions.java + test/sun/security/krb5/config/KdcDefaultOptions.java + test/sun/security/krb5/config/kdc_default_options.conf From john.zavgren at oracle.com Mon Oct 29 06:06:24 2012 From: john.zavgren at oracle.com (John Zavgren) Date: Mon, 29 Oct 2012 06:06:24 -0700 (PDT) Subject: RFR: 8001579, security code modifications that eliminate compiler warnings, etc. Message-ID: <30433552-ab3f-413c-8aa1-cecdf4981eac@default> Greetings: I modified several files in the core library security code: src/share/native/sun/security/jgss/wrapper/GSSLibStub.c src/share/native/sun/security/jgss/wrapper/NativeUtil.c src/share/native/sun/security/pkcs11/wrapper/p11_convert.c src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c src/share/native/sun/security/pkcs11/wrapper/p11_digest.c src/share/native/sun/security/pkcs11/wrapper/p11_general.c src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c src/share/native/sun/security/pkcs11/wrapper/p11_sign.c src/share/native/sun/security/pkcs11/wrapper/p11_util.c src/solaris/native/sun/security/pkcs11/j2secmod_md.c src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c to eliminate compiler warnings. I used the OS-independent ptr_to_jlong() and jlong_to_ptr() macros to ensure that casting is done correctly, changed local variables to have the correct type before comparison (unsigned versus signed integers), made format strings and arguments consistent, initialized one data structure (memory was being accessed before initialization), initialized several local variables, etc. The webrev image of these changes is located at: http://cr.openjdk.java.net/~alanb/8001579/webrev/ I look forward to your comments. Thanks! John Zavgren From mstjohns at comcast.net Mon Oct 29 08:20:55 2012 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 29 Oct 2012 11:20:55 -0400 Subject: RFR: 8001579, security code modifications that eliminate compiler warnings, etc. In-Reply-To: <30433552-ab3f-413c-8aa1-cecdf4981eac@default> References: <30433552-ab3f-413c-8aa1-cecdf4981eac@default> Message-ID: <20121029152052.61FCC624B@mail.openjdk.java.net> For the PKCS11 wrapper stuff, would it be legitimate to tie this to JNA? The current version of the wrapper is about 8 years old - and doesn't support a lot of the new mechanisms. At some point, this is going to need an update to support PKCS11 v2.30 and other new mechanisms. I had a thought that instead of doing this through new native code for the new structures it may make sense to provide support for a JNA based definition of those structures. That would make extending the PKCS11 provider a bit easier. Later, Mike At 09:06 AM 10/29/2012, John Zavgren wrote: >Greetings: > >I modified several files in the core library security code: > >src/share/native/sun/security/jgss/wrapper/GSSLibStub.c >src/share/native/sun/security/jgss/wrapper/NativeUtil.c >src/share/native/sun/security/pkcs11/wrapper/p11_convert.c >src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c >src/share/native/sun/security/pkcs11/wrapper/p11_digest.c >src/share/native/sun/security/pkcs11/wrapper/p11_general.c >src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c >src/share/native/sun/security/pkcs11/wrapper/p11_sign.c >src/share/native/sun/security/pkcs11/wrapper/p11_util.c >src/solaris/native/sun/security/pkcs11/j2secmod_md.c >src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c > >to eliminate compiler warnings. I used the OS-independent ptr_to_jlong() and jlong_to_ptr() macros to ensure that casting is done correctly, changed local variables to have the correct type before comparison (unsigned versus signed integers), made format strings and arguments consistent, initialized one data structure (memory was being accessed before initialization), initialized several local variables, etc. > >The webrev image of these changes is located at: http://cr.openjdk.java.net/~alanb/8001579/webrev/ > >I look forward to your comments. > >Thanks! >John Zavgren From naoto.sato at oracle.com Mon Oct 29 10:43:25 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 29 Oct 2012 17:43:25 +0000 Subject: hg: jdk8/tl/jdk: 8000997: Multiple locale sensitive services cannot be loaded Message-ID: <20121029174347.8406347650@hg.openjdk.java.net> Changeset: 7fa45c455034 Author: naoto Date: 2012-10-29 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fa45c455034 8000997: Multiple locale sensitive services cannot be loaded Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider From staffan.larsen at oracle.com Mon Oct 29 01:24:57 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 29 Oct 2012 08:24:57 +0000 Subject: hg: jdk8/tl/jdk: 8001621: Update awk scripts that check output from jps/jcmd Message-ID: <20121029082519.8411F47642@hg.openjdk.java.net> Changeset: d1ffbdf7e3c6 Author: sla Date: 2012-10-29 09:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1ffbdf7e3c6 8001621: Update awk scripts that check output from jps/jcmd Reviewed-by: alanb ! test/sun/tools/jcmd/jcmd_Output1.awk ! test/sun/tools/jps/jps-l_Output1.awk ! test/sun/tools/jps/jps_Output1.awk From fredrik.ohrstrom at oracle.com Mon Oct 29 06:24:10 2012 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Mon, 29 Oct 2012 13:24:10 +0000 Subject: hg: jdk8/tl/corba: 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK. Message-ID: <20121029132412.718A647644@hg.openjdk.java.net> Changeset: 643e7612cf6d Author: ohrstrom Date: 2012-10-29 14:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/643e7612cf6d 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK. Reviewed-by: alanb, wetmore ! src/share/classes/com/sun/corba/se/impl/util/IdentityHashtable.java + src/share/classes/com/sun/corba/se/impl/util/IdentityHashtableEntry.java From fredrik.ohrstrom at oracle.com Mon Oct 29 06:25:12 2012 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Mon, 29 Oct 2012 13:25:12 +0000 Subject: hg: jdk8/tl/jdk: 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK Message-ID: <20121029132537.2347B47645@hg.openjdk.java.net> Changeset: 17384fc6b31f Author: ohrstrom Date: 2012-10-29 14:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17384fc6b31f 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK Reviewed-by: alanb, wetmore + make/tools/src/build/tools/generatenimbus/AbstractGradient.java + make/tools/src/build/tools/generatenimbus/Border.java + make/tools/src/build/tools/generatenimbus/Canvas.java + make/tools/src/build/tools/generatenimbus/ComponentColor.java + make/tools/src/build/tools/generatenimbus/Dimension.java + make/tools/src/build/tools/generatenimbus/Ellipse.java + make/tools/src/build/tools/generatenimbus/Gradient.java + make/tools/src/build/tools/generatenimbus/GradientStop.java + make/tools/src/build/tools/generatenimbus/Insets.java + make/tools/src/build/tools/generatenimbus/Layer.java + make/tools/src/build/tools/generatenimbus/Matte.java ! make/tools/src/build/tools/generatenimbus/Paint.java + make/tools/src/build/tools/generatenimbus/Path.java + make/tools/src/build/tools/generatenimbus/Point.java + make/tools/src/build/tools/generatenimbus/RadialGradient.java + make/tools/src/build/tools/generatenimbus/Rectangle.java ! make/tools/src/build/tools/generatenimbus/Shape.java ! make/tools/src/build/tools/generatenimbus/SynthModel.java + make/tools/src/build/tools/generatenimbus/Typeface.java + make/tools/src/build/tools/generatenimbus/UIColor.java + make/tools/src/build/tools/generatenimbus/UIComponent.java ! make/tools/src/build/tools/generatenimbus/UIDefault.java + make/tools/src/build/tools/generatenimbus/UIFont.java + make/tools/src/build/tools/generatenimbus/UIIconRegion.java + make/tools/src/build/tools/generatenimbus/UIProperty.java + make/tools/src/build/tools/generatenimbus/UIRegion.java + make/tools/src/build/tools/generatenimbus/UIState.java + make/tools/src/build/tools/generatenimbus/UIStateType.java ! make/tools/src/build/tools/generatenimbus/UIStyle.java ! src/share/classes/javax/management/timer/Timer.java + src/share/classes/javax/management/timer/TimerAlarmClock.java + src/share/classes/sun/awt/im/ExecutableInputMethodManager.java ! src/share/classes/sun/awt/im/InputMethodManager.java + src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/net/httpserver/Event.java + src/share/classes/sun/net/httpserver/WriteFinishedEvent.java + src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java + src/share/classes/sun/security/ssl/ExtensionType.java + src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java + src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java + src/share/classes/sun/security/ssl/ServerNameExtension.java + src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java + src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java + src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java + src/share/classes/sun/security/ssl/UnknownExtension.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java + src/solaris/classes/sun/awt/X11/XChoicePeerListener.java + src/solaris/classes/sun/font/DelegateStrike.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java + src/solaris/classes/sun/java2d/jules/TileTrapContainer.java From robert.field at oracle.com Mon Oct 29 10:40:22 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Mon, 29 Oct 2012 17:40:22 +0000 Subject: hg: jdk8/tl/langtools: 8000694: Add generation of lambda implementation code: invokedynamic call, lambda method, adaptor methods Message-ID: <20121029174026.863944764F@hg.openjdk.java.net> Changeset: a65971893c50 Author: rfield Date: 2012-10-29 10:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a65971893c50 8000694: Add generation of lambda implementation code: invokedynamic call, lambda method, adaptor methods Summary: Add lambda implementation code with calling/supporting code elsewhere in the compiler Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/code/Symtab.java + src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/util/Names.java From jason.uh at oracle.com Mon Oct 29 15:39:59 2012 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 29 Oct 2012 15:39:59 -0700 Subject: Request for review: 7198416: Using X500Name in place of CertificateIssuerName and CertificateSubjectName Message-ID: <508F05BF.5060001@oracle.com> http://cr.openjdk.java.net/~juh/7198416/webrev.00/ Because sun.security.x509.CertificateIssuerName and CertificateSubjectName do not provide any functionality beyond that of X500Name, they have been removed. X509CertImpl and X509CertInfo have been modified to use X500Name directly instead of these classes. Thanks, Jason From mike.duigou at oracle.com Mon Oct 29 16:55:13 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 29 Oct 2012 23:55:13 +0000 Subject: hg: jdk8/tl/jdk: 6206780: (str) Forwarding append methods in String{Buffer, Builder} are inconsistent Message-ID: <20121029235552.4F8934766E@hg.openjdk.java.net> Changeset: e2f976a73afb Author: jgish Date: 2012-10-29 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2f976a73afb 6206780: (str) Forwarding append methods in String{Buffer,Builder} are inconsistent Summary: update StringBuilder & StringBuffer to consistently handle forwarding to AbstractStringBuilder. Some additional cleanup (removal of refs to sub-classes from AbstractStringBuilder) Reviewed-by: chegar, alanb, mduigou ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java + test/java/lang/StringBuffer/AppendStringBuilder.java + test/java/lang/StringBuffer/BufferForwarding.java + test/java/lang/StringBuffer/TestSynchronization.java + test/java/lang/StringBuilder/AppendStringBuffer.java + test/java/lang/StringBuilder/BuilderForwarding.java From jason.uh at oracle.com Tue Oct 30 01:44:45 2012 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 30 Oct 2012 01:44:45 -0700 Subject: Request for review: 7198416: Using X500Name in place of CertificateIssuerName and CertificateSubjectName In-Reply-To: <508F05BF.5060001@oracle.com> References: <508F05BF.5060001@oracle.com> Message-ID: <508F937D.9090109@oracle.com> Updated. Please see instead: http://cr.openjdk.java.net/~juh/7198416/webrev.01/ Removed a trailing space and updated certAttributes.html, a sort of cheat sheet for X.509 certificate attributes. Note that the entries for issuerUniqueID and subjectUniqueID have also been updated to reflect the changes that were made in 4647343. Thanks, Jason On 10/29/2012 03:39 PM, Jason Uh wrote: > http://cr.openjdk.java.net/~juh/7198416/webrev.00/ > > Because sun.security.x509.CertificateIssuerName and > CertificateSubjectName do not provide any functionality beyond that of > X500Name, they have been removed. X509CertImpl and X509CertInfo have > been modified to use X500Name directly instead of these classes. > > Thanks, > Jason From sean.mullan at oracle.com Tue Oct 30 07:56:28 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 30 Oct 2012 10:56:28 -0400 Subject: Request for review: 7198416: Using X500Name in place of CertificateIssuerName and CertificateSubjectName In-Reply-To: <508F937D.9090109@oracle.com> References: <508F05BF.5060001@oracle.com> <508F937D.9090109@oracle.com> Message-ID: <508FEA9C.8030804@oracle.com> Hi Jason, This looks good. An optional minor comment, but I usually update the copyrights to include 2012, as I like to see if the source has been updated and not wait for the tool to update them automatically although I know it isn't required. Anyway, I can push this for you when you are ready. --Sean On 10/30/12 4:44 AM, Jason Uh wrote: > Updated. Please see instead: > http://cr.openjdk.java.net/~juh/7198416/webrev.01/ > > Removed a trailing space and updated certAttributes.html, a sort of > cheat sheet for X.509 certificate attributes. Note that the entries for > issuerUniqueID and subjectUniqueID have also been updated to reflect the > changes that were made in 4647343. > > Thanks, > Jason > > On 10/29/2012 03:39 PM, Jason Uh wrote: >> http://cr.openjdk.java.net/~juh/7198416/webrev.00/ >> >> Because sun.security.x509.CertificateIssuerName and >> CertificateSubjectName do not provide any functionality beyond that of >> X500Name, they have been removed. X509CertImpl and X509CertInfo have >> been modified to use X500Name directly instead of these classes. >> >> Thanks, >> Jason From jonathan.gibbons at oracle.com Tue Oct 30 10:15:55 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 30 Oct 2012 17:15:55 +0000 Subject: hg: jdk8/tl/langtools: 8001929: fix doclint errors in langtools doc comments Message-ID: <20121030171600.95A7C47683@hg.openjdk.java.net> Changeset: 23fe1a96bc0f Author: jjg Date: 2012-10-30 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/23fe1a96bc0f 8001929: fix doclint errors in langtools doc comments Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java From jason.uh at oracle.com Tue Oct 30 11:01:10 2012 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 30 Oct 2012 11:01:10 -0700 Subject: Request for review: 7198416: Using X500Name in place of CertificateIssuerName and CertificateSubjectName In-Reply-To: <508FEA9C.8030804@oracle.com> References: <508F05BF.5060001@oracle.com> <508F937D.9090109@oracle.com> <508FEA9C.8030804@oracle.com> Message-ID: <509015E6.7030309@oracle.com> Thanks, Sean. With copyrights updated: http://cr.openjdk.java.net/~juh/7198416/webrev.02/ Jason On 10/30/2012 07:56 AM, Sean Mullan wrote: > Hi Jason, > > This looks good. An optional minor comment, but I usually update the copyrights > to include 2012, as I like to see if the source has been updated and not wait > for the tool to update them automatically although I know it isn't required. > > Anyway, I can push this for you when you are ready. > > --Sean > > On 10/30/12 4:44 AM, Jason Uh wrote: >> Updated. Please see instead: >> http://cr.openjdk.java.net/~juh/7198416/webrev.01/ >> >> Removed a trailing space and updated certAttributes.html, a sort of >> cheat sheet for X.509 certificate attributes. Note that the entries for >> issuerUniqueID and subjectUniqueID have also been updated to reflect the >> changes that were made in 4647343. >> >> Thanks, >> Jason >> >> On 10/29/2012 03:39 PM, Jason Uh wrote: >>> http://cr.openjdk.java.net/~juh/7198416/webrev.00/ >>> >>> Because sun.security.x509.CertificateIssuerName and >>> CertificateSubjectName do not provide any functionality beyond that of >>> X500Name, they have been removed. X509CertImpl and X509CertInfo have >>> been modified to use X500Name directly instead of these classes. >>> >>> Thanks, >>> Jason From sean.mullan at oracle.com Tue Oct 30 11:25:39 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 30 Oct 2012 14:25:39 -0400 Subject: Code review request: 7110803: SASL service for multiple hostnames In-Reply-To: <507F7404.4030805@oracle.com> References: <507F7404.4030805@oracle.com> Message-ID: <50901BA3.3070700@oracle.com> Hi Max, Looks good. A few minor comments: * SaslServerFactory 64: typo: s/to. or null/to, or null/ * Sasl 124: it would be helpful to mention the methods that the serverName argument is referring to. * GssKrb5Server.java 76: s/Will/will --Sean On 10/17/12 11:14 PM, Weijun Wang wrote: > Hi All > > Please take a look at > > http://cr.openjdk.java.net/~weijun/7110803/webrev.00/ > > In Sasl.createSaslServer() method, the serverName argument is documented > as "[t]he non-null fully qualified host name of the server". This means > a SASL service must specify the exact hostname it is serving at (say, > my.host.com). This is not true any more in today's virtualized world in > which a service might be serving clients from different networks by > exposing different service names. > > The RFE allows serverName to be set to null in Sasl.createSaslServer() > and thus creates an unbound SASL server. This will be useful if the > server can accept multiple server names (think of virtual hosts in an > Apache HTTP server) or the name is configured in the underlying > mechanism. It also provides a new negotiated property called > BOUND_SERVER_NAME so that an unbound server has a chance to see its > bound name after the auth exchange is completed. > > This patch includes the API change and trivial changes for some > mechanisms. The patch for the GSSAPI mechanism is a little more > complicated and will be addressed in a sub-bug. > > Thanks > Max > From lana.steuck at oracle.com Wed Oct 31 09:51:03 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 31 Oct 2012 16:51:03 +0000 Subject: hg: jdk8/tl: 6 new changesets Message-ID: <20121031165104.977CE476B0@hg.openjdk.java.net> Changeset: 8343ccdd63f1 Author: katleman Date: 2012-10-18 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8343ccdd63f1 Added tag jdk8-b61 for changeset 20ff117b5090 ! .hgtags Changeset: c12e759ac4e8 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c12e759ac4e8 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! README-builds.html + make/scripts/fixpath.pl ! make/scripts/vsvars.sh Changeset: 8a3fe0ae06a8 Author: katleman Date: 2012-10-24 13:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8a3fe0ae06a8 Merge Changeset: 4e984be114bd Author: katleman Date: 2012-10-25 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4e984be114bd Added tag jdk8-b62 for changeset 8a3fe0ae06a8 ! .hgtags Changeset: 744e165aaf33 Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/744e165aaf33 Merge Changeset: ce212cd7ea69 Author: lana Date: 2012-10-25 20:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ce212cd7ea69 Merge From lana.steuck at oracle.com Wed Oct 31 09:51:03 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 31 Oct 2012 16:51:03 +0000 Subject: hg: jdk8/tl/corba: 7 new changesets Message-ID: <20121031165111.69EB9476B1@hg.openjdk.java.net> Changeset: 2394155f9f9e Author: katleman Date: 2012-10-18 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2394155f9f9e Added tag jdk8-b61 for changeset 0e08ba7648fb ! .hgtags Changeset: 0a5931be9176 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0a5931be9176 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk Changeset: 08afb9c6f44f Author: katleman Date: 2012-10-24 13:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/08afb9c6f44f Merge Changeset: bbaef650c3d2 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/bbaef650c3d2 Added tag jdk8-b62 for changeset 08afb9c6f44f ! .hgtags Changeset: 23e0226a31ac Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/23e0226a31ac Merge Changeset: 9094cd4a614f Author: lana Date: 2012-10-25 20:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9094cd4a614f Merge ! make/common/shared/Defs-utils.gmk Changeset: aac74d377a03 Author: lana Date: 2012-10-30 23:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/aac74d377a03 Merge From lana.steuck at oracle.com Wed Oct 31 09:51:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 31 Oct 2012 16:51:07 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20121031165118.90B9A476B2@hg.openjdk.java.net> Changeset: d265b9b4c0f5 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d265b9b4c0f5 Added tag jdk8-b61 for changeset 97e5e74e2a34 ! .hgtags Changeset: c27ea8d489e8 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c27ea8d489e8 Added tag jdk8-b62 for changeset d265b9b4c0f5 ! .hgtags From lana.steuck at oracle.com Wed Oct 31 09:51:08 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 31 Oct 2012 16:51:08 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20121031165128.3123A476B4@hg.openjdk.java.net> Changeset: 5d0fa0108d02 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5d0fa0108d02 Added tag jdk8-b61 for changeset 6b1db0b41d2f ! .hgtags Changeset: a96e34e038f5 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a96e34e038f5 Added tag jdk8-b62 for changeset 5d0fa0108d02 ! .hgtags Changeset: 23e1d537224b Author: lana Date: 2012-10-23 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/23e1d537224b Merge Changeset: fc589819b335 Author: lana Date: 2012-10-25 20:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/fc589819b335 Merge From lana.steuck at oracle.com Wed Oct 31 09:51:26 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 31 Oct 2012 16:51:26 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20121031165139.4864B476B5@hg.openjdk.java.net> Changeset: b47bb81ba962 Author: katleman Date: 2012-10-18 11:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b47bb81ba962 Added tag jdk8-b61 for changeset 26020b247ad3 ! .hgtags Changeset: 16498acd21b5 Author: katleman Date: 2012-10-25 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/16498acd21b5 Added tag jdk8-b62 for changeset b47bb81ba962 ! .hgtags Changeset: 5dde04b8bbb3 Author: lana Date: 2012-10-23 09:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5dde04b8bbb3 Merge Changeset: 669468143a5e Author: lana Date: 2012-10-25 20:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/669468143a5e Merge Changeset: 27f7952eea3c Author: lana Date: 2012-10-31 08:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/27f7952eea3c Merge From vincent.x.ryan at oracle.com Wed Oct 31 09:55:00 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 31 Oct 2012 16:55:00 +0000 Subject: Transitioning the default keystore format to PKCS#12 In-Reply-To: <66A79E9E-3834-4B47-BBC9-18927D6EE8EB@oracle.com> References: <66A79E9E-3834-4B47-BBC9-18927D6EE8EB@oracle.com> Message-ID: <3FC6D06D-B83B-47D8-88F7-1BD930752297@oracle.com> Before considering migrating the platform default keystore format to PKCS12 its keystore implementation must at least match the functionality of JKS. I have developed a prototype of a multi-format keystore that understands both JKS and PKCS12 formats - it checks for the JKS magic number to determine the format. By supporting both formats, existing applications that access keystores using the platform default keystore format, continue to function as expected. In addition, storing trusted certs in PKCS12 is now supported. I've selected the X.509 extendedKeyUsage attribute to explicitly denote that a certificate is trusted - its default value is trusted-for-any-purpose. This well-known attribute is stored with the certificate in a PKCS12 certBag. Webrev: http://cr.openjdk.java.net/~vinnie/jdk8-multi/webrev/ Please send me any comments. Thanks. From lana.steuck at oracle.com Wed Oct 31 09:52:52 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 31 Oct 2012 16:52:52 +0000 Subject: hg: jdk8/tl/hotspot: 84 new changesets Message-ID: <20121031165614.973FC476B6@hg.openjdk.java.net> Changeset: 81e878c53615 Author: amurillo Date: 2012-10-05 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/81e878c53615 8000498: new hotspot build - hs25-b05 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d8ce2825b193 Author: coleenp Date: 2012-09-29 06:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8ce2825b193 8000213: NPG: Should have renamed arrayKlass and typeArrayKlass Summary: Capitalize these metadata types (and objArrayKlass) Reviewed-by: stefank, twisti, kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlass.java ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciArrayKlass.cpp ! src/share/vm/ci/ciArrayKlass.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciTypeArrayKlass.cpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/objArrayOop.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/shark/sharkRuntime.cpp Changeset: fab6fbf427d2 Author: kevinw Date: 2012-09-30 23:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fab6fbf427d2 7200145: runtime/7196045/Test7196045.java fails with No class provided for `main' Reviewed-by: dholmes, dsamersoff ! test/runtime/7196045/Test7196045.java Changeset: ba8fd2fe198b Author: coleenp Date: 2012-10-04 08:38 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ba8fd2fe198b 7198519: Broken build, hotspot-rt win USE_PRECOMPILED_HEADER=0 Summary: Uncommented out include for sys/stat.h and deleted include statements that were commented out. Reviewed-by: coleenp, acorn, dholmes Contributed-by: harold.seigel at oracle.com ! src/os/windows/vm/jvm_windows.h Changeset: bacdc1d5c21c Author: coleenp Date: 2012-10-04 08:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bacdc1d5c21c 6884973: java -XX:Atomics=2 crashes Summary: Remove buggy experimental option Reviewed-by: acorn, coleenp Contributed-by: harold.seigel at oracle.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 48087f745a86 Author: dholmes Date: 2012-10-04 19:52 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48087f745a86 7199186: runtime/7194254/Test7194254.java fails - wrong test name on @run Reviewed-by: kvn, twisti ! test/runtime/7194254/Test7194254.java Changeset: f2eb2d4488db Author: dholmes Date: 2012-10-04 20:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2eb2d4488db Merge Changeset: 75982791ddb6 Author: coleenp Date: 2012-10-08 09:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/75982791ddb6 7170638: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field. Summary: Don't use HS_DTRACE_PROBE_CDECL_N and HS_DTRACE_PROBE_N directly. Reviewed-by: coleenp, kamg, dholmes, sspitsyn Contributed-by: Mark Wielaard ! make/bsd/makefiles/buildtree.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/dtrace.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/dtrace.hpp Changeset: 7a40901e0d5c Author: minqi Date: 2012-10-08 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7a40901e0d5c 8000332: SA ClassDump throws exception after permgen removal Summary: In ClassWrite.writeFields(), fields count was mistakenly set to fields length which overflow the array index. Also removed a file which is leftover from 6879063 changeset. Reviewed-by: coleenp, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/native/sadis.c Changeset: 0e8ca886e4e1 Author: minqi Date: 2012-10-08 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0e8ca886e4e1 Merge Changeset: 6e5a59a8e4a7 Author: rbackman Date: 2012-10-09 07:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e5a59a8e4a7 Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 26351ce8c4b0 Author: coleenp Date: 2012-10-09 02:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26351ce8c4b0 8000622: Forgot to hg add and check in test for JDK-7170638 Summary: add the test Reviewed-by: coleenp, kamg Contributed-by: Mark Wielaard + test/serviceability/7170638/SDTProbesGNULinuxTest.sh Changeset: b9a9ed0f8eeb Author: mikael Date: 2012-10-09 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9a9ed0f8eeb 7197424: update copyright year to match last edit in jdk8 hotspot repository Summary: Update copyright year to 2012 for relevant files Reviewed-by: dholmes, coleenp ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/CounterData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/JumpData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! make/bsd/Makefile ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jvmg.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sparcWorks.make ! make/bsd/makefiles/top.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/ppc.make ! make/linux/makefiles/product.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/top.make ! make/windows/build.bat ! make/windows/build_vm_def.sh ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/shared.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/launcher.script ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/solaris/dtrace/hs_private.d ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/tools/ProjectCreator/Util.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/javaAssertions.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/collectorCounters.cpp ! src/share/vm/gc_implementation/shared/collectorCounters.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp ! src/share/vm/gc_implementation/shared/gcStats.hpp ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/libadt/set.cpp ! src/share/vm/libadt/vectset.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/space.inline.hpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/prims/jniExport.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiExtensions.cpp ! src/share/vm/prims/jvmtiRawMonitor.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiUtil.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/monitorChunk.cpp ! src/share/vm/runtime/monitorChunk.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder_elf.cpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/histogram.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/intHisto.cpp ! src/share/vm/utilities/intHisto.hpp ! src/share/vm/utilities/preserveException.cpp ! src/share/vm/utilities/stack.hpp ! src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! test/compiler/6859338/Test6859338.java ! test/compiler/7116216/StackOverflow.java Changeset: c3e799c37717 Author: vlivanov Date: 2012-10-05 18:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3e799c37717 7177003: C1: LogCompilation support Summary: add LogCompilation support in C1 - both client and tiered mode. Reviewed-by: twisti, kvn ! src/os/linux/vm/vmError_linux.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/ostream.cpp Changeset: 9a9b6e05ffb4 Author: vlivanov Date: 2012-10-05 19:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a9b6e05ffb4 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 Summary: Move decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore. Reviewed-by: twisti, kvn ! src/share/vm/code/dependencies.cpp Changeset: 9024b6b53ec2 Author: vlivanov Date: 2012-10-05 19:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9024b6b53ec2 8000485: Hotspot build fails in Solaris Studio IDE when building dtrace Summary: Prepend '.' to the existing native library path Reviewed-by: kvn, sspitsyn ! make/bsd/makefiles/dtrace.make ! make/solaris/makefiles/dtrace.make Changeset: 377508648226 Author: vlivanov Date: 2012-10-08 13:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/377508648226 8000313: C2 should use jlong for 64bit values Summary: Replace all occurrences of long with jlong in C2 code. Reviewed-by: kvn, twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/phaseX.hpp Changeset: 65d07d9ee446 Author: twisti Date: 2012-10-08 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65d07d9ee446 8000263: JSR 292: signature types may appear to be unloaded Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp Changeset: 8e47bac5643a Author: roland Date: 2012-10-09 10:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8e47bac5643a 7054512: Compress class pointers after perm gen removal Summary: support of compress class pointers in the compilers. Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/debugger/Address.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dummy/DummyAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MetadataField.java + agent/src/share/classes/sun/jvm/hotspot/oops/NarrowKlassField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/bsd/dtrace/jhelper.d ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: f6badecb7ea7 Author: vlivanov Date: 2012-10-09 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6badecb7ea7 7199654: Remove LoadUI2LNode Summary: Removed LoadUI2L node from Ideal nodes, use match rule in .ad files instead. Reviewed-by: kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/superword.cpp Changeset: d336b3173277 Author: kvn Date: 2012-10-09 16:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d336b3173277 8000592: Improve adlc usability Summary: several changes to adlc to improve its usability Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp Changeset: 94e9408dbf50 Author: roland Date: 2012-10-11 18:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94e9408dbf50 8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off Summary: code generated by c1 for getClass intrinsic broken when klass field is loaded on 64bit with compressed klass off. Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: 19eb999cb72c Author: twisti Date: 2012-10-11 14:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/19eb999cb72c 8000740: remove LinkWellKnownClasses Reviewed-by: kvn, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp Changeset: d804e148cff8 Author: kvn Date: 2012-10-12 09:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d804e148cff8 Merge ! make/bsd/makefiles/dtrace.make ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fb19af007ffc Author: jprovino Date: 2012-10-10 14:35 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fb19af007ffc 7189254: Change makefiles for more flexibility to override defaults Summary: Change makefiles so that targets and parameters can be overridden by alternate makefiles. Reviewed-by: dholmes, coleenp ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/ia64.make + make/bsd/makefiles/minimal1.make ! make/bsd/makefiles/vm.make ! make/defs.make + make/excludeSrc.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/ia64.make + make/linux/makefiles/minimal1.make ! make/linux/makefiles/vm.make ! make/windows/makefiles/defs.make ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/forte.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/heapDumper.hpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/runtimeService.hpp ! src/share/vm/utilities/macros.hpp Changeset: bbeecede56dd Author: jiangli Date: 2012-10-11 14:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bbeecede56dd 8000459: assert(java_lang_String::is_instance(entry)) failure with various mlvm tests. Summary: Remove unneeded assert. Reviewed-by: sspitsyn, coleenp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 9855b7e559ae Author: collins Date: 2012-10-12 10:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9855b7e559ae Merge ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/vm.make ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/management.cpp Changeset: 5876f980ea19 Author: collins Date: 2012-10-12 11:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5876f980ea19 Merge ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b261523fe66c Author: amurillo Date: 2012-10-12 13:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b261523fe66c Merge Changeset: 4547dc71db76 Author: amurillo Date: 2012-10-12 13:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4547dc71db76 Added tag hs25-b05 for changeset b261523fe66c ! .hgtags Changeset: fcbdaeb69946 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fcbdaeb69946 Added tag jdk8-b61 for changeset 4547dc71db76 ! .hgtags Changeset: 58fbf2da3c16 Author: amurillo Date: 2012-10-12 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58fbf2da3c16 8000834: new hotspot build - hs25-b06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8a5ea0a9ccc4 Author: johnc Date: 2012-10-06 01:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a5ea0a9ccc4 7127708: G1: change task num types from int to uint in concurrent mark Summary: Change the type of various task num fields, parameters etc to unsigned and rename them to be more consistent with the other collectors. Code changes were also reviewed by Vitaly Davidovich. Reviewed-by: johnc Contributed-by: Kaushik Srenevasan ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: 04155d9c8c76 Author: johnc Date: 2012-10-08 09:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04155d9c8c76 8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file Summary: Missing call to MetaspaceAux::print_on() in G1CollectedHeap::print_on(). Reviewed-by: azeemj, jmasa Contributed-by: Mikael Gerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: dd2b66d09ccd Author: stefank Date: 2012-10-09 22:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dd2b66d09ccd 8000659: NPG: ClassCastExceptions are unexpectedly thrown when testing nashorn Summary: Treat the oops in invoke_method_table() as strong roots when ClassUnloading is enabled. Reviewed-by: kamg, coleenp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 4202510ee0fe Author: johnc Date: 2012-10-15 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4202510ee0fe 8000831: Heap verification output incorrect/incomplete Summary: Restore non-silent output of heap verification. Reviewed-by: ysr, brutisso, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/debug.cpp Changeset: 633ba56cb013 Author: jmasa Date: 2012-10-17 13:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/633ba56cb013 Merge ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/memory/universe.hpp Changeset: bdb5f8c9978b Author: coleenp Date: 2012-10-10 17:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bdb5f8c9978b 7199068: NPG: SharedSkipVerify is meaningless Summary: Remove the SharedSkipVerify flag Reviewed-by: kamg, sspitsyn, coleenp Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp Changeset: 48a75d2640a5 Author: kamg Date: 2012-10-11 14:27 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48a75d2640a5 7054345: Support version 52.0 class file in HotSpot Summary: Accept classfiles with major version 52 Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp Changeset: e0ea0e94c23c Author: kevinw Date: 2012-10-15 16:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0ea0e94c23c 7195151: Multiplatform tescase for 6929067 Reviewed-by: kamg, kvn ! test/runtime/6929067/Test6929067.sh Changeset: e52361627b65 Author: coleenp Date: 2012-10-15 22:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e52361627b65 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/globals.hpp Changeset: 045cb62046a7 Author: rbackman Date: 2012-08-28 15:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/045cb62046a7 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 7b5885dadbdc Author: nloodin Date: 2012-10-17 17:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b5885dadbdc 8000617: It should be possible to allocate memory without the VM dying. Reviewed-by: coleenp, kamg ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: e8c79c2ba3f3 Author: coleenp Date: 2012-10-18 12:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8c79c2ba3f3 Merge Changeset: d0337c31c8be Author: amurillo Date: 2012-10-19 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0337c31c8be Merge Changeset: dccd40de8db1 Author: amurillo Date: 2012-10-19 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dccd40de8db1 Added tag hs25-b06 for changeset d0337c31c8be ! .hgtags Changeset: 556dd9e475c6 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/556dd9e475c6 Added tag jdk8-b62 for changeset dccd40de8db1 ! .hgtags Changeset: d0e7716b179e Author: amurillo Date: 2012-10-19 11:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0e7716b179e 8001176: new hotspot build - hs25-b07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 85916677fc22 Author: coleenp Date: 2012-10-18 13:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85916677fc22 7188233: UseVMInterruptibleIO flag deprecate for JDK8 Summary: The -XX:+UseVMInterruptibleIO flag is deprecated for JDK8. The flag will still enable Interruptible IO on Solaris, but users will get a warning. Reviewed-by: dholmes, acorn, alanb Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: 8ebcedb7604d Author: coleenp Date: 2012-10-18 13:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ebcedb7604d 7053130: hs_err file does not record specified CLASSPATH Summary: Added code to write the value of the java.class.path property to the hs_err file. Reviewed-by: kmo, dholmes, kvn Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: c7957b458bf8 Author: minqi Date: 2012-10-19 08:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c7957b458bf8 8000818: SA constant pool need to reference to reference map after permgen removal Summary: After permgen removal, constant pool changed to put _ldc and _ldc_w (fast_ldc and fast_ldcw) index to reference map, no longer calculated via constant pool cache. Reviewed-by: coleenp, sspitsyn, dholmes Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java Changeset: 8eeffbc22f10 Author: minqi Date: 2012-10-19 08:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8eeffbc22f10 8001055: Bytes.swap should follow big endian Summary: This is a mistake change in 6879063 about Bytes.swap. Java byte code order always follows big endian, but in that change, assume they follow native platform order that is not right. Reviewed-by: coleenp, sspitsyn, dholmes Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java Changeset: 716c64bda5ba Author: zgu Date: 2012-10-19 21:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/716c64bda5ba 7199092: NMT: NMT needs to deal overlapped virtual memory ranges Summary: Enhanced virtual memory tracking to track committed regions as well as reserved regions, so NMT now can generate virtual memory map. Reviewed-by: acorn, coleenp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b988bff99b38 Author: zgu Date: 2012-10-19 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b988bff99b38 Merge Changeset: 80f44792c0c9 Author: coleenp Date: 2012-10-22 12:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/80f44792c0c9 Merge Changeset: 685df3c6f84b Author: jmasa Date: 2012-09-18 23:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/685df3c6f84b 7045397: NPG: Add freelists to class loader arenas. Reviewed-by: coleenp, stefank, jprovino, ohair ! make/excludeSrc.make + src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp + src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp + src/share/vm/memory/metablock.hpp + src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 476718ea6759 Author: jmasa Date: 2012-10-25 12:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/476718ea6759 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() Reviewed-by: johnc, tamao ! src/share/vm/memory/binaryTreeDictionary.hpp Changeset: b58313cf9afd Author: jcoomes Date: 2012-10-26 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b58313cf9afd Merge Changeset: cfe522e6461c Author: kvn Date: 2012-10-17 12:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cfe522e6461c 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space Summary: Fix type of method pointer load from vtable. Reviewed-by: twisti, johnc, roland ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/library_call.cpp Changeset: e81a8af10cd9 Author: kvn Date: 2012-10-18 07:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e81a8af10cd9 8001071: Add simple range check into VM implemenation of Unsafe access methods Summary: Add simple check in debug version of VM. Reviewed-by: twisti, johnc ! src/share/vm/prims/unsafe.cpp Changeset: aaeb9add1ab3 Author: dlong Date: 2012-10-19 14:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aaeb9add1ab3 8001101: C2: more general vector rule subsetting Summary: Allow which vector rules are supported to be decided at runtime. Also a small change to allow vector types in Type::_type_info[] to apply to more platforms. Reviewed-by: kvn, twisti Contributed-by: dean.long at oracle.com ! src/share/vm/opto/type.cpp ! src/share/vm/opto/vectornode.cpp Changeset: 67f4c477c9ab Author: vlivanov Date: 2012-10-22 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/67f4c477c9ab 8000805: JMM issue: short loads are non-atomic Summary: perform transforms during IGVN phase when Load has a single user. Reviewed-by: jrose, kvn, twisti ! src/share/vm/opto/mulnode.cpp + test/compiler/8000805/Test8000805.java Changeset: fd1d564dd460 Author: twisti Date: 2012-10-22 16:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd1d564dd460 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: b2c669fd8114 Author: kvn Date: 2012-10-23 13:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2c669fd8114 8001183: incorrect results of char vectors right shift operaiton Summary: do vector right shift operation for small int types only after loads Reviewed-by: jrose, dlong ! src/cpu/x86/vm/x86.ad ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! test/compiler/6340864/TestByteVect.java ! test/compiler/6340864/TestIntVect.java ! test/compiler/6340864/TestLongVect.java ! test/compiler/6340864/TestShortVect.java + test/compiler/8001183/TestCharVect.java Changeset: a3ecd773a7b9 Author: kvn Date: 2012-10-24 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a3ecd773a7b9 7184394: add intrinsics to use AES instructions Summary: Use new x86 AES instructions for AESCrypt. Reviewed-by: twisti, kvn, roland Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7184394/TestAESBase.java + test/compiler/7184394/TestAESDecode.java + test/compiler/7184394/TestAESEncode.java + test/compiler/7184394/TestAESMain.java Changeset: 006174cfe979 Author: kvn Date: 2012-10-25 17:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/006174cfe979 7163534: VM could crashes assert(false) failed: infinite EA connection graph build Summary: In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already. Reviewed-by: twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/escape.cpp Changeset: 410afdc6a07c Author: kvn Date: 2012-10-26 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/410afdc6a07c 8001635: assert(in_bb(n)) failed: must be Summary: Added missed check that Load node is in processed loop block. Reviewed-by: twisti ! src/share/vm/opto/superword.cpp Changeset: 588f08ed16cf Author: kvn Date: 2012-10-26 12:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/588f08ed16cf Merge ! src/share/vm/runtime/globals.hpp Changeset: dc16fe422c53 Author: amurillo Date: 2012-10-26 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc16fe422c53 Merge Changeset: 57c61f87a1fd Author: amurillo Date: 2012-10-26 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57c61f87a1fd Added tag hs25-b07 for changeset dc16fe422c53 ! .hgtags Changeset: bf14ed159fb0 Author: kvn Date: 2012-05-23 12:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf14ed159fb0 7158801: Improve VM CompileOnly option Summary: Fixed buffer overflow during parsing flags -XX:CompileCommand=, -XX:CompileOnly= and command lines in .hotspot_compiler file. Reviewed-by: never ! src/share/vm/compiler/compilerOracle.cpp Changeset: fe4a4ea5bed9 Author: kamg Date: 2012-06-08 12:49 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe4a4ea5bed9 7158804: Improve config file parsing Summary: Check buffer length when reading Reviewed-by: dholmes, dcubed ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp + test/runtime/7158804/Test7158804.sh Changeset: 6b5a3d18fe0e Author: asaha Date: 2012-08-02 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6b5a3d18fe0e Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 000352e00389 Author: asaha Date: 2012-08-02 22:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/000352e00389 Merge Changeset: defeb6dad7d5 Author: asaha Date: 2012-08-10 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/defeb6dad7d5 Merge Changeset: e4d10261499c Author: asaha Date: 2012-09-07 18:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e4d10261499c Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 521c82b9cbf8 Author: kvn Date: 2012-09-19 13:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/521c82b9cbf8 7198606: Improve VM optimization Summary: Remove incorrect code in OptimizeFill optimization. Reviewed-by: roland, twisti ! src/share/vm/opto/loopTransform.cpp Changeset: 849cf0480cb9 Author: asaha Date: 2012-09-25 11:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/849cf0480cb9 Merge Changeset: 5a3a6dac85e2 Author: asaha Date: 2012-09-26 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a3a6dac85e2 7199488: [TEST] runtime/7158800/InternTest.java failed due to false-positive on PID match. Reviewed-by: coleenp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 218a94758fe7 Author: asaha Date: 2012-10-10 14:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/218a94758fe7 Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/compiler/compilerOracle.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 6ba00f89fbe1 Author: asaha Date: 2012-10-11 15:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6ba00f89fbe1 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d2582a08fa5d Author: asaha Date: 2012-10-18 21:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d2582a08fa5d Merge ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: cb829aa4c98e Author: lana Date: 2012-10-25 20:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb829aa4c98e Merge - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: acabb5c282f5 Author: lana Date: 2012-10-30 13:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/acabb5c282f5 Merge ! src/share/vm/runtime/arguments.cpp From lana.steuck at oracle.com Wed Oct 31 09:53:10 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 31 Oct 2012 16:53:10 +0000 Subject: hg: jdk8/tl/jdk: 49 new changesets Message-ID: <20121031170517.78356476BA@hg.openjdk.java.net> Changeset: 1ae6420126af Author: katleman Date: 2012-10-18 11:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ae6420126af Added tag jdk8-b61 for changeset 61ddb3fd000a ! .hgtags Changeset: 61af38b8d4ff Author: twisti Date: 2012-10-19 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61af38b8d4ff 8000989: smaller code changes to make future JSR 292 backports easier Reviewed-by: jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/PrivateInvokeTest.java Changeset: 7a7e49acadec Author: kamg Date: 2012-10-22 20:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a7e49acadec 8001225: Disable jdk regression test java/lang/System/Versions.java until jdk's classfile version code is updated Summary: Exclude java/lang/System/Versions.java test Reviewed-by: sspitsyn, coleenp ! test/ProblemList.txt Changeset: a0a2b186ae28 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0a2b186ae28 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! make/com/sun/java/pack/Makefile ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/jdk_generic_profile.sh ! make/tools/freetypecheck/Makefile + make/tools/msys_build_scripts/dospath.sh + make/tools/msys_build_scripts/dospath.vbs Changeset: 50b8b17449d2 Author: katleman Date: 2012-10-24 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50b8b17449d2 Merge Changeset: 65d2c6726487 Author: katleman Date: 2012-10-25 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/65d2c6726487 Added tag jdk8-b62 for changeset 50b8b17449d2 ! .hgtags Changeset: 117eed515e42 Author: bae Date: 2012-10-23 13:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/117eed515e42 7051394: NullPointerException when running regression tests LoadProfileTest by using openjdk-7-b144 Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: aeb96dec1c6b Author: lana Date: 2012-10-23 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aeb96dec1c6b Merge Changeset: 93e2669f1ac2 Author: leonidr Date: 2012-10-09 18:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93e2669f1ac2 7185280: Jre7cert: focusgained does not get called for all focus req when do alt + tab Reviewed-by: anthony ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 527f8eeb8e8d Author: leonidr Date: 2012-10-09 20:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/527f8eeb8e8d 7124321: [macosx] TrayIcon MouseListener is never triggered Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/macosx/native/sun/awt/CTrayIcon.h ! src/macosx/native/sun/awt/CTrayIcon.m Changeset: d4d0327e36e2 Author: kshefov Date: 2012-10-12 18:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4d0327e36e2 7184326: TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo Reviewed-by: anthony ! test/java/awt/Frame/7024749/bug7024749.java Changeset: 34d502d14a61 Author: lana Date: 2012-10-12 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34d502d14a61 Merge - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: f42d178f0452 Author: anthony Date: 2012-10-16 20:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f42d178f0452 6818083: When DISPLAY is bad, InternalError thrown, not AWTError Summary: Throw AWTError instead of InternalError if the DISPLAY is bad Reviewed-by: anthony, serb Contributed-by: Mikhail Cherkasov ! src/solaris/native/sun/awt/awt_GraphicsEnv.c + test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.java + test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.sh Changeset: 47cdc463b4b0 Author: kizune Date: 2012-10-17 14:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/47cdc463b4b0 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test Reviewed-by: serb, leonidr ! src/macosx/classes/sun/awt/CGraphicsDevice.java Changeset: e6a8ee65d248 Author: alexsch Date: 2012-10-17 17:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6a8ee65d248 8000969: [macosx] Directories are not deselected when JFileChooser has FILES_ONLY selection mode Reviewed-by: rupashka ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java Changeset: 29b7bd890d3a Author: alexsch Date: 2012-10-17 10:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29b7bd890d3a 8000626: Implement dead key detection for KeyEvent on Linux Reviewed-by: kizune ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 9c6f60a4e996 Author: alexsch Date: 2012-10-18 17:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c6f60a4e996 7199708: FileChooser crashs when opening large folder Reviewed-by: bagiras ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java Changeset: 8bbc6a5f1e92 Author: alexsch Date: 2012-10-18 18:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8bbc6a5f1e92 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 6b16f6fc41c5 Author: serb Date: 2012-10-19 15:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b16f6fc41c5 7124520: [macosx] re:6373505 Toolkit.getScreenResolution() != GraphicsConfiguration.getNormalizingTransform() Reviewed-by: anthony, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java + test/java/awt/GraphicsConfiguration/NormalizingTransformTest/NormalizingTransformTest.java Changeset: e0f91b40b8dd Author: alexsch Date: 2012-10-23 14:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0f91b40b8dd 6624200: Regression test fails: test/closed/javax/swing/JMenuItem/4654927/bug4654927.java Reviewed-by: rupashka + test/javax/swing/JMenuItem/4654927/bug4654927.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 37a6ead4a357 Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37a6ead4a357 Merge Changeset: cdc7f9be3707 Author: lana Date: 2012-10-23 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdc7f9be3707 Merge - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 0582dc4674c9 Author: wetmore Date: 2012-05-21 15:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0582dc4674c9 7167656: Multiple Seeders are being created Reviewed-by: smarks, mduigou, ahgross ! src/share/classes/sun/security/provider/SecureRandom.java Changeset: b4f35876d9b5 Author: mullan Date: 2012-06-08 11:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4f35876d9b5 7163198: Tightened package accessibility 7169887: Tightened package accessibility Reviewed-by: vinnie, hawtin ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 89a0551b98d8 Author: weijun Date: 2012-06-15 09:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89a0551b98d8 6631398: FilePermission improved path checking Reviewed-by: mullan, skoivu, jdn ! src/share/classes/java/io/FilePermission.java Changeset: 7439e8007e09 Author: mullan Date: 2012-06-18 10:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7439e8007e09 7172522: Improve DomainCombiner checking Reviewed-by: vinnie, ahgross ! src/share/classes/java/security/AccessController.java Changeset: 2a98c51549a8 Author: smarks Date: 2012-06-21 00:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a98c51549a8 7093490: adjust package access in rmiregistry Reviewed-by: ahgross, coffeys, dmocek ! src/share/classes/sun/rmi/registry/RegistryImpl.java Changeset: 263f15439f4b Author: dsamersoff Date: 2012-06-22 16:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/263f15439f4b 7158796: Tighten properties checking in EnvHelp Summary: Move getProperty call out of computeBooleanFromString Reviewed-by: skoivu, sla ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java Changeset: 3a825f6cbc71 Author: dsamersoff Date: 2012-06-22 18:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a825f6cbc71 7169888: Narrowing resource definitions in JMX RMI connector Summary: CPU bug, we can't put offending calls outside doPrivileged, but narrow granted permissions. Reviewed-by: ahgross, fparain ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: 90498c1cc87c Author: xuelei Date: 2012-07-28 19:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90498c1cc87c 7186286: TLS implementation to better adhere to RFC Summary: also reviewed by Alexander Fomin , Andrew Gross, Sean Coffey Reviewed-by: valeriep, wetmore ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: 983c17aecdac Author: mullan Date: 2012-08-15 15:31 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/983c17aecdac 7189490: More improvements to DomainCombiner checking Reviewed-by: ahgross, jdn, vinnie ! src/share/classes/java/security/AccessController.java Changeset: 6cc28cc213b6 Author: chegar Date: 2012-08-16 15:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cc28cc213b6 7189103: Executors needs to maintain state Reviewed-by: dholmes, hawtin ! src/share/classes/java/util/concurrent/Executors.java Changeset: a09b9ebb61b6 Author: chegar Date: 2012-08-29 14:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a09b9ebb61b6 7189567: java net obselete protocol Reviewed-by: alanb, ahgross ! make/sun/net/FILES_java.gmk - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java ! test/java/net/URL/Test.java Changeset: 2ac636f46c5b Author: alanb Date: 2012-09-08 20:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ac636f46c5b 7169884: LogManager checks do not work correctly for sub-types Reviewed-by: mchung, ahgross ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java Changeset: 4488ea026532 Author: asaha Date: 2012-09-08 22:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4488ea026532 Merge Changeset: e869a8513cb7 Author: smarks Date: 2012-09-10 16:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e869a8513cb7 7195919: (sl) ServiceLoader can throw CCE without needing to create instance Reviewed-by: ahgross, alanb, dmeetry ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/sun/misc/Service.java Changeset: 9a7e2fa3c9c5 Author: malenkov Date: 2012-09-11 12:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a7e2fa3c9c5 7195549: Better bean object persistence Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java Changeset: 1d1fcf0c1ce8 Author: rupashka Date: 2012-09-11 15:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d1fcf0c1ce8 7195194: Better data validation for Swing Reviewed-by: art, ahgross ! src/share/classes/javax/swing/text/DefaultFormatter.java Changeset: 3b49bd3c392b Author: malenkov Date: 2012-09-19 21:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b49bd3c392b 7195917: XMLDecoder parsing at close-time should be improved Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/decoder/DocumentHandler.java ! src/share/classes/java/beans/XMLDecoder.java Changeset: 762eee5e6e16 Author: jrose Date: 2012-09-20 14:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/762eee5e6e16 7196190: Improve method of handling MethodHandles Summary: Bind callers to caller-sensitive methods. Reviewed-by: twisti, jjh, vlivanov, ahgross ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/anon/AnonymousClassLoader.java ! src/share/classes/sun/invoke/util/ValueConversions.java + test/java/lang/invoke/7196190/ClassForNameTest.java + test/java/lang/invoke/7196190/GetUnsafeTest.java + test/java/lang/invoke/7196190/MHProxyTest.java + test/java/lang/invoke/7196190/jtreg.security.policy Changeset: e113ffde452a Author: dsamersoff Date: 2012-09-24 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e113ffde452a 7198296: Problem with classloader in JMX Summary: wb classes have to be available for hotspot tests Reviewed-by: ahgross, asaha Contributed-by: frederic.parain at oracle.com, daniel.fuchs at oracle.com, jean-francois.denise at oracle.com ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: ca79b33a0731 Author: dsamersoff Date: 2012-09-24 17:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca79b33a0731 7192975: Issue with JMX reflection Summary: Make security check unconditional Reviewed-by: ahgross, asaha Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java Changeset: 74eec13c464e Author: asaha Date: 2012-09-25 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74eec13c464e Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk Changeset: e4ce54b79bb4 Author: asaha Date: 2012-10-10 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ce54b79bb4 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java ! src/share/classes/java/io/FilePermission.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 28fe37b50e3c Author: asaha Date: 2012-10-11 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28fe37b50e3c Merge Changeset: d3b3fea7d1d7 Author: asaha Date: 2012-10-18 22:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3b3fea7d1d7 Merge ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/util/ServiceLoader.java - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: e6fbbb2c610d Author: lana Date: 2012-10-23 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6fbbb2c610d Merge ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/logging/LogManager.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: dfd509da3da6 Author: lana Date: 2012-10-25 20:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfd509da3da6 Merge ! make/common/Release.gmk ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/sun/invoke/util/ValueConversions.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c ! test/ProblemList.txt - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: ac97b1cfc0ea Author: lana Date: 2012-10-31 08:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac97b1cfc0ea Merge ! make/common/shared/Sanity.gmk ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java From naoto.sato at oracle.com Wed Oct 31 11:36:13 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 31 Oct 2012 18:36:13 +0000 Subject: hg: jdk8/tl/jdk: 8001231: Move locale data out of rt.jar (except the US locale) Message-ID: <20121031183648.E343F476CB@hg.openjdk.java.net> Changeset: 178618fb4300 Author: naoto Date: 2012-10-31 11:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/178618fb4300 8001231: Move locale data out of rt.jar (except the US locale) Reviewed-by: alanb, erikj ! make/java/java/genlocales.gmk ! make/java/java/localegen.sh ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! make/sun/text/FILES_java.gmk ! make/sun/text/FILES_properties.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template From jonathan.gibbons at oracle.com Wed Oct 31 13:49:00 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 31 Oct 2012 20:49:00 +0000 Subject: hg: jdk8/tl/langtools: 8001664: refactor javadoc to use abstraction to handle files Message-ID: <20121031204905.65366476CF@hg.openjdk.java.net> Changeset: b980e8e6aabf Author: jjg Date: 2012-10-31 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b980e8e6aabf 8001664: refactor javadoc to use abstraction to handle files Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java From weijun.wang at oracle.com Wed Oct 31 19:08:28 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 01 Nov 2012 10:08:28 +0800 Subject: Transitioning the default keystore format to PKCS#12 In-Reply-To: <3FC6D06D-B83B-47D8-88F7-1BD930752297@oracle.com> References: <66A79E9E-3834-4B47-BBC9-18927D6EE8EB@oracle.com> <3FC6D06D-B83B-47D8-88F7-1BD930752297@oracle.com> Message-ID: <5091D99C.5070306@oracle.com> A little off topic: Do we still care about the JCEKS storetype? Maybe no one stores secret keys in a keystore? Thanks Max On 11/01/2012 12:55 AM, Vincent Ryan wrote: > > Before considering migrating the platform default keystore format to PKCS12 its keystore implementation > must at least match the functionality of JKS. > > I have developed a prototype of a multi-format keystore that understands both JKS and PKCS12 > formats - it checks for the JKS magic number to determine the format. By supporting both formats, > existing applications that access keystores using the platform default keystore format, continue to > function as expected. > > In addition, storing trusted certs in PKCS12 is now supported. I've selected the X.509 > extendedKeyUsage attribute to explicitly denote that a certificate is trusted - its default value is > trusted-for-any-purpose. This well-known attribute is stored with the certificate in a PKCS12 > certBag. > > Webrev: > http://cr.openjdk.java.net/~vinnie/jdk8-multi/webrev/ > > Please send me any comments. > Thanks. >