From ahughes at redhat.com Wed Aug 1 02:35:47 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 1 Aug 2012 05:35:47 -0400 (EDT) Subject: Buffer overflow in C code. In-Reply-To: <50188217.80006@oracle.com> Message-ID: <2132440157.6666601.1343813747100.JavaMail.root@redhat.com> ----- Original Message ----- > [cc'ing net-dev mailing list] > > Thanks for reporting this issue. > > This looks like 7089443 [1], fixed in jdk8 via 7112670 [2]. Looks > like > icetea needs to sync up, or maybe they are based against the jdk7 > repo. The report is from OpenJDK6: /usr/lib/jvm/java-6-openjdk-amd64/ There is IcedTea support for 6, 7 and 8, but we only ship the complete releases (6 & 7) at present. Shipping an early release / early releases of 8 may be on the agenda at some point, but it means also covering it for security issues. > If so, this could be a good candidate to backport from jdk8 to jdk7 ( > then I think icetea will get it for free! ). > I'll look into this. > -Chris. > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089443 > [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112670 > > -Chris. > > On 31/07/12 06:07, Robert ?wi?cki wrote: > > Hi, > > > > When using Java code compiled with gllibc's fortify source (buffer > > overflow detection among others). It crashes: > > > > $ java -jar jar.jar > > *** buffer overflow detected ***: java terminated > > ======= Backtrace: ========= > > /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7fc56100a007] > > /lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7fc561008f00] > > /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libnet.so(Java_java_net_Inet4AddressImpl_getLocalHostName+0x1a0)[0x7fc55d8e4530] > > [0x7fc555010d28] > > ======= Memory map: ======== > > 00400000-00409000 r-xp 00000000 fd:01 2872 > > /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java > > 00608000-00609000 r--p 00008000 fd:01 2872 > > /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java > > 00609000-0060a000 rw-p 00009000 fd:01 2872 > > /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java > > 01dba000-01ddb000 rw-p 00000000 00:00 0 > > [heap] > > cc000000-cca70000 rw-p 00000000 00:00 0 > > cca70000-d9e00000 rw-p 00000000 00:00 0 > > d9e00000-db2f0000 rw-p 00000000 00:00 0 > > db2f0000-f5a00000 rw-p 00000000 00:00 0 > > f5a00000-f6ec0000 rw-p 00000000 00:00 0 > > f6ec0000-100000000 rw-p 00000000 00:00 0 > > 7fc538000000-7fc538021000 rw-p 00000000 00:00 0 > > 7fc538021000-7fc53c000000 ---p 00000000 00:00 0 > > 7fc53c000000-7fc53c021000 rw-p 00000000 00:00 0 > > 7fc53c021000-7fc540000000 ---p 00000000 00:00 0 > > 7fc540000000-7fc540021000 rw-p 00000000 00:00 0 > > 7fc540021000-7fc544000000 ---p 00000000 00:00 0 > > 7fc544000000-7fc5440f5000 rw-p 00000000 00:00 0 > > 7fc5440f5000-7fc548000000 ---p 00000000 00:00 0 > > 7fc548000000-7fc548021000 rw-p 00000000 00:00 0 > > 7fc548021000-7fc54c000000 ---p 00000000 00:00 0 > > > > IMO, the problem is here > > > > http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/jdk/src/solaris/native/java/net/Inet4AddressImpl.c.html > > (line 112) > > > > I.e. MAXHOSTNAMELEN is declarative only (a convention), and it is > > assumed there that gethostbyaddr-like functions will return strings > > which are shorter-equal than 64 (typical value of MAXHOSTNAMELEN). > > > > The machine's FQDN was way over 64 characters, so it crashed. I > > don't > > think it's easily exploitable (requires control over DNS), but it'd > > be > > probably good to fix it. > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From vincent.x.ryan at oracle.com Wed Aug 1 04:15:32 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 01 Aug 2012 12:15:32 +0100 Subject: JDK8 Code review request for 7179715: OCSP revocation checking fails if the signer certificate is identified using the key ID In-Reply-To: <5018519D.5060203@oracle.com> References: <5018519D.5060203@oracle.com> Message-ID: <50190FD4.8020902@oracle.com> That fix looks good Sean. On 07/31/12 10:43 PM, Sean Mullan wrote: > Hi Vinnie, > > Can you please review my fix for 7179715? > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/7179715/webrev.00/ > > This was a regression caused by the integration of JEP 124. The > responderKey was not being parsed correctly and was causing a DER > parsing exception. I have also moved the parsing of the responderId > inside debugging blocks because it is only currently used for debugging > purposes. > > The bug is not available at bugs.sun.com for some reason. > > Thanks, > Sean From sean.mullan at oracle.com Wed Aug 1 08:27:07 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 01 Aug 2012 15:27:07 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120801152759.4764C472E9@hg.openjdk.java.net> Changeset: 21c590fdc8cb Author: mullan Date: 2012-08-01 11:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21c590fdc8cb 7179715: OCSP revocation checking fails if the signer certificate is identified using the key ID Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 9a5a3741bac9 Author: mullan Date: 2012-08-01 11:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a5a3741bac9 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh From mike.duigou at oracle.com Wed Aug 1 11:37:45 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 01 Aug 2012 18:37:45 +0000 Subject: hg: jdk8/tl/jdk: 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Message-ID: <20120801183804.137F7472EF@hg.openjdk.java.net> Changeset: 184da100cf45 Author: jgish Date: 2012-07-27 16:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184da100cf45 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Summary: Change contentEquals( CharSequence cs ) to do synchronization if cs is a StringBuffer Reviewed-by: mduigou Contributed-by: Jim Gish ! src/share/classes/java/lang/String.java From ahughes at redhat.com Wed Aug 1 14:13:37 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 01 Aug 2012 21:13:37 +0000 Subject: hg: jdk8/tl/jdk: 6844255: Potential stack corruption in GetJavaProperties Message-ID: <20120801211403.2FF9A472F5@hg.openjdk.java.net> Changeset: 75bda37d0337 Author: omajid Date: 2012-08-01 22:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75bda37d0337 6844255: Potential stack corruption in GetJavaProperties Summary: Use dynamically allocated buffers for temp and encoding. Reviewed-by: alanb, andrew ! src/solaris/native/java/lang/java_props_md.c From weijun.wang at oracle.com Thu Aug 2 06:41:33 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 02 Aug 2012 21:41:33 +0800 Subject: Code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <500657BF.3020107@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> <500657BF.3020107@oracle.com> Message-ID: <501A838D.40107@oracle.com> Ping again. On 07/18/2012 02:29 PM, Weijun Wang wrote: > 7184815: [macosx] Need to read Kerberos config in files > > Please take a review: > > http://cr.openjdk.java.net/~weijun/7184815/webrev.00/ > > I break the config setting to Java setting and native setting, and > insert the reading of SCDynamicStoreConfig between the two. This should > preserve the 6u behavior and add a fallback to legacy config files. > > No new regression test, because of SCDynamicStoreConfig and system > config files, will ask SQE to create a manual test. > > Thanks > Max > > > On 07/18/2012 08:26 AM, Weijun Wang wrote: >> I'm not familiar with how Mac does it, but normally there are two ways a >> Kerberos authentication is performed, through the initial login and >> through kinit. The former is integrated into the system (a pam module?) >> and I guess in this case the config is inside SCDynamicStoreConfig. For >> the latter, the Kerberos clients are regarded as standalone tools and a >> /etc/krb5.conf is needed. >> >> Java works in both ways, if there is already a credentials cache it will >> happily use it. On the other hand, it also includes the Krb5LoginModule >> that does all the login itself. Therefore, it should read both styles of >> config on a Mac. >> >> I've filed a new bug, It will appear soon at >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184815 >> >> Thanks >> Max >> >> >> On 07/17/2012 10:35 PM, Mike Swingler wrote: >>> On Jul 16, 2012, at 8:32 PM, Weijun Wang wrote: >>> >>>> Ping again. >>>> >>>> On 07/05/2012 04:34 PM, Weijun Wang wrote: >>>>> Hi Scott >>>>> >>>>> On Mac since Lion, sun.security.krb5.Config tries to locate the config >>>>> info in this order: >>>>> >>>>> 1. java.security.krb5.conf system property >>>>> 2. ${jre}/lib/security/krb5.conf >>>>> 3. SCDynamicStoreConfig >>>>> >>>>> The main difference from other platforms is that it will not try >>>>> config >>>>> files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. >>>>> >>>>> On the other hand, even /usr/bin/kinit comes with Lion reads the >>>>> config >>>>> file (if there is no SCDynamicStoreConfig setting). >>>>> >>>>> Is there a special reason for the current Java behavior? I do notice >>>>> that the Apple 6u33 already does this. >>> >>> No special reason I can think of, beyond simply swapping the >>> implementation to read from the SCDynamicStoreConfig. Java SE 6 had >>> previously had been relying on the system to write out a >>> /Library/Preferences/edu.mit.Kerberos file, but that went away with OS >>> X 10.7, so we didn't see much point in reading the file, since little >>> else on the system would be paying attention to it either for the >>> purposes of SSO. >>> >>> It seems perfectly reasonable that if there are no >>> SCDynamicStoreConfig entries, falling back to reading the legacy >>> config files may be a valid option. I'm actually somewhat surprised >>> that they are consulted by kinit. >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >> > From weijun.wang at oracle.com Thu Aug 2 07:14:29 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 02 Aug 2012 22:14:29 +0800 Subject: Code review request: 7184246: Simplify Config.get() of krb5 In-Reply-To: <14914072.1343818131183.JavaMail.sbladm@swsblss4-new.central.sun.com> References: <14914072.1343818131183.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <501A8B45.9070907@oracle.com> 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 sean.mullan at oracle.com Thu Aug 2 07:43:22 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 02 Aug 2012 14:43:22 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120802144350.F260647318@hg.openjdk.java.net> Changeset: b0bfa441d70f Author: mullan Date: 2012-08-02 10:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0bfa441d70f 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) Reviewed-by: mullan, xuelei, weijun Contributed-by: jason.uh at oracle.com ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java + test/sun/security/x509/X509CRLImpl/Verify.java + test/sun/security/x509/X509CertImpl/Verify.java Changeset: 4e8bafdcefda Author: mullan Date: 2012-08-02 10:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e8bafdcefda Merge From stuart.marks at oracle.com Thu Aug 2 18:10:45 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 03 Aug 2012 01:10:45 +0000 Subject: hg: jdk8/tl/jdk: 7187876: ClassCastException in TCPTransport.executeAcceptLoop Message-ID: <20120803011056.B618C47338@hg.openjdk.java.net> Changeset: 8a82e5f9c47f Author: dmocek Date: 2012-08-02 18:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a82e5f9c47f 7187876: ClassCastException in TCPTransport.executeAcceptLoop Reviewed-by: dholmes, smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java From maurizio.cimadamore at oracle.com Fri Aug 3 02:15:32 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 03 Aug 2012 09:15:32 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20120803091601.8756947361@hg.openjdk.java.net> Changeset: cddc2c894cc6 Author: mcimadamore Date: 2012-08-02 18:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cddc2c894cc6 7175911: Simplify error reporting API in Check.CheckContext interface Summary: Make error messages generated during Check.checkType more uniform and more scalable Reviewed-by: jjg, dlsmith ! 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/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! 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/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.out ! test/tools/javac/T6326754.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/cast/6270087/T6270087neg.out ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/cast/6932571/T6932571neg.out ! test/tools/javac/cast/7005095/T7005095neg.out ! test/tools/javac/cast/7005671/T7005671.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToLower.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/6207386/T6207386.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/rawOverride/7062745/T7062745neg.out ! test/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/tools/javac/multicatch/Neg06.out ! test/tools/javac/multicatch/Neg07.out ! test/tools/javac/types/CastObjectToPrimitiveTest.out ! test/tools/javac/varargs/6313164/T6313164.out ! test/tools/javac/varargs/7097436/T7097436.out Changeset: e5cf1569d3a4 Author: mcimadamore Date: 2012-08-02 18:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e5cf1569d3a4 7175538: Integrate efectively final check with DA/DU analysis Summary: Allow generalized effectively-final analysis for all local variables Reviewed-by: jjg, dlsmith ! 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/Flow.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java + test/tools/javac/lambda/EffectivelyFinalTest.java + test/tools/javac/lambda/EffectivelyFinalTest01.out + test/tools/javac/lambda/EffectivelyFinalTest02.out Changeset: 2d75e7c952b8 Author: mcimadamore Date: 2012-08-02 18:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d75e7c952b8 7187104: Inference cleanup: remove redundant exception classes in Infer.java Summary: Remove unused exception classes in Infer.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java From xueming.shen at oracle.com Fri Aug 3 13:36:11 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 03 Aug 2012 20:36:11 +0000 Subject: hg: jdk8/tl/jdk: 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Message-ID: <20120803203637.C9C044736B@hg.openjdk.java.net> Changeset: 1468b0af0d06 Author: sherman Date: 2012-08-03 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1468b0af0d06 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Summary: re-implemented getBytesRead/Writtten() at java level Reviewed-by: andrew, alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zlib-1.2.5/compress.c ! src/share/native/java/util/zip/zlib-1.2.5/inflate.c ! src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java ! src/share/native/java/util/zip/zlib-1.2.5/zlib.h + test/java/util/zip/TotalInOut.java From kumar.x.srinivasan at oracle.com Sat Aug 4 16:36:02 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 04 Aug 2012 23:36:02 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120804233656.5075B47389@hg.openjdk.java.net> Changeset: 3521fcad4b5f Author: ksrini Date: 2012-07-31 06:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3521fcad4b5f 7188114: (launcher) need an alternate command line parser for Windows Reviewed-by: darcy, dholmes, jjh Contributed-by: akhil.arora at oracle.com + src/windows/bin/cmdtoargs.c Changeset: 2dd41a2dfe54 Author: ksrini Date: 2012-07-31 06:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2dd41a2dfe54 7146424: Wildcard expansion for single entry classpath Reviewed-by: dholmes, darcy, jjh, sherman ! make/common/Program.gmk ! make/java/jli/Makefile ! make/java/jli/mapfile-vers ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/share/bin/main.c ! src/share/bin/wildcard.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties - src/solaris/bin/java_md.c ! src/solaris/bin/java_md_common.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java ! test/tools/launcher/ToolsOpts.java From sean.mullan at oracle.com Mon Aug 6 07:43:05 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 06 Aug 2012 10:43:05 -0400 Subject: JDK 8 Code Review Request: 7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null Message-ID: <501FD7F9.9070207@oracle.com> Hi Valerie, Could you please review this simple fix to P11DSAKeyFactory.implTranslatePublicKey? http://cr.openjdk.java.net/~mullan/webrevs/7187962/webrev.00/ Thanks, Sean From xuelei.fan at oracle.com Mon Aug 6 08:03:58 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 06 Aug 2012 23:03:58 +0800 Subject: JDK 8 Code Review Request: 7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null In-Reply-To: <501FD7F9.9070207@oracle.com> References: <501FD7F9.9070207@oracle.com> Message-ID: <501FDCDE.2070109@oracle.com> Does other JCE provider also need to check the parameter? For example, sun.security.provider.DSAKeyFactory. Thanks, Xuelei On 8/6/2012 10:43 PM, Sean Mullan wrote: > Hi Valerie, > > Could you please review this simple fix to > P11DSAKeyFactory.implTranslatePublicKey? > > http://cr.openjdk.java.net/~mullan/webrevs/7187962/webrev.00/ > > Thanks, > Sean From sean.mullan at oracle.com Mon Aug 6 08:12:18 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 06 Aug 2012 11:12:18 -0400 Subject: JDK 8 Code Review Request: 7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null In-Reply-To: <501FDCDE.2070109@oracle.com> References: <501FD7F9.9070207@oracle.com> <501FDCDE.2070109@oracle.com> Message-ID: <501FDED2.1040908@oracle.com> On 08/06/2012 11:03 AM, Xuelei Fan wrote: > Does other JCE provider also need to check the parameter? For example, > sun.security.provider.DSAKeyFactory. It already does. This fix makes the SunPKCS11 provider consistent with the SUN provider. See the sun.security.provider.DSA.setParams method: private void setParams(DSAParams params) throws InvalidKeyException { if (params == null) { throw new InvalidKeyException("DSA public key lacks parameters"); } ... --Sean > > Thanks, > Xuelei > > On 8/6/2012 10:43 PM, Sean Mullan wrote: >> Hi Valerie, >> >> Could you please review this simple fix to >> P11DSAKeyFactory.implTranslatePublicKey? >> >> http://cr.openjdk.java.net/~mullan/webrevs/7187962/webrev.00/ >> >> Thanks, >> Sean > From alan.bateman at oracle.com Tue Aug 7 04:48:43 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 07 Aug 2012 11:48:43 +0000 Subject: hg: jdk8/tl/jdk: 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Message-ID: <20120807114853.E377C473D2@hg.openjdk.java.net> Changeset: e0ef14d89741 Author: alanb Date: 2012-08-07 12:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0ef14d89741 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/basic.sh From lana.steuck at oracle.com Tue Aug 7 23:06:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:06:54 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b50 for changeset 2fd67618b9a3 Message-ID: <20120808060654.ECD174740F@hg.openjdk.java.net> Changeset: 57c0aee73090 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/57c0aee73090 Added tag jdk8-b50 for changeset 2fd67618b9a3 ! .hgtags From lana.steuck at oracle.com Tue Aug 7 23:06:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:06:54 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b50 for changeset d20d9eb9f093 Message-ID: <20120808060658.0931F47410@hg.openjdk.java.net> Changeset: 9b0f841ca9f7 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9b0f841ca9f7 Added tag jdk8-b50 for changeset d20d9eb9f093 ! .hgtags From lana.steuck at oracle.com Tue Aug 7 23:07:03 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:03 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b50 for changeset 2791ec55f66b Message-ID: <20120808060714.543A047411@hg.openjdk.java.net> Changeset: dc1ea77ed9d9 Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/dc1ea77ed9d9 Added tag jdk8-b50 for changeset 2791ec55f66b ! .hgtags From lana.steuck at oracle.com Tue Aug 7 23:07:05 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:05 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b50 for changeset bdab72e87b83 Message-ID: <20120808060714.A9C1447412@hg.openjdk.java.net> Changeset: 1a70b6333ebe Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1a70b6333ebe Added tag jdk8-b50 for changeset bdab72e87b83 ! .hgtags From lana.steuck at oracle.com Tue Aug 7 23:07:10 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:10 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20120808060731.B65B047413@hg.openjdk.java.net> Changeset: c4cd4cab2220 Author: katleman Date: 2012-08-02 15:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c4cd4cab2220 Added tag jdk8-b50 for changeset b2d8a270f5f2 ! .hgtags Changeset: cfa70d7ac944 Author: lana Date: 2012-08-07 20:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cfa70d7ac944 Merge From lana.steuck at oracle.com Tue Aug 7 23:07:26 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:26 +0000 Subject: hg: jdk8/tl/hotspot: 37 new changesets Message-ID: <20120808060917.2339E47414@hg.openjdk.java.net> Changeset: 54e66510c9cd Author: amurillo Date: 2012-07-13 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/54e66510c9cd 7184050: new hotspot build - hs24-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8150fa46d2ed Author: jiangli Date: 2012-06-26 19:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8150fa46d2ed 7178145: Change constMethodOop::_exception_table to optionally inlined u2 table. Summary: Change constMethodOop::_exception_table to optionally inlined u2 table. Reviewed-by: bdelsart, coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java + agent/src/share/classes/sun/jvm/hotspot/oops/ExceptionTableElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.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/generateOopMap.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f0b82641fb7e Author: bdelsart Date: 2012-07-02 04:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f0b82641fb7e Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: d68b1274b9ba Author: jiangli Date: 2012-07-05 18:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d68b1274b9ba 7180914: Compilation warning after: 7172967: Eliminate the constMethod's _method backpointer to the methodOop. Summary: Use read_pointer(J...) to access from 'constMethod' base in name_for_methodOop(), libjvm_db.c. Reviewed-by: kvn, coleenp ! src/os/solaris/dtrace/libjvm_db.c Changeset: 161ae369407d Author: jiangli Date: 2012-07-05 20:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/161ae369407d 7181632: nsk classLoad001_14 failure and CompileTheWorld crash after 7178145. Summary: Need to copy the inlined exception table to the new constMethodOop during method rewriting. Reviewed-by: coleenp, dholmes ! src/share/vm/oops/methodOop.cpp Changeset: e74da3c2b827 Author: jiangli Date: 2012-07-13 20:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e74da3c2b827 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 0bca41b2fa63 Author: jiangli Date: 2012-07-17 12:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0bca41b2fa63 Merge Changeset: 922993931b3d Author: brutisso Date: 2012-07-11 22:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/922993931b3d 7178361: G1: Make sure that PrintGC and PrintGCDetails use the same timing for the GC pause Summary: Also reviewed by: vitalyd at gmail.com. Move the timing out of G1CollectorPolicy into the G1GCPhaseTimes class Reviewed-by: johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 3a431b605145 Author: jmasa Date: 2012-07-16 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a431b605145 Merge ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 7553d441b878 Author: jmasa Date: 2012-07-17 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7553d441b878 Merge Changeset: 6d8f36bcef55 Author: jrose Date: 2012-07-12 00:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d8f36bcef55 6711908: JVM needs direct access to some annotations Summary: Add annotation extraction code to class file parser. Reviewed-by: twisti, jrose, kvn Contributed-by: michael.haupt at oracle.com ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodOop.hpp Changeset: ed21db7b3fda Author: kvn Date: 2012-07-13 17:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed21db7b3fda 7123926: Some CTW test crash: !_control.contains(ctrl) Summary: Don't eliminate Integer::toString() call node during String concatenation optimization if it has several uses. Reviewed-by: twisti ! src/share/vm/opto/stringopts.cpp Changeset: 56c4f88474b3 Author: twisti Date: 2012-07-16 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/56c4f88474b3 7087357: JSR 292: remove obsolete code after 7085860 Reviewed-by: kvn, never ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2c368ea3e844 Author: kvn Date: 2012-07-16 17:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c368ea3e844 7181494: cleanup avx and vectors code Summary: renamed mach nodes which use scalar AVX instructions, added integer vectors shuffling instructions Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86.ad ! src/share/vm/code/vmreg.hpp Changeset: 9c9fb30d2b3b Author: kvn Date: 2012-07-16 19:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c9fb30d2b3b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/unsafe.cpp Changeset: dd785aabe02b Author: kvn Date: 2012-07-17 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dd785aabe02b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp Changeset: bc3e01899804 Author: kvn Date: 2012-07-19 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bc3e01899804 Merge Changeset: d900d95bfdb0 Author: fparain Date: 2012-07-16 04:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d900d95bfdb0 7183754: Test runtime/6294277/Test6294277.sh runs wrong JVM Reviewed-by: kamg, coleenp, ctornqvi ! test/runtime/6294277/SourceDebugExtension.java - test/runtime/6294277/Test6294277.sh Changeset: 149c36689fcb Author: asaha Date: 2012-07-17 22:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/149c36689fcb 7053586: TEST: runtime/7020373/Test7020373.sh fails on 64-bit platforms Reviewed-by: kamg ! test/runtime/7020373/Test7020373.sh Changeset: 7e5976e66c62 Author: zgu Date: 2012-07-19 09:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7e5976e66c62 7182543: NMT ON: Aggregate a few NMT related bugs Summary: 1) Fixed MemTrackWorker::generations_in_used() calculation 2) Ensured NMT not to leak memory recorders after shutdown 3) Used ThreadCritical to block safepoint safe threads Reviewed-by: acorn, coleenp, dholmes, kvn ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: f1f45dddb0bd Author: zgu Date: 2012-07-16 14:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1f45dddb0bd 7181986: NMT ON: Assertion failure when running jdi ExpiredRequestDeletionTest Summary: Changed _query_lock to heap object from static object. Also fixed _query_lock and snapshot lock ranks, so they can participate deadlock detection. Reviewed-by: coleenp, dholmes, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: d5bc62fcfac7 Author: zgu Date: 2012-07-19 09:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5bc62fcfac7 Merge ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 04a9b3789683 Author: zgu Date: 2012-07-16 14:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04a9b3789683 7181989: NMT ON: Assertion failure when NMT checks thread's native stack base address Summary: Assertion on stack base is not necessary Reviewed-by: coleenp, dholmes, kvn ! src/share/vm/services/memTracker.cpp Changeset: 58a04a45a549 Author: zgu Date: 2012-07-19 09:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58a04a45a549 Merge ! src/share/vm/services/memTracker.cpp Changeset: 950ed41429e5 Author: zgu Date: 2012-07-19 06:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/950ed41429e5 Merge Changeset: 12fc2571a6e2 Author: coleenp Date: 2012-07-20 12:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12fc2571a6e2 Merge - test/runtime/6294277/Test6294277.sh Changeset: bd54fe36b5e5 Author: amurillo Date: 2012-07-23 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd54fe36b5e5 Merge - test/runtime/6294277/Test6294277.sh Changeset: 15eb2b903b04 Author: amurillo Date: 2012-07-23 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15eb2b903b04 Added tag hs24-b17 for changeset bd54fe36b5e5 ! .hgtags Changeset: aba91a731143 Author: amurillo Date: 2012-07-23 13:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aba91a731143 7185775: new hotspot build - hs24-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: fe94b4e7212b Author: asaha Date: 2012-07-23 14:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe94b4e7212b 7185550: TEST: runtime/7020373/Test7020373.sh fails because there is no test/runtime/7020373/testcase.jar Reviewed-by: coleenp ! test/runtime/7020373/Test7020373.sh + test/runtime/7020373/testcase.jar Changeset: 43541217e9f7 Author: jiangli Date: 2012-07-26 17:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/43541217e9f7 7187046: Crash in ClassFileParser on solaris-ia32 during RetransformClasses. Summary: Lower compiler optimization level when compiling jvmtiClassFileReconstituter.cpp as a workaround for the solaris x86 5.10 cc bug. Reviewed-by: kvn, coleenp ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make Changeset: 611e8a669a2c Author: dlong Date: 2012-07-16 15:31 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/611e8a669a2c 7147464: Java crashed while executing method with over 8k of dneg operations Summary: replace recursive method with iterative Reviewed-by: kvn, twisti Contributed-by: dean.long at oracle.com ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp Changeset: a93a6d2c9e6c Author: jiangli Date: 2012-07-24 13:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a93a6d2c9e6c Merge Changeset: bcd1b9d98558 Author: jiangli Date: 2012-07-26 16:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bcd1b9d98558 Merge Changeset: 72e0362c3f0c Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72e0362c3f0c Merge ! .hgtags - test/runtime/6294277/Test6294277.sh Changeset: 58f237a9e83a Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58f237a9e83a Added tag hs24-b18 for changeset 72e0362c3f0c ! .hgtags Changeset: c01c8e05ec8c Author: katleman Date: 2012-08-02 15:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c01c8e05ec8c Added tag jdk8-b50 for changeset 58f237a9e83a ! .hgtags From lana.steuck at oracle.com Tue Aug 7 23:07:56 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:56 +0000 Subject: hg: jdk8/tl/jdk: 14 new changesets Message-ID: <20120808061039.F37A747415@hg.openjdk.java.net> Changeset: 79c9847d4a5f Author: katleman Date: 2012-08-02 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79c9847d4a5f Added tag jdk8-b50 for changeset e4bae5c53fca ! .hgtags Changeset: 28665fa73b4a Author: rupashka Date: 2012-07-19 19:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28665fa73b4a 7124330: [macosx] javax.swing.JComboBox throws unexpected ClassCastException Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: b1c5e4a843f3 Author: leonidr Date: 2012-07-19 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1c5e4a843f3 7181027: [macosx] Unable to use headless mode Reviewed-by: anthony ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/solaris/native/java/lang/java_props_md.c Changeset: f04d8dee2da9 Author: alexsch Date: 2012-07-23 17:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f04d8dee2da9 7185512: The printout doesn't match image on screen. Reviewed-by: serb, bagiras ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: 8a5a71e853ed Author: alexsch Date: 2012-07-24 16:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a5a71e853ed 7129800: [macosx] Regression test OverrideRedirectWindowActivationTest fails due to timing issue Reviewed-by: rupashka + test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 3502753a9d66 Author: rupashka Date: 2012-07-25 13:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3502753a9d66 7167780: Hang javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests Reviewed-by: alexsch ! src/share/classes/javax/swing/TimerQueue.java Changeset: 1a410846d85b Author: malenkov Date: 2012-07-25 19:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a410846d85b 4650871: Classes in sunw.* should be removed from workspace and rt.jar Reviewed-by: art, rupashka ! make/Makefile ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk - make/sunw/Makefile ! makefiles/CreateJars.gmk ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/sun/misc/MetaIndex.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: 80b1ecc79852 Author: denis Date: 2012-07-27 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80b1ecc79852 7149068: java/awt/Window/Grab/GrabTest.java failed Reviewed-by: art, ant + test/java/awt/Window/Grab/GrabTest.java Changeset: 1579507a736f Author: lana Date: 2012-07-27 22:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1579507a736f Merge - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 1abb270d9038 Author: malenkov Date: 2012-07-30 13:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1abb270d9038 7187618: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Performance/Test7122740.java + test/java/beans/Performance/Test7184799.java Changeset: 896322c6f35f Author: alexsch Date: 2012-07-30 14:31 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/896322c6f35f 7184365: closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails Reviewed-by: serb, bagiras ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest.java Changeset: b08697af1c56 Author: lana Date: 2012-07-31 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b08697af1c56 Merge - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java Changeset: e865efbc7105 Author: lana Date: 2012-08-06 15:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e865efbc7105 Merge - make/sunw/Makefile - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: b0d6552ba301 Author: lana Date: 2012-08-07 20:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0d6552ba301 Merge - make/sunw/Makefile - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java ! src/solaris/native/java/lang/java_props_md.c From vincent.x.ryan at oracle.com Wed Aug 8 02:23:13 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 08 Aug 2012 10:23:13 +0100 Subject: Code Review Request for 7044060 "Need to support NSA Suite B Cryptography algorithms" In-Reply-To: <4FD293E0.9020304@oracle.com> References: <4FD293E0.9020304@oracle.com> Message-ID: <50223001.4080906@oracle.com> Hello Valerie, Your changes look good. Thanks. On 06/ 9/12 01:08 AM, Valerie (Yu-Ching) Peng wrote: > Vinnie, > > Could you please review the changes for 7044060 "Need to support NSA > Suite B Cryptography algorithms"? > The webrev is at: > http://cr.openjdk.java.net/~valeriep/7044060/webrev.00/ > > The changes are as follows: > 1) add support for larger DSA key sizes (up to 2048-bit): this also > means adding built-in parameter, and SHA224withDSA and SHA256withDSA > signatures. > 2) add AES OID support and other misc ones. > > Thanks, > Valerie > From ahughes at redhat.com Wed Aug 8 04:38:12 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 08 Aug 2012 11:38:12 +0000 Subject: hg: jdk8/tl/jdk: 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Message-ID: <20120808113853.0E03047419@hg.openjdk.java.net> Changeset: d87e86aaf2b3 Author: andrew Date: 2012-08-08 12:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d87e86aaf2b3 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Summary: Add missing calls to free Reviewed-by: alanb, dholmes, sherman ! src/solaris/native/java/lang/java_props_md.c From neil.richards at ngmr.net Wed Aug 8 05:19:56 2012 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 08 Aug 2012 13:19:56 +0100 Subject: Code review request: 6733443: JCA/JCE init does not completely reset the delayed provider selection mechanism. In-Reply-To: <50132F3F.6000509@oracle.com> References: <1343103225.26375.66.camel@chalkhill> <50132F3F.6000509@oracle.com> Message-ID: <1344428396.23350.8.camel@chalkhill> Hi Valerie, Thank you for agreeing to take a look at this suggested change. Please get back to me as soon as you have any questions, comments or observations on this. Thanks, Neil On Fri, 2012-07-27 at 17:15 -0700, Valerie (Yu-Ching) Peng wrote: > Neil, > > Thanks for the feedback, I will take a look and let you know my thoughts > sometime next week. > > Valerie > > On 07/23/12 21:13, Neil Richards wrote: > > Hi all, > > > > The PKCS11 documentation [1] describes how the selection of a security > > provider implementation is (re-)performed each time any initialization > > (init*) method is called on objects of the classes: > > * javax.crypto.Cipher > > * javax.crypto.KeyAgreement > > * javax.crypto.Mac > > * java.security.Signature > > so that a suitable implementation is chosen for the Key object given to > > these initialization methods. > > > > This behaviour, whose description was introduced in Java 5, is entirely > > sensible (from a user's point of view), I think. > > > > However, the (Sun/Oracle/OpenJDK) implementation was not modified to > > actually implement the described behaviour. > > > > Java bug 6733443 was raised to report the discrepancy [2]. > > > > I have created a webrev [3] with suggested changes to make the > > implementation conform to the described behaviour. > > > > It also holds a testcase for the change, which has a bespoke (minimally > > implemented) test-specific Provider implementation and associated > > classes. These implementations contain function just sufficient for the > > tests' needs, to support things to the point of initialization. All > > other functions are stubbed out. > > > > Also, the (invocation of the) tests for Cipher, KeyAgreement& Mac are > > currently commented out, as they will only work when the provider is > > held in a signed jar file, and I wasn't sure how to accomplish that in a > > jtreg test. > > > > However, I have successfully run all these tests using versions of the > > Cipher, KeyAgreement& Mac classes which have been mildly hacked to > > remove their check to JceSecurity.canUseProvider() in chooseProvider(). > > > > Please review the suggested fix and let me your thoughts on it. > > > > Thanks, > > Neil > > > > [1]http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html#DelayedSelect > > [2]http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6733443 > > [3]http://cr.openjdk.java.net/~ngmr/6733443/webrev.00/ > > > > -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alan.bateman at oracle.com Wed Aug 8 07:32:54 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 08 Aug 2012 14:32:54 +0000 Subject: hg: jdk8/tl/jdk: 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Message-ID: <20120808143325.73F714741B@hg.openjdk.java.net> Changeset: a50e92a980a5 Author: alanb Date: 2012-08-08 15:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a50e92a980a5 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java From kumar.x.srinivasan at oracle.com Wed Aug 8 09:33:24 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 08 Aug 2012 16:33:24 +0000 Subject: hg: jdk8/tl/jdk: 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Message-ID: <20120808163344.942374741F@hg.openjdk.java.net> Changeset: a44671e0b6d7 Author: ksrini Date: 2012-08-08 09:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a44671e0b6d7 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Reviewed-by: darcy, jgish ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java From sundararajan.athijegannathan at oracle.com Wed Aug 8 09:45:37 2012 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 08 Aug 2012 16:45:37 +0000 Subject: hg: jdk8/tl/langtools: 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Message-ID: <20120808164541.2905947420@hg.openjdk.java.net> Changeset: f071cd32d297 Author: sundar Date: 2012-08-08 22:17 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f071cd32d297 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/TryWithResources/T7178324.java From xuelei.fan at oracle.com Wed Aug 8 18:57:27 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 09 Aug 2012 09:57:27 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension Message-ID: <50231907.9080606@oracle.com> Please review the design of JEP 114, TLS Server Name Indication (SNI) Extension. The webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.01/ The following is a list of typical user cases, and the demo code using this spec for each case. Typical user cases for client side: Case 1: I want to access "www.example.com" sslParameters.setServerName("host_name", "www.example.com"); Set the host name explicit. It is recommend that the client always specify the host name. Case 2: The server has some compatibility issues, I do not want to use server name indication for hostname because of the compatibility concerns. sslParameters.setServerName("host_name", ""); I will not use server name indication for host_name. Case 3: I want to access URL, "https://www.example.com". Doing nothing, the provider default behaviors will set the hostname for me. I don't care about what's the real server name indication. Note that it is the compatible behaviors of JDK 7. Case 4: the parameter was previously set to "www.example.com" (see Case 1), but I want to use the provider default value. I need to remove the previous set value. sslParameters.setServerName("host_name", null); Typical user cases for application server side: Case 1: I want to accept all kind of server name indication Doing nothing, the server will ignore the server name indication Case 2: I want to deny all server name indication of type host name sslParameters.setServerName("hostname", ""); Case 3: I want to accept all kind of server name indication, but previously, I have set the server name indication to other values. I need to reset the value sslParameters.setServerName("hostname", null); Case 4: I want to accept server name indication of "www.example.com". sslParameters.setServerName("host_name", "www.example.com"); Case 5: I want to accept server name indication of "www.xuelei.com", but I also have alternative names of "www.example.edu" and "www.example.org". sslParameters.setServerName("host_name", "www.example.com"); sslParameters.setServernamePattern("host_name", Pattern.compile("www\\.example\\.(edu|org)")); Case 6: I want to accept server name indication of "www.example.com", and I have no alternative name. But I need to make sure that other component does not set alternative name for me in previous calling. sslParameters.setServerName("host_name", "www.example.com"); sslParameters.setServernamePattern("host_name", null); Typical user cases for dispatch server: A dispatch server is one server who parsers the server name indication, and dispatches the connection to the right/real server on a virtual hosting environment. See section 2, "The How-To and Scenarios in Example" of the README: http://cr.openjdk.java.net./~xuelei/7068321/README I appreciate any feedback about the spec. Thanks & Regards, Xuelei From valerie.peng at oracle.com Wed Aug 8 19:10:39 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 08 Aug 2012 19:10:39 -0700 Subject: Code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <501A838D.40107@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> <500657BF.3020107@oracle.com> <501A838D.40107@oracle.com> Message-ID: <50231C1F.9060104@oracle.com> Max, The new ordering for reading the config files sounds reasonable. However, I have questions on scenarios where the various config files don't exist and the corresponding handling. The new impl of getJavaFileName()/getNativeFileName() return file names even when the file doesn't exist. This will lead to an IOException when loadConfigFile(String) is called. Is this intended? Also, the toStringIndented(...) method removed several calls which append the 'prefix' and made various adjustments. Do you have sample output using the new impl? Reading through the code, some don't look quite right. Thanks, Valerie On 08/02/12 06:41, Weijun Wang wrote: > Ping again. > > On 07/18/2012 02:29 PM, Weijun Wang wrote: >> 7184815: [macosx] Need to read Kerberos config in files >> >> Please take a review: >> >> http://cr.openjdk.java.net/~weijun/7184815/webrev.00/ >> >> I break the config setting to Java setting and native setting, and >> insert the reading of SCDynamicStoreConfig between the two. This should >> preserve the 6u behavior and add a fallback to legacy config files. >> >> No new regression test, because of SCDynamicStoreConfig and system >> config files, will ask SQE to create a manual test. >> >> Thanks >> Max >> >> >> On 07/18/2012 08:26 AM, Weijun Wang wrote: >>> I'm not familiar with how Mac does it, but normally there are two >>> ways a >>> Kerberos authentication is performed, through the initial login and >>> through kinit. The former is integrated into the system (a pam module?) >>> and I guess in this case the config is inside SCDynamicStoreConfig. For >>> the latter, the Kerberos clients are regarded as standalone tools and a >>> /etc/krb5.conf is needed. >>> >>> Java works in both ways, if there is already a credentials cache it >>> will >>> happily use it. On the other hand, it also includes the Krb5LoginModule >>> that does all the login itself. Therefore, it should read both >>> styles of >>> config on a Mac. >>> >>> I've filed a new bug, It will appear soon at >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184815 >>> >>> Thanks >>> Max >>> >>> >>> On 07/17/2012 10:35 PM, Mike Swingler wrote: >>>> On Jul 16, 2012, at 8:32 PM, Weijun Wang >>>> wrote: >>>> >>>>> Ping again. >>>>> >>>>> On 07/05/2012 04:34 PM, Weijun Wang wrote: >>>>>> Hi Scott >>>>>> >>>>>> On Mac since Lion, sun.security.krb5.Config tries to locate the >>>>>> config >>>>>> info in this order: >>>>>> >>>>>> 1. java.security.krb5.conf system property >>>>>> 2. ${jre}/lib/security/krb5.conf >>>>>> 3. SCDynamicStoreConfig >>>>>> >>>>>> The main difference from other platforms is that it will not try >>>>>> config >>>>>> files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. >>>>>> >>>>>> On the other hand, even /usr/bin/kinit comes with Lion reads the >>>>>> config >>>>>> file (if there is no SCDynamicStoreConfig setting). >>>>>> >>>>>> Is there a special reason for the current Java behavior? I do notice >>>>>> that the Apple 6u33 already does this. >>>> >>>> No special reason I can think of, beyond simply swapping the >>>> implementation to read from the SCDynamicStoreConfig. Java SE 6 had >>>> previously had been relying on the system to write out a >>>> /Library/Preferences/edu.mit.Kerberos file, but that went away with OS >>>> X 10.7, so we didn't see much point in reading the file, since little >>>> else on the system would be paying attention to it either for the >>>> purposes of SSO. >>>> >>>> It seems perfectly reasonable that if there are no >>>> SCDynamicStoreConfig entries, falling back to reading the legacy >>>> config files may be a valid option. I'm actually somewhat surprised >>>> that they are consulted by kinit. >>>> >>>> Regards, >>>> Mike Swingler >>>> Apple Inc. >>>> >>> >> From weijun.wang at oracle.com Wed Aug 8 19:33:34 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 09 Aug 2012 10:33:34 +0800 Subject: Code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <50231C1F.9060104@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> <500657BF.3020107@oracle.com> <501A838D.40107@oracle.com> <50231C1F.9060104@oracle.com> Message-ID: <5023217E.5000308@oracle.com> On 08/09/2012 10:10 AM, Valerie (Yu-Ching) Peng wrote: > Max, > > The new ordering for reading the config files sounds reasonable. > However, I have questions on scenarios where the various config files > don't exist and the corresponding handling. > The new impl of getJavaFileName()/getNativeFileName() return file names > even when the file doesn't exist. > This will lead to an IOException when loadConfigFile(String) is called. > Is this intended? Yes. But this IOException will be ignored at the end of the private constructor. This is the also the old behavior. The main purpose is that even there is no (any kind of) krb5.conf there is still a chance to read config from DNS etc. > > Also, the toStringIndented(...) method removed several calls which > append the 'prefix' and made various adjustments. > Do you have sample output using the new impl? Reading through the code, > some don't look quite right. There are 2 major changes: 1. A string value does not starts from a newline 2. Vectors are inside square brackets. For example, for a very typical krb5.conf [libdefaults] default_realm = R [realms] R = { kdc = k1 kdc = k2 } the old toString is libdefaults = { default_realm = { R } } realms = { R = { kdc = { k1 k2 } } } and the new output is { libdefaults = { default_realm = R } realms = { R = { kdc = [k1,k2,] } } } Thanks Max > Thanks, > Valerie > > On 08/02/12 06:41, Weijun Wang wrote: >> Ping again. >> >> On 07/18/2012 02:29 PM, Weijun Wang wrote: >>> 7184815: [macosx] Need to read Kerberos config in files >>> >>> Please take a review: >>> >>> http://cr.openjdk.java.net/~weijun/7184815/webrev.00/ >>> >>> I break the config setting to Java setting and native setting, and >>> insert the reading of SCDynamicStoreConfig between the two. This should >>> preserve the 6u behavior and add a fallback to legacy config files. >>> >>> No new regression test, because of SCDynamicStoreConfig and system >>> config files, will ask SQE to create a manual test. >>> >>> Thanks >>> Max >>> >>> >>> On 07/18/2012 08:26 AM, Weijun Wang wrote: >>>> I'm not familiar with how Mac does it, but normally there are two >>>> ways a >>>> Kerberos authentication is performed, through the initial login and >>>> through kinit. The former is integrated into the system (a pam module?) >>>> and I guess in this case the config is inside SCDynamicStoreConfig. For >>>> the latter, the Kerberos clients are regarded as standalone tools and a >>>> /etc/krb5.conf is needed. >>>> >>>> Java works in both ways, if there is already a credentials cache it >>>> will >>>> happily use it. On the other hand, it also includes the Krb5LoginModule >>>> that does all the login itself. Therefore, it should read both >>>> styles of >>>> config on a Mac. >>>> >>>> I've filed a new bug, It will appear soon at >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184815 >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 07/17/2012 10:35 PM, Mike Swingler wrote: >>>>> On Jul 16, 2012, at 8:32 PM, Weijun Wang >>>>> wrote: >>>>> >>>>>> Ping again. >>>>>> >>>>>> On 07/05/2012 04:34 PM, Weijun Wang wrote: >>>>>>> Hi Scott >>>>>>> >>>>>>> On Mac since Lion, sun.security.krb5.Config tries to locate the >>>>>>> config >>>>>>> info in this order: >>>>>>> >>>>>>> 1. java.security.krb5.conf system property >>>>>>> 2. ${jre}/lib/security/krb5.conf >>>>>>> 3. SCDynamicStoreConfig >>>>>>> >>>>>>> The main difference from other platforms is that it will not try >>>>>>> config >>>>>>> files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. >>>>>>> >>>>>>> On the other hand, even /usr/bin/kinit comes with Lion reads the >>>>>>> config >>>>>>> file (if there is no SCDynamicStoreConfig setting). >>>>>>> >>>>>>> Is there a special reason for the current Java behavior? I do notice >>>>>>> that the Apple 6u33 already does this. >>>>> >>>>> No special reason I can think of, beyond simply swapping the >>>>> implementation to read from the SCDynamicStoreConfig. Java SE 6 had >>>>> previously had been relying on the system to write out a >>>>> /Library/Preferences/edu.mit.Kerberos file, but that went away with OS >>>>> X 10.7, so we didn't see much point in reading the file, since little >>>>> else on the system would be paying attention to it either for the >>>>> purposes of SSO. >>>>> >>>>> It seems perfectly reasonable that if there are no >>>>> SCDynamicStoreConfig entries, falling back to reading the legacy >>>>> config files may be a valid option. I'm actually somewhat surprised >>>>> that they are consulted by kinit. >>>>> >>>>> Regards, >>>>> Mike Swingler >>>>> Apple Inc. >>>>> >>>> >>> > From sean.mullan at oracle.com Thu Aug 9 06:53:01 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 09 Aug 2012 09:53:01 -0400 Subject: JDK 8 Code Review Request: 7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null In-Reply-To: <501FD7F9.9070207@oracle.com> References: <501FD7F9.9070207@oracle.com> Message-ID: <5023C0BD.3030709@oracle.com> I have re-worked this fix so that our PKIX CertPathValidator implementation detects if a TrustAnchor's DSA key has no parameters *before* using it to verify a signature. This is a cleaner fix, as it turns out there is quite a bit of existing code in JCE that already assumes a DSA key has parameters, and will throw an NPE if it doesn't. Please review: http://cr.openjdk.java.net/~mullan/webrevs/7187962/webrev.01/ Thanks, Sean On 8/6/12 10:43 AM, Sean Mullan wrote: > Hi Valerie, > > Could you please review this simple fix to > P11DSAKeyFactory.implTranslatePublicKey? > > http://cr.openjdk.java.net/~mullan/webrevs/7187962/webrev.00/ > > Thanks, > Sean > From xuelei.fan at oracle.com Thu Aug 9 09:04:37 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 10 Aug 2012 00:04:37 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <50231907.9080606@oracle.com> References: <50231907.9080606@oracle.com> Message-ID: <5023DF95.7040507@oracle.com> The new webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.02/ Diffs from the previous webrev: 1. changed the method names setServername->setAccessibleServerName getServername->getAccessibleServerNames setServernamePattern->setRecognizableServername getServernamePatterns->getRecognizableServernames 2. behaviors changes: set/getAccessibleServerName(s) will only make sense in client mode, and set/getRecognizableServername(s) will only make sense in server mode. Have not merge all comments from Sean, will do it tomorrow. Thanks, Xuelei On 8/9/2012 9:57 AM, Xuelei Fan wrote: > Please review the design of JEP 114, TLS Server Name Indication (SNI) > Extension. > > The webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.01/ > > The following is a list of typical user cases, and the demo code using > this spec for each case. > > > Typical user cases for client side: > > Case 1: I want to access "www.example.com" > sslParameters.setServerName("host_name", "www.example.com"); > Set the host name explicit. > > It is recommend that the client always specify the host name. > > Case 2: The server has some compatibility issues, I do not want > to use server name indication for hostname because of the compatibility > concerns. > sslParameters.setServerName("host_name", ""); > I will not use server name indication for host_name. > > Case 3: I want to access URL, "https://www.example.com". > Doing nothing, the provider default behaviors will set the hostname > for me. I don't care about what's the real server name indication. > > Note that it is the compatible behaviors of JDK 7. > > Case 4: the parameter was previously set to "www.example.com" (see > Case 1), but I want to use the provider default value. I need to remove > the previous set value. > sslParameters.setServerName("host_name", null); > > > > Typical user cases for application server side: > > Case 1: I want to accept all kind of server name indication > Doing nothing, the server will ignore the server name indication > > Case 2: I want to deny all server name indication of type host name > sslParameters.setServerName("hostname", ""); > > Case 3: I want to accept all kind of server name indication, but > previously, I have set the server name indication to other values. I > need to reset the value > sslParameters.setServerName("hostname", null); > > Case 4: I want to accept server name indication of "www.example.com". > sslParameters.setServerName("host_name", "www.example.com"); > > Case 5: I want to accept server name indication of > "www.xuelei.com", but I also have alternative names of "www.example.edu" > and "www.example.org". > sslParameters.setServerName("host_name", "www.example.com"); > sslParameters.setServernamePattern("host_name", > Pattern.compile("www\\.example\\.(edu|org)")); > > Case 6: I want to accept server name indication of > "www.example.com", and I have no alternative name. But I need to make > sure that other component does not set alternative name for me in > previous calling. > sslParameters.setServerName("host_name", "www.example.com"); > sslParameters.setServernamePattern("host_name", null); > > > Typical user cases for dispatch server: > A dispatch server is one server who parsers the server name indication, > and dispatches the connection to the right/real server on a virtual > hosting environment. > > See section 2, "The How-To and Scenarios in Example" of the README: > http://cr.openjdk.java.net./~xuelei/7068321/README > > I appreciate any feedback about the spec. > > Thanks & Regards, > Xuelei > From xueming.shen at oracle.com Thu Aug 9 10:15:49 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 09 Aug 2012 17:15:49 +0000 Subject: hg: jdk8/tl/jdk: 7189363: Regex Pattern compilation buggy for special sequences Message-ID: <20120809171612.1831D4744F@hg.openjdk.java.net> Changeset: 717ed00b7787 Author: sherman Date: 2012-08-09 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/717ed00b7787 7189363: Regex Pattern compilation buggy for special sequences Summary: fixed the incorrect implementation in expr(...) Reviewed-by: psandoz, alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java From valerie.peng at oracle.com Thu Aug 9 13:09:16 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 09 Aug 2012 13:09:16 -0700 Subject: JDK 8 Code Review Request: 7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null In-Reply-To: <5023C0BD.3030709@oracle.com> References: <501FD7F9.9070207@oracle.com> <5023C0BD.3030709@oracle.com> Message-ID: <502418EC.4090504@oracle.com> Yes, various places assume that the params being non-null since they are needed for crypto operations. I think what you have here is the right fix for the particular test failure. Do you know if Certificate.getPublicKey() is called on a certificate contains a DSA key whose DSA params should be inherited from the signing CA, will the returned DSA public key has the necessary params? Thanks, Valerie On 08/09/12 06:53, Sean Mullan wrote: > I have re-worked this fix so that our PKIX CertPathValidator implementation > detects if a TrustAnchor's DSA key has no parameters *before* using it to verify > a signature. This is a cleaner fix, as it turns out there is quite a bit of > existing code in JCE that already assumes a DSA key has parameters, and will > throw an NPE if it doesn't. > > Please review: > > http://cr.openjdk.java.net/~mullan/webrevs/7187962/webrev.01/ > > Thanks, > Sean > > On 8/6/12 10:43 AM, Sean Mullan wrote: >> Hi Valerie, >> >> Could you please review this simple fix to >> P11DSAKeyFactory.implTranslatePublicKey? >> >> http://cr.openjdk.java.net/~mullan/webrevs/7187962/webrev.00/ >> >> Thanks, >> Sean >> From sean.mullan at oracle.com Thu Aug 9 13:22:27 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 09 Aug 2012 16:22:27 -0400 Subject: JDK 8 Code Review Request: 7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null In-Reply-To: <502418EC.4090504@oracle.com> References: <501FD7F9.9070207@oracle.com> <5023C0BD.3030709@oracle.com> <502418EC.4090504@oracle.com> Message-ID: <50241C03.7000709@oracle.com> On 8/9/12 4:09 PM, Valerie (Yu-Ching) Peng wrote: > > Yes, various places assume that the params being non-null since they are > needed for crypto operations. > I think what you have here is the right fix for the particular test failure. > Do you know if Certificate.getPublicKey() is called on a certificate > contains a DSA key whose DSA params should be inherited from the signing > CA, will the returned DSA public key has the necessary params? Yes, in this case BasicChecker already has logic to check for and inherit the DSA Params from the certificate issuer's key, if necessary. It basically recreates a new DSA key with the inherited params before using it to verify a signature on the next cert in the chain. Thanks for the quick review. --Sean > > Thanks, > Valerie > > On 08/09/12 06:53, Sean Mullan wrote: >> I have re-worked this fix so that our PKIX CertPathValidator implementation >> detects if a TrustAnchor's DSA key has no parameters *before* using it to verify >> a signature. This is a cleaner fix, as it turns out there is quite a bit of >> existing code in JCE that already assumes a DSA key has parameters, and will >> throw an NPE if it doesn't. >> >> Please review: >> >> http://cr.openjdk.java.net/~mullan/webrevs/7187962/webrev.01/ >> >> Thanks, >> Sean >> >> On 8/6/12 10:43 AM, Sean Mullan wrote: >>> Hi Valerie, >>> >>> Could you please review this simple fix to >>> P11DSAKeyFactory.implTranslatePublicKey? >>> >>> http://cr.openjdk.java.net/~mullan/webrevs/7187962/webrev.00/ >>> >>> Thanks, >>> Sean >>> > From valerie.peng at oracle.com Thu Aug 9 16:18:20 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 09 Aug 2012 16:18:20 -0700 Subject: Code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <5023217E.5000308@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> <500657BF.3020107@oracle.com> <501A838D.40107@oracle.com> <50231C1F.9060104@oracle.com> <5023217E.5000308@oracle.com> Message-ID: <5024453C.7050308@oracle.com> Max, Please find my comments in line. On 08/08/12 19:33, Weijun Wang wrote: > > On 08/09/2012 10:10 AM, Valerie (Yu-Ching) Peng wrote: >> Max, >> >> The new ordering for reading the config files sounds reasonable. >> However, I have questions on scenarios where the various config files >> don't exist and the corresponding handling. >> The new impl of getJavaFileName()/getNativeFileName() return file names >> even when the file doesn't exist. >> This will lead to an IOException when loadConfigFile(String) is called. >> Is this intended? > > Yes. But this IOException will be ignored at the end of the private > constructor. This is the also the old behavior. The main purpose is > that even there is no (any kind of) krb5.conf there is still a chance > to read config from DNS etc. Ok, after re-read the old impl, I agree that the current behavior seems to match the old one. >> >> Also, the toStringIndented(...) method removed several calls which >> append the 'prefix' and made various adjustments. >> Do you have sample output using the new impl? Reading through the code, >> some don't look quite right. > > There are 2 major changes: > > 1. A string value does not starts from a newline > 2. Vectors are inside square brackets. Hmm, now I see what your new code is doing. However, it's a bit obscure and hard to understand as far as I am concerned. With the new impl, the responsibility for doing indention when printing out the String 'obj' is the caller's responsibility. When given a String 'obj', the toStringIndented(...) ignores the given prefix value, and only append the String 'obj' followed by a '\n'. Same goes for the Vector 'obj', the prefix is not used at all. Can you add additional comments to make this clear? I think it'd be good to include the syntax of your new output, so it's clear that why prefix is only used for Hashtable 'obj'. Thanks, Valerie > > For example, for a very typical krb5.conf > > [libdefaults] > default_realm = R > [realms] > R = { > kdc = k1 > kdc = k2 > } > > the old toString is > > libdefaults = { > default_realm = { > R > } > } > realms = { > R = { > kdc = { > k1 > k2 > } > } > } > > and the new output is > > { > libdefaults = { > default_realm = R > } > realms = { > R = { > kdc = [k1,k2,] > } > } > } > > Thanks > Max > > >> Thanks, >> Valerie >> >> On 08/02/12 06:41, Weijun Wang wrote: >>> Ping again. >>> >>> On 07/18/2012 02:29 PM, Weijun Wang wrote: >>>> 7184815: [macosx] Need to read Kerberos config in files >>>> >>>> Please take a review: >>>> >>>> http://cr.openjdk.java.net/~weijun/7184815/webrev.00/ >>>> >>>> I break the config setting to Java setting and native setting, and >>>> insert the reading of SCDynamicStoreConfig between the two. This >>>> should >>>> preserve the 6u behavior and add a fallback to legacy config files. >>>> >>>> No new regression test, because of SCDynamicStoreConfig and system >>>> config files, will ask SQE to create a manual test. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 07/18/2012 08:26 AM, Weijun Wang wrote: >>>>> I'm not familiar with how Mac does it, but normally there are two >>>>> ways a >>>>> Kerberos authentication is performed, through the initial login and >>>>> through kinit. The former is integrated into the system (a pam >>>>> module?) >>>>> and I guess in this case the config is inside >>>>> SCDynamicStoreConfig. For >>>>> the latter, the Kerberos clients are regarded as standalone tools >>>>> and a >>>>> /etc/krb5.conf is needed. >>>>> >>>>> Java works in both ways, if there is already a credentials cache it >>>>> will >>>>> happily use it. On the other hand, it also includes the >>>>> Krb5LoginModule >>>>> that does all the login itself. Therefore, it should read both >>>>> styles of >>>>> config on a Mac. >>>>> >>>>> I've filed a new bug, It will appear soon at >>>>> >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184815 >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 07/17/2012 10:35 PM, Mike Swingler wrote: >>>>>> On Jul 16, 2012, at 8:32 PM, Weijun Wang >>>>>> wrote: >>>>>> >>>>>>> Ping again. >>>>>>> >>>>>>> On 07/05/2012 04:34 PM, Weijun Wang wrote: >>>>>>>> Hi Scott >>>>>>>> >>>>>>>> On Mac since Lion, sun.security.krb5.Config tries to locate the >>>>>>>> config >>>>>>>> info in this order: >>>>>>>> >>>>>>>> 1. java.security.krb5.conf system property >>>>>>>> 2. ${jre}/lib/security/krb5.conf >>>>>>>> 3. SCDynamicStoreConfig >>>>>>>> >>>>>>>> The main difference from other platforms is that it will not try >>>>>>>> config >>>>>>>> files, say, /Library/Preferences/edu.mit.Kerberos or >>>>>>>> /etc/krb5.conf. >>>>>>>> >>>>>>>> On the other hand, even /usr/bin/kinit comes with Lion reads the >>>>>>>> config >>>>>>>> file (if there is no SCDynamicStoreConfig setting). >>>>>>>> >>>>>>>> Is there a special reason for the current Java behavior? I do >>>>>>>> notice >>>>>>>> that the Apple 6u33 already does this. >>>>>> >>>>>> No special reason I can think of, beyond simply swapping the >>>>>> implementation to read from the SCDynamicStoreConfig. Java SE 6 had >>>>>> previously had been relying on the system to write out a >>>>>> /Library/Preferences/edu.mit.Kerberos file, but that went away >>>>>> with OS >>>>>> X 10.7, so we didn't see much point in reading the file, since >>>>>> little >>>>>> else on the system would be paying attention to it either for the >>>>>> purposes of SSO. >>>>>> >>>>>> It seems perfectly reasonable that if there are no >>>>>> SCDynamicStoreConfig entries, falling back to reading the legacy >>>>>> config files may be a valid option. I'm actually somewhat surprised >>>>>> that they are consulted by kinit. >>>>>> >>>>>> Regards, >>>>>> Mike Swingler >>>>>> Apple Inc. >>>>>> >>>>> >>>> >> From weijun.wang at oracle.com Thu Aug 9 17:17:14 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 Aug 2012 08:17:14 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5023DF95.7040507@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> Message-ID: <5024530A.9070809@oracle.com> On 08/10/2012 12:04 AM, Xuelei Fan wrote: > The new webrev: > http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.02/ > > Diffs from the previous webrev: > 1. changed the method names > setServername->setAccessibleServerName > getServername->getAccessibleServerNames > setServernamePattern->setRecognizableServername > getServernamePatterns->getRecognizableServernames s/.etRecognizableServername/.etRecognizableServer*N*ame/ I'm glad to see the method names for client and server are different, although I'm not sure if the current names are the best. What does "accessible" mean here? Also, IMO the old name "pattern" is better. A pattern already means "ServerName*s*" so it seems the setter should be setRecognizableServerNames, but then, shall we use getRecognizableServerNameses for getter? Thanks Max > > 2. behaviors changes: > set/getAccessibleServerName(s) will only make sense in client mode, > and set/getRecognizableServername(s) will only make sense in server mode. > > Have not merge all comments from Sean, will do it tomorrow. > > Thanks, > Xuelei > > > On 8/9/2012 9:57 AM, Xuelei Fan wrote: >> Please review the design of JEP 114, TLS Server Name Indication (SNI) >> Extension. >> >> The webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.01/ >> >> The following is a list of typical user cases, and the demo code using >> this spec for each case. >> >> >> Typical user cases for client side: >> >> Case 1: I want to access "www.example.com" >> sslParameters.setServerName("host_name", "www.example.com"); >> Set the host name explicit. >> >> It is recommend that the client always specify the host name. >> >> Case 2: The server has some compatibility issues, I do not want >> to use server name indication for hostname because of the compatibility >> concerns. >> sslParameters.setServerName("host_name", ""); >> I will not use server name indication for host_name. >> >> Case 3: I want to access URL, "https://www.example.com". >> Doing nothing, the provider default behaviors will set the hostname >> for me. I don't care about what's the real server name indication. >> >> Note that it is the compatible behaviors of JDK 7. >> >> Case 4: the parameter was previously set to "www.example.com" (see >> Case 1), but I want to use the provider default value. I need to remove >> the previous set value. >> sslParameters.setServerName("host_name", null); >> >> >> >> Typical user cases for application server side: >> >> Case 1: I want to accept all kind of server name indication >> Doing nothing, the server will ignore the server name indication >> >> Case 2: I want to deny all server name indication of type host name >> sslParameters.setServerName("hostname", ""); >> >> Case 3: I want to accept all kind of server name indication, but >> previously, I have set the server name indication to other values. I >> need to reset the value >> sslParameters.setServerName("hostname", null); >> >> Case 4: I want to accept server name indication of "www.example.com". >> sslParameters.setServerName("host_name", "www.example.com"); >> >> Case 5: I want to accept server name indication of >> "www.xuelei.com", but I also have alternative names of "www.example.edu" >> and "www.example.org". >> sslParameters.setServerName("host_name", "www.example.com"); >> sslParameters.setServernamePattern("host_name", >> Pattern.compile("www\\.example\\.(edu|org)")); >> >> Case 6: I want to accept server name indication of >> "www.example.com", and I have no alternative name. But I need to make >> sure that other component does not set alternative name for me in >> previous calling. >> sslParameters.setServerName("host_name", "www.example.com"); >> sslParameters.setServernamePattern("host_name", null); >> >> >> Typical user cases for dispatch server: >> A dispatch server is one server who parsers the server name indication, >> and dispatches the connection to the right/real server on a virtual >> hosting environment. >> >> See section 2, "The How-To and Scenarios in Example" of the README: >> http://cr.openjdk.java.net./~xuelei/7068321/README >> >> I appreciate any feedback about the spec. >> >> Thanks & Regards, >> Xuelei >> > From bradford.wetmore at oracle.com Thu Aug 9 17:37:09 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 09 Aug 2012 17:37:09 -0700 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5023DF95.7040507@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> Message-ID: <502457B5.6020204@oracle.com> Hi Xuelei, I like this style much better than your earlier versions. Thanks for considering them. We should still do a little more wordsmithing, some of the passages are a little awkward. The following are mainly content questions. ExtendedSSLSession.java ======================= 91: Having the SNI acronym will help people who are specifically looking for this option. (i.e. find) Suggest updating to caps and include acronym. values of the Server Name Indication (SNI) capability. 94: "to to"->"to" 98: "of enabled server name"->"of requested server name" 99: SNI SSLParameters.java ================== One general question before we get to specifics. Your current default behavior of the SunJSSE is to add a SNI extension if we have the value available. So if we call: sslSocket = socketFactory.createSocket("www.example.com", 443); sslp = sslParameters.getSSLParameters(); will this sslParameters ever contain a map with preinstalled "host_name" set to "www.example.com", or will it be empty? I think the answer will be empty. This API is just a way to force setting the value if an implementation select an unwanted value. But here's my point. These are brand new methods. Have you considered just having the SSLSocket.getSSLParameters() return the already fully populated SNI field, that is, the SSLSocketImpl's default values are already set in the SSLParameters? That way, if someone sets value to null, then we know they don't want the provider to send SNI fields of that type. e.g. sslp = sslParameters.getSSLParameters(); // sslp has host_name already set to www.example.com sslp.setAccessibleServerName("host_name", null); this makes it less confusing in that you get rid of all that ambigious "default" discussions in your API, and the user can easily find out exactly what will be sent. Something to consider. 72: Might suggest minor rewording: // As "hostname" is the only known server name indication type, to // As "host_name" is the only known Server Name Indication (SNI) type, RFC 6066 uses "host_name" and as previously mentioned, having the SNI acronym will help people who are specifically looking for this. (i.e. find) 76: Not sure why you want/need a LinkedHashMap with only one currently defined NameType. Even if there were multiple types, I don't think that SNI requires an ordering. You also mention this in setAccessibleServerName, but not sure what purpose this serves. I'm not strongly against it, just wondering. 271: Same comment in the APIs about SNI acronym. 295: So what does value = "" mean now? Will that send a SNI extension with an empty string, or will no SNI entry be sent? If null is passed, then it's up to the provider to decide what to do, but there doesn't seem to be a way to shut off SNI like in your old proposal. 308: What kinds of things are you thinking of writing in the Additional Standard Names doc for "value"? Would it be sufficient to just say "this is the SNI hostname value"? 365: alternatice -> alternate 368: "www\\.example\\.com|www\\.example\\.org" -> "www\\.example\\.(com,org)" This is a little more illuminating of the power of these patterns. Even though you have a link to java.util.regex.Pattern in the actual API, you might also mention here in textual form that these are java.util.regex patterns, and add a @link java.util.regex. Makes it more clear where to go to learn about how to specify patterns. 379: So what does "" mean now? Will an empty string SNI extension be accepted? Or we will 379: "will not try to recognize the server name value..." I'm thinking of IETF's "WILL/SHALL/MAY" here. What do you mean by "will not try"? Do you mean that if this is null, we will not use the SNI extension of this type? Or that we could possibly try? 387: This is a pattern and not a String, so only listing setAccessibleServerName() isn't quite complete. You might also list "and also see the Pattern page for details on specifying regular expression patterns". SSLSocketFactory.java ===================== 187: I would suggest following the style in the SocketFactory page which describes the functionality differences in the various createSocket methods. A new second paragraph really should give some motivation for this method. "allow for inspection of inbound data, then provide that data to the SSLSocket's normal IO streams in the consumed variable, etc." Since you're leaving the door open for this socket being either client or server, shouldn't the API then be similar to the existing layered socket one, just including the additional InputStream here: public abstract Socket createSocket(Socket s, InputStream is, String host, int port, boolean autoClose) We might be able to glean SNI information from the host here. 171: Interesting, the existing layered createSocket doesn't mention anything about whether client or server mode, and that you must set the mode or suffer with the default. Might want to file a bug and CCC this also. 197: You're not planning to process (e.g. ServerHandshaker/ClientHandshaker.process_message) the consumed handshaking bytes immediately during the createSocket call, are you? You still need to allow the user time to set the socket options/SSLParameters/etc. I was expecting in this method you'd just suck in the consumed bytes into temporary storage, then create/return the socket, and then when the handshaking is started, you then read out from the temporary storage until you run out, then you switch to the Socket's InputStream. 197: This needs some wordsmithing here. This method will produce the SSLSocket that will be consuming this data, so of course it has to be called first. 204: This description is too implementation specific, and can probably be left out. 206: "comsumed"->"consumed" 221: this should probably have the same behavior as the other layered SSLSocket at 183: This should be an IOException. If not, then this javadoc does not describe why an IOException might be thrown. Hope this helps. We can wordsmith next week. Brad On 8/9/2012 9:04 AM, Xuelei Fan wrote: > The new webrev: > http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.02/ > > Diffs from the previous webrev: > 1. changed the method names > setServername->setAccessibleServerName > getServername->getAccessibleServerNames > setServernamePattern->setRecognizableServername > getServernamePatterns->getRecognizableServernames > > 2. behaviors changes: > set/getAccessibleServerName(s) will only make sense in client mode, > and set/getRecognizableServername(s) will only make sense in server mode. > > Have not merge all comments from Sean, will do it tomorrow. > > Thanks, > Xuelei > > > On 8/9/2012 9:57 AM, Xuelei Fan wrote: >> Please review the design of JEP 114, TLS Server Name Indication (SNI) >> Extension. >> >> The webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.01/ >> >> The following is a list of typical user cases, and the demo code using >> this spec for each case. >> >> >> Typical user cases for client side: >> >> Case 1: I want to access "www.example.com" >> sslParameters.setServerName("host_name", "www.example.com"); >> Set the host name explicit. >> >> It is recommend that the client always specify the host name. >> >> Case 2: The server has some compatibility issues, I do not want >> to use server name indication for hostname because of the compatibility >> concerns. >> sslParameters.setServerName("host_name", ""); >> I will not use server name indication for host_name. >> >> Case 3: I want to access URL, "https://www.example.com". >> Doing nothing, the provider default behaviors will set the hostname >> for me. I don't care about what's the real server name indication. >> >> Note that it is the compatible behaviors of JDK 7. >> >> Case 4: the parameter was previously set to "www.example.com" (see >> Case 1), but I want to use the provider default value. I need to remove >> the previous set value. >> sslParameters.setServerName("host_name", null); >> >> >> >> Typical user cases for application server side: >> >> Case 1: I want to accept all kind of server name indication >> Doing nothing, the server will ignore the server name indication >> >> Case 2: I want to deny all server name indication of type host name >> sslParameters.setServerName("hostname", ""); >> >> Case 3: I want to accept all kind of server name indication, but >> previously, I have set the server name indication to other values. I >> need to reset the value >> sslParameters.setServerName("hostname", null); >> >> Case 4: I want to accept server name indication of "www.example.com". >> sslParameters.setServerName("host_name", "www.example.com"); >> >> Case 5: I want to accept server name indication of >> "www.xuelei.com", but I also have alternative names of "www.example.edu" >> and "www.example.org". >> sslParameters.setServerName("host_name", "www.example.com"); >> sslParameters.setServernamePattern("host_name", >> Pattern.compile("www\\.example\\.(edu|org)")); >> >> Case 6: I want to accept server name indication of >> "www.example.com", and I have no alternative name. But I need to make >> sure that other component does not set alternative name for me in >> previous calling. >> sslParameters.setServerName("host_name", "www.example.com"); >> sslParameters.setServernamePattern("host_name", null); >> >> >> Typical user cases for dispatch server: >> A dispatch server is one server who parsers the server name indication, >> and dispatches the connection to the right/real server on a virtual >> hosting environment. >> >> See section 2, "The How-To and Scenarios in Example" of the README: >> http://cr.openjdk.java.net./~xuelei/7068321/README >> >> I appreciate any feedback about the spec. >> >> Thanks & Regards, >> Xuelei >> > From xuelei.fan at oracle.com Thu Aug 9 17:47:05 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 10 Aug 2012 08:47:05 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5024530A.9070809@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <5024530A.9070809@oracle.com> Message-ID: <50245A09.9040707@oracle.com> On 8/10/2012 8:17 AM, Weijun Wang wrote: > > > On 08/10/2012 12:04 AM, Xuelei Fan wrote: >> The new webrev: >> http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.02/ >> >> Diffs from the previous webrev: >> 1. changed the method names >> setServername->setAccessibleServerName >> getServername->getAccessibleServerNames >> setServernamePattern->setRecognizableServername >> getServernamePatterns->getRecognizableServernames > > s/.etRecognizableServername/.etRecognizableServer*N*ame/ > Good! > I'm glad to see the method names for client and server are different, > although I'm not sure if the current names are the best. What does > "accessible" mean here? I spent a lot of time to look for a word pairing with "Recognizable". I even thought about to use "Requestable". "Accessible" is not a very good word, any other suggestion? "reachable"? > Also, IMO the old name "pattern" is better. Properly. Thanks, Xuelei > A > pattern already means "ServerName*s*" so it seems the setter should be > setRecognizableServerNames, but then, shall we use > getRecognizableServerNameses for getter? > > Thanks > Max > >> >> 2. behaviors changes: >> set/getAccessibleServerName(s) will only make sense in client mode, >> and set/getRecognizableServername(s) will only make sense in server mode. >> >> Have not merge all comments from Sean, will do it tomorrow. >> >> Thanks, >> Xuelei >> >> >> On 8/9/2012 9:57 AM, Xuelei Fan wrote: >>> Please review the design of JEP 114, TLS Server Name Indication (SNI) >>> Extension. >>> >>> The webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.01/ >>> >>> The following is a list of typical user cases, and the demo code using >>> this spec for each case. >>> >>> >>> Typical user cases for client side: >>> >>> Case 1: I want to access "www.example.com" >>> sslParameters.setServerName("host_name", "www.example.com"); >>> Set the host name explicit. >>> >>> It is recommend that the client always specify the host name. >>> >>> Case 2: The server has some compatibility issues, I do not want >>> to use server name indication for hostname because of the compatibility >>> concerns. >>> sslParameters.setServerName("host_name", ""); >>> I will not use server name indication for host_name. >>> >>> Case 3: I want to access URL, "https://www.example.com". >>> Doing nothing, the provider default behaviors will set the hostname >>> for me. I don't care about what's the real server name indication. >>> >>> Note that it is the compatible behaviors of JDK 7. >>> >>> Case 4: the parameter was previously set to "www.example.com" (see >>> Case 1), but I want to use the provider default value. I need to remove >>> the previous set value. >>> sslParameters.setServerName("host_name", null); >>> >>> >>> >>> Typical user cases for application server side: >>> >>> Case 1: I want to accept all kind of server name indication >>> Doing nothing, the server will ignore the server name indication >>> >>> Case 2: I want to deny all server name indication of type host name >>> sslParameters.setServerName("hostname", ""); >>> >>> Case 3: I want to accept all kind of server name indication, but >>> previously, I have set the server name indication to other values. I >>> need to reset the value >>> sslParameters.setServerName("hostname", null); >>> >>> Case 4: I want to accept server name indication of "www.example.com". >>> sslParameters.setServerName("host_name", "www.example.com"); >>> >>> Case 5: I want to accept server name indication of >>> "www.xuelei.com", but I also have alternative names of "www.example.edu" >>> and "www.example.org". >>> sslParameters.setServerName("host_name", "www.example.com"); >>> sslParameters.setServernamePattern("host_name", >>> Pattern.compile("www\\.example\\.(edu|org)")); >>> >>> Case 6: I want to accept server name indication of >>> "www.example.com", and I have no alternative name. But I need to make >>> sure that other component does not set alternative name for me in >>> previous calling. >>> sslParameters.setServerName("host_name", "www.example.com"); >>> sslParameters.setServernamePattern("host_name", null); >>> >>> >>> Typical user cases for dispatch server: >>> A dispatch server is one server who parsers the server name indication, >>> and dispatches the connection to the right/real server on a virtual >>> hosting environment. >>> >>> See section 2, "The How-To and Scenarios in Example" of the README: >>> http://cr.openjdk.java.net./~xuelei/7068321/README >>> >>> I appreciate any feedback about the spec. >>> >>> Thanks & Regards, >>> Xuelei >>> >> From weijun.wang at oracle.com Thu Aug 9 20:51:13 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 Aug 2012 11:51:13 +0800 Subject: Code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <5024453C.7050308@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> <500657BF.3020107@oracle.com> <501A838D.40107@oracle.com> <50231C1F.9060104@oracle.com> <5023217E.5000308@oracle.com> <5024453C.7050308@oracle.com> Message-ID: <50248531.6080403@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/7184815/webrev.01/ Add comments before toString and inside toStringIndented. > With the new impl, the responsibility for doing indention when > printing out the String 'obj' is the caller's responsibility. Well, not really. The indentation is removed in the new impl because there is no more indentation now, i.e. the String is printed *inline*. Compare the old output: key = { value } to new output key = value The old impl looks like everything is a collection. In the new impl, String, Vector and Hashtable have completely different format and are easily distinguishable. Thanks Max On 08/10/2012 07:18 AM, Valerie (Yu-Ching) Peng wrote: > Max, > > Please find my comments in line. > > On 08/08/12 19:33, Weijun Wang wrote: >> >> On 08/09/2012 10:10 AM, Valerie (Yu-Ching) Peng wrote: >>> Max, >>> >>> The new ordering for reading the config files sounds reasonable. >>> However, I have questions on scenarios where the various config files >>> don't exist and the corresponding handling. >>> The new impl of getJavaFileName()/getNativeFileName() return file names >>> even when the file doesn't exist. >>> This will lead to an IOException when loadConfigFile(String) is called. >>> Is this intended? >> >> Yes. But this IOException will be ignored at the end of the private >> constructor. This is the also the old behavior. The main purpose is >> that even there is no (any kind of) krb5.conf there is still a chance >> to read config from DNS etc. > > Ok, after re-read the old impl, I agree that the current behavior seems > to match the old one. > >>> >>> Also, the toStringIndented(...) method removed several calls which >>> append the 'prefix' and made various adjustments. >>> Do you have sample output using the new impl? Reading through the code, >>> some don't look quite right. >> >> There are 2 major changes: >> >> 1. A string value does not starts from a newline >> 2. Vectors are inside square brackets. > > Hmm, now I see what your new code is doing. However, it's a bit obscure > and hard to understand as far as I am concerned. > With the new impl, the responsibility for doing indention when printing > out the String 'obj' is the caller's responsibility. > When given a String 'obj', the toStringIndented(...) ignores the given > prefix value, and only append the String 'obj' followed by a '\n'. Same > goes for the Vector 'obj', the prefix is not used at all. > Can you add additional comments to make this clear? I think it'd be good > to include the syntax of your new output, so it's clear that why prefix > is only used for Hashtable 'obj'. > > Thanks, > Valerie > >> >> For example, for a very typical krb5.conf >> >> [libdefaults] >> default_realm = R >> [realms] >> R = { >> kdc = k1 >> kdc = k2 >> } >> >> the old toString is >> >> libdefaults = { >> default_realm = { >> R >> } >> } >> realms = { >> R = { >> kdc = { >> k1 >> k2 >> } >> } >> } >> >> and the new output is >> >> { >> libdefaults = { >> default_realm = R >> } >> realms = { >> R = { >> kdc = [k1,k2,] >> } >> } >> } >> >> Thanks >> Max >> >> >>> Thanks, >>> Valerie >>> >>> On 08/02/12 06:41, Weijun Wang wrote: >>>> Ping again. >>>> >>>> On 07/18/2012 02:29 PM, Weijun Wang wrote: >>>>> 7184815: [macosx] Need to read Kerberos config in files >>>>> >>>>> Please take a review: >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7184815/webrev.00/ >>>>> >>>>> I break the config setting to Java setting and native setting, and >>>>> insert the reading of SCDynamicStoreConfig between the two. This >>>>> should >>>>> preserve the 6u behavior and add a fallback to legacy config files. >>>>> >>>>> No new regression test, because of SCDynamicStoreConfig and system >>>>> config files, will ask SQE to create a manual test. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 07/18/2012 08:26 AM, Weijun Wang wrote: >>>>>> I'm not familiar with how Mac does it, but normally there are two >>>>>> ways a >>>>>> Kerberos authentication is performed, through the initial login and >>>>>> through kinit. The former is integrated into the system (a pam >>>>>> module?) >>>>>> and I guess in this case the config is inside >>>>>> SCDynamicStoreConfig. For >>>>>> the latter, the Kerberos clients are regarded as standalone tools >>>>>> and a >>>>>> /etc/krb5.conf is needed. >>>>>> >>>>>> Java works in both ways, if there is already a credentials cache it >>>>>> will >>>>>> happily use it. On the other hand, it also includes the >>>>>> Krb5LoginModule >>>>>> that does all the login itself. Therefore, it should read both >>>>>> styles of >>>>>> config on a Mac. >>>>>> >>>>>> I've filed a new bug, It will appear soon at >>>>>> >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184815 >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> On 07/17/2012 10:35 PM, Mike Swingler wrote: >>>>>>> On Jul 16, 2012, at 8:32 PM, Weijun Wang >>>>>>> wrote: >>>>>>> >>>>>>>> Ping again. >>>>>>>> >>>>>>>> On 07/05/2012 04:34 PM, Weijun Wang wrote: >>>>>>>>> Hi Scott >>>>>>>>> >>>>>>>>> On Mac since Lion, sun.security.krb5.Config tries to locate the >>>>>>>>> config >>>>>>>>> info in this order: >>>>>>>>> >>>>>>>>> 1. java.security.krb5.conf system property >>>>>>>>> 2. ${jre}/lib/security/krb5.conf >>>>>>>>> 3. SCDynamicStoreConfig >>>>>>>>> >>>>>>>>> The main difference from other platforms is that it will not try >>>>>>>>> config >>>>>>>>> files, say, /Library/Preferences/edu.mit.Kerberos or >>>>>>>>> /etc/krb5.conf. >>>>>>>>> >>>>>>>>> On the other hand, even /usr/bin/kinit comes with Lion reads the >>>>>>>>> config >>>>>>>>> file (if there is no SCDynamicStoreConfig setting). >>>>>>>>> >>>>>>>>> Is there a special reason for the current Java behavior? I do >>>>>>>>> notice >>>>>>>>> that the Apple 6u33 already does this. >>>>>>> >>>>>>> No special reason I can think of, beyond simply swapping the >>>>>>> implementation to read from the SCDynamicStoreConfig. Java SE 6 had >>>>>>> previously had been relying on the system to write out a >>>>>>> /Library/Preferences/edu.mit.Kerberos file, but that went away >>>>>>> with OS >>>>>>> X 10.7, so we didn't see much point in reading the file, since >>>>>>> little >>>>>>> else on the system would be paying attention to it either for the >>>>>>> purposes of SSO. >>>>>>> >>>>>>> It seems perfectly reasonable that if there are no >>>>>>> SCDynamicStoreConfig entries, falling back to reading the legacy >>>>>>> config files may be a valid option. I'm actually somewhat surprised >>>>>>> that they are consulted by kinit. >>>>>>> >>>>>>> Regards, >>>>>>> Mike Swingler >>>>>>> Apple Inc. >>>>>>> >>>>>> >>>>> >>> > From sean.mullan at oracle.com Fri Aug 10 06:19:51 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 10 Aug 2012 13:19:51 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120810132030.15BD147483@hg.openjdk.java.net> Changeset: 57b5025548d6 Author: mullan Date: 2012-08-10 09:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57b5025548d6 7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null Reviewed-by: valeriep ! src/share/classes/sun/security/provider/certpath/BasicChecker.java Changeset: 629f357fc17b Author: mullan Date: 2012-08-10 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/629f357fc17b Merge From sean.mullan at oracle.com Fri Aug 10 08:13:33 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 10 Aug 2012 11:13:33 -0400 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5023DF95.7040507@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> Message-ID: <5025251D.1090503@oracle.com> On 8/9/12 12:04 PM, Xuelei Fan wrote: > The new webrev: > http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.02/ > > Diffs from the previous webrev: > 1. changed the method names > setServername->setAccessibleServerName > getServername->getAccessibleServerNames > setServernamePattern->setRecognizableServername > getServernamePatterns->getRecognizableServernames FWIW, I prefer the previous names. The terms "Accessible" and "Recognizable" are a bit awkward. I like the short, simple method names for the client side (get/setServerName) and having the Pattern name in the server method more clearly indicates that this is for matching server names. --Sean From valerie.peng at oracle.com Fri Aug 10 11:47:18 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 10 Aug 2012 11:47:18 -0700 Subject: Code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <50248531.6080403@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> <500657BF.3020107@oracle.com> <501A838D.40107@oracle.com> <50231C1F.9060104@oracle.com> <5023217E.5000308@oracle.com> <5024453C.7050308@oracle.com> <50248531.6080403@oracle.com> Message-ID: <50255736.1020202@oracle.com> I like the new format better, but the code looks confusing w/o appropriate comments explaining why prefix is only applied for one type of arguments. The old toStringIndented(...) will indent and place whatever obj arg according to prefix, but the new impl ignores the prefix except for one type of arg. This kind of usage fits your new format, but if toStringIndented(...) were to be used as an utility method for printing out Vector and String objects, then it'd be a surprise to the callers that prefix is simply ignored. In a perfect world, they should be in a separate method since they aren't "indented" using the prefix as the method name implied. But having enough comments to make it clear is sufficient for this since it's not used by other classes. The update webrev looks good. Valerie On 08/09/12 20:51, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/7184815/webrev.01/ > > Add comments before toString and inside toStringIndented. > >> With the new impl, the responsibility for doing indention when >> printing out the String 'obj' is the caller's responsibility. > > Well, not really. The indentation is removed in the new impl because > there is no more indentation now, i.e. the String is printed *inline*. > > Compare the old output: > > key = { > value > } > > to new output > > key = value > > The old impl looks like everything is a collection. In the new impl, > String, Vector and Hashtable have completely different format and are > easily distinguishable. > > Thanks > Max > > On 08/10/2012 07:18 AM, Valerie (Yu-Ching) Peng wrote: >> Max, >> >> Please find my comments in line. >> >> On 08/08/12 19:33, Weijun Wang wrote: >>> >>> On 08/09/2012 10:10 AM, Valerie (Yu-Ching) Peng wrote: >>>> Max, >>>> >>>> The new ordering for reading the config files sounds reasonable. >>>> However, I have questions on scenarios where the various config files >>>> don't exist and the corresponding handling. >>>> The new impl of getJavaFileName()/getNativeFileName() return file >>>> names >>>> even when the file doesn't exist. >>>> This will lead to an IOException when loadConfigFile(String) is >>>> called. >>>> Is this intended? >>> >>> Yes. But this IOException will be ignored at the end of the private >>> constructor. This is the also the old behavior. The main purpose is >>> that even there is no (any kind of) krb5.conf there is still a chance >>> to read config from DNS etc. >> >> Ok, after re-read the old impl, I agree that the current behavior seems >> to match the old one. >> >>>> >>>> Also, the toStringIndented(...) method removed several calls which >>>> append the 'prefix' and made various adjustments. >>>> Do you have sample output using the new impl? Reading through the >>>> code, >>>> some don't look quite right. >>> >>> There are 2 major changes: >>> >>> 1. A string value does not starts from a newline >>> 2. Vectors are inside square brackets. >> >> Hmm, now I see what your new code is doing. However, it's a bit obscure >> and hard to understand as far as I am concerned. >> With the new impl, the responsibility for doing indention when printing >> out the String 'obj' is the caller's responsibility. >> When given a String 'obj', the toStringIndented(...) ignores the given >> prefix value, and only append the String 'obj' followed by a '\n'. Same >> goes for the Vector 'obj', the prefix is not used at all. >> Can you add additional comments to make this clear? I think it'd be good >> to include the syntax of your new output, so it's clear that why prefix >> is only used for Hashtable 'obj'. >> >> Thanks, >> Valerie >> >>> >>> For example, for a very typical krb5.conf >>> >>> [libdefaults] >>> default_realm = R >>> [realms] >>> R = { >>> kdc = k1 >>> kdc = k2 >>> } >>> >>> the old toString is >>> >>> libdefaults = { >>> default_realm = { >>> R >>> } >>> } >>> realms = { >>> R = { >>> kdc = { >>> k1 >>> k2 >>> } >>> } >>> } >>> >>> and the new output is >>> >>> { >>> libdefaults = { >>> default_realm = R >>> } >>> realms = { >>> R = { >>> kdc = [k1,k2,] >>> } >>> } >>> } >>> >>> Thanks >>> Max >>> >>> >>>> Thanks, >>>> Valerie >>>> >>>> On 08/02/12 06:41, Weijun Wang wrote: >>>>> Ping again. >>>>> >>>>> On 07/18/2012 02:29 PM, Weijun Wang wrote: >>>>>> 7184815: [macosx] Need to read Kerberos config in files >>>>>> >>>>>> Please take a review: >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/7184815/webrev.00/ >>>>>> >>>>>> I break the config setting to Java setting and native setting, and >>>>>> insert the reading of SCDynamicStoreConfig between the two. This >>>>>> should >>>>>> preserve the 6u behavior and add a fallback to legacy config files. >>>>>> >>>>>> No new regression test, because of SCDynamicStoreConfig and system >>>>>> config files, will ask SQE to create a manual test. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> On 07/18/2012 08:26 AM, Weijun Wang wrote: >>>>>>> I'm not familiar with how Mac does it, but normally there are two >>>>>>> ways a >>>>>>> Kerberos authentication is performed, through the initial login and >>>>>>> through kinit. The former is integrated into the system (a pam >>>>>>> module?) >>>>>>> and I guess in this case the config is inside >>>>>>> SCDynamicStoreConfig. For >>>>>>> the latter, the Kerberos clients are regarded as standalone tools >>>>>>> and a >>>>>>> /etc/krb5.conf is needed. >>>>>>> >>>>>>> Java works in both ways, if there is already a credentials cache it >>>>>>> will >>>>>>> happily use it. On the other hand, it also includes the >>>>>>> Krb5LoginModule >>>>>>> that does all the login itself. Therefore, it should read both >>>>>>> styles of >>>>>>> config on a Mac. >>>>>>> >>>>>>> I've filed a new bug, It will appear soon at >>>>>>> >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184815 >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> On 07/17/2012 10:35 PM, Mike Swingler wrote: >>>>>>>> On Jul 16, 2012, at 8:32 PM, Weijun Wang >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ping again. >>>>>>>>> >>>>>>>>> On 07/05/2012 04:34 PM, Weijun Wang wrote: >>>>>>>>>> Hi Scott >>>>>>>>>> >>>>>>>>>> On Mac since Lion, sun.security.krb5.Config tries to locate the >>>>>>>>>> config >>>>>>>>>> info in this order: >>>>>>>>>> >>>>>>>>>> 1. java.security.krb5.conf system property >>>>>>>>>> 2. ${jre}/lib/security/krb5.conf >>>>>>>>>> 3. SCDynamicStoreConfig >>>>>>>>>> >>>>>>>>>> The main difference from other platforms is that it will not try >>>>>>>>>> config >>>>>>>>>> files, say, /Library/Preferences/edu.mit.Kerberos or >>>>>>>>>> /etc/krb5.conf. >>>>>>>>>> >>>>>>>>>> On the other hand, even /usr/bin/kinit comes with Lion reads the >>>>>>>>>> config >>>>>>>>>> file (if there is no SCDynamicStoreConfig setting). >>>>>>>>>> >>>>>>>>>> Is there a special reason for the current Java behavior? I do >>>>>>>>>> notice >>>>>>>>>> that the Apple 6u33 already does this. >>>>>>>> >>>>>>>> No special reason I can think of, beyond simply swapping the >>>>>>>> implementation to read from the SCDynamicStoreConfig. Java SE 6 >>>>>>>> had >>>>>>>> previously had been relying on the system to write out a >>>>>>>> /Library/Preferences/edu.mit.Kerberos file, but that went away >>>>>>>> with OS >>>>>>>> X 10.7, so we didn't see much point in reading the file, since >>>>>>>> little >>>>>>>> else on the system would be paying attention to it either for the >>>>>>>> purposes of SSO. >>>>>>>> >>>>>>>> It seems perfectly reasonable that if there are no >>>>>>>> SCDynamicStoreConfig entries, falling back to reading the legacy >>>>>>>> config files may be a valid option. I'm actually somewhat >>>>>>>> surprised >>>>>>>> that they are consulted by kinit. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Mike Swingler >>>>>>>> Apple Inc. >>>>>>>> >>>>>>> >>>>>> >>>> >> From valerie.peng at oracle.com Fri Aug 10 13:11:14 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 10 Aug 2012 20:11:14 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120810201145.E123447493@hg.openjdk.java.net> Changeset: 114fbbeb8f75 Author: valeriep Date: 2012-08-10 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/114fbbeb8f75 7107613: scalability bloker in javax.crypto.CryptoPermissions Summary: Changed the type of field "perms" from Hashtable to ConcurrentHashMap. Reviewed-by: weijun, xuelei ! src/share/classes/javax/crypto/CryptoPermissions.java Changeset: 175036ada2e3 Author: valeriep Date: 2012-08-10 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/175036ada2e3 7107616: scalability bloker in javax.crypto.JceSecurityManager Summary: Changed the type of field "exemptCache" from HashMap to ConcurrentHashMap. Reviewed-by: weijun, xuelei ! src/share/classes/javax/crypto/JceSecurityManager.java Changeset: 9e97dacbfd35 Author: valeriep Date: 2012-08-10 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e97dacbfd35 7185471: Avoid key expansion when AES cipher is re-init w/ the same key Summary: Saved the last cipher key value and skip key expansion if key value is the same. Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/crypto/provider/AESCrypt.java From lana.steuck at oracle.com Fri Aug 10 14:01:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:07 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b51 for changeset 57c0aee73090 Message-ID: <20120810210107.E226347494@hg.openjdk.java.net> Changeset: 8d24def5ceb3 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8d24def5ceb3 Added tag jdk8-b51 for changeset 57c0aee73090 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:01:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:07 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b51 for changeset 9b0f841ca9f7 Message-ID: <20120810210111.8CE8547495@hg.openjdk.java.net> Changeset: 80689ff9cb49 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/80689ff9cb49 Added tag jdk8-b51 for changeset 9b0f841ca9f7 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:01:09 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:09 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b51 for changeset 1a70b6333ebe Message-ID: <20120810210118.0A27C47496@hg.openjdk.java.net> Changeset: f62bc618122e Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f62bc618122e Added tag jdk8-b51 for changeset 1a70b6333ebe ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:01:14 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:14 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20120810210121.DBA8347497@hg.openjdk.java.net> Changeset: 23032c78b2d1 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/23032c78b2d1 Added tag jdk8-b51 for changeset c4cd4cab2220 ! .hgtags Changeset: 1d2db0e5eabc Author: lana Date: 2012-08-10 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1d2db0e5eabc Merge From lana.steuck at oracle.com Fri Aug 10 14:01:21 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:21 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b51 for changeset dc1ea77ed9d9 Message-ID: <20120810210129.0D22B47498@hg.openjdk.java.net> Changeset: bd3c00d57614 Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bd3c00d57614 Added tag jdk8-b51 for changeset dc1ea77ed9d9 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:01:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:12 +0000 Subject: hg: jdk8/tl/hotspot: 15 new changesets Message-ID: <20120810210149.78C0C47499@hg.openjdk.java.net> Changeset: 86a687be3f02 Author: amurillo Date: 2012-07-27 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86a687be3f02 7187463: new hotspot build - hs24-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 594dff5e3c2e Author: johnc Date: 2012-07-17 11:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/594dff5e3c2e 7173712: G1: Duplicated code in G1UpdateRSOrPushRefOopClosure::do_oop_nv() Summary: Duplicated code from G1RemSet::par_write_ref() inlined into G1UpdateRSOrPushRefOopClosure::do_oop_nv() was showing up in profiles with a fairly high amount of CPU time. Manually inline the main part of G1RemSet::par_write_ref() to eliminate the code duplication. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: d42fe3c3001d Author: johnc Date: 2012-07-17 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d42fe3c3001d 7184772: G1: Incorrect assert in HeapRegionLinkedList::add_as_head() Summary: Assertion incorrectly checks that _head is NULL and should be checking that _tail is NULL instead. Reviewed-by: johnc Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp Changeset: db823a892a55 Author: johnc Date: 2012-07-17 12:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db823a892a55 7182260: G1: Fine grain RSet freeing bottleneck Summary: Chain the fine grain PerRegionTables in an individual RSet together and free them in bulk using a single operation. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: a2f7274eb6ef Author: tonyp Date: 2012-07-19 15:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a2f7274eb6ef 7114678: G1: various small fixes, code cleanup, and refactoring Summary: Various cleanups as a prelude to introducing iterators for HeapRegions. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp Changeset: 113f4c73df61 Author: jmasa Date: 2012-07-24 14:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/113f4c73df61 Merge Changeset: 3080f4743cf2 Author: jmasa Date: 2012-07-26 23:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3080f4743cf2 Merge Changeset: ff58dfd5b977 Author: jmasa Date: 2012-07-27 21:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff58dfd5b977 Merge Changeset: 3b01d0321dfa Author: zgu Date: 2012-07-30 10:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b01d0321dfa 7186778: MachO decoder implementation for MacOSX Summary: Implementation of decoder for Apple's MacOSX. The implementation is based on the patch provided by Kevin Walls. Reviewed-by: coleenp, kamg, kevinw ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp Changeset: 4bfef6df8881 Author: zgu Date: 2012-07-30 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4bfef6df8881 Merge Changeset: 5e2dc722e70d Author: andrew Date: 2012-07-31 16:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e2dc722e70d 7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 Summary: Templates need this object if not using template parameter in call Reviewed-by: coleenp, kamg, dholmes ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: e37a5219e297 Author: dcubed Date: 2012-07-31 18:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e37a5219e297 Merge Changeset: 3b3ad1642970 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b3ad1642970 Merge Changeset: 663fc23da8d5 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/663fc23da8d5 Added tag hs24-b19 for changeset 3b3ad1642970 ! .hgtags Changeset: abc951e44e1b Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/abc951e44e1b Added tag jdk8-b51 for changeset 663fc23da8d5 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:01:25 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:25 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20120810210210.96A404749A@hg.openjdk.java.net> Changeset: b3b0d75cb117 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3b0d75cb117 Added tag jdk8-b51 for changeset e865efbc7105 ! .hgtags Changeset: da8649489aff Author: lana Date: 2012-08-10 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da8649489aff Merge Changeset: 449c17c7a63a Author: lana Date: 2012-08-10 12:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/449c17c7a63a Merge Changeset: e8b14276d434 Author: lana Date: 2012-08-10 14:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8b14276d434 Merge From dmitry.samersoff at oracle.com Thu Aug 9 03:53:29 2012 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Thu, 09 Aug 2012 10:53:29 +0000 Subject: hg: jdk8/tl/jdk: 7183753: [TEST] Some colon in the diff for this test Message-ID: <20120809105414.95DC44744A@hg.openjdk.java.net> Changeset: bf85c3ab2637 Author: dsamersoff Date: 2012-08-09 14:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf85c3ab2637 7183753: [TEST] Some colon in the diff for this test Summary: Reference output file contains extra colon Reviewed-by: sspitsyn, mgronlun ! test/sun/tools/jcmd/help_help.out From xuelei.fan at oracle.com Sun Aug 12 05:50:46 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 12 Aug 2012 20:50:46 +0800 Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension Message-ID: <5027A6A6.9080702@oracle.com> Hi, Please review the spec of JEP 114, TLS Server Name Indication (SNI) Extension. http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ Please read the README to help you understanding the the specification: http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt The major differences comparing with previous webrev are: 1. client mode and server mode will use separated API set. For client, the related APIs are: setServerName(String type, String value) clearServerName(String type) disableServerName(String type) enableServerName(String type) isDisabledServerName(String type) getServerNames() For server side, the related APIs are: setServerNamePattern(String type, Pattern pattern) clearServerNamePattern(String type) getServerNamePatterns() 2. close the door to use the generated socket in client mode. SSLSocketFactory.createSocket(Socket s, InputStream consumed, boolean autoClose) The returned socket was set in server mode. Regards, Xuelei From xuelei.fan at oracle.com Sun Aug 12 05:52:16 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 12 Aug 2012 20:52:16 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5025251D.1090503@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <5025251D.1090503@oracle.com> Message-ID: <5027A700.4030800@oracle.com> On 8/10/2012 11:13 PM, Sean Mullan wrote: > On 8/9/12 12:04 PM, Xuelei Fan wrote: >> The new webrev: >> http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.02/ >> >> Diffs from the previous webrev: >> 1. changed the method names >> setServername->setAccessibleServerName >> getServername->getAccessibleServerNames >> setServernamePattern->setRecognizableServername >> getServernamePatterns->getRecognizableServernames > > FWIW, I prefer the previous names. The terms "Accessible" and "Recognizable" are > a bit awkward. I like the short, simple method names for the client side > (get/setServerName) and having the Pattern name in the server method more > clearly indicates that this is for matching server names. > OK, It's 2:2 now. Sean and I prefer to previous names; Brad and Weijun prefer other names. I revised to use the previous names. I can change it to some better names if we have better proposals. See the revised the APIs: http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ Xuelei > --Sean > From xuelei.fan at oracle.com Sun Aug 12 05:52:34 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 12 Aug 2012 20:52:34 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502457B5.6020204@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> Message-ID: <5027A712.9080105@oracle.com> I revised the APIs to separate the differnt server name values and will send it in another thread. http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt Only reply on those items we may have different opinions. On 8/10/2012 8:37 AM, Brad Wetmore wrote: > > SSLParameters.java > ================== > > One general question before we get to specifics. Your current default > behavior of the SunJSSE is to add a SNI extension if we have the value > available. So if we call: > > sslSocket = socketFactory.createSocket("www.example.com", 443); > sslp = sslParameters.getSSLParameters(); > > will this sslParameters ever contain a map with preinstalled "host_name" > set to "www.example.com", or will it be empty? I think the answer will > be empty. This API is just a way to force setting the value if an > implementation select an unwanted value. > No, it is not empty. The default value will appear in the SSLParameters in my prototype implementation. But that's an interesting topic to discuss as there are a few concerns I have to consider when I design the APIs. There are public SSLParameters constructors. As means that an instance of SSLParameters is not always got from a SSLSocket or SSLEngine instance. Then we are not always able to have the *default* value of an instance of SSLSocket/SSLEngine into SSLParameters if it is not bound to SSLSocket/SSLEngine. So we still need to discuss about how the user specified values work with the default ones. SSLParameters sslParameters = new SSLParameters(); ... sslSocket.setSSLParameters(sslParameters); > 76: Not sure why you want/need a LinkedHashMap with only one currently > defined NameType. Even if there were multiple types, I don't think that > SNI requires an ordering. You also mention this in > setAccessibleServerName, but not sure what purpose this serves. I'm not > strongly against it, just wondering. > I am also not sure about the strong desire that the SNI should be ordered. But Weijun prefers it to be ordered because he think the SNI in RFC6066 is defined as an ordered sequence. struct { ServerName server_name_list<1..2^16-1> } ServerNameList; > 295: So what does value = "" mean now? Will that send a SNI extension > with an empty string, or will no SNI entry be sent? If null is passed, > then it's up to the provider to decide what to do, but there doesn't > seem to be a way to shut off SNI like in your old proposal. > The APIs was revised. But even in the new APIs, it is still a concern. According to the spec of host_name, a string length of a hostname should be greater than 1: opaque HostName<1..2^16-1>; The SSLParameters will not check the validity of the value. The checking will be checked later during handshaking. With the revised APIs, empty string is not valid. An exception will be thrown during the preparing of SNI extension. > 308: What kinds of things are you thinking of writing in the Additional > Standard Names doc for "value"? > That was a hot discussion, I think we had talked about it a lot. This API is not necessary to be forward compatibility with new name type of server name indication. We may be able to use subclasses of "ServerName" class, or ServerNameType enum for SSLParameters. As will make the methods look straightforward. For example: sslParameters.setServerName(ServerName); or: sslParameters.setServerName(ServerNameType.HOST_NAME, "www.example.com"); But we lose the flexibility to support new defined server name type in the future if we don't define new APIs. For example, when IETF defines a new server name type, "cert_principal", we would have to add a new subclass of ServerName to represent "cert_principal", or extend the ServerNameType with more enum items. Otherwise, we cannot support "cert_principal". It's not the biggest concerns of mine. Although it is not that flexible, but we still can extend the APIs in the future. My biggest concerns is that we need the forward compatibility in ExtendedSSLSession.getRequestedServerNames(): public Map getRequestedServerNames(); We need to be able to parser unknown server name types in server mode. Otherwise, we are not able to get the requested server names. Even we have to use the string-type-and-string-value style in ExtendedSSLSession, I want to keep it consistent in SSLParameters, rather than define new "ServerName" class or "ServerNameType" enum. I think that's also the traditional approach in JSSE to make forward compatibility, e.g, the TLS protocols, the cipher suites, etc. > Would it be sufficient to just say "this is the SNI hostname value"? See above, not all values are for host_name. The value format may be different, we need to describe the format in an additional doc. > Even though you have a link to java.util.regex.Pattern in the actual > API, you might also mention here in textual form that these are > java.util.regex patterns, and add a @link java.util.regex. Makes it > more clear where to go to learn about how to specify patterns. > > 387: This is a pattern and not a String, so only listing > setAccessibleServerName() isn't quite complete. You might also list > "and also see the Pattern page for details on specifying regular > expression patterns". IMHO, I did not see strong necessary of the description. The parameter is not a string regular expression, it is an instance of Pattern. When one want to use the Pattern class, definitely, he knows it an instance related java.util.regex patterns. It is a pattern and not a string, why we should describe the string regular expression here? > 379: So what does "" mean now? Will an empty string SNI extension be > accepted? Or we will > See aove, empty string ("") is invalid, the application will run into exception during handshaking for empty string hostname. > > SSLSocketFactory.java > ===================== > > Since you're leaving the door open for this socket being either client > or server, shouldn't the API then be similar to the existing layered > socket one, just including the additional InputStream here: > > public abstract Socket createSocket(Socket s, InputStream is, > String host, int port, boolean autoClose) > > We might be able to glean SNI information from the host here. > To make it more straightforward, I closed the door for this socket being in client mode in the revised APIs. > 171: Interesting, the existing layered createSocket doesn't mention > anything about whether client or server mode, and that you must set the > mode or suffer with the default. Might want to file a bug and CCC this > also. > Not really need the description of the mode. The existing description has already implied that the return socket must be in client mode. * @param host the server host * @param port the server port * @return a socket connected to the specified host and port > 197: You're not planning to process (e.g. > ServerHandshaker/ClientHandshaker.process_message) the consumed > handshaking bytes immediately during the createSocket call, are you? You > still need to allow the user time to set the socket > options/SSLParameters/etc. I was expecting in this method you'd just > suck in the consumed bytes into temporary storage, then create/return > the socket, and then when the handshaking is started, you then read out > from the temporary storage until you run out, then you switch to the > Socket's InputStream. > You're right. It is allowed to set more options in the returned socket before kick off handshake. > 197: This needs some wordsmithing here. This method will produce the > SSLSocket that will be consuming this data, so of course it has to be > called first. > I'm not sure I understand your point. Please comment it again with the revised APIs if you still have concerns. Thanks, Xuelei From chris.hegarty at oracle.com Sun Aug 12 14:57:58 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 12 Aug 2012 21:57:58 +0000 Subject: hg: jdk8/tl/jdk: 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c Message-ID: <20120812215828.DDB64474C8@hg.openjdk.java.net> Changeset: e7d125f2575b Author: chegar Date: 2012-08-12 22:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7d125f2575b 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c Reviewed-by: chegar Contributed-by: Christian Schulte ! src/share/classes/sun/net/spi/DefaultProxySelector.java + test/java/net/ProxySelector/MultiThreadedSystemProxies.java From weijun.wang at oracle.com Sun Aug 12 20:34:37 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 12 Aug 2012 20:34:37 -0700 (PDT) Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension Message-ID: ExtendedSSLSession.java: + * @return a non-null immutable map of requested server name types and + * values of the SNI capability, may be empty if the capability + * is not available. The iteration ordering of the map is the same + * as that in the requested server name indication. Does "capability is not available" mean the client has not sent the extension? SSLParameters.java: Do you want to explicitly point out that the vendor-defined value will not show in the map? 289 * whenever the server can be located by a supported name type. Maybe "determined for a supported name type"? 291 * For example, in the following exampless, How about simply "In the following examples,"? 459 * 
 460      *     sslParameters.setServerNamePattern("host_name",
 461      *         Pattern.compile("*\\.example\\.com"));
 462      *
463 * means that the server can serve as any hostname in the example.com 464 * domain. Do you mean ".*\\.example\\.com"? 511 * If a server name type is not contained in the returned Map, 512 * an SSL/TLS handshaking should not be interrupted for reasons of 513 * unrecognized server name of that type. Is this only Oracle JSSE behavior? Or every vendor should do that? Of course, I have no good idea how a server can get a default pattern. SSLSocketFactory.java: 191 * This constructor is normally used to enable SSL/TLS transactions over 192 * an existing server acceped socket. The returned socket was set to use 193 * server mode when handshaking (see 194 * {@link SSLSocket#setUseClientMode(boolean)}). s/acceped/accepted/. And, what does "was" mean here? 196 * The consumed data may be used for inspection of inbound 197 * network data, for example, inspection of Server Name Indication (SNI) 198 * (See section 3 of TLS 199 * Extensions (RFC6066)). In this contruction, the 200 * consumed inbound network data is provided to the returned 201 * socket's normal I/O streams. s/contruction/constructor/. I know what you mean but the words are a little strange. Also, maybe you need to mention consumed right in the first line of the method spec. That's why this method is special. 202 *

203 * Please NOTE that the application is responsible for ensuring that this 204 * method must be called before any handshaking occurs, and all 205 * consumed network data must be resumable from the consumed 206 * parameter. Otherwise, the behavior of the returned socket is not 207 * defined. I think the precise meaning of "any handshaking occurs" is "any bytes is sent back to client"? Thanks Max ----- Original Message ----- From: xuelei.fan at oracle.com To: security-dev at openjdk.java.net Sent: Sunday, August 12, 2012 8:51:39 PM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension Hi, Please review the spec of JEP 114, TLS Server Name Indication (SNI) Extension. http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ Please read the README to help you understanding the the specification: http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt The major differences comparing with previous webrev are: 1. client mode and server mode will use separated API set. For client, the related APIs are: setServerName(String type, String value) clearServerName(String type) disableServerName(String type) enableServerName(String type) isDisabledServerName(String type) getServerNames() For server side, the related APIs are: setServerNamePattern(String type, Pattern pattern) clearServerNamePattern(String type) getServerNamePatterns() 2. close the door to use the generated socket in client mode. SSLSocketFactory.createSocket(Socket s, InputStream consumed, boolean autoClose) The returned socket was set in server mode. Regards, Xuelei From xuelei.fan at oracle.com Mon Aug 13 02:25:21 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 13 Aug 2012 17:25:21 +0800 Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: References: Message-ID: <5028C801.8040301@oracle.com> On 8/13/2012 11:34 AM, Weijun Wang wrote: > 511 * If a server name type is not contained in the returned Map, > 512 * an SSL/TLS handshaking should not be interrupted for reasons of > 513 * unrecognized server name of that type. > > Is this only Oracle JSSE behavior? Or every vendor should do that? Of course, I have no good idea how a server can get a default pattern. > It's the required behavior for all providers. According to TLS extensions spec, a server run into unknown extensions, it should ignore the extension and continue the transactions. And for compatibilities, a server also should ignore the SNI extension. So I would like it to be a behavior of all providers. > SSLSocketFactory.java: > 202 *

> 203 * Please NOTE that the application is responsible for ensuring that this > 204 * method must be called before any handshaking occurs, and all > 205 * consumed network data must be resumable from the consumed > 206 * parameter. Otherwise, the behavior of the returned socket is not > 207 * defined. > > I think the precise meaning of "any handshaking occurs" is "any bytes is sent back to client"? > Yes, I will do dome word smithing here. Thanks, Xuelei From vincent.x.ryan at oracle.com Mon Aug 13 03:39:17 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 13 Aug 2012 11:39:17 +0100 Subject: Code review request: 7190945: pkcs11 problem loading NSS libs on Ubuntu Message-ID: <5028D955.4070609@oracle.com> Please review these changes to correct a problem loading Mozilla NSS on multi-arch Ubuntu: http://cr.openjdk.java.net/~vinnie/7190945/webrev.00/ Thanks. From xuelei.fan at oracle.com Mon Aug 13 03:44:03 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 13 Aug 2012 18:44:03 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5027A712.9080105@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> Message-ID: <5028DA73.1060608@oracle.com> On 8/12/2012 8:52 PM, Xuelei Fan wrote: >> SSLParameters.java >> > ================== >> > >> > One general question before we get to specifics. Your current default >> > behavior of the SunJSSE is to add a SNI extension if we have the value >> > available. So if we call: >> > >> > sslSocket = socketFactory.createSocket("www.example.com", 443); >> > sslp = sslParameters.getSSLParameters(); >> > >> > will this sslParameters ever contain a map with preinstalled "host_name" >> > set to "www.example.com", or will it be empty? I think the answer will >> > be empty. This API is just a way to force setting the value if an >> > implementation select an unwanted value. >> > > No, it is not empty. The default value will appear in the SSLParameters > in my prototype implementation. > Thought more about the design, I would have to say that we cannot return the default value in sslParameters.getServerNames(). Otherwise, the following two block of codes look very weird to me: // case one: 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); 2 sslParameters.clearServerName("host_name"); 3 Map names = sslParameters.getServerNames(); 4 sslSocket.setSSLParameters(sslParameters); 5 sslParameters = sslSocket.getSSLParameters(); 6 names = sslParameters.getServerNames(); In line 3, the returned map does not contain "host_name" entry. But in line 6, it may be expected that no "host_name" in the returned map. But if we want to return default values, line 6 do need to return a map containing "host_name". The behavior is pretty confusing. We may want to try avoid the confusion. And there are similar concerns at line 4 and 7 in the 2nd case: // case two: 1 SSLparameters sslParameters = new SSLParameters(); 2 sslParameters.setServerName("host_name", "www.example.com"); 3 sslParameters.clearServerName("host_name"); 4 Map names = sslParameters.getServerNames(); 5 sslSocket.setSSLParameters(sslParameters); 6 sslParameters = sslSocket.getSSLParameters(); 7 names = sslParameters.getServerNames(); I will describe it explicit in the spec that the default values will not show in the map. Xuelei > But that's an interesting topic to discuss as there are a few concerns I > have to consider when I design the APIs. > > There are public SSLParameters constructors. As means that an instance > of SSLParameters is not always got from a SSLSocket or SSLEngine > instance. Then we are not always able to have the *default* value of an > instance of SSLSocket/SSLEngine into SSLParameters if it is not bound to > SSLSocket/SSLEngine. So we still need to discuss about how the user > specified values work with the default ones. > > SSLParameters sslParameters = new SSLParameters(); > ... > sslSocket.setSSLParameters(sslParameters); > From xuelei.fan at oracle.com Mon Aug 13 04:31:08 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 13 Aug 2012 19:31:08 +0800 Subject: Code review request: 7190945: pkcs11 problem loading NSS libs on Ubuntu In-Reply-To: <5028D955.4070609@oracle.com> References: <5028D955.4070609@oracle.com> Message-ID: <5028E57C.7010307@oracle.com> Looks fine to me. A very very minor comment about the potential exception. Before the update, if the NSS libraries was not found, I think the exception may looks like: java.io.FileNotFoundException: /usr/lib/libnss3.so But with this update, I think it may looks like: java.io.FileNotFoundException: /usr/lib/nss/libnss3.so I would like the fore as "/usr/lib" is the normal location of a lib file. I was wondering, can we just fail back to the normal case if the library in Unbuntu does not exist. 410 File libraryFile = new File(libraryDir, libraryName); 411 if (!libraryFile.isFile()) { 412 File failover = new File(libraryDir, "nss/" + libraryName); + if (failover.isFile()) { + libraryFile = failover; + } 413 } 414 this.libraryName = libraryFile.getPath(); It is pretty trivial suggestion, I'm OK with your current fix. Xuelei On 8/13/2012 6:39 PM, Vincent Ryan wrote: > Please review these changes to correct a problem loading Mozilla NSS > on multi-arch Ubuntu: > > http://cr.openjdk.java.net/~vinnie/7190945/webrev.00/ > > Thanks. From luchsh at linux.vnet.ibm.com Mon Aug 13 04:52:47 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Mon, 13 Aug 2012 11:52:47 +0000 Subject: hg: jdk8/tl/jdk: 7190219: (bf) CharBuffer.put(String, int, int) modifies position even if BufferOverflowException thrown Message-ID: <20120813115315.AA9ED474D7@hg.openjdk.java.net> Changeset: bf0c6f91bc22 Author: luchsh Date: 2012-08-13 19:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf0c6f91bc22 7190219: (bf) CharBuffer.put(String,int,int) modifies position even if BufferOverflowException thrown Reviewed-by: alanb ! src/share/classes/java/nio/X-Buffer.java.template ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java From chris.hegarty at oracle.com Mon Aug 13 05:42:04 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 13 Aug 2012 12:42:04 +0000 Subject: hg: jdk8/tl/jdk: 7190254: NetworkInterface getFlags implementation should support full integer bit range for flags value Message-ID: <20120813124227.27CDB474DB@hg.openjdk.java.net> Changeset: 399c2adf3ad6 Author: chegar Date: 2012-08-13 13:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/399c2adf3ad6 7190254: NetworkInterface getFlags implementation should support full integer bit range for flags value Reviewed-by: chegar Contributed-by: Shirish Kuncolienkar ! src/solaris/native/java/net/NetworkInterface.c From vincent.x.ryan at oracle.com Mon Aug 13 06:13:18 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 13 Aug 2012 13:13:18 +0000 Subject: hg: jdk8/tl/jdk: 7190945: pkcs11 problem loading NSS libs on Ubuntu Message-ID: <20120813131337.54712474DD@hg.openjdk.java.net> Changeset: 5e5bdfd18325 Author: vinnie Date: 2012-08-13 14:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e5bdfd18325 7190945: pkcs11 problem loading NSS libs on Ubuntu Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/pkcs11/Secmod.java ! test/sun/security/pkcs11/PKCS11Test.java ! test/sun/security/pkcs11/Secmod/keystore.jks From vincent.x.ryan at oracle.com Mon Aug 13 06:34:15 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 13 Aug 2012 14:34:15 +0100 Subject: Code review request: 7190945: pkcs11 problem loading NSS libs on Ubuntu In-Reply-To: <5028E57C.7010307@oracle.com> References: <5028D955.4070609@oracle.com> <5028E57C.7010307@oracle.com> Message-ID: <50290257.2090106@oracle.com> Thanks. I've corrected the path as you suggest. On 08/13/12 12:31 PM, Xuelei Fan wrote: > Looks fine to me. > > A very very minor comment about the potential exception. Before the > update, if the NSS libraries was not found, I think the exception may > looks like: > java.io.FileNotFoundException: /usr/lib/libnss3.so > > But with this update, I think it may looks like: > java.io.FileNotFoundException: /usr/lib/nss/libnss3.so > > I would like the fore as "/usr/lib" is the normal location of a lib > file. I was wondering, can we just fail back to the normal case if the > library in Unbuntu does not exist. > > 410 File libraryFile = new File(libraryDir, libraryName); > 411 if (!libraryFile.isFile()) { > 412 File failover = new File(libraryDir, > "nss/" + libraryName); > + if (failover.isFile()) { > + libraryFile = failover; > + } > 413 } > 414 this.libraryName = libraryFile.getPath(); > > It is pretty trivial suggestion, I'm OK with your current fix. > > Xuelei > > On 8/13/2012 6:39 PM, Vincent Ryan wrote: >> Please review these changes to correct a problem loading Mozilla NSS >> on multi-arch Ubuntu: >> >> http://cr.openjdk.java.net/~vinnie/7190945/webrev.00/ >> >> Thanks. > From jonathan.gibbons at oracle.com Mon Aug 13 12:16:08 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 13 Aug 2012 19:16:08 +0000 Subject: hg: jdk8/tl/jdk: 7188442: rename java.lang.annotation.ContainerAnnotation to ContainedBy Message-ID: <20120813191618.C7FEE474E6@hg.openjdk.java.net> Changeset: f0bf7358ba23 Author: jfranck Date: 2012-08-09 17:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0bf7358ba23 7188442: rename java.lang.annotation.ContainerAnnotation to ContainedBy Reviewed-by: darcy, jjg + src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerAnnotation.java From ahughes at redhat.com Mon Aug 13 14:48:13 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Mon, 13 Aug 2012 17:48:13 -0400 (EDT) Subject: Code review request: 7190945: pkcs11 problem loading NSS libs on Ubuntu In-Reply-To: <5028D955.4070609@oracle.com> Message-ID: <1845086965.4172163.1344894493849.JavaMail.root@redhat.com> ----- Original Message ----- > Please review these changes to correct a problem loading Mozilla NSS > on multi-arch Ubuntu: > > http://cr.openjdk.java.net/~vinnie/7190945/webrev.00/ > > Thanks. > NSS works fine here with this change applied. The libraries are still being loaded successfully on other GNU/Linux platforms. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From bradford.wetmore at oracle.com Mon Aug 13 15:39:09 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 13 Aug 2012 15:39:09 -0700 Subject: Code review request: 7190945: pkcs11 problem loading NSS libs on Ubuntu In-Reply-To: <5028D955.4070609@oracle.com> References: <5028D955.4070609@oracle.com> Message-ID: <5029820D.4060107@oracle.com> Vinnie, I'm cleaning out email from vacation, and saw the following new bug which sounds similar. 7189635 PKCS11 tests failed on Ubuntu due to nss libs path is not same as assumed in test Is this the same bug as 7189635? It's currently unassigned. Brad On 8/13/2012 3:39 AM, Vincent Ryan wrote: > Please review these changes to correct a problem loading Mozilla NSS > on multi-arch Ubuntu: > > http://cr.openjdk.java.net/~vinnie/7190945/webrev.00/ > > Thanks. From vincent.x.ryan at oracle.com Tue Aug 14 01:19:15 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 14 Aug 2012 09:19:15 +0100 Subject: Code review request: 7190945: pkcs11 problem loading NSS libs on Ubuntu In-Reply-To: <1845086965.4172163.1344894493849.JavaMail.root@redhat.com> References: <1845086965.4172163.1344894493849.JavaMail.root@redhat.com> Message-ID: <502A0A03.8050207@oracle.com> Thanks for verifying. On 08/13/12 10:48 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Please review these changes to correct a problem loading Mozilla NSS >> on multi-arch Ubuntu: >> >> http://cr.openjdk.java.net/~vinnie/7190945/webrev.00/ >> >> Thanks. >> > > NSS works fine here with this change applied. The libraries are still being > loaded successfully on other GNU/Linux platforms. From 1983-01-06 at gmx.net Tue Aug 14 02:14:07 2012 From: 1983-01-06 at gmx.net (1983-01-06 at gmx.net) Date: Tue, 14 Aug 2012 11:14:07 +0200 Subject: Patching bug 6722928/serious limitations of JGSS under Windows 7 Message-ID: <20120814091407.180540@gmx.net> Hi folks, like many many other developers I have switched to Windows 7 on my machine. After hours of search I have realized that JGSS is seriously crippled due to UAC, account permissions and LSA's limitations. I have found the ticket 6722928 which has been filed more than 4 years ago. Suprisingly, Weijun Wang has already provided a very good patch [1] and nothing has happened since 2010. The current situation of Kerberos in Java on Windows 7 is very frustating from an enterprise point of view. I am convinced that I speak for the vast majority of devs and users who want to have native SSPI support on Windows with tampering with the registry, cred caches, ini files. Most even can't do because group policies don't allow it. Fortunately I can but since I am a local admin with a domain account, I am crippled too. Is there anything happening from the OpenJDK folks (Oracle JDK devs) for fix that issue anytime soon? This would bring the great Java platform on par with .NET's support of GSS-API/SSPI on Windows. Yours, Michael Osipov [1] http://cr.openjdk.java.net/~weijun/6722928/webrev.00/jdk.patch From weijun.wang at oracle.com Tue Aug 14 02:30:21 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Aug 2012 17:30:21 +0800 Subject: Patching bug 6722928/serious limitations of JGSS under Windows 7 In-Reply-To: <20120814091407.180540@gmx.net> References: <20120814091407.180540@gmx.net> Message-ID: <502A1AAD.4090906@oracle.com> Hi Michael The feature was dropped mainly because of delegation problem. If I remember (and understand) correctly, using the underlying SSPI there seems no good way to acquire a FORWARDED ticket and send it to the middle server to perform delegation. I think maybe Microsoft restricts this so that you are always under the UAC umbrella, otherwise, a forwarded TGT might let you do much more it wants. This means if the client uses SSPI but the server uses pure Java, there is a loss of function, and I was not happy with this (4 years ago). This might change if pure Java Kerberos also supports constrained delegation. BTW, when you say "a very good patch", have you compiled it and really find it useful? This patch was still in experimental status at the time of posting. Thanks Weijun On 08/14/2012 05:14 PM, 1983-01-06 at gmx.net wrote: > Hi folks, > > like many many other developers I have switched to Windows 7 on my machine. After hours of search I have realized that JGSS is seriously crippled due to UAC, account permissions and LSA's limitations. > > I have found the ticket 6722928 which has been filed more than 4 years ago. Suprisingly, Weijun Wang has already provided a very good patch [1] and nothing has happened since 2010. > > The current situation of Kerberos in Java on Windows 7 is very frustating from an enterprise point of view. I am convinced that I speak for the vast majority of devs and users who want to have native SSPI support on Windows with tampering with the registry, cred caches, ini files. Most even can't do because group policies don't allow it. Fortunately I can but since I am a local admin with a domain account, I am crippled too. > > Is there anything happening from the OpenJDK folks (Oracle JDK devs) for fix that issue anytime soon? This would bring the great Java platform on par with .NET's support of GSS-API/SSPI on Windows. > > Yours, > > Michael Osipov > > [1] http://cr.openjdk.java.net/~weijun/6722928/webrev.00/jdk.patch > From 1983-01-06 at gmx.net Tue Aug 14 03:35:31 2012 From: 1983-01-06 at gmx.net (1983-01-06 at gmx.net) Date: Tue, 14 Aug 2012 12:35:31 +0200 Subject: Patching bug 6722928/serious limitations of JGSS under Windows 7 In-Reply-To: <502A1AAD.4090906@oracle.com> References: <20120814091407.180540@gmx.net> <502A1AAD.4090906@oracle.com> Message-ID: <20120814103531.148010@gmx.net> Hi Weijun, > Hi Michael > > The feature was dropped mainly because of delegation problem. If I > remember (and understand) correctly, using the underlying SSPI there > seems no good way to acquire a FORWARDED ticket and send it to the > middle server to perform delegation. I think maybe Microsoft restricts > this so that you are always under the UAC umbrella, otherwise, a > forwarded TGT might let you do much more it wants. > > This means if the client uses SSPI but the server uses pure Java, there > is a loss of function, and I was not happy with this (4 years ago). > > This might change if pure Java Kerberos also supports constrained > delegation. this is confusing. Why is a SPNEGO ticket sent by Firefox which is generated with SSPI forwardable then? I was happily able to perform to retrieve a service ticket for an Active Directory server on behalf of that user's GSSCredential and retrieve some data through LDAP. InitializeSecurityContext and ISC_REQ_DELEGATE don't not do the job? Would it suffice to aquire the CredHandle from AcquireCredentialsHandle and convert that to GSSCredential? Disclaimer: I an not a C++ hacker nor I am experienced with SSPI. But strong with Kerberos on Java. > BTW, when you say "a very good patch", have you compiled it and really > find it useful? This patch was still in experimental status at the time > of posting. No, I did a code review. It looked very promising. At least way better that the current situation. Is there any chance to re-review that in 2012 with a new outcome? Thanks for the quick response, Mike > On 08/14/2012 05:14 PM, 1983-01-06 at gmx.net wrote: > > Hi folks, > > > > like many many other developers I have switched to Windows 7 on my > machine. After hours of search I have realized that JGSS is seriously crippled > due to UAC, account permissions and LSA's limitations. > > > > I have found the ticket 6722928 which has been filed more than 4 years > ago. Suprisingly, Weijun Wang has already provided a very good patch [1] and > nothing has happened since 2010. > > > > The current situation of Kerberos in Java on Windows 7 is very > frustating from an enterprise point of view. I am convinced that I speak for the > vast majority of devs and users who want to have native SSPI support on > Windows with tampering with the registry, cred caches, ini files. Most even can't > do because group policies don't allow it. Fortunately I can but since I am > a local admin with a domain account, I am crippled too. > > > > Is there anything happening from the OpenJDK folks (Oracle JDK devs) for > fix that issue anytime soon? This would bring the great Java platform on > par with .NET's support of GSS-API/SSPI on Windows. > > > > Yours, > > > > Michael Osipov > > > > [1] http://cr.openjdk.java.net/~weijun/6722928/webrev.00/jdk.patch > > From weijun.wang at oracle.com Tue Aug 14 03:59:35 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Aug 2012 18:59:35 +0800 Subject: Patching bug 6722928/serious limitations of JGSS under Windows 7 In-Reply-To: <20120814103531.148010@gmx.net> References: <20120814091407.180540@gmx.net> <502A1AAD.4090906@oracle.com> <20120814103531.148010@gmx.net> Message-ID: <502A2F97.7080500@oracle.com> On 08/14/2012 06:35 PM, 1983-01-06 at gmx.net wrote: > Hi Weijun, > >> Hi Michael >> >> The feature was dropped mainly because of delegation problem. If I >> remember (and understand) correctly, using the underlying SSPI there >> seems no good way to acquire a FORWARDED ticket and send it to the >> middle server to perform delegation. I think maybe Microsoft restricts >> this so that you are always under the UAC umbrella, otherwise, a >> forwarded TGT might let you do much more it wants. >> >> This means if the client uses SSPI but the server uses pure Java, there >> is a loss of function, and I was not happy with this (4 years ago). >> >> This might change if pure Java Kerberos also supports constrained >> delegation. > > this is confusing. Why is a SPNEGO ticket sent by Firefox which is generated with SSPI forwardable then? I was happily able to perform to retrieve a service ticket for an Active Directory server on behalf of that user's GSSCredential and retrieve some data through LDAP. InitializeSecurityContext and ISC_REQ_DELEGATE don't not do the job? Maybe I can look at it again. I remember the problem was about delegation. I am not sure now. I cannot determine when I can pick up the feature again. Sorry. -Weijun > > Would it suffice to aquire the CredHandle from AcquireCredentialsHandle and convert that to GSSCredential? > > Disclaimer: I an not a C++ hacker nor I am experienced with SSPI. But strong with Kerberos on Java. > >> BTW, when you say "a very good patch", have you compiled it and really >> find it useful? This patch was still in experimental status at the time >> of posting. > > No, I did a code review. It looked very promising. At least way better that the current situation. Is there any chance to re-review that in 2012 with a new outcome? > > Thanks for the quick response, > > Mike > >> On 08/14/2012 05:14 PM, 1983-01-06 at gmx.net wrote: >>> Hi folks, >>> >>> like many many other developers I have switched to Windows 7 on my >> machine. After hours of search I have realized that JGSS is seriously crippled >> due to UAC, account permissions and LSA's limitations. >>> >>> I have found the ticket 6722928 which has been filed more than 4 years >> ago. Suprisingly, Weijun Wang has already provided a very good patch [1] and >> nothing has happened since 2010. >>> >>> The current situation of Kerberos in Java on Windows 7 is very >> frustating from an enterprise point of view. I am convinced that I speak for the >> vast majority of devs and users who want to have native SSPI support on >> Windows with tampering with the registry, cred caches, ini files. Most even can't >> do because group policies don't allow it. Fortunately I can but since I am >> a local admin with a domain account, I am crippled too. >>> >>> Is there anything happening from the OpenJDK folks (Oracle JDK devs) for >> fix that issue anytime soon? This would bring the great Java platform on >> par with .NET's support of GSS-API/SSPI on Windows. >>> >>> Yours, >>> >>> Michael Osipov >>> >>> [1] http://cr.openjdk.java.net/~weijun/6722928/webrev.00/jdk.patch >>> > From 1983-01-06 at gmx.net Tue Aug 14 04:17:23 2012 From: 1983-01-06 at gmx.net (1983-01-06 at gmx.net) Date: Tue, 14 Aug 2012 13:17:23 +0200 Subject: Patching bug 6722928/serious limitations of JGSS under Windows 7 In-Reply-To: <502A2F97.7080500@oracle.com> References: <20120814091407.180540@gmx.net> <502A1AAD.4090906@oracle.com> <20120814103531.148010@gmx.net> <502A2F97.7080500@oracle.com> Message-ID: <20120814111723.112350@gmx.net> > > On 08/14/2012 06:35 PM, 1983-01-06 at gmx.net wrote: > > Hi Weijun, > > > >> Hi Michael > >> > >> The feature was dropped mainly because of delegation problem. If I > >> remember (and understand) correctly, using the underlying SSPI there > >> seems no good way to acquire a FORWARDED ticket and send it to the > >> middle server to perform delegation. I think maybe Microsoft restricts > >> this so that you are always under the UAC umbrella, otherwise, a > >> forwarded TGT might let you do much more it wants. > >> > >> This means if the client uses SSPI but the server uses pure Java, there > >> is a loss of function, and I was not happy with this (4 years ago). > >> > >> This might change if pure Java Kerberos also supports constrained > >> delegation. > > > > this is confusing. Why is a SPNEGO ticket sent by Firefox which is > generated with SSPI forwardable then? I was happily able to perform to retrieve > a service ticket for an Active Directory server on behalf of that user's > GSSCredential and retrieve some data through LDAP. InitializeSecurityContext > and ISC_REQ_DELEGATE don't not do the job? > > Maybe I can look at it again. I remember the problem was about > delegation. I am not sure now. > > I cannot determine when I can pick up the feature again. Sorry. Thank you! That would be a viable contribution to the entire framework. Michael From sean.mullan at oracle.com Tue Aug 14 07:01:14 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Aug 2012 10:01:14 -0400 Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5027A6A6.9080702@oracle.com> References: <5027A6A6.9080702@oracle.com> Message-ID: <502A5A2A.2000206@oracle.com> SSLSocketFactory - The new createSocket throws an IAE if the socket is an SSLSocket, but the existing createSocket method doesn't. That seems a bit odd, what do we currently do? --Sean On 8/12/12 8:50 AM, Xuelei Fan wrote: > Hi, > > Please review the spec of JEP 114, TLS Server Name Indication (SNI) > Extension. > > http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ > > Please read the README to help you understanding the the specification: > > http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt > > The major differences comparing with previous webrev are: > 1. client mode and server mode will use separated API set. > For client, the related APIs are: > setServerName(String type, String value) > clearServerName(String type) > disableServerName(String type) > enableServerName(String type) > isDisabledServerName(String type) > getServerNames() > > For server side, the related APIs are: > setServerNamePattern(String type, Pattern pattern) > clearServerNamePattern(String type) > getServerNamePatterns() > > 2. close the door to use the generated socket in client mode. > > SSLSocketFactory.createSocket(Socket s, > InputStream consumed, boolean autoClose) > > The returned socket was set in server mode. > > Regards, > Xuelei > From vincent.x.ryan at oracle.com Tue Aug 14 09:10:38 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 14 Aug 2012 17:10:38 +0100 Subject: Code review request: 7190945: pkcs11 problem loading NSS libs on Ubuntu In-Reply-To: <5029820D.4060107@oracle.com> References: <5028D955.4070609@oracle.com> <5029820D.4060107@oracle.com> Message-ID: <502A787E.4030606@oracle.com> Well spotted. I've closed it as a dup. On 08/13/12 11:39 PM, Brad Wetmore wrote: > Vinnie, > > I'm cleaning out email from vacation, and saw the following new bug > which sounds similar. > > 7189635 PKCS11 tests failed on Ubuntu due to nss libs path is not same > as assumed in test > > Is this the same bug as 7189635? It's currently unassigned. > > Brad > > > On 8/13/2012 3:39 AM, Vincent Ryan wrote: >> Please review these changes to correct a problem loading Mozilla NSS >> on multi-arch Ubuntu: >> >> http://cr.openjdk.java.net/~vinnie/7190945/webrev.00/ >> >> Thanks. From sean.mullan at oracle.com Tue Aug 14 09:54:02 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Aug 2012 12:54:02 -0400 Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5027A6A6.9080702@oracle.com> References: <5027A6A6.9080702@oracle.com> Message-ID: <502A82AA.9040001@oracle.com> SSLParameters: In your README, you write: "Unknown server name type will be expressed as "sni-", and the value of the name is encoded as UTF-8 string." This needs to be documented in the APIs. I think you should also be more specific about what means - I assume this is the type value in the SNI extension? - It might be useful to add a public String constant for the "host_name" type, ex: SSLParameters.SNI_HOST_NAME. setServerName: "In client mode, it is recommended that, by default, providers should include the server name indication whenever the server can be located by a supported name type." If we say "recommended" it means that it isn't a violation of the specification if a provider doesn't do this, and that makes it impossible to test compliance and harder for apps to depend on consistent behavior across different providers. I think we should strongly consider changing "recommended" and "should" to "required" and "must" here. Is there any reason why a provider wouldn't want to do this? --Sean On 8/12/12 8:50 AM, Xuelei Fan wrote: > Hi, > > Please review the spec of JEP 114, TLS Server Name Indication (SNI) > Extension. > > http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ > > Please read the README to help you understanding the the specification: > > http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt > > The major differences comparing with previous webrev are: > 1. client mode and server mode will use separated API set. > For client, the related APIs are: > setServerName(String type, String value) > clearServerName(String type) > disableServerName(String type) > enableServerName(String type) > isDisabledServerName(String type) > getServerNames() > > For server side, the related APIs are: > setServerNamePattern(String type, Pattern pattern) > clearServerNamePattern(String type) > getServerNamePatterns() > > 2. close the door to use the generated socket in client mode. > > SSLSocketFactory.createSocket(Socket s, > InputStream consumed, boolean autoClose) > > The returned socket was set in server mode. > > Regards, > Xuelei > From spoole167 at googlemail.com Tue Aug 14 01:27:41 2012 From: spoole167 at googlemail.com (Steve Poole) Date: Tue, 14 Aug 2012 09:27:41 +0100 Subject: Code review request: 6733443: JCA/JCE init does not completely reset the delayed provider selection mechanism. Message-ID: Hi Valerie - are you able to share your thoughts on this request yet? Cheers Steve From valerie.peng at oracle.com Tue Aug 14 11:49:07 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Tue, 14 Aug 2012 11:49:07 -0700 Subject: Code review request: 6733443: JCA/JCE init does not completely reset the delayed provider selection mechanism. In-Reply-To: References: Message-ID: <502A9DA3.4020706@oracle.com> Oh-well, sorry that this took longer than I anticipated. My plate got quite full lately. I have not completely gone through all the changes yet. There are a few changes that I am not sure if they are absolutely necessary. It's true that the doc description seems inconsistent to the current implementation, so we need to address it. Regards, Valerie On 08/14/12 01:27, Steve Poole wrote: > Hi Valerie - are you able to share your thoughts on this request yet? > > Cheers > > Steve From bradford.wetmore at oracle.com Tue Aug 14 16:54:00 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 14 Aug 2012 16:54:00 -0700 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5027A712.9080105@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> Message-ID: <502AE518.1050308@oracle.com> On 8/12/2012 5:52 AM, Xuelei Fan wrote: > I revised the APIs to separate the differnt server name values and will > send it in another thread. > http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ > http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt > > Only reply on those items we may have different opinions. I'll address the 3rd Round's CR in another email. This will contain just responses to your comments to keep the message flow in the archives. > On 8/10/2012 8:37 AM, Brad Wetmore wrote: >> >> SSLParameters.java >> ================== >> >> One general question before we get to specifics. Your current default >> behavior of the SunJSSE is to add a SNI extension if we have the value >> available. So if we call: >> >> sslSocket = socketFactory.createSocket("www.example.com", 443); >> sslp = sslParameters.getSSLParameters(); >> >> will this sslParameters ever contain a map with preinstalled "host_name" >> set to "www.example.com", or will it be empty? I think the answer will >> be empty. This API is just a way to force setting the value if an >> implementation select an unwanted value. >> > No, it is not empty. The default value will appear in the SSLParameters > in my prototype implementation. That's good to know, that will help make things much easier to understand, rather than a "null" value which is interpreted in a undefined way underneath. I'll keep this in mind in the next review. Although I just found your second email. Talk more there. > But that's an interesting topic to discuss as there are a few concerns I > have to consider when I design the APIs. > > There are public SSLParameters constructors. As means that an instance > of SSLParameters is not always got from a SSLSocket or SSLEngine > instance. Then we are not always able to have the *default* value of an > instance of SSLSocket/SSLEngine into SSLParameters if it is not bound to > SSLSocket/SSLEngine. So we still need to discuss about how the user > specified values work with the default ones. > > SSLParameters sslParameters = new SSLParameters(); > ... > sslSocket.setSSLParameters(sslParameters); We have the same situation with ciphersuites/protocols/endpointAlgs/AlgorithmConstraints. I was expecting you'd do the same thing as the last two, that is, they're interpreted at the SSLSocketImpl level. If they're null (not set), then something similar needs to happen here. I'll also keep that in mind in the next review. >> 76: Not sure why you want/need a LinkedHashMap with only one currently >> defined NameType. Even if there were multiple types, I don't think that >> SNI requires an ordering. You also mention this in >> setAccessibleServerName, but not sure what purpose this serves. I'm not >> strongly against it, just wondering. >> > I am also not sure about the strong desire that the SNI should be > ordered. But Weijun prefers it to be ordered because he think the SNI in > RFC6066 is defined as an ordered sequence. > > struct { > ServerName server_name_list<1..2^16-1> > } ServerNameList; I've gone through RFC6066 pretty carefully, and I'm not seeing any indication that this should be ordered. In RFC 2246, if there is an ordering required, such as cipher_suites/compression/certs/cert_requests, it's specifically called out. For any other "lists", it is not specified. Section 7.4.1.2 The CipherSuite list, passed from the client to the server in the client hello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). ...deleted... The client hello includes a list of compression algorithms supported by the client, ordered according to the client's preference. ...deleted... cipher_suites This is a list of the cryptographic options supported by the client, with the client's first preference first. ...deleted... compression_methods This is a list of the compression methods supported by the client, sorted by client preference. Section 7.4.2 certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Section 7.4.4 certificate_types This field is a list of the types of certificates requested, sorted in order of the server's preference. Weijun, did you see something else in your read of the spec that indicates an ordering? If not, maybe we should not put in the order wording now. If it turns out we do need it, we can always add that wording later in a later release, but it will be impossible to remove it if we add it now. >> 295: So what does value = "" mean now? Will that send a SNI extension >> with an empty string, or will no SNI entry be sent? If null is passed, >> then it's up to the provider to decide what to do, but there doesn't >> seem to be a way to shut off SNI like in your old proposal. >> > The APIs was revised. But even in the new APIs, it is still a concern. > According to the spec of host_name, a string length of a hostname should > be greater than 1: > > opaque HostName<1..2^16-1>; Yes, of course, I missed that! Ok, I'll wait to see what your new API looks like. > The SSLParameters will not check the validity of the value. The checking > will be checked later during handshaking. With the revised APIs, empty > string is not valid. An exception will be thrown during the preparing of > SNI extension. > >> 308: What kinds of things are you thinking of writing in the Additional >> Standard Names doc for "value"? >> > That was a hot discussion, I think we had talked about it a lot. You missed my original point, sorry for dragging you into that discussion. I was talking about the "value" field not the "name" field. In that section, you indicated that the "value" field was going to be talked about in the Standard Algorithm Name document. I was wondering what you were going to be talking about there, just that this needs to be an ASCII value of a DNS hostname if it's a host_name type? For example, a table with: type value ==== ===== host_name ASCII representation of a DNS hostname > This > API is not necessary to be forward compatibility with new name type of > server name indication. We may be able to use subclasses of "ServerName" > class, or ServerNameType enum for SSLParameters. As will make the > methods look straightforward. For example: > sslParameters.setServerName(ServerName); > or: > sslParameters.setServerName(ServerNameType.HOST_NAME, > "www.example.com"); > > But we lose the flexibility to support new defined server name type in > the future if we don't define new APIs. For example, when IETF defines a > new server name type, "cert_principal", we would have to add a new > subclass of ServerName to represent "cert_principal", or extend the > ServerNameType with more enum items. Otherwise, we cannot support > "cert_principal". > > It's not the biggest concerns of mine. Although it is not that > flexible, but we still can extend the APIs in the future. > > My biggest concerns is that we need the forward compatibility in > ExtendedSSLSession.getRequestedServerNames(): > > public Map getRequestedServerNames(); > > We need to be able to parser unknown server name types in server mode. > Otherwise, we are not able to get the requested server names. > > Even we have to use the string-type-and-string-value style in > ExtendedSSLSession, I want to keep it consistent in SSLParameters, > rather than define new "ServerName" class or "ServerNameType" enum. > > I think that's also the traditional approach in JSSE to make forward > compatibility, e.g, the TLS protocols, the cipher suites, etc. > >> Would it be sufficient to just say "this is the SNI hostname value"? > > See above, not all values are for host_name. The value format may be > different, we need to describe the format in an additional doc. This was my question! ;) >> Even though you have a link to java.util.regex.Pattern in the actual >> API, you might also mention here in textual form that these are >> java.util.regex patterns, and add a @link java.util.regex. Makes it >> more clear where to go to learn about how to specify patterns. >> > >> 387: This is a pattern and not a String, so only listing >> setAccessibleServerName() isn't quite complete. You might also list >> "and also see the Pattern page for details on specifying regular >> expression patterns". > > IMHO, I did not see strong necessary of the description. The parameter > is not a string regular expression, it is an instance of Pattern. When > one want to use the Pattern class, definitely, he knows it an instance > related java.util.regex patterns. > > It is a pattern and not a string, why we should describe the string > regular expression here? I withdraw my comment. They can click through using the Pattern if needed. I might suggest capitalizing Pattern here though. "accessibhle" -> "accessible" I might also suggest: "is used to match alternative server names" -> "is used to match server names" since it's for the main and alternate names. >> 379: So what does "" mean now? Will an empty string SNI extension be >> accepted? Or we will >> > See aove, empty string ("") is invalid, the application will run into > exception during handshaking for empty string hostname. Ok. Will look at this in your next rev. >> SSLSocketFactory.java >> ===================== >> >> Since you're leaving the door open for this socket being either client >> or server, shouldn't the API then be similar to the existing layered >> socket one, just including the additional InputStream here: >> >> public abstract Socket createSocket(Socket s, InputStream is, >> String host, int port, boolean autoClose) >> >> We might be able to glean SNI information from the host here. >> > To make it more straightforward, I closed the door for this socket being > in client mode in the revised APIs. As you like. I would think adding an InputStream to the existing API is just as straightforward also for learning the API, but since we would only expect this to be used in server mode, your point has merit. >> 171: Interesting, the existing layered createSocket doesn't mention >> anything about whether client or server mode, and that you must set the >> mode or suffer with the default. Might want to file a bug and CCC this >> also. >> > Not really need the description of the mode. The existing description > has already implied that the return socket must be in client mode. > > * @param host the server host > * @param port the server port > * @return a socket connected to the specified host and port You mean because it's a "named host"? I can kind of buy that. But currently it's kind of subtle that it will be in client mode. I was thinking we should make it more clear. >> 197: You're not planning to process (e.g. >> ServerHandshaker/ClientHandshaker.process_message) the consumed >> handshaking bytes immediately during the createSocket call, are you? You >> still need to allow the user time to set the socket >> options/SSLParameters/etc. I was expecting in this method you'd just >> suck in the consumed bytes into temporary storage, then create/return >> the socket, and then when the handshaking is started, you then read out >> from the temporary storage until you run out, then you switch to the >> Socket's InputStream. >> > You're right. It is allowed to set more options in the returned socket > before kick off handshake. > >> 197: This needs some wordsmithing here. This method will produce the >> SSLSocket that will be consuming this data, so of course it has to be >> called first. >> > I'm not sure I understand your point. Please comment it again with the > revised APIs if you still have concerns. I just didn't understand much of this paragraph. 1. You have to call this method, then set up your parameters, then start your handshaking. So the first half of this sentence doesn't apply. 2. "consumed network data is resumable" wasn't clear either. To me this should mean that you can obtain the data which has already been read from "s". 3. "Otherwise, the behavior of the return socket is not defined" lost me. Does this mean that that SSLParameters and assorted settings are not otherwise defined? I think you could delete this paragraph. From your second email: > Thought more about the design, I would have to say that we cannot return > the default value in sslParameters.getServerNames(). Otherwise, the > following two block of codes look very weird to me: > // case one: > 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); > 2 sslParameters.clearServerName("host_name"); > 3 Map names = sslParameters.getServerNames(); > 4 sslSocket.setSSLParameters(sslParameters); > 5 sslParameters = sslSocket.getSSLParameters(); > 6 names = sslParameters.getServerNames(); > > In line 3, the returned map does not contain "host_name" entry. But in > line 6, it may be expected that no "host_name" in the returned map. But > if we want to return default values, line 6 do need to return a map > containing "host_name". The behavior is pretty confusing. We may want > to try avoid the confusion. I'm not following your confusion, it seemed pretty straightforward to me, it works much like CipherSuites. We have a set of ciphersuites which are enabled by default. We can turn some off by using SSLParameters. Expanding a bit on your example here, I'll describe what I think would happen internally/externally: 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( "www.example.com", 443); mySSLSocketFactory sets any initial parameters as usual. SSLSocketImpl knows it's connecting to www.example.com and automatically stores "host_name" -> "www.example.com" in its local host data (map or separate variables). 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the hostmap to the one value "host_name" -> "www.example.com" If the application want to get the "default values", they just pull them out of the SSLParameters here 3 sslParameters.clearServerName("host_name"); Or sslParameters.setServerName("host_name", null)? User just decided to clear it. Ok, that's what we do. It becomes an empty map in SSLParameters. 4 Map names = sslParameters.getServerNames(); Returns empty Map. 5 sslSocket.setSSLParameters(sslParameters); SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this SSLParameters and as a result, clears it's internal "host_name" map to null, and thus won't send anything out since it's empty. 6 sslParameters = sslSocket.getSSLParameters(); SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees that there's no name indication, so it creates an empty name map and stores in SSLParameters. 7 names = sslParameters.getServerNames(); returns empty. It's no longer the default value, because they have specifically set the value. HTH, Brad > Thanks, > Xuelei > From bradford.wetmore at oracle.com Tue Aug 14 17:31:13 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 14 Aug 2012 17:31:13 -0700 Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5027A6A6.9080702@oracle.com> References: <5027A6A6.9080702@oracle.com> Message-ID: <502AEDD1.50506@oracle.com> Still looking over the changes, but a few preliminary comments. On 8/12/2012 5:50 AM, Xuelei Fan wrote: > Hi, > > Please review the spec of JEP 114, TLS Server Name Indication (SNI) > Extension. > > http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ > > Please read the README to help you understanding the the specification: > > http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt I forgot to mention this previously: > Oracle provider now only supports one server name type, "host_name". > The value of name is encoded as UTF-8 string. RFC 6066 requires ASCII, earlier versions (RFC 4366) have this as UTF-8. Do you want to allow for UTF-8 here? > The major differences comparing with previous webrev are: > 1. client mode and server mode will use separated API set. > For client, the related APIs are: > setServerName(String type, String value) > clearServerName(String type) > disableServerName(String type) > enableServerName(String type) > isDisabledServerName(String type) > getServerNames() Please read my note on the 2nd round review before reading this, specifically the section that starts "I'm not following your confusion". So wow, what happened here? I thought we were so very close on finalizing the API, and it was just a matter of tweaking the wording to have a null value disable the type from being sent. setServerName(String type, String value) { if type == value throw IAE; if value == null map.remove(type); return; else if value.equals("") throw IAE; else map.put(value); } Then in the Handshakers, only those type/values that are present in the map are be pulled out for constructing the SNI extensions. If you want to go with this new API style with clear/disable/enable, I can see where you are coming from, but that was unexpected. Before I review for accuracy, I want to make sure you really want to tweak things so extensively. I think what you had previously fit the bill pretty well. > For server side, the related APIs are: > setServerNamePattern(String type, Pattern pattern) > clearServerNamePattern(String type) > getServerNamePatterns() and same for this one. I'll look over the rest once I get your answer to the above. > 2. close the door to use the generated socket in client mode. > > SSLSocketFactory.createSocket(Socket s, > InputStream consumed, boolean autoClose) > > The returned socket was set in server mode. Brad From xuelei.fan at oracle.com Tue Aug 14 19:45:48 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Aug 2012 10:45:48 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502AE518.1050308@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> Message-ID: <502B0D5C.6080303@oracle.com> I only reply on the items that I may need more review. On 8/15/2012 7:54 AM, Brad Wetmore wrote: >>> SSLParameters.java >>> ================== >>> 76: Not sure why you want/need a LinkedHashMap with only one currently >>> defined NameType. Even if there were multiple types, I don't think that >>> SNI requires an ordering. You also mention this in >>> setAccessibleServerName, but not sure what purpose this serves. I'm not >>> strongly against it, just wondering. >>> >> I am also not sure about the strong desire that the SNI should be >> ordered. But Weijun prefers it to be ordered because he think the SNI in >> RFC6066 is defined as an ordered sequence. >> >> struct { >> ServerName server_name_list<1..2^16-1> >> } ServerNameList; > > I've gone through RFC6066 pretty carefully, and I'm not seeing any > indication that this should be ordered. > > In RFC 2246, if there is an ordering required, such as > cipher_suites/compression/certs/cert_requests, it's specifically called > out. For any other "lists", it is not specified. > > Section 7.4.1.2 > > The CipherSuite list, passed from the client to the server in the > client hello message, contains the combinations of cryptographic > algorithms supported by the client in order of the client's > preference (favorite choice first). > > ...deleted... > > The client hello includes a list of compression algorithms supported > by the client, ordered according to the client's preference. > > ...deleted... > > cipher_suites > This is a list of the cryptographic options supported by the > client, with the client's first preference first. > > ...deleted... > > compression_methods > This is a list of the compression methods supported by the > client, sorted by client preference. > > Section 7.4.2 > > certificate_list > This is a sequence (chain) of X.509v3 certificates. The sender's > certificate must come first in the list. > > Section 7.4.4 > > certificate_types > This field is a list of the types of certificates requested, > sorted in order of the server's preference. > > Weijun, did you see something else in your read of the spec that > indicates an ordering? If not, maybe we should not put in the order > wording now. If it turns out we do need it, we can always add that > wording later in a later release, but it will be impossible to remove it > if we add it now. > I think you are right. If Weijun has no other concerns, I will remove related description. >> The SSLParameters will not check the validity of the value. The checking >> will be checked later during handshaking. With the revised APIs, empty >> string is not valid. An exception will be thrown during the preparing of >> SNI extension. >> >>> 308: What kinds of things are you thinking of writing in the Additional >>> Standard Names doc for "value"? >>> >> That was a hot discussion, I think we had talked about it a lot. > > You missed my original point, sorry for dragging you into that > discussion. I was talking about the "value" field not the "name" field. > In that section, you indicated that the "value" field was going to be > talked about in the Standard Algorithm Name document. I was wondering > what you were going to be talking about there, just that this needs to > be an ASCII value of a DNS hostname if it's a host_name type? For > example, a table with: > > type value > ==== ===== > host_name ASCII representation of a DNS hostname > Sorry, I did misunderstand your point. Yes, the doc will looks like your above example. >>> SSLSocketFactory.java >>> ===================== >>> >>> Since you're leaving the door open for this socket being either client >>> or server, shouldn't the API then be similar to the existing layered >>> socket one, just including the additional InputStream here: >>> >>> public abstract Socket createSocket(Socket s, InputStream is, >>> String host, int port, boolean autoClose) >>> >>> We might be able to glean SNI information from the host here. >>> >> To make it more straightforward, I closed the door for this socket being >> in client mode in the revised APIs. > > As you like. I would think adding an InputStream to the existing API is > just as straightforward also for learning the API, but since we would > only expect this to be used in server mode, your point has merit. > >>> 171: Interesting, the existing layered createSocket doesn't mention >>> anything about whether client or server mode, and that you must set the >>> mode or suffer with the default. Might want to file a bug and CCC this >>> also. >>> >> Not really need the description of the mode. The existing description >> has already implied that the return socket must be in client mode. >> >> * @param host the server host >> * @param port the server port >> * @return a socket connected to the specified host and port > > You mean because it's a "named host"? I can kind of buy that. But > currently it's kind of subtle that it will be in client mode. I was > thinking we should make it more clear. > I mean the "host" param is the *server* host, and the "port" param is the *server* port, and the returned value is connected to the server "host" and server "port", so it should be a client. But, it is not straightforward. I'm OK to make it more clear. >>> 197: You're not planning to process (e.g. >>> ServerHandshaker/ClientHandshaker.process_message) the consumed >>> handshaking bytes immediately during the createSocket call, are you? You >>> still need to allow the user time to set the socket >>> options/SSLParameters/etc. I was expecting in this method you'd just >>> suck in the consumed bytes into temporary storage, then create/return >>> the socket, and then when the handshaking is started, you then read out >>> from the temporary storage until you run out, then you switch to the >>> Socket's InputStream. >>> >> You're right. It is allowed to set more options in the returned socket >> before kick off handshake. >> >>> 197: This needs some wordsmithing here. This method will produce the >>> SSLSocket that will be consuming this data, so of course it has to be >>> called first. >>> >> I'm not sure I understand your point. Please comment it again with the >> revised APIs if you still have concerns. > > I just didn't understand much of this paragraph. > > 1. You have to call this method, then set up your parameters, then start > your handshaking. So the first half of this sentence doesn't apply. > Oh, I know your concerns. What I want to express is that before the calling to method, the caller should not do real handshaking. The logic I concerned looks like: // 1. accept a socket // 2. read ClientHello and reply ServerHello to output stream. // 3. call this method SSLSocket sslSocket = (SSLSocket)sslSocketFactory.createSocket( socke, inputStream, true); because the handshaking has started in step 2, then in step 3, we cannot get a proper SSLSocket. > 2. "consumed network data is resumable" wasn't clear either. To me this > should mean that you can obtain the data which has already been read > from "s". > Yes, need wordsmithing here. > 3. "Otherwise, the behavior of the return socket is not defined" lost > me. Does this mean that that SSLParameters and assorted settings are > not otherwise defined? > See above example. > I think you could delete this paragraph. > > From your second email: > >> Thought more about the design, I would have to say that we cannot return >> the default value in sslParameters.getServerNames(). Otherwise, the >> following two block of codes look very weird to me: >> // case one: >> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >> 2 sslParameters.clearServerName("host_name"); >> 3 Map names = sslParameters.getServerNames(); >> 4 sslSocket.setSSLParameters(sslParameters); >> 5 sslParameters = sslSocket.getSSLParameters(); >> 6 names = sslParameters.getServerNames(); >> >> In line 3, the returned map does not contain "host_name" entry. But in >> line 6, it may be expected that no "host_name" in the returned map. But >> if we want to return default values, line 6 do need to return a map >> containing "host_name". The behavior is pretty confusing. We may want >> to try avoid the confusion. > > I'm not following your confusion, it seemed pretty straightforward to > me, it works much like CipherSuites. We have a set of ciphersuites > which are enabled by default. We can turn some off by using > SSLParameters. Expanding a bit on your example here, I'll describe what > I think would happen internally/externally: > > 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( > "www.example.com", 443); > > mySSLSocketFactory sets any initial parameters as usual. SSLSocketImpl > knows it's connecting to www.example.com and automatically stores > "host_name" -> "www.example.com" in its local host data (map or separate > variables). > > 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); > > SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the > hostmap to the one value "host_name" -> "www.example.com" > > If the application want to get the "default values", they just pull them > out of the SSLParameters here > > 3 sslParameters.clearServerName("host_name"); > > Or sslParameters.setServerName("host_name", null)? > > User just decided to clear it. Ok, that's what we do. It becomes an > empty map in SSLParameters. > > 4 Map names = sslParameters.getServerNames(); > > Returns empty Map. > As far as good. > 5 sslSocket.setSSLParameters(sslParameters); > > SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this > SSLParameters and as a result, clears it's internal "host_name" map to > null, and thus won't send anything out since it's empty. > We have problems here. We need to support that if an application does not specified host_name value, we should use default values. I. SSLParameters sslParameters = new SSLParameters(); II. sslParameters.setCipherSuites(...); III. SSLSocket sslSocket = sslSocketFactory.createSocket("www.example.com", 443) IV. sslSocket.setSSLParameters(sslParameters); Before line IV and after line II, the sslParameters.getServerNames() are empty. In line IV, we need to make sure the internal "host_name", "www.example.com" is used as default value, and send it to server in SNI. That's the default behaviors in JDK 7. We cannot break it without strong desires. I think it means that we cannot clear the internal "host_name" when the sslParameters.getServerNames() return empty. Does it make sense to you? Thanks, Xuelei > 6 sslParameters = sslSocket.getSSLParameters(); > > SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees > that there's no name indication, so it creates an empty name map and > stores in SSLParameters. > > 7 names = sslParameters.getServerNames(); > > returns empty. > > It's no longer the default value, because they have specifically set the > value. > > HTH, > > Brad From xuelei.fan at oracle.com Tue Aug 14 20:15:11 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Aug 2012 11:15:11 +0800 Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502A5A2A.2000206@oracle.com> References: <5027A6A6.9080702@oracle.com> <502A5A2A.2000206@oracle.com> Message-ID: <502B143F.6040801@oracle.com> On 8/14/2012 10:01 PM, Sean Mullan wrote: > SSLSocketFactory > > - The new createSocket throws an IAE if the socket is an SSLSocket, but the > existing createSocket method doesn't. That seems a bit odd, what do we currently do? > For the existing createSocket, it does not work when the socket is an instance of SSLSocket. It is expected to read and write raw SSL records from the socket. But if it is SSLSocket, the I/O are for application data over the TLS layer. I want to describe it clear in the new API. Xuelei > --Sean > > > On 8/12/12 8:50 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the spec of JEP 114, TLS Server Name Indication (SNI) >> Extension. >> >> http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ >> >> Please read the README to help you understanding the the specification: >> >> http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt >> >> The major differences comparing with previous webrev are: >> 1. client mode and server mode will use separated API set. >> For client, the related APIs are: >> setServerName(String type, String value) >> clearServerName(String type) >> disableServerName(String type) >> enableServerName(String type) >> isDisabledServerName(String type) >> getServerNames() >> >> For server side, the related APIs are: >> setServerNamePattern(String type, Pattern pattern) >> clearServerNamePattern(String type) >> getServerNamePatterns() >> >> 2. close the door to use the generated socket in client mode. >> >> SSLSocketFactory.createSocket(Socket s, >> InputStream consumed, boolean autoClose) >> >> The returned socket was set in server mode. >> >> Regards, >> Xuelei >> From xuelei.fan at oracle.com Tue Aug 14 20:38:13 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Aug 2012 11:38:13 +0800 Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502A82AA.9040001@oracle.com> References: <5027A6A6.9080702@oracle.com> <502A82AA.9040001@oracle.com> Message-ID: <502B19A5.1060909@oracle.com> On 8/15/2012 12:54 AM, Sean Mullan wrote: > SSLParameters: > > In your README, you write: > > "Unknown server name type will be expressed as "sni-", and the > value of the name is encoded as UTF-8 string." > > This needs to be documented in the APIs. As we document the known server name types in Java doc. I thought it may be enough to document unknown ones in java doc also. But I understand your point if we define constants, SSLParameters.SNI_HOST_NAME. > I think you should also be more > specific about what means - I assume this is the type value in the SNI > extension? > Yes. > - It might be useful to add a public String constant for the "host_name" type, > ex: SSLParameters.SNI_HOST_NAME. > Good point. > setServerName: > > "In client mode, it is recommended that, by default, providers should include > the server name indication whenever the server can be located by a supported > name type." > > If we say "recommended" it means that it isn't a violation of the specification > if a provider doesn't do this, and that makes it impossible to test compliance > and harder for apps to depend on consistent behavior across different providers. > I think we should strongly consider changing "recommended" and "should" to > "required" and "must" here. Is there any reason why a provider wouldn't want to > do this? > >From my point, it is mainly for compatibility. Third parties old providers may not support SNI or may not provider default values. For example, if the following is an old block of code: SSLParameters sslParameters = new SSLParameters(); sslParameters.setCipheSuites(...); ... SSLSocket sslSocket = sslSocketFactory.createSocket("www.example.com", 443); sslSocket.setParameters(sslParameters); SunJSSE in JDK 7 will have the default value "www.example.com", but other vendors may not. So I think if I use a strong tone, "must"/"required", applications may run into problems with old providers. I hope an application specify the value explicit in order to avoid provider dependency. Xuelei > --Sean > > On 8/12/12 8:50 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the spec of JEP 114, TLS Server Name Indication (SNI) >> Extension. >> >> http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ >> >> Please read the README to help you understanding the the specification: >> >> http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt >> >> The major differences comparing with previous webrev are: >> 1. client mode and server mode will use separated API set. >> For client, the related APIs are: >> setServerName(String type, String value) >> clearServerName(String type) >> disableServerName(String type) >> enableServerName(String type) >> isDisabledServerName(String type) >> getServerNames() >> >> For server side, the related APIs are: >> setServerNamePattern(String type, Pattern pattern) >> clearServerNamePattern(String type) >> getServerNamePatterns() >> >> 2. close the door to use the generated socket in client mode. >> >> SSLSocketFactory.createSocket(Socket s, >> InputStream consumed, boolean autoClose) >> >> The returned socket was set in server mode. >> >> Regards, >> Xuelei >> From weijun.wang at oracle.com Tue Aug 14 20:43:11 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Aug 2012 11:43:11 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502B0D5C.6080303@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> Message-ID: <502B1ACF.40402@oracle.com> On 08/15/2012 10:45 AM, Xuelei Fan wrote: > I only reply on the items that I may need more review. > > On 8/15/2012 7:54 AM, Brad Wetmore wrote: >>>> SSLParameters.java >>>> ================== >>>> 76: Not sure why you want/need a LinkedHashMap with only one currently >>>> defined NameType. Even if there were multiple types, I don't think that >>>> SNI requires an ordering. You also mention this in >>>> setAccessibleServerName, but not sure what purpose this serves. I'm not >>>> strongly against it, just wondering. >>>> >>> I am also not sure about the strong desire that the SNI should be >>> ordered. But Weijun prefers it to be ordered because he think the SNI in >>> RFC6066 is defined as an ordered sequence. >>> >>> struct { >>> ServerName server_name_list<1..2^16-1> >>> } ServerNameList; >> >> I've gone through RFC6066 pretty carefully, and I'm not seeing any >> indication that this should be ordered. >> >> In RFC 2246, if there is an ordering required, such as >> cipher_suites/compression/certs/cert_requests, it's specifically called >> out. For any other "lists", it is not specified. >> >> Weijun, did you see something else in your read of the spec that >> indicates an ordering? If not, maybe we should not put in the order >> wording now. If it turns out we do need it, we can always add that >> wording later in a later release, but it will be impossible to remove it >> if we add it now. No, I didn't read anything else. However, I cannot think of a reason why we will need to remove it later. >> > I think you are right. If Weijun has no other concerns, I will remove > related description. > >>> Thought more about the design, I would have to say that we cannot return >>> the default value in sslParameters.getServerNames(). Otherwise, the >>> following two block of codes look very weird to me: >>> // case one: >>> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>> 2 sslParameters.clearServerName("host_name"); >>> 3 Map names = sslParameters.getServerNames(); >>> 4 sslSocket.setSSLParameters(sslParameters); >>> 5 sslParameters = sslSocket.getSSLParameters(); >>> 6 names = sslParameters.getServerNames(); >>> >>> In line 3, the returned map does not contain "host_name" entry. But in >>> line 6, it may be expected that no "host_name" in the returned map. But >>> if we want to return default values, line 6 do need to return a map >>> containing "host_name". The behavior is pretty confusing. We may want >>> to try avoid the confusion. >> >> I'm not following your confusion, it seemed pretty straightforward to >> me, it works much like CipherSuites. We have a set of ciphersuites >> which are enabled by default. We can turn some off by using >> SSLParameters. Expanding a bit on your example here, I'll describe what >> I think would happen internally/externally: >> >> 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( >> "www.example.com", 443); >> >> mySSLSocketFactory sets any initial parameters as usual. SSLSocketImpl >> knows it's connecting to www.example.com and automatically stores >> "host_name" -> "www.example.com" in its local host data (map or separate >> variables). >> >> 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); >> >> SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the >> hostmap to the one value "host_name" -> "www.example.com" >> >> If the application want to get the "default values", they just pull them >> out of the SSLParameters here >> >> 3 sslParameters.clearServerName("host_name"); >> >> Or sslParameters.setServerName("host_name", null)? >> >> User just decided to clear it. Ok, that's what we do. It becomes an >> empty map in SSLParameters. >> >> 4 Map names = sslParameters.getServerNames(); >> >> Returns empty Map. >> > As far as good. > >> 5 sslSocket.setSSLParameters(sslParameters); >> >> SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this >> SSLParameters and as a result, clears it's internal "host_name" map to >> null, and thus won't send anything out since it's empty. >> > We have problems here. We need to support that if an application does > not specified host_name value, we should use default values. > I. SSLParameters sslParameters = new SSLParameters(); > II. sslParameters.setCipherSuites(...); > III. SSLSocket sslSocket = > sslSocketFactory.createSocket("www.example.com", 443) > IV. sslSocket.setSSLParameters(sslParameters); > > Before line IV and after line II, the sslParameters.getServerNames() are > empty. In line IV, we need to make sure the internal "host_name", > "www.example.com" is used as default value, and send it to server in > SNI. That's the default behaviors in JDK 7. We cannot break it without > strong desires. > > I think it means that we cannot clear the internal "host_name" when the > sslParameters.getServerNames() return empty. > > Does it make sense to you? This is how I understand this problem: There are two ways you get a SSLParameters object with an empty server name map. 1. SSLparameters sslParameters = sslSocket.getSSLParameters(); sslParameters.clearServerName("host_name"); 2. SSLParameters sslParameters = new SSLParameters(); Now these 2 objects are identical. If you call sslSocket.setSSLParameters(sslParameters) now, what should it do? By looking at 1, it seems you cleared something; but by 2, you touched nothing and it should go default. Thanks Max > > Thanks, > Xuelei From jason.uh at oracle.com Tue Aug 14 20:51:10 2012 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 14 Aug 2012 20:51:10 -0700 Subject: JDK 8 Code Review Request: 6500133/6931888: CertificateParsingException for CDP Message-ID: <502B1CAE.1030101@oracle.com> Hi all, This change fixes -- 6500133: CertificateParsingException for CRL Distribution Point with blank; and 6931888: Inconsistent behavior for invalid URI name in cert file CRs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500133 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6931888 They are effectively duplicates, both regarding an exception thrown when parsing CRL Distribution Point URIs with invalid characters, like a space or backslash. This change uses sun.net.www.ParseUtil.encodePath(String) to re-encode bad URIs. Webrev: http://cr.openjdk.java.net/~juh/6500133/webrev.00/ Thanks, Jason From xuelei.fan at oracle.com Tue Aug 14 21:19:12 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Aug 2012 12:19:12 +0800 Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502AEDD1.50506@oracle.com> References: <5027A6A6.9080702@oracle.com> <502AEDD1.50506@oracle.com> Message-ID: <502B2340.1010202@oracle.com> On 8/15/2012 8:31 AM, Brad Wetmore wrote: > Still looking over the changes, but a few preliminary comments. > > On 8/12/2012 5:50 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the spec of JEP 114, TLS Server Name Indication (SNI) >> Extension. >> >> http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ >> >> Please read the README to help you understanding the the specification: >> >> http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt > > I forgot to mention this previously: > >> Oracle provider now only supports one server name type, "host_name". >> The value of name is encoded as UTF-8 string. > > RFC 6066 requires ASCII, earlier versions (RFC 4366) have this as UTF-8. > Do you want to allow for UTF-8 here? > Good point! I think we may send ASCII, but accept UTF-8. Need to consider it more during implementation. >> The major differences comparing with previous webrev are: >> 1. client mode and server mode will use separated API set. >> For client, the related APIs are: >> setServerName(String type, String value) >> clearServerName(String type) >> disableServerName(String type) >> enableServerName(String type) >> isDisabledServerName(String type) >> getServerNames() > > Please read my note on the 2nd round review before reading this, > specifically the section that starts "I'm not following your confusion". > > So wow, what happened here? I thought we were so very close on > finalizing the API, and it was just a matter of tweaking the wording to > have a null value disable the type from being sent. > > setServerName(String type, String value) { > if type == value > throw IAE; > if value == null > map.remove(type); > return; > else if value.equals("") > throw IAE; > else > map.put(value); > } > > Then in the Handshakers, only those type/values that are present in the > map are be pulled out for constructing the SNI extensions. > > If you want to go with this new API style with clear/disable/enable, I > can see where you are coming from, but that was unexpected. Before I > review for accuracy, I want to make sure you really want to tweak things > so extensively. I think what you had previously fit the bill pretty well. > >> For server side, the related APIs are: >> setServerNamePattern(String type, Pattern pattern) >> clearServerNamePattern(String type) >> getServerNamePatterns() > > and same for this one. > Sorry about that. It's not an easy trad-off for me between fewer APIs and clearer APIs. The underlying motivation pushed me to extend the APIs is that we may don't want the developers to find the usage of "null" from java doc, and remember what the "null" value means. The new APIs are more clear to me. Sorry. No main framework changes, hope it is the final revision of the APIs. ;-) Thanks, Xuelei > I'll look over the rest once I get your answer to the above. > >> 2. close the door to use the generated socket in client mode. >> >> SSLSocketFactory.createSocket(Socket s, >> InputStream consumed, boolean autoClose) >> >> The returned socket was set in server mode. > > Brad > From bradford.wetmore at oracle.com Tue Aug 14 23:10:29 2012 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 14 Aug 2012 23:10:29 -0700 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502B0D5C.6080303@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> Message-ID: <502B3D55.30604@oracle.com> On 8/14/2012 7:45 PM, Xuelei Fan wrote: >>>> 197: You're not planning to process (e.g. >>>> ServerHandshaker/ClientHandshaker.process_message) the consumed >>>> handshaking bytes immediately during the createSocket call, are you? You >>>> still need to allow the user time to set the socket >>>> options/SSLParameters/etc. I was expecting in this method you'd just >>>> suck in the consumed bytes into temporary storage, then create/return >>>> the socket, and then when the handshaking is started, you then read out >>>> from the temporary storage until you run out, then you switch to the >>>> Socket's InputStream. >>>> >>> You're right. It is allowed to set more options in the returned socket >>> before kick off handshake. >>> >>>> 197: This needs some wordsmithing here. This method will produce the >>>> SSLSocket that will be consuming this data, so of course it has to be >>>> called first. >>>> >>> I'm not sure I understand your point. Please comment it again with the >>> revised APIs if you still have concerns. >> >> I just didn't understand much of this paragraph. >> >> 1. You have to call this method, then set up your parameters, then start >> your handshaking. So the first half of this sentence doesn't apply. >> > Oh, I know your concerns. What I want to express is that before the > calling to method, the caller should not do real handshaking. The logic > I concerned looks like: > // 1. accept a socket > // 2. read ClientHello and reply ServerHello to output stream. > // 3. call this method > SSLSocket sslSocket = (SSLSocket)sslSocketFactory.createSocket( > socke, inputStream, true); > > because the handshaking has started in step 2, then in step 3, we cannot > get a proper SSLSocket. How would the ServerHello be generated until you call this method and then start the handshaking on the returned SSLSocket? You said in a previous internal conversation that SSLExplore would not generate any ServerHello, so this can't be what you mean. Are you talking about layering another SSLSocket over a already layered SSLSocket? >> 2. "consumed network data is resumable" wasn't clear either. To me this >> should mean that you can obtain the data which has already been read >> from "s". >> > Yes, need wordsmithing here. > >> 3. "Otherwise, the behavior of the return socket is not defined" lost >> me. Does this mean that that SSLParameters and assorted settings are >> not otherwise defined? >> > See above example. I think I need the above answered before I can comment further here. >> I think you could delete this paragraph. >> >> From your second email: >> >>> Thought more about the design, I would have to say that we cannot return >>> the default value in sslParameters.getServerNames(). Otherwise, the >>> following two block of codes look very weird to me: >>> // case one: >>> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>> 2 sslParameters.clearServerName("host_name"); >>> 3 Map names = sslParameters.getServerNames(); >>> 4 sslSocket.setSSLParameters(sslParameters); >>> 5 sslParameters = sslSocket.getSSLParameters(); >>> 6 names = sslParameters.getServerNames(); >>> >>> In line 3, the returned map does not contain "host_name" entry. But in >>> line 6, it may be expected that no "host_name" in the returned map. But >>> if we want to return default values, line 6 do need to return a map >>> containing "host_name". The behavior is pretty confusing. We may want >>> to try avoid the confusion. >> >> I'm not following your confusion, it seemed pretty straightforward to >> me, it works much like CipherSuites. We have a set of ciphersuites >> which are enabled by default. We can turn some off by using >> SSLParameters. Expanding a bit on your example here, I'll describe what >> I think would happen internally/externally: >> >> 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( >> "www.example.com", 443); >> >> mySSLSocketFactory sets any initial parameters as usual. SSLSocketImpl >> knows it's connecting to www.example.com and automatically stores >> "host_name" -> "www.example.com" in its local host data (map or separate >> variables). >> >> 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); >> >> SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the >> hostmap to the one value "host_name" -> "www.example.com" >> >> If the application want to get the "default values", they just pull them >> out of the SSLParameters here >> >> 3 sslParameters.clearServerName("host_name"); >> >> Or sslParameters.setServerName("host_name", null)? >> >> User just decided to clear it. Ok, that's what we do. It becomes an >> empty map in SSLParameters. >> >> 4 Map names = sslParameters.getServerNames(); >> >> Returns empty Map. >> > As far as good. > >> 5 sslSocket.setSSLParameters(sslParameters); >> >> SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this >> SSLParameters and as a result, clears it's internal "host_name" map to >> null, and thus won't send anything out since it's empty. >> > We have problems here. We need to support that if an application does > not specified host_name value, we should use default values. > I. SSLParameters sslParameters = new SSLParameters(); > II. sslParameters.setCipherSuites(...); > III. SSLSocket sslSocket = > sslSocketFactory.createSocket("www.example.com", 443) > IV. sslSocket.setSSLParameters(sslParameters); > > Before line IV and after line II, the sslParameters.getServerNames() are > empty. In line IV, we need to make sure the internal "host_name", > "www.example.com" is used as default value, and send it to server in > SNI. That's the default behaviors in JDK 7. We cannot break it without > strong desires. > > I think it means that we cannot clear the internal "host_name" when the > sslParameters.getServerNames() return empty. > > Does it make sense to you? Ok, that's an issue, I was assuming people would generally get a SSLParameters from the SSLSocket/SSLEngine, which would have prepopulated values such as CipherSuites/Protocols and SNI values. Now I hear what you're saying. So in SSLSocket/SSLEngine, we have a very similar situation with the CipherSuites/Protocols. The way we did it there was if SSLParameters.getCipherSuites() is null (that is, has not been set in this instance), we let the default values stand (that is we did not call SSLSocket.setEnabledCipherSuites()). You could do something like that with the SNI info. I've always felt the setServerName/getServerName should take/return the same Map value, but you felt strongly about a setServerName(String, String) so I didn't push it. If we didn't set this value, then the original value could stand. Maybe your current design addresses this in a better way, I'll have to look at this in the morning, I still have a couple hours of home stuff to do before I can go to bed. Brad > Thanks, > Xuelei > >> 6 sslParameters = sslSocket.getSSLParameters(); >> >> SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees >> that there's no name indication, so it creates an empty name map and >> stores in SSLParameters. >> >> 7 names = sslParameters.getServerNames(); >> >> returns empty. >> >> It's no longer the default value, because they have specifically set the >> value. >> >> HTH, >> >> Brad > From xuelei.fan at oracle.com Wed Aug 15 00:03:03 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Aug 2012 15:03:03 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502B3D55.30604@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> <502B3D55.30604@oracle.com> Message-ID: <502B49A7.8000704@oracle.com> On 8/15/2012 2:10 PM, Bradford Wetmore wrote: > > > On 8/14/2012 7:45 PM, Xuelei Fan wrote: > >>>>> 197: You're not planning to process (e.g. >>>>> ServerHandshaker/ClientHandshaker.process_message) the consumed >>>>> handshaking bytes immediately during the createSocket call, are >>>>> you? You >>>>> still need to allow the user time to set the socket >>>>> options/SSLParameters/etc. I was expecting in this method you'd just >>>>> suck in the consumed bytes into temporary storage, then create/return >>>>> the socket, and then when the handshaking is started, you then read >>>>> out >>>>> from the temporary storage until you run out, then you switch to the >>>>> Socket's InputStream. >>>>> >>>> You're right. It is allowed to set more options in the returned socket >>>> before kick off handshake. >>>> >>>>> 197: This needs some wordsmithing here. This method will produce the >>>>> SSLSocket that will be consuming this data, so of course it has to be >>>>> called first. >>>>> >>>> I'm not sure I understand your point. Please comment it again with the >>>> revised APIs if you still have concerns. >>> >>> I just didn't understand much of this paragraph. >>> >>> 1. You have to call this method, then set up your parameters, then start >>> your handshaking. So the first half of this sentence doesn't apply. >>> >> Oh, I know your concerns. What I want to express is that before the >> calling to method, the caller should not do real handshaking. The logic >> I concerned looks like: >> // 1. accept a socket >> // 2. read ClientHello and reply ServerHello to output stream. >> // 3. call this method >> SSLSocket sslSocket = (SSLSocket)sslSocketFactory.createSocket( >> socke, inputStream, true); >> >> because the handshaking has started in step 2, then in step 3, we cannot >> get a proper SSLSocket. > > How would the ServerHello be generated until you call this method and > then start the handshaking on the returned SSLSocket? One can use SSLEngine.wrap()/unwrap() to generate handshaking messages from socket I/O stream. // accept a socket // read/write the I/O with SSLEngine // call this method Xuelei > You said in a > previous internal conversation that SSLExplore would not generate any > ServerHello, so this can't be what you mean. Are you talking about > layering another SSLSocket over a already layered SSLSocket? > >>> 2. "consumed network data is resumable" wasn't clear either. To me this >>> should mean that you can obtain the data which has already been read >>> from "s". >>> >> Yes, need wordsmithing here. >> >>> 3. "Otherwise, the behavior of the return socket is not defined" lost >>> me. Does this mean that that SSLParameters and assorted settings are >>> not otherwise defined? >>> >> See above example. > > I think I need the above answered before I can comment further here. > >>> I think you could delete this paragraph. >>> >>> From your second email: >>> >>>> Thought more about the design, I would have to say that we cannot >>>> return >>>> the default value in sslParameters.getServerNames(). Otherwise, the >>>> following two block of codes look very weird to me: >>>> // case one: >>>> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>> 2 sslParameters.clearServerName("host_name"); >>>> 3 Map names = sslParameters.getServerNames(); >>>> 4 sslSocket.setSSLParameters(sslParameters); >>>> 5 sslParameters = sslSocket.getSSLParameters(); >>>> 6 names = sslParameters.getServerNames(); >>>> >>>> In line 3, the returned map does not contain "host_name" entry. But in >>>> line 6, it may be expected that no "host_name" in the returned map. But >>>> if we want to return default values, line 6 do need to return a map >>>> containing "host_name". The behavior is pretty confusing. We may want >>>> to try avoid the confusion. >>> >>> I'm not following your confusion, it seemed pretty straightforward to >>> me, it works much like CipherSuites. We have a set of ciphersuites >>> which are enabled by default. We can turn some off by using >>> SSLParameters. Expanding a bit on your example here, I'll describe what >>> I think would happen internally/externally: >>> >>> 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( >>> "www.example.com", 443); >>> >>> mySSLSocketFactory sets any initial parameters as usual. SSLSocketImpl >>> knows it's connecting to www.example.com and automatically stores >>> "host_name" -> "www.example.com" in its local host data (map or separate >>> variables). >>> >>> 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>> >>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the >>> hostmap to the one value "host_name" -> "www.example.com" >>> >>> If the application want to get the "default values", they just pull them >>> out of the SSLParameters here >>> >>> 3 sslParameters.clearServerName("host_name"); >>> >>> Or sslParameters.setServerName("host_name", null)? >>> >>> User just decided to clear it. Ok, that's what we do. It becomes an >>> empty map in SSLParameters. >>> >>> 4 Map names = sslParameters.getServerNames(); >>> >>> Returns empty Map. >>> >> As far as good. >> >>> 5 sslSocket.setSSLParameters(sslParameters); >>> >>> SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this >>> SSLParameters and as a result, clears it's internal "host_name" map to >>> null, and thus won't send anything out since it's empty. >>> >> We have problems here. We need to support that if an application does >> not specified host_name value, we should use default values. >> I. SSLParameters sslParameters = new SSLParameters(); >> II. sslParameters.setCipherSuites(...); >> III. SSLSocket sslSocket = >> sslSocketFactory.createSocket("www.example.com", 443) >> IV. sslSocket.setSSLParameters(sslParameters); >> >> Before line IV and after line II, the sslParameters.getServerNames() are >> empty. In line IV, we need to make sure the internal "host_name", >> "www.example.com" is used as default value, and send it to server in >> SNI. That's the default behaviors in JDK 7. We cannot break it without >> strong desires. >> >> I think it means that we cannot clear the internal "host_name" when the >> sslParameters.getServerNames() return empty. >> >> Does it make sense to you? > > Ok, that's an issue, I was assuming people would generally get a > SSLParameters from the SSLSocket/SSLEngine, which would have > prepopulated values such as CipherSuites/Protocols and SNI values. Now I > hear what you're saying. > > So in SSLSocket/SSLEngine, we have a very similar situation with the > CipherSuites/Protocols. The way we did it there was if > SSLParameters.getCipherSuites() is null (that is, has not been set in > this instance), we let the default values stand (that is we did not call > SSLSocket.setEnabledCipherSuites()). You could do something like that > with the SNI info. I've always felt the setServerName/getServerName > should take/return the same Map value, but you felt > strongly about a setServerName(String, String) so I didn't push it. If > we didn't set this value, then the original value could stand. > > Maybe your current design addresses this in a better way, I'll have to > look at this in the morning, I still have a couple hours of home stuff > to do before I can go to bed. > > Brad > >> Thanks, >> Xuelei >> >>> 6 sslParameters = sslSocket.getSSLParameters(); >>> >>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees >>> that there's no name indication, so it creates an empty name map and >>> stores in SSLParameters. >>> >>> 7 names = sslParameters.getServerNames(); >>> >>> returns empty. >>> >>> It's no longer the default value, because they have specifically set the >>> value. >>> >>> HTH, >>> >>> Brad >> > From bradford.wetmore at oracle.com Wed Aug 15 00:24:05 2012 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 15 Aug 2012 00:24:05 -0700 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502B49A7.8000704@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> <502B3D55.30604@oracle.com> <502B49A7.8000704@oracle.com> Message-ID: <502B4E95.7070105@oracle.com> >> How would the ServerHello be generated until you call this method and >> then start the handshaking on the returned SSLSocket? > One can use SSLEngine.wrap()/unwrap() to generate handshaking messages > from socket I/O stream. > // accept a socket > // read/write the I/O with SSLEngine > // call this method Switching between SSLSocket/SSLEngine like that would require intentional misuse of the API. You could make the same claim for regular handshaking. Brad > Xuelei > >> You said in a >> previous internal conversation that SSLExplore would not generate any >> ServerHello, so this can't be what you mean. Are you talking about >> layering another SSLSocket over a already layered SSLSocket? >> >>>> 2. "consumed network data is resumable" wasn't clear either. To me this >>>> should mean that you can obtain the data which has already been read >>>> from "s". >>>> >>> Yes, need wordsmithing here. >>> >>>> 3. "Otherwise, the behavior of the return socket is not defined" lost >>>> me. Does this mean that that SSLParameters and assorted settings are >>>> not otherwise defined? >>>> >>> See above example. >> >> I think I need the above answered before I can comment further here. >> >>>> I think you could delete this paragraph. >>>> >>>> From your second email: >>>> >>>>> Thought more about the design, I would have to say that we cannot >>>>> return >>>>> the default value in sslParameters.getServerNames(). Otherwise, the >>>>> following two block of codes look very weird to me: >>>>> // case one: >>>>> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>>> 2 sslParameters.clearServerName("host_name"); >>>>> 3 Map names = sslParameters.getServerNames(); >>>>> 4 sslSocket.setSSLParameters(sslParameters); >>>>> 5 sslParameters = sslSocket.getSSLParameters(); >>>>> 6 names = sslParameters.getServerNames(); >>>>> >>>>> In line 3, the returned map does not contain "host_name" entry. But in >>>>> line 6, it may be expected that no "host_name" in the returned map. But >>>>> if we want to return default values, line 6 do need to return a map >>>>> containing "host_name". The behavior is pretty confusing. We may want >>>>> to try avoid the confusion. >>>> >>>> I'm not following your confusion, it seemed pretty straightforward to >>>> me, it works much like CipherSuites. We have a set of ciphersuites >>>> which are enabled by default. We can turn some off by using >>>> SSLParameters. Expanding a bit on your example here, I'll describe what >>>> I think would happen internally/externally: >>>> >>>> 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( >>>> "www.example.com", 443); >>>> >>>> mySSLSocketFactory sets any initial parameters as usual. SSLSocketImpl >>>> knows it's connecting to www.example.com and automatically stores >>>> "host_name" -> "www.example.com" in its local host data (map or separate >>>> variables). >>>> >>>> 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>> >>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the >>>> hostmap to the one value "host_name" -> "www.example.com" >>>> >>>> If the application want to get the "default values", they just pull them >>>> out of the SSLParameters here >>>> >>>> 3 sslParameters.clearServerName("host_name"); >>>> >>>> Or sslParameters.setServerName("host_name", null)? >>>> >>>> User just decided to clear it. Ok, that's what we do. It becomes an >>>> empty map in SSLParameters. >>>> >>>> 4 Map names = sslParameters.getServerNames(); >>>> >>>> Returns empty Map. >>>> >>> As far as good. >>> >>>> 5 sslSocket.setSSLParameters(sslParameters); >>>> >>>> SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this >>>> SSLParameters and as a result, clears it's internal "host_name" map to >>>> null, and thus won't send anything out since it's empty. >>>> >>> We have problems here. We need to support that if an application does >>> not specified host_name value, we should use default values. >>> I. SSLParameters sslParameters = new SSLParameters(); >>> II. sslParameters.setCipherSuites(...); >>> III. SSLSocket sslSocket = >>> sslSocketFactory.createSocket("www.example.com", 443) >>> IV. sslSocket.setSSLParameters(sslParameters); >>> >>> Before line IV and after line II, the sslParameters.getServerNames() are >>> empty. In line IV, we need to make sure the internal "host_name", >>> "www.example.com" is used as default value, and send it to server in >>> SNI. That's the default behaviors in JDK 7. We cannot break it without >>> strong desires. >>> >>> I think it means that we cannot clear the internal "host_name" when the >>> sslParameters.getServerNames() return empty. >>> >>> Does it make sense to you? >> >> Ok, that's an issue, I was assuming people would generally get a >> SSLParameters from the SSLSocket/SSLEngine, which would have >> prepopulated values such as CipherSuites/Protocols and SNI values. Now I >> hear what you're saying. >> >> So in SSLSocket/SSLEngine, we have a very similar situation with the >> CipherSuites/Protocols. The way we did it there was if >> SSLParameters.getCipherSuites() is null (that is, has not been set in >> this instance), we let the default values stand (that is we did not call >> SSLSocket.setEnabledCipherSuites()). You could do something like that >> with the SNI info. I've always felt the setServerName/getServerName >> should take/return the same Map value, but you felt >> strongly about a setServerName(String, String) so I didn't push it. If >> we didn't set this value, then the original value could stand. >> >> Maybe your current design addresses this in a better way, I'll have to >> look at this in the morning, I still have a couple hours of home stuff >> to do before I can go to bed. >> >> Brad >> >>> Thanks, >>> Xuelei >>> >>>> 6 sslParameters = sslSocket.getSSLParameters(); >>>> >>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees >>>> that there's no name indication, so it creates an empty name map and >>>> stores in SSLParameters. >>>> >>>> 7 names = sslParameters.getServerNames(); >>>> >>>> returns empty. >>>> >>>> It's no longer the default value, because they have specifically set the >>>> value. >>>> >>>> HTH, >>>> >>>> Brad >>> >> > From xuelei.fan at oracle.com Wed Aug 15 03:26:17 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Aug 2012 18:26:17 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502B0D5C.6080303@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> Message-ID: <502B7949.4020907@oracle.com> More comments about whether we are able to override the default value. On 8/15/2012 10:45 AM, Xuelei Fan wrote: >>> >> Thought more about the design, I would have to say that we cannot return >>> >> the default value in sslParameters.getServerNames(). Otherwise, the >>> >> following two block of codes look very weird to me: >>> >> // case one: >>> >> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>> >> 2 sslParameters.clearServerName("host_name"); >>> >> 3 Map names = sslParameters.getServerNames(); >>> >> 4 sslSocket.setSSLParameters(sslParameters); >>> >> 5 sslParameters = sslSocket.getSSLParameters(); >>> >> 6 names = sslParameters.getServerNames(); >>> >> >>> >> In line 3, the returned map does not contain "host_name" entry. But in >>> >> line 6, it may be expected that no "host_name" in the returned map. But >>> >> if we want to return default values, line 6 do need to return a map >>> >> containing "host_name". The behavior is pretty confusing. We may want >>> >> to try avoid the confusion. >> > >> > I'm not following your confusion, it seemed pretty straightforward to >> > me, it works much like CipherSuites. We have a set of ciphersuites >> > which are enabled by default. We can turn some off by using >> > SSLParameters. Compatibility is my concerns here. When the SSLParameters class was was introduced in JDK 6, set/getCipherSuites() and set/getProtocols were new, so there was no compatibility issue for these two pairs methods at that time, as they were not used in old applications. In JDK 7, we introduced two new methods, set/getAlgorithmConstraints(). We were luck that we cannot allow the override of default constraints because of security consideration, and the concept of algorithm constraints was new in JDK 7. So we needed not to consider the compatibility issue too much between JDK 6 and 7 for this pair of methods. However, things get changed for the Server Name Inidication (SNI), because in JDK 7 we have already support default SNI extension implicit. We have to consider the compatibility issues more between JDK 7 and JDK 8, we need to make sure the behaviors are consistent whenever we call the set/getServerName(). If we allow override of default value, the application may run into corner trap as the description in my previous mail. That's the background of my thoughts. Hope it helps you understand the current design. Thanks, Xuelei >> > Expanding a bit on your example here, I'll describe what >> > I think would happen internally/externally: >> > >> > 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( >> > "www.example.com", 443); >> > >> > mySSLSocketFactory sets any initial parameters as usual. SSLSocketImpl >> > knows it's connecting to www.example.com and automatically stores >> > "host_name" -> "www.example.com" in its local host data (map or separate >> > variables). >> > >> > 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); >> > >> > SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the >> > hostmap to the one value "host_name" -> "www.example.com" >> > >> > If the application want to get the "default values", they just pull them >> > out of the SSLParameters here >> > >> > 3 sslParameters.clearServerName("host_name"); >> > >> > Or sslParameters.setServerName("host_name", null)? >> > >> > User just decided to clear it. Ok, that's what we do. It becomes an >> > empty map in SSLParameters. >> > >> > 4 Map names = sslParameters.getServerNames(); >> > >> > Returns empty Map. >> > > As far as good. > >> > 5 sslSocket.setSSLParameters(sslParameters); >> > >> > SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this >> > SSLParameters and as a result, clears it's internal "host_name" map to >> > null, and thus won't send anything out since it's empty. >> > > We have problems here. We need to support that if an application does > not specified host_name value, we should use default values. > I. SSLParameters sslParameters = new SSLParameters(); > II. sslParameters.setCipherSuites(...); > III. SSLSocket sslSocket = > sslSocketFactory.createSocket("www.example.com", 443) > IV. sslSocket.setSSLParameters(sslParameters); > > Before line IV and after line II, the sslParameters.getServerNames() are > empty. In line IV, we need to make sure the internal "host_name", > "www.example.com" is used as default value, and send it to server in > SNI. That's the default behaviors in JDK 7. We cannot break it without > strong desires. > > I think it means that we cannot clear the internal "host_name" when the > sslParameters.getServerNames() return empty. > > Does it make sense to you? > > Thanks, > Xuelei > >> > 6 sslParameters = sslSocket.getSSLParameters(); >> > >> > SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees >> > that there's no name indication, so it creates an empty name map and >> > stores in SSLParameters. >> > >> > 7 names = sslParameters.getServerNames(); >> > >> > returns empty. >> > >> > It's no longer the default value, because they have specifically set the >> > value. >> > >> > HTH, >> > >> > Brad From weijun.wang at oracle.com Wed Aug 15 05:25:54 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Aug 2012 20:25:54 +0800 Subject: Code review request: 7184246: Simplify Config.get() of krb5 In-Reply-To: <501A8B45.9070907@oracle.com> References: <14914072.1343818131183.JavaMail.sbladm@swsblss4-new.central.sun.com> <501A8B45.9070907@oracle.com> Message-ID: <502B9552.6030705@oracle.com> 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 Wed Aug 15 06:30:05 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Aug 2012 21:30:05 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502B4E95.7070105@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> <502B3D55.30604@oracle.com> <502B49A7.8000704@oracle.com> <502B4E95.7070105@oracle.com> Message-ID: <502BA45D.2060008@oracle.com> This paragraph was removed in the latest update. Please ignore the webrev_spec.04 and previous webrevs, and review webrev_spec.05. http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.05/ Thanks, Xuelei On 8/15/2012 3:24 PM, Bradford Wetmore wrote: > > >>> How would the ServerHello be generated until you call this method and >>> then start the handshaking on the returned SSLSocket? >> One can use SSLEngine.wrap()/unwrap() to generate handshaking messages >> from socket I/O stream. >> // accept a socket >> // read/write the I/O with SSLEngine >> // call this method > > Switching between SSLSocket/SSLEngine like that would require > intentional misuse of the API. You could make the same claim for > regular handshaking. > > Brad > >> Xuelei >> >>> You said in a >>> previous internal conversation that SSLExplore would not generate any >>> ServerHello, so this can't be what you mean. Are you talking about >>> layering another SSLSocket over a already layered SSLSocket? >>> >>>>> 2. "consumed network data is resumable" wasn't clear either. To me >>>>> this >>>>> should mean that you can obtain the data which has already been read >>>>> from "s". >>>>> >>>> Yes, need wordsmithing here. >>>> >>>>> 3. "Otherwise, the behavior of the return socket is not defined" lost >>>>> me. Does this mean that that SSLParameters and assorted settings are >>>>> not otherwise defined? >>>>> >>>> See above example. >>> >>> I think I need the above answered before I can comment further here. >>> >>>>> I think you could delete this paragraph. >>>>> >>>>> From your second email: >>>>> >>>>>> Thought more about the design, I would have to say that we cannot >>>>>> return >>>>>> the default value in sslParameters.getServerNames(). Otherwise, the >>>>>> following two block of codes look very weird to me: >>>>>> // case one: >>>>>> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>>>> 2 sslParameters.clearServerName("host_name"); >>>>>> 3 Map names = sslParameters.getServerNames(); >>>>>> 4 sslSocket.setSSLParameters(sslParameters); >>>>>> 5 sslParameters = sslSocket.getSSLParameters(); >>>>>> 6 names = sslParameters.getServerNames(); >>>>>> >>>>>> In line 3, the returned map does not contain "host_name" entry. >>>>>> But in >>>>>> line 6, it may be expected that no "host_name" in the returned >>>>>> map. But >>>>>> if we want to return default values, line 6 do need to return a map >>>>>> containing "host_name". The behavior is pretty confusing. We may >>>>>> want >>>>>> to try avoid the confusion. >>>>> >>>>> I'm not following your confusion, it seemed pretty straightforward to >>>>> me, it works much like CipherSuites. We have a set of ciphersuites >>>>> which are enabled by default. We can turn some off by using >>>>> SSLParameters. Expanding a bit on your example here, I'll describe >>>>> what >>>>> I think would happen internally/externally: >>>>> >>>>> 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( >>>>> "www.example.com", 443); >>>>> >>>>> mySSLSocketFactory sets any initial parameters as usual. >>>>> SSLSocketImpl >>>>> knows it's connecting to www.example.com and automatically stores >>>>> "host_name" -> "www.example.com" in its local host data (map or >>>>> separate >>>>> variables). >>>>> >>>>> 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>>> >>>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the >>>>> hostmap to the one value "host_name" -> "www.example.com" >>>>> >>>>> If the application want to get the "default values", they just pull >>>>> them >>>>> out of the SSLParameters here >>>>> >>>>> 3 sslParameters.clearServerName("host_name"); >>>>> >>>>> Or sslParameters.setServerName("host_name", null)? >>>>> >>>>> User just decided to clear it. Ok, that's what we do. It becomes an >>>>> empty map in SSLParameters. >>>>> >>>>> 4 Map names = sslParameters.getServerNames(); >>>>> >>>>> Returns empty Map. >>>>> >>>> As far as good. >>>> >>>>> 5 sslSocket.setSSLParameters(sslParameters); >>>>> >>>>> SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this >>>>> SSLParameters and as a result, clears it's internal "host_name" map to >>>>> null, and thus won't send anything out since it's empty. >>>>> >>>> We have problems here. We need to support that if an application does >>>> not specified host_name value, we should use default values. >>>> I. SSLParameters sslParameters = new SSLParameters(); >>>> II. sslParameters.setCipherSuites(...); >>>> III. SSLSocket sslSocket = >>>> sslSocketFactory.createSocket("www.example.com", 443) >>>> IV. sslSocket.setSSLParameters(sslParameters); >>>> >>>> Before line IV and after line II, the sslParameters.getServerNames() >>>> are >>>> empty. In line IV, we need to make sure the internal "host_name", >>>> "www.example.com" is used as default value, and send it to server in >>>> SNI. That's the default behaviors in JDK 7. We cannot break it >>>> without >>>> strong desires. >>>> >>>> I think it means that we cannot clear the internal "host_name" when the >>>> sslParameters.getServerNames() return empty. >>>> >>>> Does it make sense to you? >>> >>> Ok, that's an issue, I was assuming people would generally get a >>> SSLParameters from the SSLSocket/SSLEngine, which would have >>> prepopulated values such as CipherSuites/Protocols and SNI values. Now I >>> hear what you're saying. >>> >>> So in SSLSocket/SSLEngine, we have a very similar situation with the >>> CipherSuites/Protocols. The way we did it there was if >>> SSLParameters.getCipherSuites() is null (that is, has not been set in >>> this instance), we let the default values stand (that is we did not call >>> SSLSocket.setEnabledCipherSuites()). You could do something like that >>> with the SNI info. I've always felt the setServerName/getServerName >>> should take/return the same Map value, but you felt >>> strongly about a setServerName(String, String) so I didn't push it. If >>> we didn't set this value, then the original value could stand. >>> >>> Maybe your current design addresses this in a better way, I'll have to >>> look at this in the morning, I still have a couple hours of home stuff >>> to do before I can go to bed. >>> >>> Brad >>> >>>> Thanks, >>>> Xuelei >>>> >>>>> 6 sslParameters = sslSocket.getSSLParameters(); >>>>> >>>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees >>>>> that there's no name indication, so it creates an empty name map and >>>>> stores in SSLParameters. >>>>> >>>>> 7 names = sslParameters.getServerNames(); >>>>> >>>>> returns empty. >>>>> >>>>> It's no longer the default value, because they have specifically >>>>> set the >>>>> value. >>>>> >>>>> HTH, >>>>> >>>>> Brad >>>> >>> >> > From ahughes at redhat.com Wed Aug 15 06:36:16 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 15 Aug 2012 13:36:16 +0000 Subject: hg: jdk8/tl/jdk: 7110151: Use underlying platform's zlib library for Java zlib support Message-ID: <20120815133648.516A647534@hg.openjdk.java.net> Changeset: 35e024c6a62c Author: andrew Date: 2012-08-15 14:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35e024c6a62c 7110151: Use underlying platform's zlib library for Java zlib support Summary: Make SYSTEM_ZLIB more flexible by using ZLIB_{CFLAGS,LIBS} and building on more than just MACOSX. Reviewed-by: sherman, alanb ! make/com/sun/java/pack/Makefile ! make/common/Program.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-macosx.gmk ! make/common/shared/Defs-solaris.gmk ! make/java/jli/Makefile ! make/java/zip/Makefile ! make/jdk_generic_profile.sh ! make/sun/splashscreen/Makefile ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zip_util.c From xuelei.fan at oracle.com Wed Aug 15 06:36:49 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Aug 2012 21:36:49 +0800 Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <5027A6A6.9080702@oracle.com> References: <5027A6A6.9080702@oracle.com> Message-ID: <502BA5F1.7010901@oracle.com> Updated webrev according to recent feedbacks: http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ http://cr.openjdk.java.net./~xuelei/7068321/README_05.txt The major differences: 1. add constant SSLParameters.SNI_HOST_NAME, and specify the format of unknown SNI type (sni-) in ExtendedSSLSession. Then we don't need to document the types and values in Java Cryptography Architecture Standard Algorithm Name Documentation. 2. Other updates according to feedback from Brad, Weijun, and Sean. Please let me know I missed misunderstood something. Thanks, Xuelei On 8/12/2012 8:50 PM, Xuelei Fan wrote: > Hi, > > Please review the spec of JEP 114, TLS Server Name Indication (SNI) > Extension. > > http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ > > Please read the README to help you understanding the the specification: > > http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt > > The major differences comparing with previous webrev are: > 1. client mode and server mode will use separated API set. > For client, the related APIs are: > setServerName(String type, String value) > clearServerName(String type) > disableServerName(String type) > enableServerName(String type) > isDisabledServerName(String type) > getServerNames() > > For server side, the related APIs are: > setServerNamePattern(String type, Pattern pattern) > clearServerNamePattern(String type) > getServerNamePatterns() > > 2. close the door to use the generated socket in client mode. > > SSLSocketFactory.createSocket(Socket s, > InputStream consumed, boolean autoClose) > > The returned socket was set in server mode. > > Regards, > Xuelei > From xuelei.fan at oracle.com Wed Aug 15 06:40:27 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Aug 2012 21:40:27 +0800 Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502BA5F1.7010901@oracle.com> References: <5027A6A6.9080702@oracle.com> <502BA5F1.7010901@oracle.com> Message-ID: <502BA6CB.5060907@oracle.com> On 8/15/2012 9:36 PM, Xuelei Fan wrote: > Updated webrev according to recent feedbacks: > http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ > http://cr.openjdk.java.net./~xuelei/7068321/README_05.txt > > The major differences: > 1. add constant SSLParameters.SNI_HOST_NAME, and specify the format of > unknown SNI type (sni-) in ExtendedSSLSession. > Then we don't need to document the types and values in Java > Cryptography Architecture Standard Algorithm Name Documentation. > > 2. Other updates according to feedback from Brad, Weijun, and Sean. > Please let me know I missed misunderstood something. > missed or misunderstood ;-) > Thanks, > Xuelei > > On 8/12/2012 8:50 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the spec of JEP 114, TLS Server Name Indication (SNI) >> Extension. >> >> http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/ >> >> Please read the README to help you understanding the the specification: >> >> http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt >> >> The major differences comparing with previous webrev are: >> 1. client mode and server mode will use separated API set. >> For client, the related APIs are: >> setServerName(String type, String value) >> clearServerName(String type) >> disableServerName(String type) >> enableServerName(String type) >> isDisabledServerName(String type) >> getServerNames() >> >> For server side, the related APIs are: >> setServerNamePattern(String type, Pattern pattern) >> clearServerNamePattern(String type) >> getServerNamePatterns() >> >> 2. close the door to use the generated socket in client mode. >> >> SSLSocketFactory.createSocket(Socket s, >> InputStream consumed, boolean autoClose) >> >> The returned socket was set in server mode. >> >> Regards, >> Xuelei >> > From weijun.wang at oracle.com Wed Aug 15 07:06:21 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Aug 2012 22:06:21 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502BA45D.2060008@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> <502B3D55.30604@oracle.com> <502B49A7.8000704@oracle.com> <502B4E95.7070105@oracle.com> <502BA45D.2060008@oracle.com> Message-ID: <502BACDD.10106@oracle.com> Some suggestions to SSLParameters: 1. Since you now decide to exclude the default SNI value from getServerNames(), maybe you can emphasis this by using "user-provided server name" in the spec. 2. At disableServerName(), maybe you can explicitly point out that "A disabled server name type cannot be used as a part of the server name indication in SSL/TLS handshaking, even if the provider has a default value for this server name type". 3. isDisabledServerName, maybe isServerNameDisabled? Neither sounds perfect. 4. I just noticed that the type can be also "sni-". What if someone call setServerName("sni-0", "...")? Is it the same as calling setServerName(SNI_HOST_NAME, "...")? Thanks Max On 08/15/2012 09:30 PM, Xuelei Fan wrote: > This paragraph was removed in the latest update. Please ignore the > webrev_spec.04 and previous webrevs, and review webrev_spec.05. > > http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.05/ > > Thanks, > Xuelei > > On 8/15/2012 3:24 PM, Bradford Wetmore wrote: >> >> >>>> How would the ServerHello be generated until you call this method and >>>> then start the handshaking on the returned SSLSocket? >>> One can use SSLEngine.wrap()/unwrap() to generate handshaking messages >>> from socket I/O stream. >>> // accept a socket >>> // read/write the I/O with SSLEngine >>> // call this method >> >> Switching between SSLSocket/SSLEngine like that would require >> intentional misuse of the API. You could make the same claim for >> regular handshaking. >> >> Brad >> >>> Xuelei >>> >>>> You said in a >>>> previous internal conversation that SSLExplore would not generate any >>>> ServerHello, so this can't be what you mean. Are you talking about >>>> layering another SSLSocket over a already layered SSLSocket? >>>> >>>>>> 2. "consumed network data is resumable" wasn't clear either. To me >>>>>> this >>>>>> should mean that you can obtain the data which has already been read >>>>>> from "s". >>>>>> >>>>> Yes, need wordsmithing here. >>>>> >>>>>> 3. "Otherwise, the behavior of the return socket is not defined" lost >>>>>> me. Does this mean that that SSLParameters and assorted settings are >>>>>> not otherwise defined? >>>>>> >>>>> See above example. >>>> >>>> I think I need the above answered before I can comment further here. >>>> >>>>>> I think you could delete this paragraph. >>>>>> >>>>>> From your second email: >>>>>> >>>>>>> Thought more about the design, I would have to say that we cannot >>>>>>> return >>>>>>> the default value in sslParameters.getServerNames(). Otherwise, the >>>>>>> following two block of codes look very weird to me: >>>>>>> // case one: >>>>>>> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>>>>> 2 sslParameters.clearServerName("host_name"); >>>>>>> 3 Map names = sslParameters.getServerNames(); >>>>>>> 4 sslSocket.setSSLParameters(sslParameters); >>>>>>> 5 sslParameters = sslSocket.getSSLParameters(); >>>>>>> 6 names = sslParameters.getServerNames(); >>>>>>> >>>>>>> In line 3, the returned map does not contain "host_name" entry. >>>>>>> But in >>>>>>> line 6, it may be expected that no "host_name" in the returned >>>>>>> map. But >>>>>>> if we want to return default values, line 6 do need to return a map >>>>>>> containing "host_name". The behavior is pretty confusing. We may >>>>>>> want >>>>>>> to try avoid the confusion. >>>>>> >>>>>> I'm not following your confusion, it seemed pretty straightforward to >>>>>> me, it works much like CipherSuites. We have a set of ciphersuites >>>>>> which are enabled by default. We can turn some off by using >>>>>> SSLParameters. Expanding a bit on your example here, I'll describe >>>>>> what >>>>>> I think would happen internally/externally: >>>>>> >>>>>> 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( >>>>>> "www.example.com", 443); >>>>>> >>>>>> mySSLSocketFactory sets any initial parameters as usual. >>>>>> SSLSocketImpl >>>>>> knows it's connecting to www.example.com and automatically stores >>>>>> "host_name" -> "www.example.com" in its local host data (map or >>>>>> separate >>>>>> variables). >>>>>> >>>>>> 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>>>> >>>>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the >>>>>> hostmap to the one value "host_name" -> "www.example.com" >>>>>> >>>>>> If the application want to get the "default values", they just pull >>>>>> them >>>>>> out of the SSLParameters here >>>>>> >>>>>> 3 sslParameters.clearServerName("host_name"); >>>>>> >>>>>> Or sslParameters.setServerName("host_name", null)? >>>>>> >>>>>> User just decided to clear it. Ok, that's what we do. It becomes an >>>>>> empty map in SSLParameters. >>>>>> >>>>>> 4 Map names = sslParameters.getServerNames(); >>>>>> >>>>>> Returns empty Map. >>>>>> >>>>> As far as good. >>>>> >>>>>> 5 sslSocket.setSSLParameters(sslParameters); >>>>>> >>>>>> SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this >>>>>> SSLParameters and as a result, clears it's internal "host_name" map to >>>>>> null, and thus won't send anything out since it's empty. >>>>>> >>>>> We have problems here. We need to support that if an application does >>>>> not specified host_name value, we should use default values. >>>>> I. SSLParameters sslParameters = new SSLParameters(); >>>>> II. sslParameters.setCipherSuites(...); >>>>> III. SSLSocket sslSocket = >>>>> sslSocketFactory.createSocket("www.example.com", 443) >>>>> IV. sslSocket.setSSLParameters(sslParameters); >>>>> >>>>> Before line IV and after line II, the sslParameters.getServerNames() >>>>> are >>>>> empty. In line IV, we need to make sure the internal "host_name", >>>>> "www.example.com" is used as default value, and send it to server in >>>>> SNI. That's the default behaviors in JDK 7. We cannot break it >>>>> without >>>>> strong desires. >>>>> >>>>> I think it means that we cannot clear the internal "host_name" when the >>>>> sslParameters.getServerNames() return empty. >>>>> >>>>> Does it make sense to you? >>>> >>>> Ok, that's an issue, I was assuming people would generally get a >>>> SSLParameters from the SSLSocket/SSLEngine, which would have >>>> prepopulated values such as CipherSuites/Protocols and SNI values. Now I >>>> hear what you're saying. >>>> >>>> So in SSLSocket/SSLEngine, we have a very similar situation with the >>>> CipherSuites/Protocols. The way we did it there was if >>>> SSLParameters.getCipherSuites() is null (that is, has not been set in >>>> this instance), we let the default values stand (that is we did not call >>>> SSLSocket.setEnabledCipherSuites()). You could do something like that >>>> with the SNI info. I've always felt the setServerName/getServerName >>>> should take/return the same Map value, but you felt >>>> strongly about a setServerName(String, String) so I didn't push it. If >>>> we didn't set this value, then the original value could stand. >>>> >>>> Maybe your current design addresses this in a better way, I'll have to >>>> look at this in the morning, I still have a couple hours of home stuff >>>> to do before I can go to bed. >>>> >>>> Brad >>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> 6 sslParameters = sslSocket.getSSLParameters(); >>>>>> >>>>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees >>>>>> that there's no name indication, so it creates an empty name map and >>>>>> stores in SSLParameters. >>>>>> >>>>>> 7 names = sslParameters.getServerNames(); >>>>>> >>>>>> returns empty. >>>>>> >>>>>> It's no longer the default value, because they have specifically >>>>>> set the >>>>>> value. >>>>>> >>>>>> HTH, >>>>>> >>>>>> Brad >>>>> >>>> >>> >> > From xuelei.fan at oracle.com Wed Aug 15 07:34:52 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Aug 2012 22:34:52 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502BACDD.10106@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> <502B3D55.30604@oracle.com> <502B49A7.8000704@oracle.com> <502B4E95.7070105@oracle.com> <502BA45D.2060008@oracle.com> <502BACDD.10106@oracle.com> Message-ID: <502BB38C.5050900@oracle.com> On 8/15/2012 10:06 PM, Weijun Wang wrote: > Some suggestions to SSLParameters: > > 1. Since you now decide to exclude the default SNI value from > getServerNames(), maybe you can emphasis this by using "user-provided > server name" in the spec. > I have a paragraph in setServerName: * Note that the returned Map of * {@link #setServerName(String, String)} does not contain the provider * default server name types and values. Did you suggest to replace the "desired" with "user-provided" or "user-specified"? > 2. At disableServerName(), maybe you can explicitly point out that "A > disabled server name type cannot be used as a part of the server name > indication in SSL/TLS handshaking, even if the provider has a default > value for this server name type". > OK. > 3. isDisabledServerName, maybe isServerNameDisabled? Neither sounds > perfect. > I'd like to collect more votes on the name. ;-) > 4. I just noticed that the type can be also "sni-". What if someone > call setServerName("sni-0", "...")? Is it the same as calling > setServerName(SNI_HOST_NAME, "...")? > Unspecified behavior. Maybe not, because of the value encoding method. We may throw exception in Oracle provider. Other providers may want to support "sni-32" or "principal" for its private server name type. Thanks for the quick response! Xuelei > Thanks > Max > > > On 08/15/2012 09:30 PM, Xuelei Fan wrote: >> This paragraph was removed in the latest update. Please ignore the >> webrev_spec.04 and previous webrevs, and review webrev_spec.05. >> >> http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.05/ >> >> Thanks, >> Xuelei >> >> On 8/15/2012 3:24 PM, Bradford Wetmore wrote: >>> >>> >>>>> How would the ServerHello be generated until you call this method and >>>>> then start the handshaking on the returned SSLSocket? >>>> One can use SSLEngine.wrap()/unwrap() to generate handshaking messages >>>> from socket I/O stream. >>>> // accept a socket >>>> // read/write the I/O with SSLEngine >>>> // call this method >>> >>> Switching between SSLSocket/SSLEngine like that would require >>> intentional misuse of the API. You could make the same claim for >>> regular handshaking. >>> >>> Brad >>> >>>> Xuelei >>>> >>>>> You said in a >>>>> previous internal conversation that SSLExplore would not generate any >>>>> ServerHello, so this can't be what you mean. Are you talking about >>>>> layering another SSLSocket over a already layered SSLSocket? >>>>> >>>>>>> 2. "consumed network data is resumable" wasn't clear either. To me >>>>>>> this >>>>>>> should mean that you can obtain the data which has already been read >>>>>>> from "s". >>>>>>> >>>>>> Yes, need wordsmithing here. >>>>>> >>>>>>> 3. "Otherwise, the behavior of the return socket is not defined" >>>>>>> lost >>>>>>> me. Does this mean that that SSLParameters and assorted settings >>>>>>> are >>>>>>> not otherwise defined? >>>>>>> >>>>>> See above example. >>>>> >>>>> I think I need the above answered before I can comment further here. >>>>> >>>>>>> I think you could delete this paragraph. >>>>>>> >>>>>>> From your second email: >>>>>>> >>>>>>>> Thought more about the design, I would have to say that we cannot >>>>>>>> return >>>>>>>> the default value in sslParameters.getServerNames(). Otherwise, >>>>>>>> the >>>>>>>> following two block of codes look very weird to me: >>>>>>>> // case one: >>>>>>>> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>>>>>> 2 sslParameters.clearServerName("host_name"); >>>>>>>> 3 Map names = sslParameters.getServerNames(); >>>>>>>> 4 sslSocket.setSSLParameters(sslParameters); >>>>>>>> 5 sslParameters = sslSocket.getSSLParameters(); >>>>>>>> 6 names = sslParameters.getServerNames(); >>>>>>>> >>>>>>>> In line 3, the returned map does not contain "host_name" entry. >>>>>>>> But in >>>>>>>> line 6, it may be expected that no "host_name" in the returned >>>>>>>> map. But >>>>>>>> if we want to return default values, line 6 do need to return a map >>>>>>>> containing "host_name". The behavior is pretty confusing. We may >>>>>>>> want >>>>>>>> to try avoid the confusion. >>>>>>> >>>>>>> I'm not following your confusion, it seemed pretty >>>>>>> straightforward to >>>>>>> me, it works much like CipherSuites. We have a set of ciphersuites >>>>>>> which are enabled by default. We can turn some off by using >>>>>>> SSLParameters. Expanding a bit on your example here, I'll describe >>>>>>> what >>>>>>> I think would happen internally/externally: >>>>>>> >>>>>>> 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( >>>>>>> "www.example.com", 443); >>>>>>> >>>>>>> mySSLSocketFactory sets any initial parameters as usual. >>>>>>> SSLSocketImpl >>>>>>> knows it's connecting to www.example.com and automatically stores >>>>>>> "host_name" -> "www.example.com" in its local host data (map or >>>>>>> separate >>>>>>> variables). >>>>>>> >>>>>>> 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>>>>> >>>>>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, and >>>>>>> sets the >>>>>>> hostmap to the one value "host_name" -> "www.example.com" >>>>>>> >>>>>>> If the application want to get the "default values", they just pull >>>>>>> them >>>>>>> out of the SSLParameters here >>>>>>> >>>>>>> 3 sslParameters.clearServerName("host_name"); >>>>>>> >>>>>>> Or sslParameters.setServerName("host_name", null)? >>>>>>> >>>>>>> User just decided to clear it. Ok, that's what we do. It >>>>>>> becomes an >>>>>>> empty map in SSLParameters. >>>>>>> >>>>>>> 4 Map names = sslParameters.getServerNames(); >>>>>>> >>>>>>> Returns empty Map. >>>>>>> >>>>>> As far as good. >>>>>> >>>>>>> 5 sslSocket.setSSLParameters(sslParameters); >>>>>>> >>>>>>> SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this >>>>>>> SSLParameters and as a result, clears it's internal "host_name" >>>>>>> map to >>>>>>> null, and thus won't send anything out since it's empty. >>>>>>> >>>>>> We have problems here. We need to support that if an application >>>>>> does >>>>>> not specified host_name value, we should use default values. >>>>>> I. SSLParameters sslParameters = new SSLParameters(); >>>>>> II. sslParameters.setCipherSuites(...); >>>>>> III. SSLSocket sslSocket = >>>>>> sslSocketFactory.createSocket("www.example.com", 443) >>>>>> IV. sslSocket.setSSLParameters(sslParameters); >>>>>> >>>>>> Before line IV and after line II, the sslParameters.getServerNames() >>>>>> are >>>>>> empty. In line IV, we need to make sure the internal "host_name", >>>>>> "www.example.com" is used as default value, and send it to server in >>>>>> SNI. That's the default behaviors in JDK 7. We cannot break it >>>>>> without >>>>>> strong desires. >>>>>> >>>>>> I think it means that we cannot clear the internal "host_name" >>>>>> when the >>>>>> sslParameters.getServerNames() return empty. >>>>>> >>>>>> Does it make sense to you? >>>>> >>>>> Ok, that's an issue, I was assuming people would generally get a >>>>> SSLParameters from the SSLSocket/SSLEngine, which would have >>>>> prepopulated values such as CipherSuites/Protocols and SNI values. >>>>> Now I >>>>> hear what you're saying. >>>>> >>>>> So in SSLSocket/SSLEngine, we have a very similar situation with the >>>>> CipherSuites/Protocols. The way we did it there was if >>>>> SSLParameters.getCipherSuites() is null (that is, has not been set in >>>>> this instance), we let the default values stand (that is we did not >>>>> call >>>>> SSLSocket.setEnabledCipherSuites()). You could do something like that >>>>> with the SNI info. I've always felt the setServerName/getServerName >>>>> should take/return the same Map value, but you felt >>>>> strongly about a setServerName(String, String) so I didn't push >>>>> it. If >>>>> we didn't set this value, then the original value could stand. >>>>> >>>>> Maybe your current design addresses this in a better way, I'll have to >>>>> look at this in the morning, I still have a couple hours of home stuff >>>>> to do before I can go to bed. >>>>> >>>>> Brad >>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>>> 6 sslParameters = sslSocket.getSSLParameters(); >>>>>>> >>>>>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees >>>>>>> that there's no name indication, so it creates an empty name map and >>>>>>> stores in SSLParameters. >>>>>>> >>>>>>> 7 names = sslParameters.getServerNames(); >>>>>>> >>>>>>> returns empty. >>>>>>> >>>>>>> It's no longer the default value, because they have specifically >>>>>>> set the >>>>>>> value. >>>>>>> >>>>>>> HTH, >>>>>>> >>>>>>> Brad >>>>>> >>>>> >>>> >>> >> From sean.mullan at oracle.com Wed Aug 15 07:46:54 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Aug 2012 10:46:54 -0400 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502B0D5C.6080303@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> Message-ID: <502BB65E.1010207@oracle.com> On 08/14/2012 10:45 PM, Xuelei Fan wrote: > I only reply on the items that I may need more review. > > On 8/15/2012 7:54 AM, Brad Wetmore wrote: >>>> SSLParameters.java >>>> ================== >>>> 76: Not sure why you want/need a LinkedHashMap with only one currently >>>> defined NameType. Even if there were multiple types, I don't think that >>>> SNI requires an ordering. You also mention this in >>>> setAccessibleServerName, but not sure what purpose this serves. I'm not >>>> strongly against it, just wondering. >>>> >>> I am also not sure about the strong desire that the SNI should be >>> ordered. But Weijun prefers it to be ordered because he think the SNI in >>> RFC6066 is defined as an ordered sequence. >>> >>> struct { >>> ServerName server_name_list<1..2^16-1> >>> } ServerNameList; >> >> I've gone through RFC6066 pretty carefully, and I'm not seeing any >> indication that this should be ordered. >> >> In RFC 2246, if there is an ordering required, such as >> cipher_suites/compression/certs/cert_requests, it's specifically called >> out. For any other "lists", it is not specified. >> >> Section 7.4.1.2 >> >> The CipherSuite list, passed from the client to the server in the >> client hello message, contains the combinations of cryptographic >> algorithms supported by the client in order of the client's >> preference (favorite choice first). >> >> ...deleted... >> >> The client hello includes a list of compression algorithms supported >> by the client, ordered according to the client's preference. >> >> ...deleted... >> >> cipher_suites >> This is a list of the cryptographic options supported by the >> client, with the client's first preference first. >> >> ...deleted... >> >> compression_methods >> This is a list of the compression methods supported by the >> client, sorted by client preference. >> >> Section 7.4.2 >> >> certificate_list >> This is a sequence (chain) of X.509v3 certificates. The sender's >> certificate must come first in the list. >> >> Section 7.4.4 >> >> certificate_types >> This field is a list of the types of certificates requested, >> sorted in order of the server's preference. >> >> Weijun, did you see something else in your read of the spec that >> indicates an ordering? If not, maybe we should not put in the order >> wording now. If it turns out we do need it, we can always add that >> wording later in a later release, but it will be impossible to remove it >> if we add it now. >> > I think you are right. If Weijun has no other concerns, I will remove > related description. Doesn't a "List" imply it is ordered? I guess I'm ok with not putting any specific wording in right now, since there's likely only going to be one entry anyway, but if subsequent standard name types are defined later, order might become important for some reason. --Sean From weijun.wang at oracle.com Wed Aug 15 07:47:56 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Aug 2012 22:47:56 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502BB38C.5050900@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> <502B3D55.30604@oracle.com> <502B49A7.8000704@oracle.com> <502B4E95.7070105@oracle.com> <502BA45D.2060008@oracle.com> <502BACDD.10106@oracle.com> <502BB38C.5050900@oracle.com> Message-ID: <502BB69C.8080403@oracle.com> On 08/15/2012 10:34 PM, Xuelei Fan wrote: > On 8/15/2012 10:06 PM, Weijun Wang wrote: >> Some suggestions to SSLParameters: >> >> 1. Since you now decide to exclude the default SNI value from >> getServerNames(), maybe you can emphasis this by using "user-provided >> server name" in the spec. >> > I have a paragraph in setServerName: > * Note that the returned Map of > * {@link #setServerName(String, String)} does not contain the provider > * default server name types and values. > > Did you suggest to replace the "desired" with "user-provided" or > "user-specified"? Yes. > >> 2. At disableServerName(), maybe you can explicitly point out that "A >> disabled server name type cannot be used as a part of the server name >> indication in SSL/TLS handshaking, even if the provider has a default >> value for this server name type". >> > OK. > >> 3. isDisabledServerName, maybe isServerNameDisabled? Neither sounds >> perfect. >> > I'd like to collect more votes on the name. ;-) > >> 4. I just noticed that the type can be also "sni-". What if someone >> call setServerName("sni-0", "...")? Is it the same as calling >> setServerName(SNI_HOST_NAME, "...")? >> > Unspecified behavior. Maybe not, because of the value encoding method. > We may throw exception in Oracle provider. Other providers may want to > support "sni-32" or "principal" for its private server name type. I'm not sure. Suppose tomorrow the type nick_name(1) is supported and a customer begins using "sni-1". The day after tomorrow, Java is updated and we have a string "nick_name" for it. I guess you will make "sni-1" and "nick_home" equivalent so that the customer's app will still work? If so, why not start doing it today for "sni-0" and "host_name"? Thanks Max > > Thanks for the quick response! > > Xuelei > >> Thanks >> Max >> >> >> On 08/15/2012 09:30 PM, Xuelei Fan wrote: >>> This paragraph was removed in the latest update. Please ignore the >>> webrev_spec.04 and previous webrevs, and review webrev_spec.05. >>> >>> http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.05/ >>> >>> Thanks, >>> Xuelei >>> >>> On 8/15/2012 3:24 PM, Bradford Wetmore wrote: >>>> >>>> >>>>>> How would the ServerHello be generated until you call this method and >>>>>> then start the handshaking on the returned SSLSocket? >>>>> One can use SSLEngine.wrap()/unwrap() to generate handshaking messages >>>>> from socket I/O stream. >>>>> // accept a socket >>>>> // read/write the I/O with SSLEngine >>>>> // call this method >>>> >>>> Switching between SSLSocket/SSLEngine like that would require >>>> intentional misuse of the API. You could make the same claim for >>>> regular handshaking. >>>> >>>> Brad >>>> >>>>> Xuelei >>>>> >>>>>> You said in a >>>>>> previous internal conversation that SSLExplore would not generate any >>>>>> ServerHello, so this can't be what you mean. Are you talking about >>>>>> layering another SSLSocket over a already layered SSLSocket? >>>>>> >>>>>>>> 2. "consumed network data is resumable" wasn't clear either. To me >>>>>>>> this >>>>>>>> should mean that you can obtain the data which has already been read >>>>>>>> from "s". >>>>>>>> >>>>>>> Yes, need wordsmithing here. >>>>>>> >>>>>>>> 3. "Otherwise, the behavior of the return socket is not defined" >>>>>>>> lost >>>>>>>> me. Does this mean that that SSLParameters and assorted settings >>>>>>>> are >>>>>>>> not otherwise defined? >>>>>>>> >>>>>>> See above example. >>>>>> >>>>>> I think I need the above answered before I can comment further here. >>>>>> >>>>>>>> I think you could delete this paragraph. >>>>>>>> >>>>>>>> From your second email: >>>>>>>> >>>>>>>>> Thought more about the design, I would have to say that we cannot >>>>>>>>> return >>>>>>>>> the default value in sslParameters.getServerNames(). Otherwise, >>>>>>>>> the >>>>>>>>> following two block of codes look very weird to me: >>>>>>>>> // case one: >>>>>>>>> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>>>>>>> 2 sslParameters.clearServerName("host_name"); >>>>>>>>> 3 Map names = sslParameters.getServerNames(); >>>>>>>>> 4 sslSocket.setSSLParameters(sslParameters); >>>>>>>>> 5 sslParameters = sslSocket.getSSLParameters(); >>>>>>>>> 6 names = sslParameters.getServerNames(); >>>>>>>>> >>>>>>>>> In line 3, the returned map does not contain "host_name" entry. >>>>>>>>> But in >>>>>>>>> line 6, it may be expected that no "host_name" in the returned >>>>>>>>> map. But >>>>>>>>> if we want to return default values, line 6 do need to return a map >>>>>>>>> containing "host_name". The behavior is pretty confusing. We may >>>>>>>>> want >>>>>>>>> to try avoid the confusion. >>>>>>>> >>>>>>>> I'm not following your confusion, it seemed pretty >>>>>>>> straightforward to >>>>>>>> me, it works much like CipherSuites. We have a set of ciphersuites >>>>>>>> which are enabled by default. We can turn some off by using >>>>>>>> SSLParameters. Expanding a bit on your example here, I'll describe >>>>>>>> what >>>>>>>> I think would happen internally/externally: >>>>>>>> >>>>>>>> 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( >>>>>>>> "www.example.com", 443); >>>>>>>> >>>>>>>> mySSLSocketFactory sets any initial parameters as usual. >>>>>>>> SSLSocketImpl >>>>>>>> knows it's connecting to www.example.com and automatically stores >>>>>>>> "host_name" -> "www.example.com" in its local host data (map or >>>>>>>> separate >>>>>>>> variables). >>>>>>>> >>>>>>>> 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>>>>>> >>>>>>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, and >>>>>>>> sets the >>>>>>>> hostmap to the one value "host_name" -> "www.example.com" >>>>>>>> >>>>>>>> If the application want to get the "default values", they just pull >>>>>>>> them >>>>>>>> out of the SSLParameters here >>>>>>>> >>>>>>>> 3 sslParameters.clearServerName("host_name"); >>>>>>>> >>>>>>>> Or sslParameters.setServerName("host_name", null)? >>>>>>>> >>>>>>>> User just decided to clear it. Ok, that's what we do. It >>>>>>>> becomes an >>>>>>>> empty map in SSLParameters. >>>>>>>> >>>>>>>> 4 Map names = sslParameters.getServerNames(); >>>>>>>> >>>>>>>> Returns empty Map. >>>>>>>> >>>>>>> As far as good. >>>>>>> >>>>>>>> 5 sslSocket.setSSLParameters(sslParameters); >>>>>>>> >>>>>>>> SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this >>>>>>>> SSLParameters and as a result, clears it's internal "host_name" >>>>>>>> map to >>>>>>>> null, and thus won't send anything out since it's empty. >>>>>>>> >>>>>>> We have problems here. We need to support that if an application >>>>>>> does >>>>>>> not specified host_name value, we should use default values. >>>>>>> I. SSLParameters sslParameters = new SSLParameters(); >>>>>>> II. sslParameters.setCipherSuites(...); >>>>>>> III. SSLSocket sslSocket = >>>>>>> sslSocketFactory.createSocket("www.example.com", 443) >>>>>>> IV. sslSocket.setSSLParameters(sslParameters); >>>>>>> >>>>>>> Before line IV and after line II, the sslParameters.getServerNames() >>>>>>> are >>>>>>> empty. In line IV, we need to make sure the internal "host_name", >>>>>>> "www.example.com" is used as default value, and send it to server in >>>>>>> SNI. That's the default behaviors in JDK 7. We cannot break it >>>>>>> without >>>>>>> strong desires. >>>>>>> >>>>>>> I think it means that we cannot clear the internal "host_name" >>>>>>> when the >>>>>>> sslParameters.getServerNames() return empty. >>>>>>> >>>>>>> Does it make sense to you? >>>>>> >>>>>> Ok, that's an issue, I was assuming people would generally get a >>>>>> SSLParameters from the SSLSocket/SSLEngine, which would have >>>>>> prepopulated values such as CipherSuites/Protocols and SNI values. >>>>>> Now I >>>>>> hear what you're saying. >>>>>> >>>>>> So in SSLSocket/SSLEngine, we have a very similar situation with the >>>>>> CipherSuites/Protocols. The way we did it there was if >>>>>> SSLParameters.getCipherSuites() is null (that is, has not been set in >>>>>> this instance), we let the default values stand (that is we did not >>>>>> call >>>>>> SSLSocket.setEnabledCipherSuites()). You could do something like that >>>>>> with the SNI info. I've always felt the setServerName/getServerName >>>>>> should take/return the same Map value, but you felt >>>>>> strongly about a setServerName(String, String) so I didn't push >>>>>> it. If >>>>>> we didn't set this value, then the original value could stand. >>>>>> >>>>>> Maybe your current design addresses this in a better way, I'll have to >>>>>> look at this in the morning, I still have a couple hours of home stuff >>>>>> to do before I can go to bed. >>>>>> >>>>>> Brad >>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>>> 6 sslParameters = sslSocket.getSSLParameters(); >>>>>>>> >>>>>>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees >>>>>>>> that there's no name indication, so it creates an empty name map and >>>>>>>> stores in SSLParameters. >>>>>>>> >>>>>>>> 7 names = sslParameters.getServerNames(); >>>>>>>> >>>>>>>> returns empty. >>>>>>>> >>>>>>>> It's no longer the default value, because they have specifically >>>>>>>> set the >>>>>>>> value. >>>>>>>> >>>>>>>> HTH, >>>>>>>> >>>>>>>> Brad >>>>>>> >>>>>> >>>>> >>>> >>> > From weijun.wang at oracle.com Wed Aug 15 08:05:19 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Aug 2012 23:05:19 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502BB69C.8080403@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> <502B3D55.30604@oracle.com> <502B49A7.8000704@oracle.com> <502B4E95.7070105@oracle.com> <502BA45D.2060008@oracle.com> <502BACDD.10106@oracle.com> <502BB38C.5050900@oracle.com> <502BB69C.8080403@oracle.com> Message-ID: <502BBAAF.40709@oracle.com> >> >>> 4. I just noticed that the type can be also "sni-". What if someone >>> call setServerName("sni-0", "...")? Is it the same as calling >>> setServerName(SNI_HOST_NAME, "...")? >>> >> Unspecified behavior. Maybe not, because of the value encoding method. >> We may throw exception in Oracle provider. Other providers may want to >> support "sni-32" or "principal" for its private server name type. > > I'm not sure. Suppose tomorrow the type nick_name(1) is supported and a > customer begins using "sni-1". The day after tomorrow, Java is updated > and we have a string "nick_name" for it. I guess you will make "sni-1" > and "nick_home" equivalent so that the customer's app will still work? > If so, why not start doing it today for "sni-0" and "host_name"? In fact, I don't quite understand how this is used. On the client side, when the developer knows nick_name(1) is not yet supported by the current JDK, he will use the "sni-1" type so that the SNI will be correctly encoded. Then, JDK is updated and the name type is now "nick_name", but I believe the old app should still work, so "sni-1" should be still accepted and be equivalent to "nick_name". On the server side, the old JDK and new JDK would return different values for getServerNames(). It's likely that the user app will be broken if it cannot successfully predict the "nick_name" name and already support it. Therefore, seriously, I suggest we change Map to Map. Since we already defined SSLParamters constant for the types, the user won't feel uncomfortable. Thanks Max From Xuelei.Fan at Oracle.Com Wed Aug 15 09:02:12 2012 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Thu, 16 Aug 2012 00:02:12 +0800 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502BBAAF.40709@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> <502B3D55.30604@oracle.com> <502B49A7.8000704@oracle.com> <502B4E95.7070105@oracle.com> <502BA45D.2060008@oracle.com> <502BACDD.10106@oracle.com> <502BB38C.5050900@oracle.com> <502BB69C.8080403@oracle.com> <502BBAAF.40709@oracle.com> Message-ID: On Aug 15, 2012, at 11:05 PM, Weijun Wang wrote: >>> >>>> 4. I just noticed that the type can be also "sni-". What if someone >>>> call setServerName("sni-0", "...")? Is it the same as calling >>>> setServerName(SNI_HOST_NAME, "...")? >>>> >>> Unspecified behavior. Maybe not, because of the value encoding method. >>> We may throw exception in Oracle provider. Other providers may want to >>> support "sni-32" or "principal" for its private server name type. >> >> I'm not sure. Suppose tomorrow the type nick_name(1) is supported and a >> customer begins using "sni-1". The day after tomorrow, Java is updated >> and we have a string "nick_name" for it. I guess you will make "sni-1" >> and "nick_home" equivalent so that the customer's app will still work? >> If so, why not start doing it today for "sni-0" and "host_name"? > > In fact, I don't quite understand how this is used. On the client side, when the developer knows nick_name(1) is not yet supported by the current JDK, he will use the "sni-1" type so that the SNI will be correctly encoded. Then, JDK is updated and the name type is now "nick_name", but I believe the old app should still work, so "sni-1" should be still accepted and be equivalent to "nick_name". > > On the server side, the old JDK and new JDK would return different values for getServerNames(). It's likely that the user app will be broken if it cannot successfully predict the "nick_name" name and already support it. > > Therefore, seriously, I suggest we change Map to Map. Since we already defined SSLParamters constant for the types, the user won't feel uncomfortable. > We have to consider two things, the type and the encoding method of the value. For oracle provider, we will not support unknown type in SSLParameters because we don't know the encoding method. We support unknown type in session but we require the value is encoded in utf-8. I do not prefer integer for the type because from the integer type I cannot tell whether the type is unknown or not, and then cannot make sure what is the proper encoding according. For example, the old application does not know "nick-name", so the type integer is 1 and the value encoded as UTF-8, but what if the encoding is not UTF-8 in the formal spec? We will not be able to decode the value properly. Xuelei > Thanks > Max > From sean.mullan at oracle.com Wed Aug 15 10:38:51 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Aug 2012 13:38:51 -0400 Subject: JDK 8 Code Review Request: 6500133/6931888: CertificateParsingException for CDP In-Reply-To: <502B1CAE.1030101@oracle.com> References: <502B1CAE.1030101@oracle.com> Message-ID: <502BDEAB.7070508@oracle.com> This looks good to me. Couple of comments: 111: Can you add a comment, something like "Try parsing the URI again after encoding/escaping any illegal characters". 113-4: When this code was written there probably wasn't yet an IOException(String, Throwable) ctor. Now there is, so you can change this to: throw new IOException("invalid URI name:" + name, use2); There are also a couple other places in URIName where you can replace the same code using initCause with the IOExc ctor above. That's a low-risk refactoring you can include in this change. --Sean On 08/14/2012 11:51 PM, Jason Uh wrote: > Hi all, > > This change fixes -- > 6500133: CertificateParsingException for CRL Distribution Point with > blank; and > 6931888: Inconsistent behavior for invalid URI name in cert file > > CRs: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500133 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6931888 > > They are effectively duplicates, both regarding an exception thrown when > parsing CRL Distribution Point URIs with invalid characters, like a > space or backslash. This change uses > sun.net.www.ParseUtil.encodePath(String) to re-encode bad URIs. > > Webrev: http://cr.openjdk.java.net/~juh/6500133/webrev.00/ > > Thanks, > Jason From james.holmlund at oracle.com Wed Aug 15 13:49:54 2012 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Wed, 15 Aug 2012 20:49:54 +0000 Subject: hg: jdk8/tl/langtools: 7191449: update copyright year to match last edit in jdk8 langtools repository Message-ID: <20120815204957.4373F4753D@hg.openjdk.java.net> Changeset: 9d47f4850714 Author: jjh Date: 2012-08-15 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 7191449: update copyright year to match last edit in jdk8 langtools repository Reviewed-by: jjh Contributed-by: steve.sides at oracle.com ! make/jprt.properties ! make/tools/anttasks/CompilePropertiesTask.java ! make/tools/anttasks/GenStubsTask.java ! make/tools/anttasks/SelectToolTask.java ! make/tools/compileproperties/CompileProperties.java ! make/tools/genstubs/GenStubs.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.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/main/Main.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/api/7086261/T7086261.java ! test/tools/javac/api/T6397104.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java ! test/tools/javac/diags/examples/ApplicableMethodFound1.java ! test/tools/javac/diags/examples/IllegalDot.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.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/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/typevars/T7148242.java ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/parser/T4881269.java ! test/tools/javac/processing/TestWarnErrorCount.java From rob.mckenna at oracle.com Wed Aug 15 14:45:47 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 15 Aug 2012 21:45:47 +0000 Subject: hg: jdk8/tl/jdk: 6931128: (spec) File attribute tests fail when run as root. Message-ID: <20120815214616.DAD5F4753E@hg.openjdk.java.net> Changeset: da14e2c90bcb Author: robm Date: 2012-08-15 22:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da14e2c90bcb 6931128: (spec) File attribute tests fail when run as root. Reviewed-by: alanb ! src/share/classes/java/io/File.java ! test/java/io/File/Basic.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SetReadOnly.java ! test/java/io/File/SymLinks.java + test/java/io/File/Util.java From bradford.wetmore at oracle.com Wed Aug 15 16:35:06 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 15 Aug 2012 16:35:06 -0700 Subject: (2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension In-Reply-To: <502B7949.4020907@oracle.com> References: <50231907.9080606@oracle.com> <5023DF95.7040507@oracle.com> <502457B5.6020204@oracle.com> <5027A712.9080105@oracle.com> <502AE518.1050308@oracle.com> <502B0D5C.6080303@oracle.com> <502B7949.4020907@oracle.com> Message-ID: <502C322A.60202@oracle.com> On 8/15/2012 3:26 AM, Xuelei Fan wrote: > More comments about whether we are able to override the default value. > > On 8/15/2012 10:45 AM, Xuelei Fan wrote: >>>>>> Thought more about the design, I would have to say that we cannot return >>>>>> the default value in sslParameters.getServerNames(). Otherwise, the >>>>>> following two block of codes look very weird to me: >>>>>> // case one: >>>>>> 1 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>>>> 2 sslParameters.clearServerName("host_name"); >>>>>> 3 Map names = sslParameters.getServerNames(); >>>>>> 4 sslSocket.setSSLParameters(sslParameters); >>>>>> 5 sslParameters = sslSocket.getSSLParameters(); >>>>>> 6 names = sslParameters.getServerNames(); >>>>>> >>>>>> In line 3, the returned map does not contain "host_name" entry. But in >>>>>> line 6, it may be expected that no "host_name" in the returned map. But >>>>>> if we want to return default values, line 6 do need to return a map >>>>>> containing "host_name". The behavior is pretty confusing. We may want >>>>>> to try avoid the confusion. >>>> >>>> I'm not following your confusion, it seemed pretty straightforward to >>>> me, it works much like CipherSuites. We have a set of ciphersuites >>>> which are enabled by default. We can turn some off by using >>>> SSLParameters. > Compatibility is my concerns here. > > When the SSLParameters class was was introduced in JDK 6, > set/getCipherSuites() and set/getProtocols were new, so there was no > compatibility issue for these two pairs methods at that time, as they > were not used in old applications. > > In JDK 7, we introduced two new methods, set/getAlgorithmConstraints(). > We were luck that we cannot allow the override of default constraints > because of security consideration, I didn't quite follow this sentence. We do allow the override, right? Looking at SSLSocketImpl.setSSLParameters(): algorithmConstraints = params.getAlgorithmConstraints(); > and the concept of algorithm > constraints was new in JDK 7. So we needed not to consider the > compatibility issue too much between JDK 6 and 7 for this pair of methods. > > However, things get changed for the Server Name Inidication (SNI), > because in JDK 7 we have already support default SNI extension implicit. > We have to consider the compatibility issues more between JDK 7 and JDK > 8, we need to make sure the behaviors are consistent whenever we call > the set/getServerName(). If we allow override of default value, the > application may run into corner trap as the description in my previous mail. Not sure this is a problem, possibly I didn't explain my thought fully. > That's the background of my thoughts. Hope it helps you understand the > current design. Here's what I was trying to propose: SSLParameters: // Local storage like the other variables private Map sniNames = null; ...deleted... /** * Set the SNI Names. * * A null parameter means don't set anything. Nothing is set. * * disallow invalid String->null entries. * * valid String->String entries will be added to SNI extension * if there is a recognized Key type. */ public void setServerNames(Map map) /** * Returns a copy of the array of servernames or null if * none have been set. */ public Map getServerNames() SSLSocketImpl: synchronized public void setSSLParameters(SSLParameters params) { super.setSSLParameters(); ...deleted... Map sniNames = params.getServerNames(); if (sniNames != null) { sniNameStorage = sniNames.clone(); } synchronized public SSLParameters getSSLParameters() { SSLParameters params = super.getSSLParameters(); ...deleted... // sniNameStorage currently has one entry: // "host_name", "www.example.com" params.setServerNames = sniNameStorage.clone(); So looking at the two use cases you pointed out: 1. SSLParameters sslp = new SSLParameters() getServernames() would return null. When SSLSocketImpl.setSSLParameters is called, the null indicates there is nothing to set, and the default value remains. If app wants to set something here, it can, which would override the existing default. 2. SSLParameters sslp = SSLSocket.getSSLParameters() The SSLParameters will be populated with the SNI map value stored in SSLSocketImpl/SSLEngineImpl, and apps can do whatever they choose with the Map. When setSSLParameters is called, the potentially new values are just pushed back to the SNI. In this case, the application has full access to the default Map and can see what will be sent by default. In both cases, the default remains unless the application takes steps to change it. For applications, this is the same call model as setCipherSuites()/setProtocols(), but the magic happens at different levels. Am I missing something? > because in JDK 7 we have already support default SNI extension > implicit. We are just providing API access to that functionality. Brad > Thanks, > Xuelei > >>>> Expanding a bit on your example here, I'll describe what >>>> I think would happen internally/externally: >>>> >>>> 1 SSLSocket sslSocket = mySSLSocketFactory.createSocket( >>>> "www.example.com", 443); >>>> >>>> mySSLSocketFactory sets any initial parameters as usual. SSLSocketImpl >>>> knows it's connecting to www.example.com and automatically stores >>>> "host_name" -> "www.example.com" in its local host data (map or separate >>>> variables). >>>> >>>> 2 SSLparameters sslParameters = sslSocket.getSSLParameters(); >>>> >>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the >>>> hostmap to the one value "host_name" -> "www.example.com" >>>> >>>> If the application want to get the "default values", they just pull them >>>> out of the SSLParameters here >>>> >>>> 3 sslParameters.clearServerName("host_name"); >>>> >>>> Or sslParameters.setServerName("host_name", null)? >>>> >>>> User just decided to clear it. Ok, that's what we do. It becomes an >>>> empty map in SSLParameters. >>>> >>>> 4 Map names = sslParameters.getServerNames(); >>>> >>>> Returns empty Map. >>>> >> As far as good. >> >>>> 5 sslSocket.setSSLParameters(sslParameters); >>>> >>>> SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this >>>> SSLParameters and as a result, clears it's internal "host_name" map to >>>> null, and thus won't send anything out since it's empty. >>>> >> We have problems here. We need to support that if an application does >> not specified host_name value, we should use default values. >> I. SSLParameters sslParameters = new SSLParameters(); >> II. sslParameters.setCipherSuites(...); >> III. SSLSocket sslSocket = >> sslSocketFactory.createSocket("www.example.com", 443) >> IV. sslSocket.setSSLParameters(sslParameters); >> >> Before line IV and after line II, the sslParameters.getServerNames() are >> empty. In line IV, we need to make sure the internal "host_name", >> "www.example.com" is used as default value, and send it to server in >> SNI. That's the default behaviors in JDK 7. We cannot break it without >> strong desires. >> >> I think it means that we cannot clear the internal "host_name" when the >> sslParameters.getServerNames() return empty. >> >> Does it make sense to you? >> >> Thanks, >> Xuelei >> >>>> 6 sslParameters = sslSocket.getSSLParameters(); >>>> >>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees >>>> that there's no name indication, so it creates an empty name map and >>>> stores in SSLParameters. >>>> >>>> 7 names = sslParameters.getServerNames(); >>>> >>>> returns empty. >>>> >>>> It's no longer the default value, because they have specifically set the >>>> value. >>>> >>>> HTH, >>>> >>>> Brad > From jason.uh at oracle.com Wed Aug 15 16:37:47 2012 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 15 Aug 2012 16:37:47 -0700 Subject: JDK 8 Code Review Request: 6500133/6931888: CertificateParsingException for CDP In-Reply-To: <502BDEAB.7070508@oracle.com> References: <502B1CAE.1030101@oracle.com> <502BDEAB.7070508@oracle.com> Message-ID: <502C32CB.7060200@oracle.com> Thanks, Sean. New webrev updated with your suggestions: http://cr.openjdk.java.net/~juh/6500133/webrev.01/ Jason On 08/15/2012 10:38 AM, Sean Mullan wrote: > This looks good to me. Couple of comments: > > 111: Can you add a comment, something like "Try parsing the URI again > after encoding/escaping any illegal characters". > > 113-4: When this code was written there probably wasn't yet an > IOException(String, Throwable) ctor. Now there is, so you can change > this to: > > throw new IOException("invalid URI name:" + name, use2); > > There are also a couple other places in URIName where you can replace > the same code using initCause with the IOExc ctor above. That's a > low-risk refactoring you can include in this change. > > --Sean > > On 08/14/2012 11:51 PM, Jason Uh wrote: >> Hi all, >> >> This change fixes -- >> 6500133: CertificateParsingException for CRL Distribution Point with >> blank; and >> 6931888: Inconsistent behavior for invalid URI name in cert file >> >> CRs: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500133 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6931888 >> >> They are effectively duplicates, both regarding an exception thrown when >> parsing CRL Distribution Point URIs with invalid characters, like a >> space or backslash. This change uses >> sun.net.www.ParseUtil.encodePath(String) to re-encode bad URIs. >> >> Webrev: http://cr.openjdk.java.net/~juh/6500133/webrev.00/ >> >> Thanks, >> Jason > From sean.coffey at oracle.com Thu Aug 16 02:32:58 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 16 Aug 2012 09:32:58 +0000 Subject: hg: jdk8/tl/jdk: 7056731: Race condition in CORBA code causes re-use of ABORTed connections Message-ID: <20120816093349.7EF9C47550@hg.openjdk.java.net> Changeset: 39b01268b845 Author: coffeys Date: 2012-08-16 10:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b01268b845 7056731: Race condition in CORBA code causes re-use of ABORTed connections Reviewed-by: lancea Contributed-by: d.macdonald at auckland.ac.nz ! test/Makefile + test/com/sun/corba/cachedSocket/7056731.sh + test/com/sun/corba/cachedSocket/Hello.idl + test/com/sun/corba/cachedSocket/HelloClient.java + test/com/sun/corba/cachedSocket/HelloServer.java From sean.coffey at oracle.com Thu Aug 16 02:34:28 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 16 Aug 2012 09:34:28 +0000 Subject: hg: jdk8/tl/corba: 7056731: Race condition in CORBA code causes re-use of ABORTed connections Message-ID: <20120816093431.6142B47551@hg.openjdk.java.net> Changeset: 18a02ad8dc73 Author: coffeys Date: 2012-08-16 10:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/18a02ad8dc73 7056731: Race condition in CORBA code causes re-use of ABORTed connections Reviewed-by: lancea Contributed-by: d.macdonald at auckland.ac.nz ! src/share/classes/com/sun/corba/se/impl/transport/CorbaResponseWaitingRoomImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java From sean.coffey at oracle.com Thu Aug 16 02:46:06 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 16 Aug 2012 09:46:06 +0000 Subject: hg: jdk8/tl/jdk: 7185965: Build error in javadoc make stage for bundles not containing crypto package Message-ID: <20120816094633.1DA8047552@hg.openjdk.java.net> Changeset: 56d8756749bd Author: coffeys Date: 2012-08-16 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56d8756749bd 7185965: Build error in javadoc make stage for bundles not containing crypto package Reviewed-by: chegar ! make/common/shared/Defs-java.gmk From alan.bateman at oracle.com Thu Aug 16 03:19:54 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Aug 2012 10:19:54 +0000 Subject: hg: jdk8/tl/jdk: 7191556: (fs) UnixNativeDispatcher.getextmntent should be moved into platform specific code Message-ID: <20120816102027.68A4047555@hg.openjdk.java.net> Changeset: e48a9a1c14e3 Author: alanb Date: 2012-08-16 11:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e48a9a1c14e3 7191556: (fs) UnixNativeDispatcher.getextmntent should be moved into platform specific code Reviewed-by: andrew ! make/java/nio/Makefile ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c ! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c ! src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c ! src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c From alan.bateman at oracle.com Thu Aug 16 03:42:55 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Aug 2012 10:42:55 +0000 Subject: hg: jdk8/tl/jdk: 7191892: ProblemList.txt updates (8/2012) Message-ID: <20120816104317.4D07A47556@hg.openjdk.java.net> Changeset: 4fb8792725d5 Author: alanb Date: 2012-08-16 11:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fb8792725d5 7191892: ProblemList.txt updates (8/2012) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt From alan.bateman at oracle.com Thu Aug 16 06:35:49 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Aug 2012 13:35:49 +0000 Subject: hg: jdk8/tl/jdk: 7132247: java/rmi/registry/readTest/readTest.sh failing with Cygwin Message-ID: <20120816133612.A8DEF4755A@hg.openjdk.java.net> Changeset: e50a39d011b5 Author: alanb Date: 2012-08-16 14:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e50a39d011b5 7132247: java/rmi/registry/readTest/readTest.sh failing with Cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/rmi/registry/readTest/readTest.sh From bruno at distributedmatter.net Thu Aug 16 15:26:38 2012 From: bruno at distributedmatter.net (Bruno Harbulot) Date: Thu, 16 Aug 2012 23:26:38 +0100 Subject: RFC 6125 and host name verification in Java 7+ Message-ID: Hello, Looking at the Javadoc for X509ExtendedTrustManager, it seems that the algorithms supported by SSLParameters.setEndpointIdentificationAlgorithm(...) are "HTTPS" and "LDAPS". The Javadoc for SSLParameters points to the standard names and provider documentation, but I can't find any mention of these algorithms anywhere. Are there any others? I'm not sure if there is much awareness for it, but there is an RFC that aims to harmonise the best practices for server name identification across protocols: RFC 6125, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)". (In practice, it's actually quite close to the HTTPS rules from RFC 2818.) I'd just like to suggest that further versions of the JDK/JRE could support an "RFC6125" algorithm in addition to the existing ones, since it's meant to be independent of the application protocol (perhaps all this could be enabled by default too, to prevent cases where users don't verify the host name at all). Best wishes, Bruno. From xuelei.fan at oracle.com Thu Aug 16 19:09:50 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 17 Aug 2012 10:09:50 +0800 Subject: RFC 6125 and host name verification in Java 7+ In-Reply-To: References: Message-ID: <502DA7EE.9060806@oracle.com> On 8/17/2012 6:26 AM, Bruno Harbulot wrote: > Hello, > > Looking at the Javadoc for X509ExtendedTrustManager, it seems that the > algorithms supported by > SSLParameters.setEndpointIdentificationAlgorithm(...) are "HTTPS" and > "LDAPS". The Javadoc for SSLParameters points to the standard names > and provider documentation, but I can't find any mention of these > algorithms anywhere. Are there any others? > In the pointed doc, did you noticed that there is an link to "Standard Names document"? It is the place to hold standard name now. You can click the bellow link directly: http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html and search for "LDAPS" or "HTTPS". > I'm not sure if there is much awareness for it, but there is an RFC > that aims to harmonise the best practices for server name > identification across protocols: RFC 6125, "Representation and > Verification of Domain-Based Application Service Identity within > Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in > the Context of Transport Layer Security (TLS)". (In practice, it's > actually quite close to the HTTPS rules from RFC 2818.) > > I'd just like to suggest that further versions of the JDK/JRE could > support an "RFC6125" algorithm in addition to the existing ones, since > it's meant to be independent of the application protocol (perhaps all > this could be enabled by default too, to prevent cases where users > don't verify the host name at all). > Thanks for the suggestion. I will log the feature request. Thanks, Xuelei > Best wishes, > > Bruno. > From weijun.wang at oracle.com Thu Aug 16 20:55:52 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 Aug 2012 11:55:52 +0800 Subject: Code review request: 7192202: Make sure keytool prints both unknown and unparseable extensions In-Reply-To: <13961171.1345174597674.JavaMail.sbladm@swsblss4-new.central.sun.com> References: <13961171.1345174597674.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <502DC0C8.80407@oracle.com> Hi Jason and/or Sean Here is a new test to deal with unparseable extensions. This time I've hardcoded two extensions that are likely to stay illegal forever: :) 1. An extension using 1.2.3.4 as OID 2. A KeyUsage extension with raw value 56:78 (in hex) Please take a look: http://cr.openjdk.java.net/~weijun/7192202/webrev.00/ noreg-self. Thanks Max -------- Original Message -------- 7192202: Make sure keytool prints both unknown and unparseable extensions Product: java Category: java Subcategory: classes_security Type: Defect Subtype: Status: 3-Accepted Substatus: Priority: 4-Low Introduced In Release: Introduced In Build: === *Description* ============================================================ Add a new test to confirm the behavior. From luchsh at linux.vnet.ibm.com Fri Aug 17 02:15:38 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Fri, 17 Aug 2012 09:15:38 +0000 Subject: hg: jdk8/tl/jdk: 7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to support more unix-like platforms Message-ID: <20120817091746.C6ED04759F@hg.openjdk.java.net> Changeset: 4993f8aa7f2e Author: dingxmin Date: 2012-08-17 17:10 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4993f8aa7f2e 7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to support more unix-like platforms Reviewed-by: chegar ! src/solaris/native/java/net/PlainDatagramSocketImpl.c From weijun.wang at oracle.com Fri Aug 17 03:18:05 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 Aug 2012 18:18:05 +0800 Subject: Request for comment: Supporting password expiration alert in JAAS Message-ID: <502E1A5D.7090009@oracle.com> 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 sean.mullan at oracle.com Fri Aug 17 07:55:08 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Aug 2012 10:55:08 -0400 Subject: Code review request: 7192202: Make sure keytool prints both unknown and unparseable extensions In-Reply-To: <502DC0C8.80407@oracle.com> References: <13961171.1345174597674.JavaMail.sbladm@swsblss4-new.central.sun.com> <502DC0C8.80407@oracle.com> Message-ID: <502E5B4C.7020805@oracle.com> This looks good to me. --Sean On 08/16/2012 11:55 PM, Weijun Wang wrote: > Hi Jason and/or Sean > > Here is a new test to deal with unparseable extensions. This time I've > hardcoded two extensions that are likely to stay illegal forever: :) > > 1. An extension using 1.2.3.4 as OID > 2. A KeyUsage extension with raw value 56:78 (in hex) > > Please take a look: > > http://cr.openjdk.java.net/~weijun/7192202/webrev.00/ > > noreg-self. > > Thanks > Max > > > -------- Original Message -------- > 7192202: Make sure keytool prints both unknown and unparseable extensions > > Product: java > Category: java > Subcategory: classes_security > Type: Defect > Subtype: > Status: 3-Accepted > Substatus: > Priority: 4-Low > Introduced In Release: > Introduced In Build: > > === *Description* > ============================================================ > Add a new test to confirm the behavior. > From huizhe.wang at oracle.com Fri Aug 17 09:47:27 2012 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 17 Aug 2012 16:47:27 +0000 Subject: hg: jdk8/tl/jaxp: 7191547: XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected Message-ID: <20120817164731.96CBA475B1@hg.openjdk.java.net> Changeset: 2946807a6d7f Author: joehw Date: 2012-08-17 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2946807a6d7f 7191547: XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected Summary: similar to the patch for 6756677 for XMLInputFactory and XMLOutputFactory, this patch fixes an error in XMLEventFactory where factoryId was taken as factory class. Reviewed-by: lancea ! src/javax/xml/stream/XMLEventFactory.java From sean.mullan at oracle.com Fri Aug 17 10:54:58 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Aug 2012 13:54:58 -0400 Subject: JDK 8 Code Review Request: 6500133/6931888: CertificateParsingException for CDP In-Reply-To: <502C32CB.7060200@oracle.com> References: <502B1CAE.1030101@oracle.com> <502BDEAB.7070508@oracle.com> <502C32CB.7060200@oracle.com> Message-ID: <502E8572.7080704@oracle.com> Looks good. I'll push the changeset for you. --Sean On 08/15/2012 07:37 PM, Jason Uh wrote: > Thanks, Sean. > > New webrev updated with your suggestions: > http://cr.openjdk.java.net/~juh/6500133/webrev.01/ > > Jason > > On 08/15/2012 10:38 AM, Sean Mullan wrote: >> This looks good to me. Couple of comments: >> >> 111: Can you add a comment, something like "Try parsing the URI again >> after encoding/escaping any illegal characters". >> >> 113-4: When this code was written there probably wasn't yet an >> IOException(String, Throwable) ctor. Now there is, so you can change >> this to: >> >> throw new IOException("invalid URI name:" + name, use2); >> >> There are also a couple other places in URIName where you can replace >> the same code using initCause with the IOExc ctor above. That's a >> low-risk refactoring you can include in this change. >> >> --Sean >> >> On 08/14/2012 11:51 PM, Jason Uh wrote: >>> Hi all, >>> >>> This change fixes -- >>> 6500133: CertificateParsingException for CRL Distribution Point with >>> blank; and >>> 6931888: Inconsistent behavior for invalid URI name in cert file >>> >>> CRs: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500133 >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6931888 >>> >>> They are effectively duplicates, both regarding an exception thrown when >>> parsing CRL Distribution Point URIs with invalid characters, like a >>> space or backslash. This change uses >>> sun.net.www.ParseUtil.encodePath(String) to re-encode bad URIs. >>> >>> Webrev: http://cr.openjdk.java.net/~juh/6500133/webrev.00/ >>> >>> Thanks, >>> Jason >> From sean.mullan at oracle.com Fri Aug 17 11:36:09 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 17 Aug 2012 18:36:09 +0000 Subject: hg: jdk8/tl/jdk: 6500133: REGRESSION: CertificateParsingException for CRL Distribution Point with blank Message-ID: <20120817183630.404F8475B3@hg.openjdk.java.net> Changeset: 6b2ebf3c4964 Author: mullan Date: 2012-08-17 14:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b2ebf3c4964 6500133: REGRESSION: CertificateParsingException for CRL Distribution Point with blank Reviewed-by: mullan Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/x509/URIName.java + test/sun/security/x509/URIName/Parse.java From daniel.daugherty at oracle.com Fri Aug 17 12:53:33 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 17 Aug 2012 19:53:33 +0000 Subject: hg: jdk8/tl/jdk: 7191322: add test for 7064927 to java.lang.instrument Message-ID: <20120817195352.E35B9475B6@hg.openjdk.java.net> Changeset: 509421263cdd Author: dcubed Date: 2012-08-17 12:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/509421263cdd 7191322: add test for 7064927 to java.lang.instrument Summary: Add support for canRetransform attribute to the test manager. Add test for 7064927. Reviewed-by: dsamersoff, sspitsyn, ohair ! test/java/lang/instrument/ATransformerManagementTestCase.java + test/java/lang/instrument/DummyClassWithLVT.java + test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java + test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh + test/java/lang/instrument/retransformAgent.mf From jonathan.gibbons at oracle.com Fri Aug 17 17:30:26 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 18 Aug 2012 00:30:26 +0000 Subject: hg: jdk8/tl/langtools: 7192449: fix up tests to accommodate jtreg spec change Message-ID: <20120818003031.31DB1475B9@hg.openjdk.java.net> Changeset: 5ac2e9ee969e Author: jjg Date: 2012-08-17 17:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5ac2e9ee969e 7192449: fix up tests to accommodate jtreg spec change Reviewed-by: darcy ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java From kumar.x.srinivasan at oracle.com Sat Aug 18 05:17:11 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 18 Aug 2012 12:17:11 +0000 Subject: hg: jdk8/tl/jdk: 7190750: (pack200) the java unpacker produces non spec. compliant classfile with lambda classfiles Message-ID: <20120818121739.E1A6F475C3@hg.openjdk.java.net> Changeset: 16f2865aac24 Author: ksrini Date: 2012-08-17 08:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16f2865aac24 7190750: (pack200) the java unpacker produces non spec. compliant classfile with lambda classfiles Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java From alan.bateman at oracle.com Sun Aug 19 05:06:11 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Aug 2012 12:06:11 +0000 Subject: hg: jdk8/tl/jdk: 7192275: Minimize LogManager dependencies on java.beans Message-ID: <20120819120704.462214762F@hg.openjdk.java.net> Changeset: a2359f0f9533 Author: alanb Date: 2012-08-19 13:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2359f0f9533 7192275: Minimize LogManager dependencies on java.beans Summary: Reduce dependency to PropertyChangeListener and PropertyChangeEvent. Also add basic test coverage. Reviewed-by: dcubed, dsamersoff, mchung ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/Listeners.java + test/java/util/logging/ListenersWithSM.java + test/java/util/logging/java.policy From alan.bateman at oracle.com Sun Aug 19 05:30:25 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Aug 2012 12:30:25 +0000 Subject: hg: jdk8/tl/jdk: 7191467: (fs) WatchService periodically fails to queue ENTRY_DELETE event for short lived file [sol11] Message-ID: <20120819123045.5436247630@hg.openjdk.java.net> Changeset: 5e7cfe034df4 Author: alanb Date: 2012-08-19 13:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7cfe034df4 7191467: (fs) WatchService periodically fails to queue ENTRY_DELETE event for short lived file [sol11] Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! test/java/nio/file/WatchService/MayFlies.java From weijun.wang at oracle.com Sun Aug 19 17:00:18 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 20 Aug 2012 00:00:18 +0000 Subject: hg: jdk8/tl/jdk: 7192202: Make sure keytool prints both unknown and unparseable extensions Message-ID: <20120820000050.9204147635@hg.openjdk.java.net> Changeset: 86c963b1dbf8 Author: weijun Date: 2012-08-20 07:59 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86c963b1dbf8 7192202: Make sure keytool prints both unknown and unparseable extensions Reviewed-by: mullan + test/sun/security/tools/keytool/UnknownAndUnparseable.java From weijun.wang at oracle.com Mon Aug 20 06:32:45 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 20 Aug 2012 21:32:45 +0800 Subject: Code review request: 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix In-Reply-To: <15904831.1345469487949.JavaMail.sbladm@swsblss4-new.central.sun.com> References: <15904831.1345469487949.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <50323C7D.6000805@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/7152121/webrev.00/ This fix will also be backported to a 7u release. Thanks Max -------- Original Message -------- 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix === *Description* ============================================================ In JDK 6, one can specify keyTab="file:/etc/krb5/krb5.tab" for Krb5LoginModule in a JAAS login config file. In JDK 7, we rewrote the keytab codes and this is not supported anymore. From rob.mckenna at oracle.com Mon Aug 20 06:50:34 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Mon, 20 Aug 2012 13:50:34 +0000 Subject: hg: jdk8/tl/jdk: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 Message-ID: <20120820135100.E98944763F@hg.openjdk.java.net> Changeset: 59aa7660ade4 Author: robm Date: 2012-08-20 14:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59aa7660ade4 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 Reviewed-by: dholmes, alanb ! test/java/lang/ProcessBuilder/Basic.java From 1983-01-06 at gmx.net Sat Aug 18 03:01:33 2012 From: 1983-01-06 at gmx.net (Michael-O) Date: Sat, 18 Aug 2012 12:01:33 +0200 Subject: Backport bug 7179796 to JDK 6 and JDK 7 Message-ID: <502F67FD.6010807@gmx.net> Hi, I reported that issue two month ago. This was fixed for trunk/JDK 8(b51) only. Can this trivial fix be backported to JDK 6 and 7 to? Thanks, Mike From sundararajan.athijegannathan at oracle.com Mon Aug 20 08:52:11 2012 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 20 Aug 2012 15:52:11 +0000 Subject: hg: jdk8/tl/langtools: 7181320: javac NullPointerException for switch labels with cast to String expressions Message-ID: <20120820155215.0C83D47641@hg.openjdk.java.net> Changeset: 464f52f59f7d Author: sundar Date: 2012-08-20 21:24 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/464f52f59f7d 7181320: javac NullPointerException for switch labels with cast to String expressions Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/StringsInSwitch/7181320/BinOpInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CastInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel1.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel2.java From jonathan.gibbons at oracle.com Mon Aug 20 13:50:39 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 20 Aug 2012 20:50:39 +0000 Subject: hg: jdk8/tl/langtools: 7192744: fix up tests to accommodate jtreg spec change Message-ID: <20120820205043.5BB7B4764C@hg.openjdk.java.net> Changeset: 37008b4cd97a Author: jjg Date: 2012-08-20 13:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/37008b4cd97a 7192744: fix up tests to accommodate jtreg spec change Reviewed-by: darcy ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/T6920317.java From alan.bateman at oracle.com Tue Aug 21 05:45:35 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 21 Aug 2012 12:45:35 +0000 Subject: hg: jdk8/tl/jdk: 7132889: (se) AbstractSelectableChannel.register and configureBlocking not safe from asynchronous close Message-ID: <20120821124603.52E8E4765B@hg.openjdk.java.net> Changeset: 6d29c2af040f Author: alanb Date: 2012-08-21 13:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d29c2af040f 7132889: (se) AbstractSelectableChannel.register and configureBlocking not safe from asynchronous close Reviewed-by: alanb Contributed-by: Shirish Kuncolienkar ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java + test/java/nio/channels/SelectionKey/RacyRegister.java From naoto.sato at oracle.com Tue Aug 21 11:03:47 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 21 Aug 2012 18:03:47 +0000 Subject: hg: jdk8/tl/jdk: 6336885: RFE: Locale Data Deployment Enhancements; ... Message-ID: <20120821180407.CD1CF4766A@hg.openjdk.java.net> Changeset: 131a683a2ce0 Author: naoto Date: 2012-08-21 11:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/131a683a2ce0 6336885: RFE: Locale Data Deployment Enhancements 4609153: Provide locale data for Indic locales 5104387: Support for gl_ES locale (galician language) 6337471: desktop/system locale preferences support 7056139: (cal) SPI support for locale-dependent Calendar parameters 7058206: Provide CalendarData SPI for week params and display field value names 7073852: Support multiple scripts for digits and decimal symbols per locale 7079560: [Fmt-Da] Context dependent month names support in SimpleDateFormat 7171324: getAvailableLocales() of locale sensitive services should return the actual availability of locales 7151414: (cal) Support calendar type identification 7168528: LocaleServiceProvider needs to be aware of Locale extensions 7171372: (cal) locale's default Calendar should be created if unknown calendar is specified Summary: JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (part 1 w/o packaging changes. by Naoto Sato and Masayoshi Okutsu) Reviewed-by: erikj, sherman, peytoia ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/FILES_java.gmk ! make/java/java/Makefile ! make/java/java/genlocales.gmk ! make/java/java/localegen.sh ! make/java/java/mapfile-vers ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! make/java/util/Makefile ! make/sun/Makefile + make/sun/cldr/Makefile ! make/sun/text/FILES_java.gmk ! make/sun/text/FILES_properties.gmk ! make/sun/text/Makefile ! make/tools/Makefile + make/tools/cldrconverter/Makefile + make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java + make/tools/src/build/tools/cldrconverter/Bundle.java + make/tools/src/build/tools/cldrconverter/BundleGenerator.java + make/tools/src/build/tools/cldrconverter/CLDRConverter.java + make/tools/src/build/tools/cldrconverter/CalendarType.java + make/tools/src/build/tools/cldrconverter/Container.java + make/tools/src/build/tools/cldrconverter/CopyrightHeaders.java + make/tools/src/build/tools/cldrconverter/Entry.java + make/tools/src/build/tools/cldrconverter/IgnoredContainer.java + make/tools/src/build/tools/cldrconverter/KeyContainer.java + make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java + make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java + make/tools/src/build/tools/cldrconverter/NumberingSystemsParseHandler.java + make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java + make/tools/src/build/tools/cldrconverter/StringArrayElement.java + make/tools/src/build/tools/cldrconverter/StringArrayEntry.java + make/tools/src/build/tools/cldrconverter/StringEntry.java + make/tools/src/build/tools/cldrconverter/SupplementDataParseHandler.java + make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java ! make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GenerateJavaSources.gmk + makefiles/GensrcCLDR.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcProperties.gmk ! makefiles/Tools.gmk + src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java + src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c - src/share/classes/java/text/BreakDictionary.java ! src/share/classes/java/text/BreakIterator.java - src/share/classes/java/text/CollationRules.java ! src/share/classes/java/text/Collator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java - src/share/classes/java/text/DictionaryBasedBreakIterator.java ! src/share/classes/java/text/NumberFormat.java - src/share/classes/java/text/RuleBasedBreakIterator.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/text/spi/DecimalFormatSymbolsProvider.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/TimeZone.java + src/share/classes/java/util/spi/CalendarDataProvider.java ! src/share/classes/java/util/spi/CurrencyNameProvider.java ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/javax/swing/JSpinner.java - src/share/classes/sun/text/resources/BreakIteratorInfo_th.java - src/share/classes/sun/text/resources/BreakIteratorRules_th.java - src/share/classes/sun/text/resources/CollationData_ar.java - src/share/classes/sun/text/resources/CollationData_be.java - src/share/classes/sun/text/resources/CollationData_bg.java - src/share/classes/sun/text/resources/CollationData_ca.java - src/share/classes/sun/text/resources/CollationData_cs.java - src/share/classes/sun/text/resources/CollationData_da.java - src/share/classes/sun/text/resources/CollationData_de.java - src/share/classes/sun/text/resources/CollationData_el.java - src/share/classes/sun/text/resources/CollationData_en.java - src/share/classes/sun/text/resources/CollationData_es.java - src/share/classes/sun/text/resources/CollationData_et.java - src/share/classes/sun/text/resources/CollationData_fi.java - src/share/classes/sun/text/resources/CollationData_fr.java - src/share/classes/sun/text/resources/CollationData_hi.java - src/share/classes/sun/text/resources/CollationData_hr.java - src/share/classes/sun/text/resources/CollationData_hu.java - src/share/classes/sun/text/resources/CollationData_is.java - src/share/classes/sun/text/resources/CollationData_it.java - src/share/classes/sun/text/resources/CollationData_iw.java - src/share/classes/sun/text/resources/CollationData_ja.java - src/share/classes/sun/text/resources/CollationData_ko.java - src/share/classes/sun/text/resources/CollationData_lt.java - src/share/classes/sun/text/resources/CollationData_lv.java - src/share/classes/sun/text/resources/CollationData_mk.java - src/share/classes/sun/text/resources/CollationData_nl.java - src/share/classes/sun/text/resources/CollationData_no.java - src/share/classes/sun/text/resources/CollationData_pl.java - src/share/classes/sun/text/resources/CollationData_pt.java - src/share/classes/sun/text/resources/CollationData_ro.java - src/share/classes/sun/text/resources/CollationData_ru.java - src/share/classes/sun/text/resources/CollationData_sk.java - src/share/classes/sun/text/resources/CollationData_sl.java - src/share/classes/sun/text/resources/CollationData_sq.java - src/share/classes/sun/text/resources/CollationData_sr.java - src/share/classes/sun/text/resources/CollationData_sr_Latn.java - src/share/classes/sun/text/resources/CollationData_sv.java - src/share/classes/sun/text/resources/CollationData_th.java - src/share/classes/sun/text/resources/CollationData_tr.java - src/share/classes/sun/text/resources/CollationData_uk.java - src/share/classes/sun/text/resources/CollationData_vi.java - src/share/classes/sun/text/resources/CollationData_zh.java - src/share/classes/sun/text/resources/CollationData_zh_HK.java - src/share/classes/sun/text/resources/CollationData_zh_TW.java ! src/share/classes/sun/text/resources/FormatData.java - src/share/classes/sun/text/resources/FormatData_ar.java - src/share/classes/sun/text/resources/FormatData_ar_AE.java - src/share/classes/sun/text/resources/FormatData_ar_BH.java - src/share/classes/sun/text/resources/FormatData_ar_DZ.java - src/share/classes/sun/text/resources/FormatData_ar_EG.java - src/share/classes/sun/text/resources/FormatData_ar_IQ.java - src/share/classes/sun/text/resources/FormatData_ar_JO.java - src/share/classes/sun/text/resources/FormatData_ar_KW.java - src/share/classes/sun/text/resources/FormatData_ar_LB.java - src/share/classes/sun/text/resources/FormatData_ar_LY.java - src/share/classes/sun/text/resources/FormatData_ar_MA.java - src/share/classes/sun/text/resources/FormatData_ar_OM.java - src/share/classes/sun/text/resources/FormatData_ar_QA.java - src/share/classes/sun/text/resources/FormatData_ar_SA.java - src/share/classes/sun/text/resources/FormatData_ar_SD.java - src/share/classes/sun/text/resources/FormatData_ar_SY.java - src/share/classes/sun/text/resources/FormatData_ar_TN.java - src/share/classes/sun/text/resources/FormatData_ar_YE.java - src/share/classes/sun/text/resources/FormatData_be.java - src/share/classes/sun/text/resources/FormatData_be_BY.java - src/share/classes/sun/text/resources/FormatData_bg.java - src/share/classes/sun/text/resources/FormatData_bg_BG.java - src/share/classes/sun/text/resources/FormatData_ca.java - src/share/classes/sun/text/resources/FormatData_ca_ES.java - src/share/classes/sun/text/resources/FormatData_cs.java - src/share/classes/sun/text/resources/FormatData_cs_CZ.java - src/share/classes/sun/text/resources/FormatData_da.java - src/share/classes/sun/text/resources/FormatData_da_DK.java - src/share/classes/sun/text/resources/FormatData_de.java - src/share/classes/sun/text/resources/FormatData_de_AT.java - src/share/classes/sun/text/resources/FormatData_de_CH.java - src/share/classes/sun/text/resources/FormatData_de_DE.java - src/share/classes/sun/text/resources/FormatData_de_LU.java - src/share/classes/sun/text/resources/FormatData_el.java - src/share/classes/sun/text/resources/FormatData_el_CY.java - src/share/classes/sun/text/resources/FormatData_el_GR.java - src/share/classes/sun/text/resources/FormatData_en.java - src/share/classes/sun/text/resources/FormatData_en_AU.java - src/share/classes/sun/text/resources/FormatData_en_CA.java - src/share/classes/sun/text/resources/FormatData_en_GB.java - src/share/classes/sun/text/resources/FormatData_en_IE.java - src/share/classes/sun/text/resources/FormatData_en_IN.java - src/share/classes/sun/text/resources/FormatData_en_MT.java - src/share/classes/sun/text/resources/FormatData_en_NZ.java - src/share/classes/sun/text/resources/FormatData_en_PH.java - src/share/classes/sun/text/resources/FormatData_en_SG.java - src/share/classes/sun/text/resources/FormatData_en_US.java - src/share/classes/sun/text/resources/FormatData_en_ZA.java - src/share/classes/sun/text/resources/FormatData_es.java - src/share/classes/sun/text/resources/FormatData_es_AR.java - src/share/classes/sun/text/resources/FormatData_es_BO.java - src/share/classes/sun/text/resources/FormatData_es_CL.java - src/share/classes/sun/text/resources/FormatData_es_CO.java - src/share/classes/sun/text/resources/FormatData_es_CR.java - src/share/classes/sun/text/resources/FormatData_es_DO.java - src/share/classes/sun/text/resources/FormatData_es_EC.java - src/share/classes/sun/text/resources/FormatData_es_ES.java - src/share/classes/sun/text/resources/FormatData_es_GT.java - src/share/classes/sun/text/resources/FormatData_es_HN.java - src/share/classes/sun/text/resources/FormatData_es_MX.java - src/share/classes/sun/text/resources/FormatData_es_NI.java - src/share/classes/sun/text/resources/FormatData_es_PA.java - src/share/classes/sun/text/resources/FormatData_es_PE.java - src/share/classes/sun/text/resources/FormatData_es_PR.java - src/share/classes/sun/text/resources/FormatData_es_PY.java - src/share/classes/sun/text/resources/FormatData_es_SV.java - src/share/classes/sun/text/resources/FormatData_es_US.java - src/share/classes/sun/text/resources/FormatData_es_UY.java - src/share/classes/sun/text/resources/FormatData_es_VE.java - src/share/classes/sun/text/resources/FormatData_et.java - src/share/classes/sun/text/resources/FormatData_et_EE.java - src/share/classes/sun/text/resources/FormatData_fi.java - src/share/classes/sun/text/resources/FormatData_fi_FI.java - src/share/classes/sun/text/resources/FormatData_fr.java - src/share/classes/sun/text/resources/FormatData_fr_BE.java - src/share/classes/sun/text/resources/FormatData_fr_CA.java - src/share/classes/sun/text/resources/FormatData_fr_CH.java - src/share/classes/sun/text/resources/FormatData_fr_FR.java - src/share/classes/sun/text/resources/FormatData_fr_LU.java - src/share/classes/sun/text/resources/FormatData_ga.java - src/share/classes/sun/text/resources/FormatData_ga_IE.java - src/share/classes/sun/text/resources/FormatData_hi_IN.java - src/share/classes/sun/text/resources/FormatData_hr.java - src/share/classes/sun/text/resources/FormatData_hr_HR.java - src/share/classes/sun/text/resources/FormatData_hu.java - src/share/classes/sun/text/resources/FormatData_hu_HU.java - src/share/classes/sun/text/resources/FormatData_in.java - src/share/classes/sun/text/resources/FormatData_in_ID.java - src/share/classes/sun/text/resources/FormatData_is.java - src/share/classes/sun/text/resources/FormatData_is_IS.java - src/share/classes/sun/text/resources/FormatData_it.java - src/share/classes/sun/text/resources/FormatData_it_CH.java - src/share/classes/sun/text/resources/FormatData_it_IT.java - src/share/classes/sun/text/resources/FormatData_iw.java - src/share/classes/sun/text/resources/FormatData_iw_IL.java - src/share/classes/sun/text/resources/FormatData_ja.java - src/share/classes/sun/text/resources/FormatData_ja_JP.java - src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java - src/share/classes/sun/text/resources/FormatData_ko.java - src/share/classes/sun/text/resources/FormatData_ko_KR.java - src/share/classes/sun/text/resources/FormatData_lt.java - src/share/classes/sun/text/resources/FormatData_lt_LT.java - src/share/classes/sun/text/resources/FormatData_lv.java - src/share/classes/sun/text/resources/FormatData_lv_LV.java - src/share/classes/sun/text/resources/FormatData_mk.java - src/share/classes/sun/text/resources/FormatData_mk_MK.java - src/share/classes/sun/text/resources/FormatData_ms.java - src/share/classes/sun/text/resources/FormatData_ms_MY.java - src/share/classes/sun/text/resources/FormatData_mt.java - src/share/classes/sun/text/resources/FormatData_mt_MT.java - src/share/classes/sun/text/resources/FormatData_nl.java - src/share/classes/sun/text/resources/FormatData_nl_BE.java - src/share/classes/sun/text/resources/FormatData_nl_NL.java - src/share/classes/sun/text/resources/FormatData_no.java - src/share/classes/sun/text/resources/FormatData_no_NO.java - src/share/classes/sun/text/resources/FormatData_no_NO_NY.java - src/share/classes/sun/text/resources/FormatData_pl.java - src/share/classes/sun/text/resources/FormatData_pl_PL.java - src/share/classes/sun/text/resources/FormatData_pt.java - src/share/classes/sun/text/resources/FormatData_pt_BR.java - src/share/classes/sun/text/resources/FormatData_pt_PT.java - src/share/classes/sun/text/resources/FormatData_ro.java - src/share/classes/sun/text/resources/FormatData_ro_RO.java - src/share/classes/sun/text/resources/FormatData_ru.java - src/share/classes/sun/text/resources/FormatData_ru_RU.java - src/share/classes/sun/text/resources/FormatData_sk.java - src/share/classes/sun/text/resources/FormatData_sk_SK.java - src/share/classes/sun/text/resources/FormatData_sl.java - src/share/classes/sun/text/resources/FormatData_sl_SI.java - src/share/classes/sun/text/resources/FormatData_sq.java - src/share/classes/sun/text/resources/FormatData_sq_AL.java - src/share/classes/sun/text/resources/FormatData_sr.java - src/share/classes/sun/text/resources/FormatData_sr_BA.java - src/share/classes/sun/text/resources/FormatData_sr_CS.java - src/share/classes/sun/text/resources/FormatData_sr_Latn.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java - src/share/classes/sun/text/resources/FormatData_sr_ME.java - src/share/classes/sun/text/resources/FormatData_sr_RS.java - src/share/classes/sun/text/resources/FormatData_sv.java - src/share/classes/sun/text/resources/FormatData_sv_SE.java - src/share/classes/sun/text/resources/FormatData_th.java - src/share/classes/sun/text/resources/FormatData_th_TH.java - src/share/classes/sun/text/resources/FormatData_th_TH_TH.java - src/share/classes/sun/text/resources/FormatData_tr.java - src/share/classes/sun/text/resources/FormatData_tr_TR.java - src/share/classes/sun/text/resources/FormatData_uk.java - src/share/classes/sun/text/resources/FormatData_uk_UA.java - src/share/classes/sun/text/resources/FormatData_vi.java - src/share/classes/sun/text/resources/FormatData_vi_VN.java - src/share/classes/sun/text/resources/FormatData_zh.java - src/share/classes/sun/text/resources/FormatData_zh_CN.java - src/share/classes/sun/text/resources/FormatData_zh_HK.java - src/share/classes/sun/text/resources/FormatData_zh_SG.java - src/share/classes/sun/text/resources/FormatData_zh_TW.java + src/share/classes/sun/text/resources/ar/CollationData_ar.java + src/share/classes/sun/text/resources/ar/FormatData_ar.java + src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java + src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java + src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java + src/share/classes/sun/text/resources/be/CollationData_be.java + src/share/classes/sun/text/resources/be/FormatData_be.java + src/share/classes/sun/text/resources/be/FormatData_be_BY.java + src/share/classes/sun/text/resources/bg/CollationData_bg.java + src/share/classes/sun/text/resources/bg/FormatData_bg.java + src/share/classes/sun/text/resources/bg/FormatData_bg_BG.java + src/share/classes/sun/text/resources/ca/CollationData_ca.java + src/share/classes/sun/text/resources/ca/FormatData_ca.java + src/share/classes/sun/text/resources/ca/FormatData_ca_ES.java + src/share/classes/sun/text/resources/cs/CollationData_cs.java + src/share/classes/sun/text/resources/cs/FormatData_cs.java + src/share/classes/sun/text/resources/cs/FormatData_cs_CZ.java + src/share/classes/sun/text/resources/da/CollationData_da.java + src/share/classes/sun/text/resources/da/FormatData_da.java + src/share/classes/sun/text/resources/da/FormatData_da_DK.java + src/share/classes/sun/text/resources/de/FormatData_de.java + src/share/classes/sun/text/resources/de/FormatData_de_AT.java + src/share/classes/sun/text/resources/de/FormatData_de_CH.java + src/share/classes/sun/text/resources/de/FormatData_de_DE.java + src/share/classes/sun/text/resources/de/FormatData_de_LU.java + src/share/classes/sun/text/resources/el/CollationData_el.java + src/share/classes/sun/text/resources/el/FormatData_el.java + src/share/classes/sun/text/resources/el/FormatData_el_CY.java + src/share/classes/sun/text/resources/el/FormatData_el_GR.java + src/share/classes/sun/text/resources/en/FormatData_en.java + src/share/classes/sun/text/resources/en/FormatData_en_AU.java + src/share/classes/sun/text/resources/en/FormatData_en_CA.java + src/share/classes/sun/text/resources/en/FormatData_en_GB.java + src/share/classes/sun/text/resources/en/FormatData_en_IE.java + src/share/classes/sun/text/resources/en/FormatData_en_IN.java + src/share/classes/sun/text/resources/en/FormatData_en_MT.java + src/share/classes/sun/text/resources/en/FormatData_en_NZ.java + src/share/classes/sun/text/resources/en/FormatData_en_PH.java + src/share/classes/sun/text/resources/en/FormatData_en_SG.java + src/share/classes/sun/text/resources/en/FormatData_en_US.java + src/share/classes/sun/text/resources/en/FormatData_en_ZA.java + src/share/classes/sun/text/resources/es/CollationData_es.java + src/share/classes/sun/text/resources/es/FormatData_es.java + src/share/classes/sun/text/resources/es/FormatData_es_AR.java + src/share/classes/sun/text/resources/es/FormatData_es_BO.java + src/share/classes/sun/text/resources/es/FormatData_es_CL.java + src/share/classes/sun/text/resources/es/FormatData_es_CO.java + src/share/classes/sun/text/resources/es/FormatData_es_CR.java + src/share/classes/sun/text/resources/es/FormatData_es_DO.java + src/share/classes/sun/text/resources/es/FormatData_es_EC.java + src/share/classes/sun/text/resources/es/FormatData_es_ES.java + src/share/classes/sun/text/resources/es/FormatData_es_GT.java + src/share/classes/sun/text/resources/es/FormatData_es_HN.java + src/share/classes/sun/text/resources/es/FormatData_es_MX.java + src/share/classes/sun/text/resources/es/FormatData_es_NI.java + src/share/classes/sun/text/resources/es/FormatData_es_PA.java + src/share/classes/sun/text/resources/es/FormatData_es_PE.java + src/share/classes/sun/text/resources/es/FormatData_es_PR.java + src/share/classes/sun/text/resources/es/FormatData_es_PY.java + src/share/classes/sun/text/resources/es/FormatData_es_SV.java + src/share/classes/sun/text/resources/es/FormatData_es_US.java + src/share/classes/sun/text/resources/es/FormatData_es_UY.java + src/share/classes/sun/text/resources/es/FormatData_es_VE.java + src/share/classes/sun/text/resources/et/CollationData_et.java + src/share/classes/sun/text/resources/et/FormatData_et.java + src/share/classes/sun/text/resources/et/FormatData_et_EE.java + src/share/classes/sun/text/resources/fi/CollationData_fi.java + src/share/classes/sun/text/resources/fi/FormatData_fi.java + src/share/classes/sun/text/resources/fi/FormatData_fi_FI.java + src/share/classes/sun/text/resources/fr/CollationData_fr.java + src/share/classes/sun/text/resources/fr/FormatData_fr.java + src/share/classes/sun/text/resources/fr/FormatData_fr_BE.java + src/share/classes/sun/text/resources/fr/FormatData_fr_CA.java + src/share/classes/sun/text/resources/fr/FormatData_fr_CH.java + src/share/classes/sun/text/resources/fr/FormatData_fr_FR.java + src/share/classes/sun/text/resources/ga/FormatData_ga.java + src/share/classes/sun/text/resources/ga/FormatData_ga_IE.java + src/share/classes/sun/text/resources/hi/CollationData_hi.java + src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java + src/share/classes/sun/text/resources/hr/CollationData_hr.java + src/share/classes/sun/text/resources/hr/FormatData_hr.java + src/share/classes/sun/text/resources/hr/FormatData_hr_HR.java + src/share/classes/sun/text/resources/hu/CollationData_hu.java + src/share/classes/sun/text/resources/hu/FormatData_hu.java + src/share/classes/sun/text/resources/hu/FormatData_hu_HU.java + src/share/classes/sun/text/resources/in/FormatData_in.java + src/share/classes/sun/text/resources/in/FormatData_in_ID.java + src/share/classes/sun/text/resources/is/CollationData_is.java + src/share/classes/sun/text/resources/is/FormatData_is.java + src/share/classes/sun/text/resources/is/FormatData_is_IS.java + src/share/classes/sun/text/resources/it/FormatData_it.java + src/share/classes/sun/text/resources/it/FormatData_it_CH.java + src/share/classes/sun/text/resources/it/FormatData_it_IT.java + src/share/classes/sun/text/resources/iw/CollationData_iw.java + src/share/classes/sun/text/resources/iw/FormatData_iw.java + src/share/classes/sun/text/resources/iw/FormatData_iw_IL.java + src/share/classes/sun/text/resources/ja/CollationData_ja.java + src/share/classes/sun/text/resources/ja/FormatData_ja.java + src/share/classes/sun/text/resources/ja/FormatData_ja_JP.java + src/share/classes/sun/text/resources/ko/CollationData_ko.java + src/share/classes/sun/text/resources/ko/FormatData_ko.java + src/share/classes/sun/text/resources/ko/FormatData_ko_KR.java + src/share/classes/sun/text/resources/lt/CollationData_lt.java + src/share/classes/sun/text/resources/lt/FormatData_lt.java + src/share/classes/sun/text/resources/lt/FormatData_lt_LT.java + src/share/classes/sun/text/resources/lv/CollationData_lv.java + src/share/classes/sun/text/resources/lv/FormatData_lv.java + src/share/classes/sun/text/resources/lv/FormatData_lv_LV.java + src/share/classes/sun/text/resources/mk/CollationData_mk.java + src/share/classes/sun/text/resources/mk/FormatData_mk.java + src/share/classes/sun/text/resources/mk/FormatData_mk_MK.java + src/share/classes/sun/text/resources/ms/FormatData_ms.java + src/share/classes/sun/text/resources/ms/FormatData_ms_MY.java + src/share/classes/sun/text/resources/mt/FormatData_mt.java + src/share/classes/sun/text/resources/mt/FormatData_mt_MT.java + src/share/classes/sun/text/resources/nl/FormatData_nl.java + src/share/classes/sun/text/resources/nl/FormatData_nl_BE.java + src/share/classes/sun/text/resources/nl/FormatData_nl_NL.java + src/share/classes/sun/text/resources/no/CollationData_no.java + src/share/classes/sun/text/resources/no/FormatData_no.java + src/share/classes/sun/text/resources/no/FormatData_no_NO.java + src/share/classes/sun/text/resources/no/FormatData_no_NO_NY.java + src/share/classes/sun/text/resources/pl/CollationData_pl.java + src/share/classes/sun/text/resources/pl/FormatData_pl.java + src/share/classes/sun/text/resources/pl/FormatData_pl_PL.java + src/share/classes/sun/text/resources/pt/FormatData_pt.java + src/share/classes/sun/text/resources/pt/FormatData_pt_BR.java + src/share/classes/sun/text/resources/pt/FormatData_pt_PT.java + src/share/classes/sun/text/resources/ro/CollationData_ro.java + src/share/classes/sun/text/resources/ro/FormatData_ro.java + src/share/classes/sun/text/resources/ro/FormatData_ro_RO.java + src/share/classes/sun/text/resources/ru/CollationData_ru.java + src/share/classes/sun/text/resources/ru/FormatData_ru.java + src/share/classes/sun/text/resources/ru/FormatData_ru_RU.java + src/share/classes/sun/text/resources/sk/CollationData_sk.java + src/share/classes/sun/text/resources/sk/FormatData_sk.java + src/share/classes/sun/text/resources/sk/FormatData_sk_SK.java + src/share/classes/sun/text/resources/sl/CollationData_sl.java + src/share/classes/sun/text/resources/sl/FormatData_sl.java + src/share/classes/sun/text/resources/sl/FormatData_sl_SI.java + src/share/classes/sun/text/resources/sq/CollationData_sq.java + src/share/classes/sun/text/resources/sq/FormatData_sq.java + src/share/classes/sun/text/resources/sq/FormatData_sq_AL.java + src/share/classes/sun/text/resources/sr/CollationData_sr.java + src/share/classes/sun/text/resources/sr/CollationData_sr_Latn.java + src/share/classes/sun/text/resources/sr/FormatData_sr.java + src/share/classes/sun/text/resources/sr/FormatData_sr_BA.java + src/share/classes/sun/text/resources/sr/FormatData_sr_CS.java + src/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java + src/share/classes/sun/text/resources/sr/FormatData_sr_Latn_ME.java + src/share/classes/sun/text/resources/sr/FormatData_sr_ME.java + src/share/classes/sun/text/resources/sr/FormatData_sr_RS.java + src/share/classes/sun/text/resources/sv/CollationData_sv.java + src/share/classes/sun/text/resources/sv/FormatData_sv.java + src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java + src/share/classes/sun/text/resources/th/BreakIteratorInfo_th.java + src/share/classes/sun/text/resources/th/BreakIteratorRules_th.java + src/share/classes/sun/text/resources/th/CollationData_th.java + src/share/classes/sun/text/resources/th/FormatData_th.java + src/share/classes/sun/text/resources/th/FormatData_th_TH.java + src/share/classes/sun/text/resources/th/thai_dict - src/share/classes/sun/text/resources/thai_dict + src/share/classes/sun/text/resources/tr/CollationData_tr.java + src/share/classes/sun/text/resources/tr/FormatData_tr.java + src/share/classes/sun/text/resources/tr/FormatData_tr_TR.java + src/share/classes/sun/text/resources/uk/CollationData_uk.java + src/share/classes/sun/text/resources/uk/FormatData_uk.java + src/share/classes/sun/text/resources/uk/FormatData_uk_UA.java + src/share/classes/sun/text/resources/vi/CollationData_vi.java + src/share/classes/sun/text/resources/vi/FormatData_vi.java + src/share/classes/sun/text/resources/vi/FormatData_vi_VN.java + src/share/classes/sun/text/resources/zh/CollationData_zh.java + src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java + src/share/classes/sun/text/resources/zh/CollationData_zh_TW.java + src/share/classes/sun/text/resources/zh/FormatData_zh.java + src/share/classes/sun/text/resources/zh/FormatData_zh_CN.java + src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java + src/share/classes/sun/text/resources/zh/FormatData_zh_SG.java + src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java ! src/share/classes/sun/util/BuddhistCalendar.java - src/share/classes/sun/util/EmptyListResourceBundle.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template - src/share/classes/sun/util/LocaleServiceProviderPool.java - src/share/classes/sun/util/TimeZoneNameUtility.java + src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java + src/share/classes/sun/util/cldr/resources/21_0_1/LICENSE + src/share/classes/sun/util/cldr/resources/21_0_1/common/dtd/ldml.dtd + src/share/classes/sun/util/cldr/resources/21_0_1/common/dtd/ldmlSupplemental.dtd + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ak.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ak_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/am.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/am_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_001.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_AE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_BH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_DZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_EG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_IQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_JO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_KW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_LB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_LY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_OM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_QA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_TN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_YE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/as.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/as_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/asa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/asa_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Cyrl_AZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Latn_AZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bas.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bas_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/be.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/be_BY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bem.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bem_ZM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bez.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bez_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bg_BG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bm_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn_BD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/br.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/br_FR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/brx.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/brx_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bs.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bs_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/byn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/byn_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ca.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ca_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cgg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cgg_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/chr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/chr_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cs.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cs_CZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cy_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/da.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/da_DK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dav.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dav_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_AT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_DE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_LI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_LU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dje.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dje_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dua.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dua_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dyo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dyo_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dz_BT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ebu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ebu_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee_TG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el_CY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el_GR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_AS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_AU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_CA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_Dsrt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_Dsrt_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_IE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_JM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_NZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_PH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_SG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_TT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_UM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_US_POSIX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_VI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_419.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_AR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_BO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_DO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_EC.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_GQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_GT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_HN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_MX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_NI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_SV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_UY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_VE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/et.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/et_EE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eu_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ewo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ewo_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa_IR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ff.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ff_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fi_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fil.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fil_PH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fo_FO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_FR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_KM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_LU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MC.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_RE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_RW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_TD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_TG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_YT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fur.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fur_IT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ga.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ga_IE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gd.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gd_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gl_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gsw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gsw_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gu_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/guz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/guz_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gv_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/haw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/haw_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/he.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/he_IL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hi_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hr_HR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hu_HU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hy_AM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ia.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/id.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/id_ID.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ig.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ig_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ii.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ii_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/is.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/is_IS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it_IT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja_JP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/jmc.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/jmc_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ka.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ka_GE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kab_DZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kam.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kam_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kde.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kde_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kea.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kea_CV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/khq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/khq_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ki.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ki_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk_Cyrl_KZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kl_GL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kln.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kln_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/km.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/km_KH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kn_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ko.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ko_KR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kok.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kok_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksb.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksb_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksf.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksf_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksh_DE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kw_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lag.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lag_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lg_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln_CG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lo_LA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lt_LT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lu_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luo_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luy_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lv_LV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mer.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mer_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mfe.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mfe_MU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mg_MG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mgh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mgh_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mk_MK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ml.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ml_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mr_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms_BN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms_MY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mt_MT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mua.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mua_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/my.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/my_MM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/naq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/naq_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nb.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nb_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nd.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nd_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne_NP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_AW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_CW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_NL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_SX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nmg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nmg_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nn_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nr_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nso.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nso_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nus.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nus_SD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nyn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nyn_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/or.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/or_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Arab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Arab_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Guru.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Guru_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pl_PL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ps.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ps_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_AO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_BR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_GW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_PT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_ST.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rm_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rn_BI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro_MD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro_RO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rof.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rof_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/root.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_MD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_RU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_UA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rw_RW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rwk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rwk_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sah.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sah_RU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/saq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/saq_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sbp.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sbp_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/seh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/seh_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ses.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ses_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sg_CF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Latn_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Tfng.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Tfng_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/si.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/si_LK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sk_SK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sl_SI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sn_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_SO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sq_AL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_ME.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_RS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_ME.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_RS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss_SZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ssy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ssy_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st_LS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv_SE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/swc.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/swc_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta_LK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/te.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/te_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg_Cyrl_TJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/th.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/th_TH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tig.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tig_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tn_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/to.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/to_TO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tr_TR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ts.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ts_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/twq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/twq_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm_Latn_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uk_UA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Arab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Arab_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Cyrl_UZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Latn_UZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Latn_LR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Vaii.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Vaii_LR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ve.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ve_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vi_VN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vun.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vun_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wae.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wae_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wal.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wal_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xh_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xog.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xog_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yav.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yav_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yo_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_MO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_SG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_MO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_TW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zu_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/metaZones.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/numberingSystems.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/supplementalData.xml ! src/share/classes/sun/util/locale/LocaleUtils.java + src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/AvailableLanguageTags.java + src/share/classes/sun/util/locale/provider/BreakDictionary.java + src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java + src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java + src/share/classes/sun/util/locale/provider/CalendarDataUtility.java + src/share/classes/sun/util/locale/provider/CollationRules.java + src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java + src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java + src/share/classes/sun/util/locale/provider/DateFormatProviderImpl.java + src/share/classes/sun/util/locale/provider/DateFormatSymbolsProviderImpl.java + src/share/classes/sun/util/locale/provider/DecimalFormatSymbolsProviderImpl.java + src/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java + src/share/classes/sun/util/locale/provider/HostLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/JRELocaleConstants.java + src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template + src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java + src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/LocaleResources.java + src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java + src/share/classes/sun/util/locale/provider/NumberFormatProviderImpl.java + src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java + src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java + src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java - src/share/classes/sun/util/resources/CalendarData_ar.properties - src/share/classes/sun/util/resources/CalendarData_be.properties - src/share/classes/sun/util/resources/CalendarData_bg.properties - src/share/classes/sun/util/resources/CalendarData_ca.properties - src/share/classes/sun/util/resources/CalendarData_cs.properties - src/share/classes/sun/util/resources/CalendarData_da.properties - src/share/classes/sun/util/resources/CalendarData_de.properties - src/share/classes/sun/util/resources/CalendarData_el.properties - src/share/classes/sun/util/resources/CalendarData_el_CY.properties - src/share/classes/sun/util/resources/CalendarData_en.properties - src/share/classes/sun/util/resources/CalendarData_en_GB.properties - src/share/classes/sun/util/resources/CalendarData_en_IE.properties - src/share/classes/sun/util/resources/CalendarData_en_MT.properties - src/share/classes/sun/util/resources/CalendarData_es.properties - src/share/classes/sun/util/resources/CalendarData_es_ES.properties - src/share/classes/sun/util/resources/CalendarData_es_US.properties - src/share/classes/sun/util/resources/CalendarData_et.properties - src/share/classes/sun/util/resources/CalendarData_fi.properties - src/share/classes/sun/util/resources/CalendarData_fr.properties - src/share/classes/sun/util/resources/CalendarData_fr_CA.properties - src/share/classes/sun/util/resources/CalendarData_hi.properties - src/share/classes/sun/util/resources/CalendarData_hr.properties - src/share/classes/sun/util/resources/CalendarData_hu.properties - src/share/classes/sun/util/resources/CalendarData_in_ID.properties - src/share/classes/sun/util/resources/CalendarData_is.properties - src/share/classes/sun/util/resources/CalendarData_it.properties - src/share/classes/sun/util/resources/CalendarData_iw.properties - src/share/classes/sun/util/resources/CalendarData_ja.properties - src/share/classes/sun/util/resources/CalendarData_ko.properties - src/share/classes/sun/util/resources/CalendarData_lt.properties - src/share/classes/sun/util/resources/CalendarData_lv.properties - src/share/classes/sun/util/resources/CalendarData_mk.properties - src/share/classes/sun/util/resources/CalendarData_ms_MY.properties - src/share/classes/sun/util/resources/CalendarData_mt.properties - src/share/classes/sun/util/resources/CalendarData_mt_MT.properties - src/share/classes/sun/util/resources/CalendarData_nl.properties - src/share/classes/sun/util/resources/CalendarData_no.properties - src/share/classes/sun/util/resources/CalendarData_pl.properties - src/share/classes/sun/util/resources/CalendarData_pt.properties - src/share/classes/sun/util/resources/CalendarData_pt_PT.properties - src/share/classes/sun/util/resources/CalendarData_ro.properties - src/share/classes/sun/util/resources/CalendarData_ru.properties - src/share/classes/sun/util/resources/CalendarData_sk.properties - src/share/classes/sun/util/resources/CalendarData_sl.properties - src/share/classes/sun/util/resources/CalendarData_sq.properties - src/share/classes/sun/util/resources/CalendarData_sr.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CalendarData_sv.properties - src/share/classes/sun/util/resources/CalendarData_th.properties - src/share/classes/sun/util/resources/CalendarData_tr.properties - src/share/classes/sun/util/resources/CalendarData_uk.properties - src/share/classes/sun/util/resources/CalendarData_vi.properties - src/share/classes/sun/util/resources/CalendarData_zh.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties - src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties - src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties - src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties - src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties - src/share/classes/sun/util/resources/CurrencyNames_de.properties - src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties - src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties - src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties - src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties - src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties - src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties - src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties - src/share/classes/sun/util/resources/CurrencyNames_en_US.properties - src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties - src/share/classes/sun/util/resources/CurrencyNames_es.properties - src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties - src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties - src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties - src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties - src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties - src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties - src/share/classes/sun/util/resources/CurrencyNames_es_US.properties - src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties - src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties - src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties - src/share/classes/sun/util/resources/CurrencyNames_fr.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties - src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties - src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties - src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties - src/share/classes/sun/util/resources/CurrencyNames_it.properties - src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties - src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties - src/share/classes/sun/util/resources/CurrencyNames_ja.properties - src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties - src/share/classes/sun/util/resources/CurrencyNames_ko.properties - src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties - src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties - src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties - src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties - src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties - src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties - src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties - src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties - src/share/classes/sun/util/resources/CurrencyNames_pt.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties - src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties - src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties - src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties - src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties - src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sv.properties - src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties - src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties - src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties - src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties - src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java - src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java - src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/LocaleData.java - src/share/classes/sun/util/resources/LocaleNames_ar.properties - src/share/classes/sun/util/resources/LocaleNames_be.properties - src/share/classes/sun/util/resources/LocaleNames_bg.properties - src/share/classes/sun/util/resources/LocaleNames_ca.properties - src/share/classes/sun/util/resources/LocaleNames_cs.properties - src/share/classes/sun/util/resources/LocaleNames_da.properties - src/share/classes/sun/util/resources/LocaleNames_de.properties - src/share/classes/sun/util/resources/LocaleNames_el.properties - src/share/classes/sun/util/resources/LocaleNames_el_CY.properties - src/share/classes/sun/util/resources/LocaleNames_en.properties - src/share/classes/sun/util/resources/LocaleNames_en_MT.properties - src/share/classes/sun/util/resources/LocaleNames_en_PH.properties - src/share/classes/sun/util/resources/LocaleNames_en_SG.properties - src/share/classes/sun/util/resources/LocaleNames_es.properties - src/share/classes/sun/util/resources/LocaleNames_es_US.properties - src/share/classes/sun/util/resources/LocaleNames_et.properties - src/share/classes/sun/util/resources/LocaleNames_fi.properties - src/share/classes/sun/util/resources/LocaleNames_fr.properties - src/share/classes/sun/util/resources/LocaleNames_ga.properties - src/share/classes/sun/util/resources/LocaleNames_hi.properties - src/share/classes/sun/util/resources/LocaleNames_hr.properties - src/share/classes/sun/util/resources/LocaleNames_hu.properties - src/share/classes/sun/util/resources/LocaleNames_in.properties - src/share/classes/sun/util/resources/LocaleNames_is.properties - src/share/classes/sun/util/resources/LocaleNames_it.properties - src/share/classes/sun/util/resources/LocaleNames_iw.properties - src/share/classes/sun/util/resources/LocaleNames_ja.properties - src/share/classes/sun/util/resources/LocaleNames_ko.properties - src/share/classes/sun/util/resources/LocaleNames_lt.properties - src/share/classes/sun/util/resources/LocaleNames_lv.properties - src/share/classes/sun/util/resources/LocaleNames_mk.properties - src/share/classes/sun/util/resources/LocaleNames_ms.properties - src/share/classes/sun/util/resources/LocaleNames_mt.properties - src/share/classes/sun/util/resources/LocaleNames_nl.properties - src/share/classes/sun/util/resources/LocaleNames_no.properties - src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties - src/share/classes/sun/util/resources/LocaleNames_pl.properties - src/share/classes/sun/util/resources/LocaleNames_pt.properties - src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties - src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties - src/share/classes/sun/util/resources/LocaleNames_ro.properties - src/share/classes/sun/util/resources/LocaleNames_ru.properties - src/share/classes/sun/util/resources/LocaleNames_sk.properties - src/share/classes/sun/util/resources/LocaleNames_sl.properties - src/share/classes/sun/util/resources/LocaleNames_sq.properties - src/share/classes/sun/util/resources/LocaleNames_sr.properties - src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties - src/share/classes/sun/util/resources/LocaleNames_sv.properties - src/share/classes/sun/util/resources/LocaleNames_th.properties - src/share/classes/sun/util/resources/LocaleNames_tr.properties - src/share/classes/sun/util/resources/LocaleNames_uk.properties - src/share/classes/sun/util/resources/LocaleNames_vi.properties - src/share/classes/sun/util/resources/LocaleNames_zh.properties - src/share/classes/sun/util/resources/LocaleNames_zh_HK.java - src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties - src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties ! src/share/classes/sun/util/resources/OpenListResourceBundle.java - src/share/classes/sun/util/resources/TimeZoneNames_de.java - src/share/classes/sun/util/resources/TimeZoneNames_en.java - src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java - src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java - src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java - src/share/classes/sun/util/resources/TimeZoneNames_es.java - src/share/classes/sun/util/resources/TimeZoneNames_fr.java - src/share/classes/sun/util/resources/TimeZoneNames_hi.java - src/share/classes/sun/util/resources/TimeZoneNames_it.java - src/share/classes/sun/util/resources/TimeZoneNames_ja.java - src/share/classes/sun/util/resources/TimeZoneNames_ko.java - src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java - src/share/classes/sun/util/resources/TimeZoneNames_sv.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java + src/share/classes/sun/util/resources/ar/CalendarData_ar.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_AE.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_BH.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_DZ.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_EG.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_IQ.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_JO.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_KW.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LB.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LY.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_MA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_OM.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_QA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SD.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SY.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_TN.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_YE.properties + src/share/classes/sun/util/resources/ar/LocaleNames_ar.properties + src/share/classes/sun/util/resources/be/CalendarData_be.properties + src/share/classes/sun/util/resources/be/CurrencyNames_be_BY.properties + src/share/classes/sun/util/resources/be/LocaleNames_be.properties + src/share/classes/sun/util/resources/bg/CalendarData_bg.properties + src/share/classes/sun/util/resources/bg/CurrencyNames_bg_BG.properties + src/share/classes/sun/util/resources/bg/LocaleNames_bg.properties + src/share/classes/sun/util/resources/ca/CalendarData_ca.properties + src/share/classes/sun/util/resources/ca/CurrencyNames_ca_ES.properties + src/share/classes/sun/util/resources/ca/LocaleNames_ca.properties + src/share/classes/sun/util/resources/cs/CalendarData_cs.properties + src/share/classes/sun/util/resources/cs/CurrencyNames_cs_CZ.properties + src/share/classes/sun/util/resources/cs/LocaleNames_cs.properties + src/share/classes/sun/util/resources/da/CalendarData_da.properties + src/share/classes/sun/util/resources/da/CurrencyNames_da_DK.properties + src/share/classes/sun/util/resources/da/LocaleNames_da.properties + src/share/classes/sun/util/resources/de/CalendarData_de.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_AT.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_CH.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_DE.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_GR.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_LU.properties + src/share/classes/sun/util/resources/de/LocaleNames_de.properties + src/share/classes/sun/util/resources/de/TimeZoneNames_de.java + src/share/classes/sun/util/resources/el/CalendarData_el.properties + src/share/classes/sun/util/resources/el/CalendarData_el_CY.properties + src/share/classes/sun/util/resources/el/CurrencyNames_el_CY.properties + src/share/classes/sun/util/resources/el/CurrencyNames_el_GR.properties + src/share/classes/sun/util/resources/el/LocaleNames_el.properties + src/share/classes/sun/util/resources/el/LocaleNames_el_CY.properties + src/share/classes/sun/util/resources/en/CalendarData_en.properties + src/share/classes/sun/util/resources/en/CalendarData_en_GB.properties + src/share/classes/sun/util/resources/en/CalendarData_en_IE.properties + src/share/classes/sun/util/resources/en/CalendarData_en_MT.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_AU.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_CA.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_GB.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_IE.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_IN.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_MT.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_NZ.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_PH.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_SG.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_US.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_ZA.properties + src/share/classes/sun/util/resources/en/LocaleNames_en.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_MT.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_PH.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_SG.properties + src/share/classes/sun/util/resources/en/TimeZoneNames_en.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_CA.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_GB.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_IE.java + src/share/classes/sun/util/resources/es/CalendarData_es.properties + src/share/classes/sun/util/resources/es/CalendarData_es_ES.properties + src/share/classes/sun/util/resources/es/CalendarData_es_US.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_AR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_BO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CL.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CU.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_DO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_EC.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_ES.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_GT.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_HN.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_MX.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_NI.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PA.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PE.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PY.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_SV.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_US.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_UY.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties + src/share/classes/sun/util/resources/es/LocaleNames_es.properties + src/share/classes/sun/util/resources/es/LocaleNames_es_US.properties + src/share/classes/sun/util/resources/es/TimeZoneNames_es.java + src/share/classes/sun/util/resources/et/CalendarData_et.properties + src/share/classes/sun/util/resources/et/CurrencyNames_et_EE.properties + src/share/classes/sun/util/resources/et/LocaleNames_et.properties + src/share/classes/sun/util/resources/fi/CalendarData_fi.properties + src/share/classes/sun/util/resources/fi/CurrencyNames_fi_FI.properties + src/share/classes/sun/util/resources/fi/LocaleNames_fi.properties + src/share/classes/sun/util/resources/fr/CalendarData_fr.properties + src/share/classes/sun/util/resources/fr/CalendarData_fr_CA.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_BE.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CA.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CH.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_FR.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_LU.properties + src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties + src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java + src/share/classes/sun/util/resources/ga/CurrencyNames_ga_IE.properties + src/share/classes/sun/util/resources/ga/LocaleNames_ga.properties + src/share/classes/sun/util/resources/hi/CalendarData_hi.properties + src/share/classes/sun/util/resources/hi/CurrencyNames_hi_IN.properties + src/share/classes/sun/util/resources/hi/LocaleNames_hi.properties + src/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java + src/share/classes/sun/util/resources/hr/CalendarData_hr.properties + src/share/classes/sun/util/resources/hr/CurrencyNames_hr_HR.properties + src/share/classes/sun/util/resources/hr/LocaleNames_hr.properties + src/share/classes/sun/util/resources/hu/CalendarData_hu.properties + src/share/classes/sun/util/resources/hu/CurrencyNames_hu_HU.properties + src/share/classes/sun/util/resources/hu/LocaleNames_hu.properties + src/share/classes/sun/util/resources/in/CalendarData_in_ID.properties + src/share/classes/sun/util/resources/in/CurrencyNames_in_ID.properties + src/share/classes/sun/util/resources/in/LocaleNames_in.properties + src/share/classes/sun/util/resources/is/CalendarData_is.properties + src/share/classes/sun/util/resources/is/CurrencyNames_is_IS.properties + src/share/classes/sun/util/resources/is/LocaleNames_is.properties + src/share/classes/sun/util/resources/it/CalendarData_it.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it_CH.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it_IT.properties + src/share/classes/sun/util/resources/it/LocaleNames_it.properties + src/share/classes/sun/util/resources/it/TimeZoneNames_it.java + src/share/classes/sun/util/resources/iw/CalendarData_iw.properties + src/share/classes/sun/util/resources/iw/CurrencyNames_iw_IL.properties + src/share/classes/sun/util/resources/iw/LocaleNames_iw.properties + src/share/classes/sun/util/resources/ja/CalendarData_ja.properties + src/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties + src/share/classes/sun/util/resources/ja/CurrencyNames_ja_JP.properties + src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties + src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java + src/share/classes/sun/util/resources/ko/CalendarData_ko.properties + src/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties + src/share/classes/sun/util/resources/ko/CurrencyNames_ko_KR.properties + src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties + src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java + src/share/classes/sun/util/resources/lt/CalendarData_lt.properties + src/share/classes/sun/util/resources/lt/CurrencyNames_lt_LT.properties + src/share/classes/sun/util/resources/lt/LocaleNames_lt.properties + src/share/classes/sun/util/resources/lv/CalendarData_lv.properties + src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties + src/share/classes/sun/util/resources/lv/LocaleNames_lv.properties + src/share/classes/sun/util/resources/mk/CalendarData_mk.properties + src/share/classes/sun/util/resources/mk/CurrencyNames_mk_MK.properties + src/share/classes/sun/util/resources/mk/LocaleNames_mk.properties + src/share/classes/sun/util/resources/ms/CalendarData_ms_MY.properties + src/share/classes/sun/util/resources/ms/CurrencyNames_ms_MY.properties + src/share/classes/sun/util/resources/ms/LocaleNames_ms.properties + src/share/classes/sun/util/resources/mt/CalendarData_mt.properties + src/share/classes/sun/util/resources/mt/CalendarData_mt_MT.properties + src/share/classes/sun/util/resources/mt/CurrencyNames_mt_MT.properties + src/share/classes/sun/util/resources/mt/LocaleNames_mt.properties + src/share/classes/sun/util/resources/nl/CalendarData_nl.properties + src/share/classes/sun/util/resources/nl/CurrencyNames_nl_BE.properties + src/share/classes/sun/util/resources/nl/CurrencyNames_nl_NL.properties + src/share/classes/sun/util/resources/nl/LocaleNames_nl.properties + src/share/classes/sun/util/resources/no/CalendarData_no.properties + src/share/classes/sun/util/resources/no/CurrencyNames_no_NO.properties + src/share/classes/sun/util/resources/no/LocaleNames_no.properties + src/share/classes/sun/util/resources/no/LocaleNames_no_NO_NY.properties + src/share/classes/sun/util/resources/pl/CalendarData_pl.properties + src/share/classes/sun/util/resources/pl/CurrencyNames_pl_PL.properties + src/share/classes/sun/util/resources/pl/LocaleNames_pl.properties + src/share/classes/sun/util/resources/pt/CalendarData_pt.properties + src/share/classes/sun/util/resources/pt/CalendarData_pt_PT.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt_BR.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt_PT.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties + src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java + src/share/classes/sun/util/resources/ro/CalendarData_ro.properties + src/share/classes/sun/util/resources/ro/CurrencyNames_ro_RO.properties + src/share/classes/sun/util/resources/ro/LocaleNames_ro.properties + src/share/classes/sun/util/resources/ru/CalendarData_ru.properties + src/share/classes/sun/util/resources/ru/CurrencyNames_ru_RU.properties + src/share/classes/sun/util/resources/ru/LocaleNames_ru.properties + src/share/classes/sun/util/resources/sk/CalendarData_sk.properties + src/share/classes/sun/util/resources/sk/CurrencyNames_sk_SK.properties + src/share/classes/sun/util/resources/sk/LocaleNames_sk.properties + src/share/classes/sun/util/resources/sl/CalendarData_sl.properties + src/share/classes/sun/util/resources/sl/CurrencyNames_sl_SI.properties + src/share/classes/sun/util/resources/sl/LocaleNames_sl.properties + src/share/classes/sun/util/resources/sq/CalendarData_sq.properties + src/share/classes/sun/util/resources/sq/CurrencyNames_sq_AL.properties + src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_BA.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_ME.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_RS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_BA.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_CS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_BA.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_ME.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_RS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_ME.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_RS.properties + src/share/classes/sun/util/resources/sr/LocaleNames_sr.properties + src/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties + src/share/classes/sun/util/resources/sv/CalendarData_sv.properties + src/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties + src/share/classes/sun/util/resources/sv/CurrencyNames_sv_SE.properties + src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties + src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java + src/share/classes/sun/util/resources/th/CalendarData_th.properties + src/share/classes/sun/util/resources/th/CurrencyNames_th_TH.properties + src/share/classes/sun/util/resources/th/LocaleNames_th.properties + src/share/classes/sun/util/resources/tr/CalendarData_tr.properties + src/share/classes/sun/util/resources/tr/CurrencyNames_tr_TR.properties + src/share/classes/sun/util/resources/tr/LocaleNames_tr.properties + src/share/classes/sun/util/resources/uk/CalendarData_uk.properties + src/share/classes/sun/util/resources/uk/CurrencyNames_uk_UA.properties + src/share/classes/sun/util/resources/uk/LocaleNames_uk.properties + src/share/classes/sun/util/resources/vi/CalendarData_vi.properties + src/share/classes/sun/util/resources/vi/CurrencyNames_vi_VN.properties + src/share/classes/sun/util/resources/vi/LocaleNames_vi.properties + src/share/classes/sun/util/resources/zh/CalendarData_zh.properties + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_CN.properties + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_TW.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java + src/share/classes/sun/util/resources/zh/LocaleNames_zh_SG.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java + src/solaris/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/solaris/native/java/lang/java_props_macosx.c + src/solaris/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c + src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java + src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c + test/java/text/Format/DateFormat/ContextMonthNamesTest.java + test/java/text/Format/NumberFormat/MultipleNumberScriptTest.java + test/java/util/Calendar/CalendarTypeTest.java ! test/java/util/Locale/Bug6989440.java + test/java/util/Locale/ExtensionsTest.java ! test/java/util/Locale/LocaleCategory.sh + test/java/util/Locale/LocaleProviders.java + test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java + test/java/util/PluggableLocale/CalendarDataProviderTest.java + test/java/util/PluggableLocale/CalendarDataProviderTest.sh ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/ProviderTest.java + test/java/util/PluggableLocale/SupportedLocalesTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile + test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarDataProvider ! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From sean.mullan at oracle.com Tue Aug 21 11:49:41 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 21 Aug 2012 14:49:41 -0400 Subject: Code review request: 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix In-Reply-To: <50323C7D.6000805@oracle.com> References: <15904831.1345469487949.JavaMail.sbladm@swsblss4-new.central.sun.com> <50323C7D.6000805@oracle.com> Message-ID: <5033D845.9050108@oracle.com> Looks fine to me. --Sean On 08/20/2012 09:32 AM, Weijun Wang wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/7152121/webrev.00/ > > This fix will also be backported to a 7u release. > > Thanks > Max > > > -------- Original Message -------- > 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix > > > === *Description* > ============================================================ > In JDK 6, one can specify keyTab="file:/etc/krb5/krb5.tab" for > Krb5LoginModule in a JAAS login config file. In JDK 7, we rewrote the > keytab codes and this is not supported anymore. From bradford.wetmore at oracle.com Wed Aug 22 14:19:32 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 22 Aug 2012 14:19:32 -0700 Subject: OpenJDK 7 SNI Implementation In-Reply-To: References: Message-ID: <50354CE4.1060508@oracle.com> Cross-posting to security-dev. Hi Tim, On 8/21/2012 8:07 PM, Tim Gustafson wrote: > I see that Java is supposed to support SNI, but it's not clear to me > how this happens, or where it happens, or if support for SNI extends > only to client SSLSocket object, or if it also applies to > SSLServerSocket objects. I can't find any documentation to tell me > exactly how Java supports SNI, nor can I find any examples of using > SNI, even from the client side of things. We currently only support client side sending of the SNI extension. Our client handshakers look to see if the SNI Extension is enabled (System Property: jsse.enableSNIExtension=true). If so, then if the SSLSocket/SSLEngine was created with a Fully Qualified Domain Name hostname, then we will load that hostname into an RFC 6066 "host_name" extension [1] and send it as part of the ClientHello. We don't currently have APIs to specify alternate server names on the client side, or to observe the received SNI extensions on the server side. We are right in the middle of designing the APIs for that[2]. We will likely be posting a new version in the next week or so to the security-dev mailing list. > I'd like my chooseServerAlias function in my X509KeyManager > implementation to pick a server alias based on what server the client > is attempting to connect to. But, I can't seem to find any properties > that are available through the "keyType", "issuers" or "socket" > parameters that are passed to that method that would tell me which > server the client is attempting to connect to. Earlier versions of the APIs are available via the security-dev mail archives[3], but I would suggest waiting for the next iteration. > I thought perhaps that I could make my client SSLSocket specify which > issuer/subject it was expecting to find on the server (and that > information would find its way to the "issuers" parameter of the > chooseServerAlias method), but I can't find any way to tell the client > SSLSocket which certificate to expect or which local certificate to > offer to the remote server. > > So, short version: where is Java's support for SNI actually documented > in detail? And are there any sample code snippets that would show me > how to use SNI? Or is Java's SNI implementation just based on the > host name that you specify when creating your client SSLSocket? Yes. > If > so, where does that host name information show up in the > chooseServerAlias function? Working on this for JDK 8. > Thanks for any help in advance! Hope this helps, Brad [1] http://www.rfc-editor.org/rfc/rfc6066.txt [2] http://openjdk.java.net/jeps/114 [3] http://mail.openjdk.java.net/pipermail/security-dev/2012-August/005285.html From luchsh at linux.vnet.ibm.com Thu Aug 23 01:30:01 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Thu, 23 Aug 2012 08:30:01 +0000 Subject: hg: jdk8/tl/jdk: 7193463: Improve registering signal handlers in java.lang.Terminator.setup() Message-ID: <20120823083029.3251A476A8@hg.openjdk.java.net> Changeset: e7b53fe85540 Author: dingxmin Date: 2012-08-23 16:28 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7b53fe85540 7193463: Improve registering signal handlers in java.lang.Terminator.setup() Reviewed-by: dholmes, alanb ! src/solaris/classes/java/lang/Terminator.java ! src/windows/classes/java/lang/Terminator.java From alan.bateman at oracle.com Thu Aug 23 05:08:02 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 23 Aug 2012 12:08:02 +0000 Subject: hg: jdk8/tl/jdk: 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx] Message-ID: <20120823120831.28817476AC@hg.openjdk.java.net> Changeset: de5a85353f4d Author: alanb Date: 2012-08-23 13:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de5a85353f4d 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx] Reviewed-by: alanb Contributed-by: Jason T Greene ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java From naoto.sato at oracle.com Fri Aug 24 10:15:54 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 24 Aug 2012 17:15:54 +0000 Subject: hg: jdk8/tl/jdk: 7193601: Build breakage with the fix to 6336885 (build-infra build) Message-ID: <20120824171623.E1F28476EB@hg.openjdk.java.net> Changeset: faf4528aea4e Author: naoto Date: 2012-08-24 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/faf4528aea4e 7193601: Build breakage with the fix to 6336885 (build-infra build) Reviewed-by: mduigou ! makefiles/CompileJavaClasses.gmk From alan.bateman at oracle.com Fri Aug 24 11:39:02 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Aug 2012 18:39:02 +0000 Subject: hg: jdk8/tl/jdk: 7193933: More ProblemList.txt updates (8/2012) Message-ID: <20120824183925.8B920476EC@hg.openjdk.java.net> Changeset: a7cdfd16e36e Author: alanb Date: 2012-08-24 19:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7cdfd16e36e 7193933: More ProblemList.txt updates (8/2012) Reviewed-by: darcy, chegar ! test/ProblemList.txt From kurchi.subhra.hazra at oracle.com Fri Aug 24 11:49:30 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 24 Aug 2012 18:49:30 +0000 Subject: hg: jdk8/tl/jdk: 7168172: (fs) Files.isReadable slow on Windows Message-ID: <20120824184950.4B799476ED@hg.openjdk.java.net> Changeset: bd91a601265c Author: khazra Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd91a601265c 7168172: (fs) Files.isReadable slow on Windows Summary: Remove DACL checking for read access, also reviewed by Ulf.Zibis at CoSoCo.de, zhong.j.yu at gmail.com Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java From mandy.chung at oracle.com Fri Aug 24 22:56:21 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 25 Aug 2012 05:56:21 +0000 Subject: hg: jdk8/tl/jdk: 7193339: Prepare system classes be defined by a non-null module loader Message-ID: <20120825055642.94E6447702@hg.openjdk.java.net> Changeset: d52081a08d11 Author: mchung Date: 2012-08-24 22:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d52081a08d11 7193339: Prepare system classes be defined by a non-null module loader Reviewed-by: alanb, dholmes, dsamersoff, sspitsyn, psandoz ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java From weijun.wang at oracle.com Sun Aug 26 19:24:34 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 27 Aug 2012 02:24:34 +0000 Subject: hg: jdk8/tl/jdk: 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix Message-ID: <20120827022448.510724772B@hg.openjdk.java.net> Changeset: 61ddc8ce7f3b Author: weijun Date: 2012-08-27 10:23 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61ddc8ce7f3b 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/auto/FileKeyTab.java From kumar.x.srinivasan at oracle.com Mon Aug 27 07:26:54 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 27 Aug 2012 14:26:54 +0000 Subject: hg: jdk8/tl/langtools: 7192068: (javac) provide a way for IDEs to produce Enclosing Method attributes. Message-ID: <20120827142658.856FA47737@hg.openjdk.java.net> Changeset: c9749226cdde Author: ksrini Date: 2012-08-27 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c9749226cdde 7192068: (javac) provide a way for IDEs to produce Enclosing Method attributes. Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java From lana.steuck at oracle.com Mon Aug 27 11:04:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:48 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20120827180448.5EB9A47744@hg.openjdk.java.net> Changeset: febd7ff52800 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/febd7ff52800 Added tag jdk8-b52 for changeset 8d24def5ceb3 ! .hgtags Changeset: c1a277c6022a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c1a277c6022a Added tag jdk8-b53 for changeset febd7ff52800 ! .hgtags From lana.steuck at oracle.com Mon Aug 27 11:04:47 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:47 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20120827180452.3413047745@hg.openjdk.java.net> Changeset: 63aeb7a2472f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/63aeb7a2472f Added tag jdk8-b52 for changeset 80689ff9cb49 ! .hgtags Changeset: 16c82fc74695 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/16c82fc74695 Added tag jdk8-b53 for changeset 63aeb7a2472f ! .hgtags Changeset: d086e67eb9dd Author: lana Date: 2012-08-27 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d086e67eb9dd Merge From lana.steuck at oracle.com Mon Aug 27 11:04:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:51 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120827180459.F101D47746@hg.openjdk.java.net> Changeset: 8a35fd644d3c Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8a35fd644d3c Added tag jdk8-b52 for changeset f62bc618122e ! .hgtags Changeset: 91970935926a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/91970935926a Added tag jdk8-b53 for changeset 8a35fd644d3c ! .hgtags From lana.steuck at oracle.com Mon Aug 27 11:04:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:51 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20120827180500.E86BE47747@hg.openjdk.java.net> Changeset: d3d0b9cd76e0 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d3d0b9cd76e0 Added tag jdk8-b52 for changeset 1d2db0e5eabc ! .hgtags Changeset: 9cf72631baf5 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9cf72631baf5 Added tag jdk8-b53 for changeset d3d0b9cd76e0 ! .hgtags Changeset: 542c87b8ce7f Author: lana Date: 2012-08-27 10:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/542c87b8ce7f Merge From lana.steuck at oracle.com Mon Aug 27 11:04:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:54 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20120827180504.56D6B47748@hg.openjdk.java.net> Changeset: 2c566f25c39f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2c566f25c39f Added tag jdk8-b52 for changeset bd3c00d57614 ! .hgtags Changeset: 7dd81ccb7c11 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7dd81ccb7c11 Added tag jdk8-b53 for changeset 2c566f25c39f ! .hgtags Changeset: 933d0234670f Author: lana Date: 2012-08-27 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/933d0234670f Merge From lana.steuck at oracle.com Mon Aug 27 11:05:02 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:05:02 +0000 Subject: hg: jdk8/tl/hotspot: 12 new changesets Message-ID: <20120827180527.BE26B47749@hg.openjdk.java.net> Changeset: ef437ea56651 Author: amurillo Date: 2012-08-03 13:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef437ea56651 7189086: new hotspot build - hs24-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1d7922586cf6 Author: twisti Date: 2012-07-24 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d7922586cf6 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, kvn, mhaupt Contributed-by: John Rose , Christian Thalinger , Michael Haupt ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! 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/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.hpp ! 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_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! 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_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! 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.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.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/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp + src/share/vm/ci/ciMemberName.cpp + src/share/vm/ci/ciMemberName.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.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/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! 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/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/jvmtiTagMap.cpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 977007096840 Author: twisti Date: 2012-07-27 16:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/977007096840 7187290: nightly failures after JSR 292 lazy method handle update Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/doCall.cpp Changeset: 6c5b7a6becc8 Author: kvn Date: 2012-07-30 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c5b7a6becc8 7187454: stack overflow in C2 compiler thread on Solaris x86 Summary: Added new FormatBufferResource class to use thread's resource area for error message buffer. Reviewed-by: twisti ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: 8cb110fd7627 Author: kvn Date: 2012-08-01 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8cb110fd7627 7188227: VM should recognize M-series SPARC Summary: Check kstat data for SPARC-M. Reviewed-by: roland ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: b72784e722ff Author: twisti Date: 2012-08-01 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b72784e722ff 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Reviewed-by: kvn, jrose ! src/share/vm/opto/doCall.cpp Changeset: 93c71eb28866 Author: twisti Date: 2012-08-07 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/93c71eb28866 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: ee7edf31f688 Author: twisti Date: 2012-08-10 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ee7edf31f688 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 ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/phaseX.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp Changeset: 4c8f2a12e757 Author: twisti Date: 2012-08-10 17:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c8f2a12e757 Merge Changeset: 6d0436885201 Author: amurillo Date: 2012-08-10 23:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d0436885201 Added tag hs24-b20 for changeset 4c8f2a12e757 ! .hgtags Changeset: 54240c1b8e87 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/54240c1b8e87 Added tag jdk8-b52 for changeset 6d0436885201 ! .hgtags Changeset: de2aa86e037d Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de2aa86e037d Added tag jdk8-b53 for changeset 54240c1b8e87 ! .hgtags From lana.steuck at oracle.com Mon Aug 27 11:05:06 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:05:06 +0000 Subject: hg: jdk8/tl/jdk: 14 new changesets Message-ID: <20120827180731.A21BC4774A@hg.openjdk.java.net> Changeset: 05e5ce861a58 Author: jrose Date: 2012-07-12 00:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/05e5ce861a58 7153157: ClassValue.get does not return if computeValue calls remove Summary: Track intermediate states more precisely, according to spec. Reviewed-by: twisti, forax ! src/share/classes/java/lang/ClassValue.java Changeset: beeb1d5ecd9e Author: jrose Date: 2012-07-12 00:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/beeb1d5ecd9e 7129034: VM crash with a field setter method with a filterArguments Summary: add null checks before unsafe calls that take a variable base reference; update unit tests Reviewed-by: kvn, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 556141c6326c Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/556141c6326c 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: 78f1f4e4e9c7 Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78f1f4e4e9c7 7127687: MethodType leaks memory due to interning Summary: Replace internTable with a weak-reference version. Reviewed-by: sundar, forax, brutisso Contributed-by: james.laskey at oracle.com ! src/share/classes/java/lang/invoke/MethodType.java Changeset: 050116960e99 Author: twisti Date: 2012-07-24 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/050116960e99 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, mhaupt, forax Contributed-by: John Rose , Christian Thalinger , Michael Haupt - src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + src/share/classes/java/lang/invoke/DontInline.java + src/share/classes/java/lang/invoke/ForceInline.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/MethodHandleInfo.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/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/misc/Unsafe.java + test/java/lang/invoke/7157574/Test7157574.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java + test/java/lang/invoke/MaxTest.java ! test/java/lang/invoke/MethodHandlesTest.java + test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java + test/java/lang/invoke/remote/RemoteExample.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 64e24cc8e009 Author: twisti Date: 2012-08-07 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64e24cc8e009 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java Changeset: e1d063685dc8 Author: twisti Date: 2012-08-09 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1d063685dc8 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 865c411ebcae Author: twisti Date: 2012-08-10 16:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/865c411ebcae Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java Changeset: 93ddd9560751 Author: youdwei Date: 2012-08-13 10:45 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93ddd9560751 7189611: Venezuela current Currency should be Bs.F. Reviewed-by: okutsu ! src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 90a9acfde9e6 Author: mfang Date: 2012-08-13 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90a9acfde9e6 Merge Changeset: e8569a473cee Author: katleman Date: 2012-08-15 18:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8569a473cee Merge Changeset: 2c6933c5106b Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c6933c5106b Added tag jdk8-b52 for changeset e8569a473cee ! .hgtags Changeset: 156ab3c38556 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/156ab3c38556 Added tag jdk8-b53 for changeset 2c6933c5106b ! .hgtags Changeset: 96990c9da294 Author: lana Date: 2012-08-27 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96990c9da294 Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From sean.mullan at oracle.com Mon Aug 27 13:23:16 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 27 Aug 2012 16:23:16 -0400 Subject: JDK 8 Code review request for 7179715: Reason of CertPathValidatorException should be UNDETERMINED_REVOCATION_STATUS if OCSP request failed Message-ID: <503BD734.2080900@oracle.com> Please review my webrev for 7179715: http://cr.openjdk.java.net/~mullan/webrevs/7192896/webrev.00/ The bugid is not accessible for some reason. Essentially this is a simple fix to set the reason of the CertPathValidatorException to UNDETERMINED_REVOCATION_STATUS if a network failure prevents us from determining if a certificate has been revoked or not. Thanks, Sean From weijun.wang at oracle.com Mon Aug 27 22:32:59 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 28 Aug 2012 13:32:59 +0800 Subject: Code review request: 7194472: FileKeyTab.java test fails on Windows In-Reply-To: <641337.1346131260797.JavaMail.sbladm@swsblss4-new.central.sun.com> References: <641337.1346131260797.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <503C580B.5050700@oracle.com> Sorry, there is a problem in the test of my recent fix at http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61ddc8ce7f3b Here is a webrev http://cr.openjdk.java.net/~weijun/7194472/webrev.00/ "/" is treated as a universal File.separatorChar in JAAS config files. Noreg-self. Thanks Max -------- Original Message -------- 7194472: FileKeyTab.java test fails on Windows http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194472 Product: java Category: java Subcategory: classes_security === *Description* ============================================================ The newly added FileKeyTab.java test fails on Windows because it creates a file server { com.sun.security.auth.module.Krb5LoginModule required principal="server/host.rabbit.hole" debug=true useKeyTab=true keyTab="file:C:\tmp\RR1\W\scratch\localkdc.ktab" storeKey=true; }; Here the keyTab line is illegal before JAAS config file is parsed with a StreamTokenizer and "\" is treated as a escape char. From Alan.Bateman at oracle.com Tue Aug 28 02:22:36 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Aug 2012 10:22:36 +0100 Subject: Code review request: 7194472: FileKeyTab.java test fails on Windows In-Reply-To: <503C580B.5050700@oracle.com> References: <641337.1346131260797.JavaMail.sbladm@swsblss4-new.central.sun.com> <503C580B.5050700@oracle.com> Message-ID: <503C8DDC.7060809@oracle.com> On 28/08/2012 06:32, Weijun Wang wrote: > Sorry, there is a problem in the test of my recent fix at > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61ddc8ce7f3b > > Here is a webrev > > http://cr.openjdk.java.net/~weijun/7194472/webrev.00/ > > "/" is treated as a universal File.separatorChar in JAAS config files. This looks okay to me. -Alan. From weijun.wang at oracle.com Tue Aug 28 02:26:49 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 28 Aug 2012 09:26:49 +0000 Subject: hg: jdk8/tl/jdk: 7194472: FileKeyTab.java test fails on Windows Message-ID: <20120828092759.8619747768@hg.openjdk.java.net> Changeset: fe496675b5e7 Author: weijun Date: 2012-08-28 17:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe496675b5e7 7194472: FileKeyTab.java test fails on Windows Reviewed-by: alanb ! test/sun/security/krb5/auto/FileKeyTab.java From jonathan.gibbons at oracle.com Tue Aug 28 02:29:52 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Aug 2012 09:29:52 +0000 Subject: hg: jdk8/tl/jdk: 7194032: update tests for upcoming changes for jtreg Message-ID: <20120828093013.189D447769@hg.openjdk.java.net> Changeset: 06d0478023ca Author: jjg Date: 2012-08-28 10:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06d0478023ca 7194032: update tests for upcoming changes for jtreg Reviewed-by: alanb, iris ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh From jonathan.gibbons at oracle.com Tue Aug 28 02:31:48 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Aug 2012 09:31:48 +0000 Subject: hg: jdk8/tl/jdk: 7194035: update tests for upcoming changes for jtreg Message-ID: <20120828093215.DD29B4776A@hg.openjdk.java.net> Changeset: 997e0d6238b7 Author: jjg Date: 2012-08-28 10:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/997e0d6238b7 7194035: update tests for upcoming changes for jtreg Reviewed-by: alanb, sspitsyn ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-m_2.sh From alan.bateman at oracle.com Tue Aug 28 03:13:46 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 28 Aug 2012 10:13:46 +0000 Subject: hg: jdk8/tl/jdk: 6962637: TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system Message-ID: <20120828101423.1DAD94776E@hg.openjdk.java.net> Changeset: c5099c988cce Author: alanb Date: 2012-08-28 11:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5099c988cce 6962637: TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system Reviewed-by: dholmes, alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/MaxPathLength.java From sean.mullan at oracle.com Tue Aug 28 05:20:30 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 28 Aug 2012 08:20:30 -0400 Subject: JDK 8 Code review request for 7179715: Reason of CertPathValidatorException should be UNDETERMINED_REVOCATION_STATUS if OCSP request failed In-Reply-To: <503BD734.2080900@oracle.com> References: <503BD734.2080900@oracle.com> Message-ID: <503CB78E.4070504@oracle.com> Vinnie, Weijun or Xuelei, Could one of you take a quick look at this and let me know if it looks ok? Thanks, Sean On 8/27/12 4:23 PM, Sean Mullan wrote: > Please review my webrev for 7179715: > > http://cr.openjdk.java.net/~mullan/webrevs/7192896/webrev.00/ > > The bugid is not accessible for some reason. Essentially this is a simple fix to > set the reason of the CertPathValidatorException to > UNDETERMINED_REVOCATION_STATUS if a network failure prevents us from determining > if a certificate has been revoked or not. > > Thanks, > Sean > From xuelei.fan at oracle.com Tue Aug 28 05:20:56 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 28 Aug 2012 20:20:56 +0800 Subject: JDK 8 Code review request for 7179715: Reason of CertPathValidatorException should be UNDETERMINED_REVOCATION_STATUS if OCSP request failed In-Reply-To: <503BD734.2080900@oracle.com> References: <503BD734.2080900@oracle.com> Message-ID: <503CB7A8.4070304@oracle.com> On 8/28/2012 4:23 AM, Sean Mullan wrote: > Please review my webrev for 7179715: > Is it 7192896? > http://cr.openjdk.java.net/~mullan/webrevs/7192896/webrev.00/ > Looks fine to me. Xuelei > The bugid is not accessible for some reason. Essentially this is a simple fix to > set the reason of the CertPathValidatorException to > UNDETERMINED_REVOCATION_STATUS if a network failure prevents us from determining > if a certificate has been revoked or not. > > Thanks, > Sean > From sean.mullan at oracle.com Tue Aug 28 05:41:12 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 28 Aug 2012 08:41:12 -0400 Subject: JDK 8 Code review request for 7179715: Reason of CertPathValidatorException should be UNDETERMINED_REVOCATION_STATUS if OCSP request failed In-Reply-To: <503CB7A8.4070304@oracle.com> References: <503BD734.2080900@oracle.com> <503CB7A8.4070304@oracle.com> Message-ID: <503CBC68.5080900@oracle.com> On 8/28/12 8:20 AM, Xuelei Fan wrote: > On 8/28/2012 4:23 AM, Sean Mullan wrote: >> Please review my webrev for 7179715: >> > Is it 7192896? Oops, yes, cut-and-paste error. > >> http://cr.openjdk.java.net/~mullan/webrevs/7192896/webrev.00/ >> > > Looks fine to me. Thanks. --Sean > > Xuelei > >> The bugid is not accessible for some reason. Essentially this is a simple fix to >> set the reason of the CertPathValidatorException to >> UNDETERMINED_REVOCATION_STATUS if a network failure prevents us from determining >> if a certificate has been revoked or not. >> >> Thanks, >> Sean >> > From sean.mullan at oracle.com Tue Aug 28 05:59:24 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 28 Aug 2012 12:59:24 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120828130004.157DF47772@hg.openjdk.java.net> Changeset: 8b90182f2b33 Author: mullan Date: 2012-08-28 08:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b90182f2b33 7192896: Reason of CertPathValidatorException should be UNDETERMINED_REVOCATION_STATUS if OCSP request failed Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: ca7f914b5fea Author: mullan Date: 2012-08-28 08:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca7f914b5fea Merge From vincent.x.ryan at oracle.com Tue Aug 28 06:02:52 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 28 Aug 2012 14:02:52 +0100 Subject: JDK 8 Code review request for 7179715: Reason of CertPathValidatorException should be UNDETERMINED_REVOCATION_STATUS if OCSP request failed In-Reply-To: <503CB78E.4070504@oracle.com> References: <503BD734.2080900@oracle.com> <503CB78E.4070504@oracle.com> Message-ID: <503CC17C.2080709@oracle.com> Webrev looks fine. On 08/28/12 01:20 PM, Sean Mullan wrote: > Vinnie, Weijun or Xuelei, > > Could one of you take a quick look at this and let me know if it looks ok? > > Thanks, > Sean > > On 8/27/12 4:23 PM, Sean Mullan wrote: >> Please review my webrev for 7179715: >> >> http://cr.openjdk.java.net/~mullan/webrevs/7192896/webrev.00/ >> >> The bugid is not accessible for some reason. Essentially this is a simple fix to >> set the reason of the CertPathValidatorException to >> UNDETERMINED_REVOCATION_STATUS if a network failure prevents us from determining >> if a certificate has been revoked or not. >> >> Thanks, >> Sean >> From daniel.daugherty at oracle.com Tue Aug 28 09:58:36 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 28 Aug 2012 16:58:36 +0000 Subject: hg: jdk8/tl/jdk: 7194608: add VerifyLocalVariableTableOnRetransformTest.sh to Problem.list Message-ID: <20120828165911.2FECC4777D@hg.openjdk.java.net> Changeset: bfd5ecb1b4aa Author: dcubed Date: 2012-08-28 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfd5ecb1b4aa 7194608: add VerifyLocalVariableTableOnRetransformTest.sh to Problem.list Reviewed-by: alanb ! test/ProblemList.txt From sean.coffey at oracle.com Tue Aug 28 13:25:26 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 28 Aug 2012 21:25:26 +0100 Subject: 7u8 Code Review Request for 7107613, 7107616, 7185471 Message-ID: <503D2936.8080007@oracle.com> Looking for a code review around the following perf. related backports to JDK 7u8. The changesets didn't apply cleanly but there was no major code differences encountered while porting. Builds and security tests ran fine. 7107616: scalability blocker in javax.crypto.JceSecurityManager jdk 8 changeset : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/175036ada2e3 7u webrev : http://cr.openjdk.java.net/~coffeys/webrev.7107616.7u/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107616 7107613: scalability blocker in javax.crypto.CryptoPermissions jdk 8 changeset : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/114fbbeb8f75 7u webrev : http://cr.openjdk.java.net/~coffeys/webrev.7107613.7u/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107613 7185471: Avoid key expansion when AES cipher is re-init w/ the same key jdk 8 changeset : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e97dacbfd35 7u webrev : http://cr.openjdk.java.net/~coffeys/webrev.7185471.7u/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185471 Regards, Sean. From weijun.wang at oracle.com Tue Aug 28 20:03:41 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 29 Aug 2012 03:03:41 +0000 Subject: hg: jdk8/tl/jdk: 7184815: [macosx] Need to read Kerberos config in files Message-ID: <20120829030404.891B247793@hg.openjdk.java.net> Changeset: c4c69b4d9ace Author: weijun Date: 2012-08-29 11:03 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c69b4d9ace 7184815: [macosx] Need to read Kerberos config in files Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java From vincent.x.ryan at oracle.com Wed Aug 29 08:20:19 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 29 Aug 2012 16:20:19 +0100 Subject: Code review request for JEP-121 In-Reply-To: <4FC90790.5070109@oracle.com> References: <4FC90790.5070109@oracle.com> Message-ID: <503E3333.7040100@oracle.com> 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 valerie.peng at oracle.com Wed Aug 29 14:08:28 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 29 Aug 2012 14:08:28 -0700 Subject: 7u8 Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <503D2936.8080007@oracle.com> References: <503D2936.8080007@oracle.com> Message-ID: <503E84CC.2050805@oracle.com> The changes look fine. Thanks, Valerie On 08/28/12 13:25, Se?n Coffey wrote: > Looking for a code review around the following perf. related backports > to JDK 7u8. The changesets didn't apply cleanly but there was no major > code differences encountered while porting. > > Builds and security tests ran fine. > > 7107616: scalability blocker in javax.crypto.JceSecurityManager > jdk 8 changeset : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/175036ada2e3 > 7u webrev : http://cr.openjdk.java.net/~coffeys/webrev.7107616.7u/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107616 > > 7107613: scalability blocker in javax.crypto.CryptoPermissions > jdk 8 changeset : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/114fbbeb8f75 > 7u webrev : http://cr.openjdk.java.net/~coffeys/webrev.7107613.7u/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107613 > > 7185471: Avoid key expansion when AES cipher is re-init w/ the same key > jdk 8 changeset : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e97dacbfd35 > 7u webrev : http://cr.openjdk.java.net/~coffeys/webrev.7185471.7u/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185471 > > > Regards, > Sean. > From alan.bateman at oracle.com Thu Aug 30 05:00:15 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 30 Aug 2012 12:00:15 +0000 Subject: hg: jdk8/tl/jdk: 7193710: ByteArrayOutputStream Javadoc contains unclosed element Message-ID: <20120830120101.5E081477E8@hg.openjdk.java.net> Changeset: cf492d1199dc Author: dxu Date: 2012-08-30 12:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf492d1199dc 7193710: ByteArrayOutputStream Javadoc contains unclosed element Reviewed-by: dholmes, alanb, ulfzibis ! src/share/classes/java/io/ByteArrayOutputStream.java ! src/share/classes/java/io/InputStreamReader.java From lance.andersen at oracle.com Thu Aug 30 10:38:39 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 30 Aug 2012 17:38:39 +0000 Subject: hg: jdk8/tl/jdk: 7193683: DriverManager Iterator Warning cleanup Message-ID: <20120830173900.5451A477FC@hg.openjdk.java.net> Changeset: 11bfec75d333 Author: lancea Date: 2012-08-30 13:38 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11bfec75d333 7193683: DriverManager Iterator Warning cleanup Reviewed-by: lancea Contributed-by: Dan Xu ! src/share/classes/java/sql/DriverManager.java From bradford.wetmore at oracle.com Thu Aug 30 14:08:35 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 30 Aug 2012 14:08:35 -0700 Subject: test/java/security/spec/EllipticCurveMatch.java othervm? In-Reply-To: <4DF8749C.6060404@oracle.com> References: <4DF8713C.3040400@oracle.com> <4DF8749C.6060404@oracle.com> Message-ID: <503FD653.3020506@oracle.com> On 6/15/2011 2:00 AM, Vincent Ryan wrote: > On 06/15/11 09:45, Weijun Wang wrote: >> Hi Vinnie >> >> Why does this test run in /othervm mode? >> >> Thanks >> Max > > It was failing due to SecureRandom problems on some platforms when run in samevm > mode. I think it was related to a lack of entropy. Really? That surprises me! Generally it's when you run in othervm that you you might run out of entropy in /dev/random. Can you reliably duplicate this? Brad From sean.mullan at oracle.com Thu Aug 30 14:47:52 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 30 Aug 2012 21:47:52 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120830214825.E8E1E47802@hg.openjdk.java.net> Changeset: 0a2565113920 Author: mullan Date: 2012-08-30 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2565113920 6995421: Eliminate the static dependency to sun.security.ec.ECKeyFactory Reviewed-by: mullan, vinnie Contributed-by: stephen.flores at oracle.com ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! src/share/classes/sun/security/ec/ECKeyFactory.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDSA.java Changeset: 47f8ba39265c Author: mullan Date: 2012-08-30 14:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/47f8ba39265c Merge From lana.steuck at oracle.com Thu Aug 30 17:01:05 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 31 Aug 2012 00:01:05 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120831000154.815484780D@hg.openjdk.java.net> Changeset: baf30df50ce3 Author: andrew Date: 2012-08-23 15:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/baf30df50ce3 7192804: Build should not install jvisualvm man page for OpenJDK Summary: OpenJDK builds don't ship VisualVM so shouldn't ship its man page either. Reviewed-by: dholmes ! make/common/Release.gmk ! makefiles/Images.gmk Changeset: 70ad0ed1d6ce Author: katleman Date: 2012-08-29 15:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70ad0ed1d6ce Merge Changeset: 334b6f0c547f Author: lana Date: 2012-08-30 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/334b6f0c547f Merge From lana.steuck at oracle.com Thu Aug 30 17:01:08 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 31 Aug 2012 00:01:08 +0000 Subject: hg: jdk8/tl/hotspot: 31 new changesets Message-ID: <20120831000218.EFDD04780E@hg.openjdk.java.net> Changeset: 6898d85cf0bb Author: amurillo Date: 2012-08-10 23:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6898d85cf0bb 7190772: new hotspot build - hs24-b21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d5ec46c7da5c Author: amurillo Date: 2012-08-15 16:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5ec46c7da5c 7191765: make jdk8 the default jprt release for hs24 Reviewed-by: jcoomes ! make/jprt.properties Changeset: aaf61e68b255 Author: johnc Date: 2012-08-06 12:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aaf61e68b255 6818524: G1: use ergonomic resizing of PLABs Summary: Employ PLABStats instances to record information about survivor and old PLABs, and use the recorded stats to adjust the sizes of survivor and old PLABS. Reviewed-by: johnc, ysr Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/precompiled/precompiled.hpp Changeset: eff5d59db7e1 Author: amurillo Date: 2012-08-07 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eff5d59db7e1 7189729: jprt.properties should include release jdk7u8 Reviewed-by: jcoomes ! make/jprt.properties Changeset: 3958f0acde31 Author: amurillo Date: 2012-08-17 15:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3958f0acde31 Merge ! make/jprt.properties - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: 6acee021f5ac Author: coleenp Date: 2012-08-01 16:52 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6acee021f5ac 7129723: MAC: Some regression tests need to recognize Mac OS X platform Summary: Add Darwin like Linux to shell scripts Reviewed-by: kvn, kamg, dholmes ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 4acebbe310e1 Author: zgu Date: 2012-08-01 17:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4acebbe310e1 7185614: NMT ON: "check by caller" assertion failed on nsk ThreadMXBean test 7187429: NMT ON: Merge failure should cause NMT to shutdown Summary: Fixed NMT assertion failures Reviewed-by: acorn, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b27675afea11 Author: zgu Date: 2012-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b27675afea11 Merge Changeset: 8e69438de9c6 Author: zgu Date: 2012-08-01 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8e69438de9c6 Merge Changeset: 282abd0fd878 Author: dcubed Date: 2012-08-02 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/282abd0fd878 7188168: 7071904 broke the DEBUG_BINARIES option on Linux Summary: Change DEBUG_BINARIES option logic to be more clear. Reviewed-by: fparain, andrew ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make Changeset: 0d8e265ba727 Author: dcubed Date: 2012-08-03 18:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0d8e265ba727 7181175: Enable builds on Windows with MinGW/MSYS Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS Reviewed-by: jcoomes, dcubed, tbell, ohair Contributed-by: volker.simonis at gmail.com ! make/windows/makefiles/defs.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/shared.make Changeset: c3c2141203e7 Author: dcubed Date: 2012-08-06 09:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3c2141203e7 Merge Changeset: 4ee06e614636 Author: kamg Date: 2012-08-06 15:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ee06e614636 7116786: RFE: Detailed information on VerifyErrors Summary: Provide additional detail in VerifyError messages Reviewed-by: sspitsyn, acorn ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/runtime/7116786/Test7116786.java + test/runtime/7116786/testcases.jar Changeset: 98625323d3a3 Author: tbell Date: 2012-08-10 23:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98625323d3a3 7190512: Fix for 7181175 broke hotspot/make/windows/create.bat builds Summary: Add some quotes around the classpath in the project file rule. Reviewed-by: dcubed ! make/windows/projectfiles/common/Makefile Changeset: e5bf1c79ed5b Author: zgu Date: 2012-08-14 13:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5bf1c79ed5b 7191124: Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Summary: Updated all related variables and methods to use NOT_PRODUCT macros Reviewed-by: coleenp, acorn, kvn ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memPtrArray.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp Changeset: fce6d7280776 Author: dcubed Date: 2012-08-17 11:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fce6d7280776 Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp Changeset: b63c0564035a Author: dcubed Date: 2012-08-21 19:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b63c0564035a Merge Changeset: f99a36499b8c Author: johnc Date: 2012-08-21 10:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f99a36499b8c 7192128: G1: Extend fix for 6948537 to G1's BOT Summary: G1 does not appear to be immune to the issue described in CR 6948537 and increasing the size of old-generation PLABs appears to increase the liklihood of seeing the issue. Extend the fix for 6948537 to G1's BlockOffsetTable. Reviewed-by: brutisso, jmasa ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7383557659bd Author: johnc Date: 2012-08-21 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7383557659bd 7185699: G1: Prediction model discrepancies Summary: Correct the result value of G1CollectedHeap::pending_card_num(). Change the code that calculates the GC efficiency of a non-young heap region to use historical data from mixed GCs and the actual number of live bytes when predicting how long it would take to collect the region. Changes were also reviewed by Thomas Schatzl. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 3650da95d2ee Author: brutisso Date: 2012-08-23 05:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3650da95d2ee 7193157: G1: Make some develpflags available in product builds Summary: Also reviewed by: vitalyd at gmail.com. Make G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, G1OldCSetRegionLiveThresholdPercent and G1OldCSetRegionThresholdPercent experimental flags Reviewed-by: ysr, johnc, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ce0254b13eb8 Author: brutisso Date: 2012-08-24 09:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce0254b13eb8 Merge Changeset: 006050192a5a Author: kvn Date: 2012-08-20 09:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/006050192a5a 6340864: Implement vectorization optimizations in hotspot-server Summary: Added asm encoding and mach nodes for vector arithmetic instructions on x86. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/6340864/TestByteVect.java + test/compiler/6340864/TestDoubleVect.java + test/compiler/6340864/TestFloatVect.java + test/compiler/6340864/TestIntVect.java + test/compiler/6340864/TestLongVect.java + test/compiler/6340864/TestShortVect.java Changeset: 09aad8452938 Author: kvn Date: 2012-08-20 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/09aad8452938 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Summary: In C2 add software membar after load from Reference.referent field to prevent commoning of loads across safepoint since GC can change its value. In C1 always generate Reference.get() intrinsic. Reviewed-by: roland, twisti, dholmes, johnc ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/7190310/Test7190310.java + test/compiler/7190310/Test7190310_unsafe.java Changeset: 7a302948f5a4 Author: twisti Date: 2012-08-21 10:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7a302948f5a4 7192167: JSR 292: C1 has old broken code which needs to be removed Reviewed-by: kvn, roland, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/callGenerator.cpp Changeset: 4b0d6fd74911 Author: kvn Date: 2012-08-21 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4b0d6fd74911 7192964: assert(false) failed: bad AD file Summary: Shifts with loop variant counts "a[i]=1<= 1) failed: illegal call to offset() Summary: C1 value numbering hits unloaded klass. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 5af51c882207 Author: kvn Date: 2012-08-22 11:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5af51c882207 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' Summary: Fixed Pack node generation. Not vectorize shift instructions if count is not the same for all shifts and if count is vector. Reviewed-by: twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/7192963/TestByteVect.java + test/compiler/7192963/TestDoubleVect.java + test/compiler/7192963/TestFloatVect.java + test/compiler/7192963/TestIntVect.java + test/compiler/7192963/TestLongVect.java + test/compiler/7192963/TestShortVect.java Changeset: f7cd53cedd78 Author: kvn Date: 2012-08-23 09:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7cd53cedd78 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Summary: Change pair check to vector check in RA bias coloring code. Reviewed-by: jrose, twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/output.cpp Changeset: c32dee9b8023 Author: twisti Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c32dee9b8023 Merge Changeset: 9e3ae661284d Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e3ae661284d Merge - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: e8fb566b9466 Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8fb566b9466 Added tag hs24-b21 for changeset 9e3ae661284d ! .hgtags From stuart.marks at oracle.com Thu Aug 30 18:53:29 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 31 Aug 2012 01:53:29 +0000 Subject: hg: jdk8/tl/jdk: 7195099: update problem list with RMI test failures Message-ID: <20120831015350.8702947819@hg.openjdk.java.net> Changeset: f9b11772c4b2 Author: smarks Date: 2012-08-30 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9b11772c4b2 7195099: update problem list with RMI test failures Reviewed-by: alanb ! test/ProblemList.txt From valerie.peng at oracle.com Thu Aug 30 19:05:02 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 30 Aug 2012 19:05:02 -0700 Subject: Code review request for JEP-121 In-Reply-To: <503E3333.7040100@oracle.com> References: <4FC90790.5070109@oracle.com> <503E3333.7040100@oracle.com> Message-ID: <50401BCE.1010003@oracle.com> 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 weijun.wang at oracle.com Thu Aug 30 22:56:31 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 Aug 2012 13:56:31 +0800 Subject: Code review request: 6355584: Introduce constrained Kerberos delegation In-Reply-To: <4FFC99D9.2010009@oracle.com> References: <4FFC99D9.2010009@oracle.com> Message-ID: <5040520F.2050006@oracle.com> Hi All Please review http://cr.openjdk.java.net/~weijun/6355584/webrev.00/ This enables 2 changes: 1. As an initiator, you can call ((ExtendedGSSCredential)cred).impersonate(other) to impersonate a client. 2. As an acceptor, context.getDelegCred() can still return a constrained delegated credential even if the initiator has not called context.requestCredDeleg(true) to enable traditional delegation. These are implemented with MS's S4U2self and S4U2proxy extensions to Kerberos 5. Thanks Max From weijun.wang at oracle.com Fri Aug 31 00:08:01 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 Aug 2012 15:08:01 +0800 Subject: Code review request: 7195426: kdc_default_options not supported correctly In-Reply-To: <24470614.1346396477127.JavaMail.sbladm@swsblss4-new.central.sun.com> References: <24470614.1346396477127.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <504062D1.2050600@oracle.com> Please take a look at the change http://cr.openjdk.java.net/~weijun/7195426/webrev.00 It seems we confused the mask and the position. Thanks Max -------- Original Message -------- 7195426: kdc_default_options not supported correctly http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195426 Product: java Category: jgss Subcategory: krb5plugin === *Description* ============================================================ kdc_default_options is a hex number for krb5.conf to define the KDCOptions flags in a single integer where each bit of it represents one of 32 flags. If you want to find out if the n-th flag is turn on, you should check for kdc_default_options & (1<<(31-n)) However, java currently checks for kdc_default_options & n From jonathan.gibbons at oracle.com Fri Aug 31 02:32:20 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 31 Aug 2012 09:32:20 +0000 Subject: hg: jdk8/tl/jdk: 7151010: Add compiler support for repeating annotations Message-ID: <20120831093502.8291647830@hg.openjdk.java.net> Changeset: bdfcc13ddeb4 Author: jfranck Date: 2012-08-31 10:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdfcc13ddeb4 7151010: Add compiler support for repeating annotations Reviewed-by: darcy, jjg + src/share/classes/java/lang/annotation/ContainerFor.java From jonathan.gibbons at oracle.com Fri Aug 31 02:38:54 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 31 Aug 2012 09:38:54 +0000 Subject: hg: jdk8/tl/langtools: 7151010: Add compiler support for repeating annotations Message-ID: <20120831093903.4FE7A47831@hg.openjdk.java.net> Changeset: 873ddd9f4900 Author: jfranck Date: 2012-08-31 10:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/873ddd9f4900 7151010: Add compiler support for repeating annotations Reviewed-by: jjg, mcimadamore + src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Lint.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/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/Enter.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java + test/tools/javac/annotations/repeatingAnnotations/BasicRepeatingAnnotations.java + test/tools/javac/annotations/repeatingAnnotations/CheckTargets.java + test/tools/javac/annotations/repeatingAnnotations/ContainerHasRepeatedContained.java + test/tools/javac/annotations/repeatingAnnotations/DelayRepeatedContainer.java + test/tools/javac/annotations/repeatingAnnotations/InvalidTarget.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/NestedContainers.java + test/tools/javac/annotations/repeatingAnnotations/RepMemberAnno.java + test/tools/javac/annotations/repeatingAnnotations/RepSelfMemberAnno.java + test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java + test/tools/javac/annotations/repeatingAnnotations/SelfRepeatingAnnotations.java + test/tools/javac/annotations/repeatingAnnotations/SingleRepeatingAndContainer.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java + test/tools/javac/diags/examples/ContainedByInheritedMismatch.java + test/tools/javac/diags/examples/ContainedByNoValue.java + test/tools/javac/diags/examples/ContainedByNonDefault.java + test/tools/javac/diags/examples/ContainedByRetentionMismatch.java + test/tools/javac/diags/examples/ContainedByTargetMismatch.java + test/tools/javac/diags/examples/ContainedByWrongValueType.java ! test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/DuplicateAnnotationJava8.java + test/tools/javac/diags/examples/RepeatingAnnotationAndContainer.java + test/tools/javac/diags/examples/WrongContainedBy.java + test/tools/javac/diags/examples/WrongContainerFor.java From xuelei.fan at oracle.com Fri Aug 31 02:51:39 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 31 Aug 2012 17:51:39 +0800 Subject: Code review request: 7195426: kdc_default_options not supported correctly In-Reply-To: <504062D1.2050600@oracle.com> References: <24470614.1346396477127.JavaMail.sbladm@swsblss4-new.central.sun.com> <504062D1.2050600@oracle.com> Message-ID: <5040892B.20009@oracle.com> On 8/31/2012 3:08 PM, Weijun Wang wrote: > Please take a look at the change > > http://cr.openjdk.java.net/~weijun/7195426/webrev.00 > According to ASN.1 spec, "The leading bit of the bit string is identified by the "number" zero, ..." [X.680] 124 private static final int KDC_OPT_RENEWABLE_OK = 0x00000010; The position of renewable-ok is 27. I think the mask is 0x0000,0100. 125 private static final int KDC_OPT_FORWARDABLE = 0x40000000; The position of FORWARDED is 2. I think the mask is 0x2000,0000. Personally, I would like to use (1<<(31-n)) as the mask. It looks more straightforward. Xuelei > > It seems we confused the mask and the position. > > Thanks > Max > > > > -------- Original Message -------- > 7195426: kdc_default_options not supported correctly > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195426 > > Product: java > Category: jgss > Subcategory: krb5plugin > > === *Description* > ============================================================ > kdc_default_options is a hex number for krb5.conf to define the > KDCOptions flags in a single integer where each bit of it represents one > of 32 flags. > > If you want to find out if the n-th flag is turn on, you should check for > > kdc_default_options & (1<<(31-n)) > > However, java currently checks for > > kdc_default_options & n > From weijun.wang at oracle.com Fri Aug 31 03:02:01 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 Aug 2012 18:02:01 +0800 Subject: Code review request: 7195426: kdc_default_options not supported correctly In-Reply-To: <5040892B.20009@oracle.com> References: <24470614.1346396477127.JavaMail.sbladm@swsblss4-new.central.sun.com> <504062D1.2050600@oracle.com> <5040892B.20009@oracle.com> Message-ID: <50408B99.40608@oracle.com> Hi Xuelei The number is not equivalent to the ASN.1 bit string. It's more like a simple mapping to an unsigned 32 bit int. Here are some codes copied from MIT krb5: krb5.h: #define KDC_OPT_FORWARDABLE 0x40000000 get_in_tkt.c: if (options&KDC_OPT_FORWARDABLE) krb5_get_init_creds_opt_set_forwardable(opt, 1); else krb5_get_init_creds_opt_set_forwardable(opt, 0); I also think 1<<(31-n) is more clear, but since the constants have been there for so many years, I believe they were defined for this very purpose and directly use them. Thanks Max On 08/31/2012 05:51 PM, Xuelei Fan wrote: > On 8/31/2012 3:08 PM, Weijun Wang wrote: >> Please take a look at the change >> >> http://cr.openjdk.java.net/~weijun/7195426/webrev.00 >> > According to ASN.1 spec, "The leading bit of the bit string is > identified by the "number" zero, ..." [X.680] > > 124 private static final int KDC_OPT_RENEWABLE_OK = 0x00000010; > The position of renewable-ok is 27. I think the mask is 0x0000,0100. > > 125 private static final int KDC_OPT_FORWARDABLE = 0x40000000; > The position of FORWARDED is 2. I think the mask is 0x2000,0000. > > Personally, I would like to use (1<<(31-n)) as the mask. It looks more > straightforward. > > Xuelei > >> >> It seems we confused the mask and the position. >> >> Thanks >> Max >> >> >> >> -------- Original Message -------- >> 7195426: kdc_default_options not supported correctly >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195426 >> >> Product: java >> Category: jgss >> Subcategory: krb5plugin >> >> === *Description* >> ============================================================ >> kdc_default_options is a hex number for krb5.conf to define the >> KDCOptions flags in a single integer where each bit of it represents one >> of 32 flags. >> >> If you want to find out if the n-th flag is turn on, you should check for >> >> kdc_default_options & (1<<(31-n)) >> >> However, java currently checks for >> >> kdc_default_options & n >> > From xuelei.fan at oracle.com Fri Aug 31 03:24:41 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 31 Aug 2012 18:24:41 +0800 Subject: Code review request: 7195426: kdc_default_options not supported correctly In-Reply-To: <50408B99.40608@oracle.com> References: <24470614.1346396477127.JavaMail.sbladm@swsblss4-new.central.sun.com> <504062D1.2050600@oracle.com> <5040892B.20009@oracle.com> <50408B99.40608@oracle.com> Message-ID: <504090E9.9010104@oracle.com> Got it! Thanks, Xuelei On 8/31/2012 6:02 PM, Weijun Wang wrote: > Hi Xuelei > > The number is not equivalent to the ASN.1 bit string. It's more like a > simple mapping to an unsigned 32 bit int. Here are some codes copied > from MIT krb5: > > krb5.h: > > #define KDC_OPT_FORWARDABLE 0x40000000 > > get_in_tkt.c: > > if (options&KDC_OPT_FORWARDABLE) > krb5_get_init_creds_opt_set_forwardable(opt, 1); > else krb5_get_init_creds_opt_set_forwardable(opt, 0); > > I also think 1<<(31-n) is more clear, but since the constants have been > there for so many years, I believe they were defined for this very > purpose and directly use them. > > Thanks > Max > > > On 08/31/2012 05:51 PM, Xuelei Fan wrote: >> On 8/31/2012 3:08 PM, Weijun Wang wrote: >>> Please take a look at the change >>> >>> http://cr.openjdk.java.net/~weijun/7195426/webrev.00 >>> >> According to ASN.1 spec, "The leading bit of the bit string is >> identified by the "number" zero, ..." [X.680] >> >> 124 private static final int KDC_OPT_RENEWABLE_OK = 0x00000010; >> The position of renewable-ok is 27. I think the mask is 0x0000,0100. >> >> 125 private static final int KDC_OPT_FORWARDABLE = 0x40000000; >> The position of FORWARDED is 2. I think the mask is 0x2000,0000. >> >> Personally, I would like to use (1<<(31-n)) as the mask. It looks more >> straightforward. >> >> Xuelei >> >>> >>> It seems we confused the mask and the position. >>> >>> Thanks >>> Max >>> >>> >>> >>> -------- Original Message -------- >>> 7195426: kdc_default_options not supported correctly >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195426 >>> >>> Product: java >>> Category: jgss >>> Subcategory: krb5plugin >>> >>> === *Description* >>> ============================================================ >>> kdc_default_options is a hex number for krb5.conf to define the >>> KDCOptions flags in a single integer where each bit of it represents one >>> of 32 flags. >>> >>> If you want to find out if the n-th flag is turn on, you should check >>> for >>> >>> kdc_default_options & (1<<(31-n)) >>> >>> However, java currently checks for >>> >>> kdc_default_options & n >>> >> From sean.coffey at oracle.com Fri Aug 31 04:22:45 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 31 Aug 2012 11:22:45 +0000 Subject: hg: jdk8/tl/jdk: 7195063: [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure. Message-ID: <20120831112311.A2D4547834@hg.openjdk.java.net> Changeset: da1436b21bc2 Author: coffeys Date: 2012-08-31 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da1436b21bc2 7195063: [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure. Reviewed-by: chegar ! test/com/sun/corba/cachedSocket/7056731.sh From alan.bateman at oracle.com Fri Aug 31 04:26:16 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 31 Aug 2012 11:26:16 +0000 Subject: hg: jdk8/tl/jdk: 7033824: TEST_BUG: java/nio/file/Files/CopyAndMove.java fails intermittently Message-ID: <20120831112639.482B947835@hg.openjdk.java.net> Changeset: 33f8ca2b4ba3 Author: alanb Date: 2012-08-31 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33f8ca2b4ba3 7033824: TEST_BUG: java/nio/file/Files/CopyAndMove.java fails intermittently Reviewed-by: chegar ! test/java/nio/file/Files/CopyAndMove.java