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 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 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 david.holmes at oracle.com Thu Aug 2 07:44:24 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Aug 2012 00:44:24 +1000 Subject: Crash due to missing synchronization on 'gconf_client' in 'jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c' In-Reply-To: <501A5C49.5020106@schulte.it> References: <501A5C49.5020106@schulte.it> Message-ID: <501A9248.3090008@oracle.com> Hi Christian, Probably best to discuss this on the net-dev at openjdk.java.net list (cc'd). Two comments from me (I'm not on net-dev): 1. CHECK_NULL does a return so you will be leaving the monitor locked if you encounter any nulls. 2. Is it simpler to add synchronization at the Java level? (I don't know how this code is used) David Holmes On 2/08/2012 8:54 PM, Christian Schulte wrote: > Hi, > > using the system property 'java.net.useSystemProxies', JDK 7 crashes on > OpenBSD 5.2. > > $ /usr/local/jre-1.7.0/bin/java -version > openjdk version "1.7.0_03" > OpenJDK Runtime Environment (build 1.7.0_03-b04) > OpenJDK Server VM (build 22.1-b02, mixed mode) > > $ /usr/local/jre-1.7.0/bin/java -cp . Crash > 2538: assertion failed "allocator->lock_loc == NULL" file > "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line 79 > function _dbus_data_slot_allocator_alloc > 2538: assertion failed "allocator->lock_loc == NULL" file > "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line 79 > function _dbus_data_slot_allocator_alloc > 2538: assertion failed "allocator->lock_loc == NULL" file > "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line 79 > function _dbus_data_slot_allocator_alloc > 2538: assertion failed "allocator->lock_loc == NULL" file > "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line 79 > function _dbus_data_slot_allocator_alloc > D-Bus not compiled with backtrace support so unable to print a backtrace > D-Bus not compiled with backtrace support so unable to print a backtrace > > $ /usr/local/jre-1.7.0/bin/java -cp . Crash > 27421: assertion failed "!(connection)->have_connection_lock" file > "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-connection.c" line 1133 > function _dbus_connection_acquire_io_path > D-Bus not compiled with backtrace support so unable to print a backtrace > Abort trap (core dumped) > > Looking at > 'openjdk/jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c', > there is a 'static void* gconf_client' which is initialized by calling > 'gconf_client_get_default' from 'libgconf-2'. Uses of that client are > not protected against concurrent accesses by multiple threads although > that gconf client is not thread-safe. Trying to add some protection > myself resulted in the attached patch. Rebuilding JDK 1.7 with this > patch applied, the 'gconf'/'dbus' related crashes no longer happen. > > Regards, > From chris.hegarty at oracle.com Thu Aug 2 08:27:50 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 02 Aug 2012 16:27:50 +0100 Subject: Crash due to missing synchronization on 'gconf_client' in 'jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c' In-Reply-To: <501A9248.3090008@oracle.com> References: <501A5C49.5020106@schulte.it> <501A9248.3090008@oracle.com> Message-ID: <501A9C76.2070007@oracle.com> Thanks for the cross post David. Yes, net-dev is the best place to discuss this issue ( bcc'ing off jdk7u-dev ). Thanks for reporting this issue Christian. I haven't looked at the proposed patch yet, but I agree we may want to simplify this if possible ( handling the synchronization at the Java level ). We also need to add support for gnome3 system proxies in the near future. We need to ensure we don't further complicate that. I filed CR 7188755: "Crash due to missing synchronization on gconf_client in DefaultProxySelector.c", to track this issue. -Chris. On 02/08/12 15:44, David Holmes wrote: > Hi Christian, > > Probably best to discuss this on the net-dev at openjdk.java.net list (cc'd). > > Two comments from me (I'm not on net-dev): > > 1. CHECK_NULL does a return so you will be leaving the monitor locked if > you encounter any nulls. > > 2. Is it simpler to add synchronization at the Java level? (I don't know > how this code is used) > > David Holmes > > On 2/08/2012 8:54 PM, Christian Schulte wrote: >> Hi, >> >> using the system property 'java.net.useSystemProxies', JDK 7 crashes on >> OpenBSD 5.2. >> >> $ /usr/local/jre-1.7.0/bin/java -version >> openjdk version "1.7.0_03" >> OpenJDK Runtime Environment (build 1.7.0_03-b04) >> OpenJDK Server VM (build 22.1-b02, mixed mode) >> >> $ /usr/local/jre-1.7.0/bin/java -cp . Crash >> 2538: assertion failed "allocator->lock_loc == NULL" file >> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line 79 >> function _dbus_data_slot_allocator_alloc >> 2538: assertion failed "allocator->lock_loc == NULL" file >> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line 79 >> function _dbus_data_slot_allocator_alloc >> 2538: assertion failed "allocator->lock_loc == NULL" file >> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line 79 >> function _dbus_data_slot_allocator_alloc >> 2538: assertion failed "allocator->lock_loc == NULL" file >> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line 79 >> function _dbus_data_slot_allocator_alloc >> D-Bus not compiled with backtrace support so unable to print a backtrace >> D-Bus not compiled with backtrace support so unable to print a backtrace >> >> $ /usr/local/jre-1.7.0/bin/java -cp . Crash >> 27421: assertion failed "!(connection)->have_connection_lock" file >> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-connection.c" line 1133 >> function _dbus_connection_acquire_io_path >> D-Bus not compiled with backtrace support so unable to print a backtrace >> Abort trap (core dumped) >> >> Looking at >> 'openjdk/jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c', >> there is a 'static void* gconf_client' which is initialized by calling >> 'gconf_client_get_default' from 'libgconf-2'. Uses of that client are >> not protected against concurrent accesses by multiple threads although >> that gconf client is not thread-safe. Trying to add some protection >> myself resulted in the attached patch. Rebuilding JDK 1.7 with this >> patch applied, the 'gconf'/'dbus' related crashes no longer happen. >> >> Regards, >> From ahughes at redhat.com Thu Aug 2 08:47:28 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 2 Aug 2012 11:47:28 -0400 (EDT) Subject: Crash due to missing synchronization on 'gconf_client' in 'jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c' In-Reply-To: <501A9C76.2070007@oracle.com> Message-ID: <1468250041.7748554.1343922448953.JavaMail.root@redhat.com> ----- Original Message ----- > Thanks for the cross post David. Yes, net-dev is the best place to > discuss this issue ( bcc'ing off jdk7u-dev ). > > Thanks for reporting this issue Christian. I haven't looked at the > proposed patch yet, but I agree we may want to simplify this if > possible > ( handling the synchronization at the Java level ). We also need to > add > support for gnome3 system proxies in the near future. We need to > ensure > we don't further complicate that. > We already have support for GNOME3 system proxies (now actually at the Glib level) in IcedTea and I intend to post an upstream version of this in the next few weeks. > I filed CR 7188755: "Crash due to missing synchronization on > gconf_client in DefaultProxySelector.c", to track this issue. > > -Chris. > > > > On 02/08/12 15:44, David Holmes wrote: > > Hi Christian, > > > > Probably best to discuss this on the net-dev at openjdk.java.net list > > (cc'd). > > > > Two comments from me (I'm not on net-dev): > > > > 1. CHECK_NULL does a return so you will be leaving the monitor > > locked if > > you encounter any nulls. > > > > 2. Is it simpler to add synchronization at the Java level? (I don't > > know > > how this code is used) > > > > David Holmes > > > > On 2/08/2012 8:54 PM, Christian Schulte wrote: > >> Hi, > >> > >> using the system property 'java.net.useSystemProxies', JDK 7 > >> crashes on > >> OpenBSD 5.2. > >> > >> $ /usr/local/jre-1.7.0/bin/java -version > >> openjdk version "1.7.0_03" > >> OpenJDK Runtime Environment (build 1.7.0_03-b04) > >> OpenJDK Server VM (build 22.1-b02, mixed mode) > >> > >> $ /usr/local/jre-1.7.0/bin/java -cp . Crash > >> 2538: assertion failed "allocator->lock_loc == NULL" file > >> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line > >> 79 > >> function _dbus_data_slot_allocator_alloc > >> 2538: assertion failed "allocator->lock_loc == NULL" file > >> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line > >> 79 > >> function _dbus_data_slot_allocator_alloc > >> 2538: assertion failed "allocator->lock_loc == NULL" file > >> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line > >> 79 > >> function _dbus_data_slot_allocator_alloc > >> 2538: assertion failed "allocator->lock_loc == NULL" file > >> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line > >> 79 > >> function _dbus_data_slot_allocator_alloc > >> D-Bus not compiled with backtrace support so unable to print a > >> backtrace > >> D-Bus not compiled with backtrace support so unable to print a > >> backtrace > >> > >> $ /usr/local/jre-1.7.0/bin/java -cp . Crash > >> 27421: assertion failed "!(connection)->have_connection_lock" file > >> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-connection.c" > >> line 1133 > >> function _dbus_connection_acquire_io_path > >> D-Bus not compiled with backtrace support so unable to print a > >> backtrace > >> Abort trap (core dumped) > >> > >> Looking at > >> 'openjdk/jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c', > >> there is a 'static void* gconf_client' which is initialized by > >> calling > >> 'gconf_client_get_default' from 'libgconf-2'. Uses of that client > >> are > >> not protected against concurrent accesses by multiple threads > >> although > >> that gconf client is not thread-safe. Trying to add some > >> protection > >> myself resulted in the attached patch. Rebuilding JDK 1.7 with > >> this > >> patch applied, the 'gconf'/'dbus' related crashes no longer > >> happen. > >> > >> Regards, > >> > -- 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 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 cs at schulte.it Thu Aug 2 22:53:03 2012 From: cs at schulte.it (Christian Schulte) Date: Fri, 03 Aug 2012 07:53:03 +0200 Subject: Crash due to missing synchronization on 'gconf_client' in 'jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c' In-Reply-To: <501A9C76.2070007@oracle.com> References: <501A5C49.5020106@schulte.it> <501A9248.3090008@oracle.com> <501A9C76.2070007@oracle.com> Message-ID: <501B673F.9080702@schulte.it> Am 08/02/12 17:27, schrieb Chris Hegarty: > Thanks for the cross post David. Yes, net-dev is the best place to > discuss this issue ( bcc'ing off jdk7u-dev ). > > Thanks for reporting this issue Christian. I haven't looked at the > proposed patch yet, but I agree we may want to simplify this if possible > ( handling the synchronization at the Java level ). We also need to add > support for gnome3 system proxies in the near future. We need to ensure > we don't further complicate that. The attached patch moves synchronization to the Java level for all platforms and also solves the issue here. Regards, -- Christian -------------- next part -------------- --- jdk/src/share/classes/sun/net/spi/DefaultProxySelector.java.orig Fri Aug 3 06:05:21 2012 +++ jdk/src/share/classes/sun/net/spi/DefaultProxySelector.java Fri Aug 3 06:05:37 2012 @@ -339,6 +339,6 @@ public class DefaultProxySelector extends ProxySelecto } } - private native static boolean init(); - private native Proxy getSystemProxy(String protocol, String host); + private synchronized native static boolean init(); + private synchronized native Proxy getSystemProxy(String protocol, String host); } From youdwei at linux.vnet.ibm.com Fri Aug 3 00:29:31 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Fri, 03 Aug 2012 15:29:31 +0800 Subject: InetAddress should utilize networkaddress.cache.ttl for getLocalHost() too In-Reply-To: <5018C36B.9040005@linux.vnet.ibm.com> References: <4FF52FEB.6000906@linux.vnet.ibm.com> <4FFD2474.2000404@oracle.com> <4FFD5B9C.6090701@oracle.com> <4FFE75D4.40701@linux.vnet.ibm.com> <500E3E00.7090208@linux.vnet.ibm.com> <50100E83.6010604@oracle.com> <501785E7.907@linux.vnet.ibm.com> <5017A61D.7090506@oracle.com> <5018C36B.9040005@linux.vnet.ibm.com> Message-ID: <501B7DDB.3080800@linux.vnet.ibm.com> Hi Michael, Any suggestion or comments for this issue? Thanks a lot! On 08/01/2012 01:49 PM, Deven You wrote: > Hi Michael, > > I have submitted a sun bug 7188315. I do not know about CCC request, > if needed, please conduct me to request it. > > Thanks a lot! > > On 07/31/2012 05:32 PM, Michael McMahon wrote: >> Deven >> >> Is there a bugid for this? We need to submit a CCC request also to >> make the spec change. >> >> Thanks >> Michael >> >> On 31/07/12 08:14, Deven You wrote: >>> Hi Michael, >>> >>> Thanks for your review, I have updated the patch[1] according to >>> your comments. >>> >>> [1] http://cr.openjdk.java.net/~youdwei/ojdk-527/webrev.03/ >>> >>> >>> Thanks a lot! >>> On 07/25/2012 11:19 PM, Michael McMahon wrote: >>>> On 24/07/12 07:17, Deven You wrote: >>>>> Hi Alan and Michael, >>>>> >>>>> I add a java doc[1] for the new networkaddress.cache.localhost.ttl >>>>> property. Please take a look when you have time. >>>>> >>>> >>>> The change looks fine to me. There is a typo in the apidoc in >>>> InetAddress. >>>> "as as" should be "as an". Might as well correct the same mistake >>>> in the previous >>>> paragraph also. >>>> >>>> Since this is a spec change, it will need a CCC request. Is there a >>>> bug id for this issue? >>>>> Again, I don't know how to set >>>>> cachePolicyPropFallback/negativeCachePolicyPropFallback. Any >>>>> suggestion please tell me. >>>>> >>>> >>>> These are system properties. So, they are normally set on the >>>> command line with java -Dsun.net.inetaddr.ttl=X .... >>>> >>>> - Michael. >>>> >>>>> [1] http://cr.openjdk.java.net/~youdwei/ojdk-527/webrev.01/ >>>>> >>>>> Thanks a lot! >>>>> >>>>> On 07/12/2012 02:59 PM, Deven You wrote: >>>>>> Hi Alan and Michael, >>>>>> >>>>>> Thanks very much for your kind suggestions. >>>>>> >>>>>> I agree that local host shouldn't follow the default caching >>>>>> mechanism because the IP may change frequently. And I also think >>>>>> making the cache time configurable is a better solution. >>>>>> >>>>>> I am willing to make these changes including adding the local >>>>>> host caching mechanism into the java doc. >>>>>> >>>>>> I have gone through the related code for InetAddress.java and >>>>>> InetAddressCachePolicy.java. And I think we could add a new >>>>>> security property networkaddress.cache.localhost.ttl to achieve >>>>>> the goal. >>>>>> >>>>>> As far as I know, to add networkaddress.cache.localhost.ttl I >>>>>> need change jdk/src/share/lib/security/java.security*(include >>>>>> java.security, java.security-solaris, java.security-macosx and >>>>>> java.security-windows). Please correct me if I have any >>>>>> misunderstanding. >>>>>> >>>>>> Here I have one question need your help: >>>>>> the static block in InetAddressCachePolicy.java will first >>>>>> try to get cachePolicyProp/negativeCachePolicyProp from System >>>>>> properties. If one of the cache values is null then the value of >>>>>> cachePolicyPropFallback/negativeCachePolicyProp would be got from >>>>>> System properties. >>>>>> I don't know where we declare these fallback properties so I >>>>>> have no idea where I can do the same thing for >>>>>> networkaddress.cache.localhost.ttl. >>>>>> >>>>>> Please take a look. >>>>>> >>>>>> Thanks a lot! >>>>>> >>>>>> >>>>>> On 07/11/2012 06:55 PM, Michael McMahon wrote: >>>>>>> On 11/07/12 08:00, Alan Bateman wrote: >>>>>>>> On 05/07/2012 07:10, Deven You wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I noticed that InetAddress.getLocalHost() uses cache to >>>>>>>>> improve the performance. However the default implementation is >>>>>>>>> caching local host within 5 seconds. >>>>>>>>> >>>>>>>>> From the spec, networkaddress.cache.ttl should be used to >>>>>>>>> control the cache behaviour and I think it is a better solution. >>>>>>>>> >>>>>>>>> For example, if the networkaddress.cache.ttl is set to -1 >>>>>>>>> which means always cache the local host then we can avoid >>>>>>>>> unnecessary operations on getAddressesFromNameService to >>>>>>>>> improve the performance. >>>>>>>>> >>>>>>>>> I have made a patch for this solution, so anyone would like to >>>>>>>>> take a look? >>>>>>>>> >>>>>>>>> [1] http://cr.openjdk.java.net/~littlee/OJDK-527/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks a lot! >>>>>>>>> -- >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Deven >>>>>>>> I'm not sure about this one as I suspect it will cause problems >>>>>>>> in DHCP or any environments where the host addresses changes, >>>>>>>> say moving to a different wireless network or waking up a >>>>>>>> machine after hibernation. >>>>>>>> >>>>>>>> -Alan >>>>>>> >>>>>>> That's true. We updated the spec for the caching behavior a >>>>>>> while back, and probably should have included this exception >>>>>>> for the local host. I agree that we shouldn't change the >>>>>>> behavior. Perhaps, the 5 seconds could be configurable itself, >>>>>>> but I think it should be kept separate from the main caching >>>>>>> behavior. >>>>>>> >>>>>>> - Michael. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Regards, >>>>>> >>>>>> Deven >>>>> >>>>> >>>>> -- >>>>> Best Regards, >>>>> >>>>> Deven >>>> >>> >>> >>> -- >>> Best Regards, >>> >>> Deven >> > > > -- > Best Regards, > > Deven -- Best Regards, Deven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20120803/f7728764/attachment.html 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 chris.hegarty at oracle.com Fri Aug 3 04:37:30 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 03 Aug 2012 12:37:30 +0100 Subject: Crash due to missing synchronization on 'gconf_client' in 'jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c' In-Reply-To: <1468250041.7748554.1343922448953.JavaMail.root@redhat.com> References: <1468250041.7748554.1343922448953.JavaMail.root@redhat.com> Message-ID: <501BB7FA.1020309@oracle.com> On 02/08/12 16:47, Andrew Hughes wrote: > ----- Original Message ----- >> Thanks for the cross post David. Yes, net-dev is the best place to >> discuss this issue ( bcc'ing off jdk7u-dev ). >> >> Thanks for reporting this issue Christian. I haven't looked at the >> proposed patch yet, but I agree we may want to simplify this if >> possible >> ( handling the synchronization at the Java level ). We also need to >> add >> support for gnome3 system proxies in the near future. We need to >> ensure >> we don't further complicate that. >> > > We already have support for GNOME3 system proxies (now actually > at the Glib level) in IcedTea and I intend to post an upstream version > of this in the next few weeks. This would be great Andrew. It's been on my todo list for a while now. I look forward to this contribution. -Chris. > >> I filed CR 7188755: "Crash due to missing synchronization on >> gconf_client in DefaultProxySelector.c", to track this issue. >> >> -Chris. >> >> >> >> On 02/08/12 15:44, David Holmes wrote: >>> Hi Christian, >>> >>> Probably best to discuss this on the net-dev at openjdk.java.net list >>> (cc'd). >>> >>> Two comments from me (I'm not on net-dev): >>> >>> 1. CHECK_NULL does a return so you will be leaving the monitor >>> locked if >>> you encounter any nulls. >>> >>> 2. Is it simpler to add synchronization at the Java level? (I don't >>> know >>> how this code is used) >>> >>> David Holmes >>> >>> On 2/08/2012 8:54 PM, Christian Schulte wrote: >>>> Hi, >>>> >>>> using the system property 'java.net.useSystemProxies', JDK 7 >>>> crashes on >>>> OpenBSD 5.2. >>>> >>>> $ /usr/local/jre-1.7.0/bin/java -version >>>> openjdk version "1.7.0_03" >>>> OpenJDK Runtime Environment (build 1.7.0_03-b04) >>>> OpenJDK Server VM (build 22.1-b02, mixed mode) >>>> >>>> $ /usr/local/jre-1.7.0/bin/java -cp . Crash >>>> 2538: assertion failed "allocator->lock_loc == NULL" file >>>> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line >>>> 79 >>>> function _dbus_data_slot_allocator_alloc >>>> 2538: assertion failed "allocator->lock_loc == NULL" file >>>> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line >>>> 79 >>>> function _dbus_data_slot_allocator_alloc >>>> 2538: assertion failed "allocator->lock_loc == NULL" file >>>> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line >>>> 79 >>>> function _dbus_data_slot_allocator_alloc >>>> 2538: assertion failed "allocator->lock_loc == NULL" file >>>> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-dataslot.c" line >>>> 79 >>>> function _dbus_data_slot_allocator_alloc >>>> D-Bus not compiled with backtrace support so unable to print a >>>> backtrace >>>> D-Bus not compiled with backtrace support so unable to print a >>>> backtrace >>>> >>>> $ /usr/local/jre-1.7.0/bin/java -cp . Crash >>>> 27421: assertion failed "!(connection)->have_connection_lock" file >>>> "/usr/ports/pobj/dbus-1.6.2/dbus-1.6.2/dbus/dbus-connection.c" >>>> line 1133 >>>> function _dbus_connection_acquire_io_path >>>> D-Bus not compiled with backtrace support so unable to print a >>>> backtrace >>>> Abort trap (core dumped) >>>> >>>> Looking at >>>> 'openjdk/jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c', >>>> there is a 'static void* gconf_client' which is initialized by >>>> calling >>>> 'gconf_client_get_default' from 'libgconf-2'. Uses of that client >>>> are >>>> not protected against concurrent accesses by multiple threads >>>> although >>>> that gconf client is not thread-safe. Trying to add some >>>> protection >>>> myself resulted in the attached patch. Rebuilding JDK 1.7 with >>>> this >>>> patch applied, the 'gconf'/'dbus' related crashes no longer >>>> happen. >>>> >>>> Regards, >>>> >> > 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 dingxmin at linux.vnet.ibm.com Mon Aug 6 22:46:32 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Tue, 07 Aug 2012 13:46:32 +0800 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX Message-ID: <5020ABB8.7080507@linux.vnet.ibm.com> Hi all, In source code "jdk\src\solaris\native\java\net\PlainDatagramSocketImpl.c", there are several macros in the form of #ifdef AF_INET6 #if defined(__solaris__) || defined(MACOSX) // code for solaris and macosx (unix) [1] #endif #ifdef __linux__ // code for linux #endif #else // code for non AF_INET6 #endif /* AF_INET6 */ The code blocks enclosed by the macro are method invocations of mcast_set_if_by_addr_v6(), mcast_set_if_by_addr_v4(), mcast_set_loop_v4(), mcast_set_loop_v6(), setHopLimit() and setTTL(). Other unix-like os, i.e. AIX, BSD and some other need exact calling sequence coded in block [1]. So I made a patch that transformed the above code into the following pattern #ifdef AF_INET6 #ifdef __linux__ // code for linux #else /* __linux__ not defined */ // code for UNIX #endif /* __linux__ */ #else // non AF_INET6 #endif /* AF_INET6 */ Could anybody take a look at my patch below and make comment? http://cr.openjdk.java.net/~youdwei/ojdk-533/webrev.00/ Thanks & Best regards, Frank 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 michael.x.mcmahon at oracle.com Tue Aug 7 16:09:42 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 08 Aug 2012 00:09:42 +0100 Subject: Http client API Message-ID: <5021A036.6020107@oracle.com> Hi, A new revision of the Http client API planned for jdk 8 can be viewed at the following link http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ We would like to review the api on this mailing list. So, all comments are welcome. Thanks Michael McMahon. 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 zhouyx at linux.vnet.ibm.com Tue Aug 7 23:25:50 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Wed, 8 Aug 2012 14:25:50 +0800 Subject: Http client API In-Reply-To: <5021A036.6020107@oracle.com> References: <5021A036.6020107@oracle.com> Message-ID: Is it possible to have methods like public abstract HTMLDocument getResponse(String request) in class HttpClient ? On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon < michael.x.mcmahon at oracle.com> wrote: > Hi, > > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~**michaelm/httpclient/v0.3/ > > We would like to review the api on this mailing list. > So, all comments are welcome. > > Thanks > Michael McMahon. > -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20120808/1837a14f/attachment.html From chris.hegarty at oracle.com Wed Aug 8 02:52:18 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 08 Aug 2012 10:52:18 +0100 Subject: Http client API In-Reply-To: References: <5021A036.6020107@oracle.com> Message-ID: <502236D2.6070301@oracle.com> On 08/08/2012 07:25, Sean Chou wrote: > > Is it possible to have methods like > > public abstract HTMLDocument getResponse(String request) in class > HttpClient ? Hi Sean, I think what you are suggesting is content specific convenience methods, something akin to URLConnection.getContent(), right? In my experience, this type of interface can be a little problematic and not all that widely used. I'm personally not in favor of such convenience methods. I can see their potential value, but this would appear to be a low level API and I don't think it should favor one specific content type over another. From my reading of the API it exposes various methods to access the response body. It is quite easy to wrap one of these in a content specific parser. For example, for xml you could do XMLInputFactory xif = ...; xif.createStreamReader(client.getResponse(request).getBodyAsInputStream()); OR SAXParserFactory spf = ...; spf.newSAXParser().parse(client.getResponse(request).getBodyAsInputStream(), handler); I think this gives the best flexibility without favoring one content type parser, or one programming model, over another. Does this make sense? Have I missed the point of your proposal? Maybe others have a different view... -Chris. > > > > On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon > > wrote: > > Hi, > > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~__michaelm/httpclient/v0.3/ > > > We would like to review the api on this mailing list. > So, all comments are welcome. > > Thanks > Michael McMahon. > > > > > -- > Best Regards, > Sean Chou > From Alan.Bateman at oracle.com Wed Aug 8 04:38:08 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Aug 2012 12:38:08 +0100 Subject: Http client API In-Reply-To: References: <5021A036.6020107@oracle.com> Message-ID: <50224FA0.8020907@oracle.com> On 08/08/2012 07:25, Sean Chou wrote: > > Is it possible to have methods like > > public abstract HTMLDocument getResponse(String request) in class > HttpClient ? > I see Chris has replied to this. One other point is that we also need to consider JDK modularization and I don't think we should have anything in this API that would require the AWT/Swing (or the "desktop" module as know it in the current prototype set of modules). -Alan 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 xuelei.fan at oracle.com Wed Aug 8 05:10:27 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 08 Aug 2012 20:10:27 +0800 Subject: Http client API In-Reply-To: <5021A036.6020107@oracle.com> References: <5021A036.6020107@oracle.com> Message-ID: <50225733.5040207@oracle.com> >From JDK 7, JSSE introduces a new hostname verifying approach. It is call "endpoint identification" in JSSE context. It can be used to replace the HostnameVerifier on SSLSession. A typical user case looks like: 1. implement a X509ExtendedTrustManager. It is required to check the endpoint identification in the following methods: checkClientTrusted(X509Certificate[], String, Socket) checkClientTrusted(X509Certificate[], String, SSLEngine) checkServerTrusted(X509Certificate[], String, Socket) checkServerTrusted(X509Certificate[], String, SSLEngine) 2. initialize a SSLParameters to enable the endpoint identification: sslParameter.setEndpointIdentificationAlgorithm("https"); 3. set the SSLParameters to SSLSocket or SSLEngine, the instance of X509ExtendedTrustManager will check the endpoint (hostname) during handshaking. Considering the java.net.httpclient.HttpsConfigurator, it is an implementation of HostnameVerifier. So it would support both HostnameVerifier and the above endpoint identification. I think as may be redundant if no compatibility concerns. I was wondering maybe it is OK to detach the HostnameVerifier interface and remove the verify() method. Maybe, you have other concerns that the HttpsConfigurator.verify() method is really needed. Thanks, Xuelei On 8/8/2012 7:09 AM, Michael McMahon wrote: > Hi, > > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ > > We would like to review the api on this mailing list. > So, all comments are welcome. > > Thanks > Michael McMahon. 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 anthony.vanelverdinghe at gmail.com Wed Aug 8 11:23:31 2012 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Wed, 08 Aug 2012 20:23:31 +0200 Subject: Http client API In-Reply-To: <5021A036.6020107@oracle.com> References: <5021A036.6020107@oracle.com> Message-ID: <5022AEA3.9030403@gmail.com> Hi With the current API (java.net.HttpURLConnection) it 's not possible to follow redirects from one protocol to another (http to https & vice versa). This is a known problem ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4620571 ), but out of security concerns this feature was not added. Will you please reconsider this feature for the new API and possibly: add extra methods: HttpRequest#setFollowRedirectsAccrossProtocols(boolean follows) & HttpRequest#followRedirectsAcrossProtocols() which would be false by default or add a system property (like the ones at http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html ) ? I am not a security expert, but for example Firefox happily follows such redirects, even in a single request like: http (request) -> https -> http (response) The current behavior is also what caused a recent issue with the JavaFX installer ( http://javafx-jira.kenai.com/browse/RT-21275 ). The solution to this JavaFX issue says the fix "enhanced code to follow https redirects." So JavaFX seems to already implement this feature. Thanks for your feedback Anthony Vanelverdinghe Op 8/08/2012 1:09, Michael McMahon schreef: > Hi, > > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ > > We would like to review the api on this mailing list. > So, all comments are welcome. > > Thanks > Michael McMahon. > > From ian.b.robertson at gmail.com Wed Aug 8 12:09:34 2012 From: ian.b.robertson at gmail.com (Ian Robertston) Date: Wed, 8 Aug 2012 19:09:34 +0000 (UTC) Subject: Http client API References: <5021A036.6020107@oracle.com> Message-ID: Instead of HttpRequest having void setBody(Iterable buffers, boolean isRestartable) what about having two methods: void setBody(Iterable buffers) // presumed restartable void setBody(Iterator buffers) // clearly not restartable Not only does this avoid a potentially confusing boolean parameter, but it also avoids forcing people to create "dishonest" Iterables, where they know the iterator() method cannot be called more than once. - Ian From chris.hegarty at oracle.com Wed Aug 8 13:35:12 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 08 Aug 2012 21:35:12 +0100 Subject: cross protocol redirects ( was:Re: Http client API ) In-Reply-To: <5022AEA3.9030403@gmail.com> References: <5021A036.6020107@oracle.com> <5022AEA3.9030403@gmail.com> Message-ID: <5022CD80.6030601@oracle.com> Great suggestion Anthony, This is something that comes up from time to time. With the clear distinction between java.net.HttpURLConnection and javax.net.ssl.HttpsURLConnection API's then it was a little difficult to do in the existing API, but there is a clear opportunity with the new API to avoid this issue in the future. Kurchi just informed me (off-list) that the current prototype implementation in the java.net project [1], supports cross protocol redirects. Though, this may be by accident! We need to do some further investigating to determine if the security concerns related to 4620571 are still valid. If so, and we cannot continue with automatic cross protocol redirects, then an explicit API ( like you suggested ) should be added. Thanks, -Chris. [1] http://java.net/projects/http-client/ On 08/08/12 19:23, Anthony Vanelverdinghe wrote: > Hi > > With the current API (java.net.HttpURLConnection) it 's not possible to > follow redirects from one protocol to another (http to https & vice versa). > This is a known problem ( > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4620571 ), but out of > security concerns this feature was not added. > > Will you please reconsider this feature for the new API and possibly: > add extra methods: > HttpRequest#setFollowRedirectsAccrossProtocols(boolean follows) & > HttpRequest#followRedirectsAcrossProtocols() which would be false by > default > or add a system property (like the ones at > http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html ) > ? > > I am not a security expert, but for example Firefox happily follows such > redirects, even in a single request like: http (request) -> https -> > http (response) > The current behavior is also what caused a recent issue with the JavaFX > installer ( http://javafx-jira.kenai.com/browse/RT-21275 ). The solution > to this JavaFX issue says the fix "enhanced code to follow https > redirects." So JavaFX seems to already implement this feature. > > Thanks for your feedback > > Anthony Vanelverdinghe > > > Op 8/08/2012 1:09, Michael McMahon schreef: >> Hi, >> >> A new revision of the Http client API planned for jdk 8 can be viewed >> at the following link >> >> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> We would like to review the api on this mailing list. >> So, all comments are welcome. >> >> Thanks >> Michael McMahon. >> >> > From chris.hegarty at oracle.com Wed Aug 8 13:50:23 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 08 Aug 2012 21:50:23 +0100 Subject: Http client API In-Reply-To: References: <5021A036.6020107@oracle.com> Message-ID: <5022D10F.4000108@oracle.com> Oh, my head hurts! ;-) There are already three setBody methods. I agree, a boolean like this can be confusing. A setBodyRestartable(Itr), and setBodyNonRestarable(Itr) may be a possible solution here. But ( what I think you are suggesting too ), Iterable implementations should do the right thing, they should always be "restartable". Maybe/Simply remove the restartable boolean param and put a note in the spec that Iterable implementations that for whatever reason cannot be restarted should perform some kind of caching. So we only support "honest" Iterables. Unless I'm missing some valid use-case that demands this non-restartable API. -Chris. On 08/08/12 20:09, Ian Robertston wrote: > Instead of HttpRequest having > > void setBody(Iterable buffers, boolean isRestartable) > > what about having two methods: > > void setBody(Iterable buffers) // presumed restartable > void setBody(Iterator buffers) // clearly not restartable > > Not only does this avoid a potentially confusing boolean parameter, but it also > avoids forcing people to create "dishonest" Iterables, where they know the > iterator() method cannot be called more than once. > > - Ian > From mike.duigou at oracle.com Wed Aug 8 15:33:16 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 8 Aug 2012 15:33:16 -0700 Subject: Http client API In-Reply-To: <5021A036.6020107@oracle.com> References: <5021A036.6020107@oracle.com> Message-ID: <20BA6568-5487-4BF2-8578-5AAEB24D3CA0@oracle.com> Hi Michael! I really look forward to using this API! It looks like you have made a lot of progress. Sorry for having so many comments on just one round. Mike General:: - It's probably already been mentioned but having the classes in the httpclient package and most of them begin with "Http" seems redundant. - Package JavaDoc is missing for both packages. - Is the SPI package needed for just one class? - I am unsure if sendRequest should be a method of Client or Request. HttpClientProvider:: - HttpClientProvider JavaDoc uses inconsistent capitalization of HTTP. - createAsynchronousHttpClient() Since there's only one create method why bother to mention that it's "Asynchronous"? - It's not clear how loadFromExternal() is different from provider(). - provider enumeration, request alternate providers? HttpClient:: - There's no way to identify the source of the HttpClient(). ie. it is returned by provider() but there's no way to tell what you got. Would be useful for debugging to log to the file what provider you received. - HttpClient createClient() -- is this the same as HttpClientProvider.provider().createAsynchronousHttpClient()? - There doesn't seem to be a way to be truly thread safe about changes to configuration other than to set all configuration options before sharing an HttpClient instance and then never changing the configuration. Is changing the configuration *after* sharing realistic or should perhaps configuration be immutable (perhaps using a Builder pattern for HttpClient instances, ie. createClient() becomes clientBuilder()). Seeing that the set methods return HttpClient (the same instance unfortunately) it looks like you are considering or have considered using a builder style construction. - Why expose the connection cache? Seems like just a good way to mess things up. Have you considered provider scope for connection cache? ie. all clients from the same provider share a cache? - setProxy lacks proxy authentication features. (sorry, I just said that to annoy you. :-) ) - Does the proxy default to system properties and respect the nonProxyHosts? ie: http.proxyHost (default: ) http.proxyPort (default: 80 if http.proxyHost specified) http.nonProxyHosts (default: ) - Is the default cookie manager from CookieHandler.getDefault() or is there no default? - Default is not specified for setAllowPipeLineMode() Presumably it is "false" - There's no discussion of pipeline mode and connection cache. - sendHeaders/sendRequest : presumably it is an error to use an HttpRequest from a different HttpClient. - setResponseBodyBufferLimit - like timeout this is a default. Perhaps setDefaultResponseBodyBufferLimit (long I know). - What happens with sendHeaders when the request already has a body? - Impact of closing the OutputStream returned from sendHeaders(). chunked mode vs. non-chucked. - getResponse : java.util.concurrent.TimeoutException has a nice name but is an odd exception to be throwing. java.net.SocketTimeoutException seems more appropriate. - I'm curious why setUpgradeHandler() takes a class rather than an instance. - getHttpsConfigurator() -- since a default is established before first invocation why not never return null. ie. implement the default behaviour in getHttpsConfigurator() and have the impl call getHttpsConfigurator(). - I missed the "s" in setHttpsConfigurator until I looked at the method in more detail. It doesn't really stand out. - getFilters() -- this is the only modify-in-place API. Kinda weird. I think having setFilters() would be better. HttpUpgradeHandler:: - perhaps in the spi package? - Method or methods to identify the UpgradeHandler. ie. getName(), getProtocols. UpgradeConnection:: - Perhaps "Upgrade**d**Connection"? - There's no way to get back the UpdgradeHandler or source client. SimpleConnectionClass:: - Package private? HttpRequest:: - copy() vs clone()? - setFollowRedirects should get a default from HttpClient (or remove defaults for timeout and buffer limits). Asymmetry is annoying. - setBody(Iterable, boolean isRestartable) -- This seems heinous. Non-restartable Iterables should be avoided. I like the suggestion of additional setBody(Iterable) method instead. - setRequestURI() -- eliminate this unless there is a really good reason to keep it. Alternately, perhaps copy(URI) instead? - getMethod() -- missing. HttpHeaders:: - getValues() how about return empty result when there is no header of that name? - getValues() -- the returned list is unmodifiable, correct? - contains() -- IAE for null. - getFirstValue() -- IAE for null name. It has to consistently be either IAE or NPE. - getAllHeaderNames() -- unmodifiable list, correct? HttpResponse:: - getBodyAsBytes(byte[], int) - I would rather the return the number of bytes put into the buffer. - getBodyAsBytes(byte[], int) - Why would I ever want a max size less than the size of my byte buffer? - getBodyAsBytes -- Document handling for content-length > Integer.MAX_VALUE - getBodyAsByteBuffers -- handling for not enough space in the array needs to be documented. Unused entries nulled out? - Perhaps maxlength -> maxBytes to be more clear? - getBodyAsByteBufferSource -- if the same iterator is always returned why not return the iterator rather than an iterable? HttpConnectionCache.CachedConnection:: - I would expect this to be abstract and that client providers would extend. - getCache() to return the client provider. On Aug 7 2012, at 16:09 , Michael McMahon wrote: > Hi, > > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ > > We would like to review the api on this mailing list. > So, all comments are welcome. > > Thanks > Michael McMahon. From jed at atlassian.com Wed Aug 8 16:00:02 2012 From: jed at atlassian.com (Jed Wesley-Smith) Date: Wed, 8 Aug 2012 23:00:02 +0000 (UTC) Subject: Http client API References: <5021A036.6020107@oracle.com> Message-ID: Michael McMahon writes: > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ > > We would like to review the api on this mailing list. > So, all comments are welcome. Can you separate the domain objects (in particular HttpClient, HttpRequest) and their set-up (all the mutators) into separate concerns (Builders perhaps, see Guava for instance)? It'd be nice to have this all thread-safe by default, it seems creating an API that isn't thread-safe is maybe not ideal. cheers, Jed Wesley-Smith From david.lloyd at redhat.com Wed Aug 8 17:49:56 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 08 Aug 2012 19:49:56 -0500 Subject: Http client API In-Reply-To: <5021A036.6020107@oracle.com> References: <5021A036.6020107@oracle.com> Message-ID: <50230934.8020101@redhat.com> On 08/07/2012 06:09 PM, Michael McMahon wrote: > Hi, > > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ > > We would like to review the api on this mailing list. > So, all comments are welcome. Why not javax.net.httpclient? Having it be backportable to earlier JDKs would definitely help adoption IMO. -- - DML From zhouyx at linux.vnet.ibm.com Wed Aug 8 22:10:19 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Thu, 9 Aug 2012 13:10:19 +0800 Subject: Http client API In-Reply-To: <502236D2.6070301@oracle.com> References: <5021A036.6020107@oracle.com> <502236D2.6070301@oracle.com> Message-ID: Hi Chris, That's exactly my concern. I agree this provides best flexibility and content convenient methods are not proper in this API. So, is there going to have content specific convenient APIs like java.nio.file.Files ? Although it is a wrapper, it may be useful and intuitive, and easy to use for those who just want to open a webpage but don't want to know request and response. And as well doesn't break modularization. Thanks. On Wed, Aug 8, 2012 at 5:52 PM, Chris Hegarty wrote: > On 08/08/2012 07:25, Sean Chou wrote: > >> >> Is it possible to have methods like >> >> public abstract HTMLDocument getResponse(String request) in class >> HttpClient ? >> > > Hi Sean, > > I think what you are suggesting is content specific convenience methods, > something akin to URLConnection.getContent(), right? In my experience, this > type of interface can be a little problematic and not all that widely used. > > I'm personally not in favor of such convenience methods. I can see their > potential value, but this would appear to be a low level API and I don't > think it should favor one specific content type over another. > > From my reading of the API it exposes various methods to access the > response body. It is quite easy to wrap one of these in a content specific > parser. For example, for xml you could do > > XMLInputFactory xif = ...; > > xif.createStreamReader(client.**getResponse(request).** > getBodyAsInputStream()); > > OR > SAXParserFactory spf = ...; > > spf.newSAXParser().parse(**client.getResponse(request).**getBodyAsInputStream(), > handler); > > I think this gives the best flexibility without favoring one content type > parser, or one programming model, over another. > > Does this make sense? Have I missed the point of your proposal? Maybe > others have a different view... > > -Chris. > > >> >> >> On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon >> >> >> wrote: >> >> Hi, >> >> A new revision of the Http client API planned for jdk 8 can be viewed >> at the following link >> >> http://cr.openjdk.java.net/~__**michaelm/httpclient/v0.3/ >> >> >> > >> >> We would like to review the api on this mailing list. >> So, all comments are welcome. >> >> Thanks >> Michael McMahon. >> >> >> >> >> -- >> Best Regards, >> Sean Chou >> >> -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20120809/7ea7d24b/attachment.html From shirishk at linux.vnet.ibm.com Thu Aug 9 01:53:20 2012 From: shirishk at linux.vnet.ibm.com (Shirish Kuncolienkar) Date: Thu, 09 Aug 2012 14:23:20 +0530 Subject: Parsing of URL's which contain Windows Path separator Message-ID: <50237A80.7020002@linux.vnet.ibm.com> Hi, I have the following piece of code URL url = new URL("file", "/", "C:\\temp\\Java6"); System.out.println(url); URL url1 = new URL(url, "hello.html"); System.out.println(url1); first System out prints as "file:///C:\temp\Java6\Lotus" Second one prints the value "file:////hello.html" As mentioned by URL parser specification the windows path separator happens to be a special character and hence the whole path is considered as a single block. However it will be useful for the URL class to take consider "\" character as a path separator as a special case and be able create relative url which is a valid one. I see mozilla browser simply replaces the "\" by a "/" and continues. URL parser could follow a similar approach. Any thoughts ? From Alan.Bateman at oracle.com Thu Aug 9 02:17:19 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 Aug 2012 10:17:19 +0100 Subject: Http client API In-Reply-To: <50230934.8020101@redhat.com> References: <5021A036.6020107@oracle.com> <50230934.8020101@redhat.com> Message-ID: <5023801F.5030005@oracle.com> On 09/08/2012 01:49, David M. Lloyd wrote: > On 08/07/2012 06:09 PM, Michael McMahon wrote: >> Hi, >> >> A new revision of the Http client API planned for jdk 8 can be viewed >> at the following link >> >> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> We would like to review the api on this mailing list. >> So, all comments are welcome. > > Why not javax.net.httpclient? I assume this would require submitting it as a standalone JSR. -Alan. From chris.hegarty at oracle.com Thu Aug 9 02:50:36 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 09 Aug 2012 10:50:36 +0100 Subject: Use Builder pattern ( was: Re: Http client API) In-Reply-To: References: <5021A036.6020107@oracle.com> Message-ID: <502387EC.90505@oracle.com> On 09/08/12 00:00, Jed Wesley-Smith wrote: > Michael McMahon writes: > >> A new revision of the Http client API planned for jdk 8 can be viewed >> at the following link >> >> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> We would like to review the api on this mailing list. >> So, all comments are welcome. > > Can you separate the domain objects (in particular HttpClient, HttpRequest) > and their set-up (all the mutators) into separate concerns (Builders perhaps, > see Guava for instance)? +1, I agree with your comment. Wherever possible we should try to use a builder pattern to build immutable objects ( or limit its mutability as much as possible ). I think Mike made a very similar comment too. Maybe the spi and factory/builder could be separated out, I think this would be much cleaner. As you say, you get thread-safety by default, which would appear to be a nice property for this API, given its different programming models. -Chris. > It'd be nice to have this all thread-safe by default, it seems creating an API > that isn't thread-safe is maybe not ideal. > > cheers, > Jed Wesley-Smith > > From chris.hegarty at oracle.com Thu Aug 9 03:00:26 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 09 Aug 2012 11:00:26 +0100 Subject: Http client API In-Reply-To: References: <5021A036.6020107@oracle.com> <502236D2.6070301@oracle.com> Message-ID: <50238A3A.6050208@oracle.com> On 09/08/12 06:10, Sean Chou wrote: > Hi Chris, > > That's exactly my concern. I agree this provides best flexibility > and content convenient methods are not proper in this API. So, is there > going to have content specific convenient APIs like java.nio.file.Files > ? Although it is a wrapper, it may be useful and intuitive, and easy to > use for those who just want to open a webpage but don't want to know > request and response. And as well doesn't break modularization. Thanks. I think it is certainly worth some consideration, but exactly where it would reside and how it could be specified without "breaking" modularity is a bit of a conundrum. Most of the types that would be useful to have in such a wrapper/convenience/utility API will come from modules that are not from the same module as the httpclient will most likely be targeted to. So any API will have cross module dependencies ( not necessarily a problem ), just need to think through the implications. -Chris > On Wed, Aug 8, 2012 at 5:52 PM, Chris Hegarty > wrote: > > On 08/08/2012 07:25, Sean Chou wrote: > > > Is it possible to have methods like > > public abstract HTMLDocument getResponse(String request) in class > HttpClient ? > > > Hi Sean, > > I think what you are suggesting is content specific convenience > methods, something akin to URLConnection.getContent(), right? In my > experience, this type of interface can be a little problematic and > not all that widely used. > > I'm personally not in favor of such convenience methods. I can see > their potential value, but this would appear to be a low level API > and I don't think it should favor one specific content type over > another. > > From my reading of the API it exposes various methods to access the > response body. It is quite easy to wrap one of these in a content > specific parser. For example, for xml you could do > > XMLInputFactory xif = ...; > > xif.createStreamReader(client.__getResponse(request).__getBodyAsInputStream()); > > OR > SAXParserFactory spf = ...; > > spf.newSAXParser().parse(__client.getResponse(request).__getBodyAsInputStream(), > handler); > > I think this gives the best flexibility without favoring one content > type parser, or one programming model, over another. > > Does this make sense? Have I missed the point of your proposal? > Maybe others have a different view... > > -Chris. > > > > > On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon > > >> wrote: > > Hi, > > A new revision of the Http client API planned for jdk 8 can > be viewed > at the following link > > http://cr.openjdk.java.net/~____michaelm/httpclient/v0.3/ > > > > > > We would like to review the api on this mailing list. > So, all comments are welcome. > > Thanks > Michael McMahon. > > > > > -- > Best Regards, > Sean Chou > > > > > -- > Best Regards, > Sean Chou > From chris.hegarty at oracle.com Thu Aug 9 03:13:37 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 09 Aug 2012 11:13:37 +0100 Subject: Http client API In-Reply-To: <20BA6568-5487-4BF2-8578-5AAEB24D3CA0@oracle.com> References: <5021A036.6020107@oracle.com> <20BA6568-5487-4BF2-8578-5AAEB24D3CA0@oracle.com> Message-ID: <50238D51.60301@oracle.com> Wow, Mike. Great feedback. I just scanned your comments, and agree/understand most of them. I'll help Michael to feed them back into the API. Though, there'll probably be a few follow up mails to answers your direct questions and seek further clarification before the new rev of the API. Thanks again, -Chris. On 08/08/12 23:33, Mike Duigou wrote: > Hi Michael! > > I really look forward to using this API! It looks like you have made a lot of progress. Sorry for having so many comments on just one round. > > Mike > > General:: > - It's probably already been mentioned but having the classes in the httpclient package and most of them begin with "Http" seems redundant. > > - Package JavaDoc is missing for both packages. > > - Is the SPI package needed for just one class? > > - I am unsure if sendRequest should be a method of Client or Request. > > > HttpClientProvider:: > > - HttpClientProvider JavaDoc uses inconsistent capitalization of HTTP. > > - createAsynchronousHttpClient() Since there's only one create method why bother to mention that it's "Asynchronous"? > > - It's not clear how loadFromExternal() is different from provider(). > > - provider enumeration, request alternate providers? > > > > HttpClient:: > > - There's no way to identify the source of the HttpClient(). ie. it is returned by provider() but there's no way to tell what you got. Would be useful for debugging to log to the file what provider you received. > > - HttpClient createClient() -- is this the same as HttpClientProvider.provider().createAsynchronousHttpClient()? > > - There doesn't seem to be a way to be truly thread safe about changes to configuration other than to set all configuration options before sharing an HttpClient instance and then never changing the configuration. Is changing the configuration *after* sharing realistic or should perhaps configuration be immutable (perhaps using a Builder pattern for HttpClient instances, ie. createClient() becomes clientBuilder()). Seeing that the set methods return HttpClient (the same instance unfortunately) it looks like you are considering or have considered using a builder style construction. > > - Why expose the connection cache? Seems like just a good way to mess things up. Have you considered provider scope for connection cache? ie. all clients from the same provider share a cache? > > - setProxy lacks proxy authentication features. (sorry, I just said that to annoy you. :-) ) > > - Does the proxy default to system properties and respect the nonProxyHosts? ie: > http.proxyHost (default: ) > http.proxyPort (default: 80 if http.proxyHost specified) > http.nonProxyHosts (default: ) > > - Is the default cookie manager from CookieHandler.getDefault() or is there no default? > > - Default is not specified for setAllowPipeLineMode() Presumably it is "false" > > - There's no discussion of pipeline mode and connection cache. > > - sendHeaders/sendRequest : presumably it is an error to use an HttpRequest from a different HttpClient. > > - setResponseBodyBufferLimit - like timeout this is a default. Perhaps setDefaultResponseBodyBufferLimit (long I know). > > - What happens with sendHeaders when the request already has a body? > > - Impact of closing the OutputStream returned from sendHeaders(). chunked mode vs. non-chucked. > > - getResponse : java.util.concurrent.TimeoutException has a nice name but is an odd exception to be throwing. java.net.SocketTimeoutException seems more appropriate. > > - I'm curious why setUpgradeHandler() takes a class rather than an instance. > > - getHttpsConfigurator() -- since a default is established before first invocation why not never return null. ie. implement the default behaviour in getHttpsConfigurator() and have the impl call getHttpsConfigurator(). > > - I missed the "s" in setHttpsConfigurator until I looked at the method in more detail. It doesn't really stand out. > > - getFilters() -- this is the only modify-in-place API. Kinda weird. I think having setFilters() would be better. > > > > HttpUpgradeHandler:: > > - perhaps in the spi package? > > - Method or methods to identify the UpgradeHandler. ie. getName(), getProtocols. > > > > UpgradeConnection:: > > - Perhaps "Upgrade**d**Connection"? > > - There's no way to get back the UpdgradeHandler or source client. > > > > SimpleConnectionClass:: > > - Package private? > > > > HttpRequest:: > > - copy() vs clone()? > > - setFollowRedirects should get a default from HttpClient (or remove defaults for timeout and buffer limits). Asymmetry is annoying. > > - setBody(Iterable, boolean isRestartable) -- This seems heinous. Non-restartable Iterables should be avoided. I like the suggestion of additional setBody(Iterable) method instead. > > - setRequestURI() -- eliminate this unless there is a really good reason to keep it. Alternately, perhaps copy(URI) instead? > > - getMethod() -- missing. > > > > HttpHeaders:: > > - getValues() how about return empty result when there is no header of that name? > > - getValues() -- the returned list is unmodifiable, correct? > > - contains() -- IAE for null. > > - getFirstValue() -- IAE for null name. It has to consistently be either IAE or NPE. > > - getAllHeaderNames() -- unmodifiable list, correct? > > > > HttpResponse:: > > - getBodyAsBytes(byte[], int) - I would rather the return the number of bytes put into the buffer. > > - getBodyAsBytes(byte[], int) - Why would I ever want a max size less than the size of my byte buffer? > > - getBodyAsBytes -- Document handling for content-length > Integer.MAX_VALUE > > - getBodyAsByteBuffers -- handling for not enough space in the array needs to be documented. Unused entries nulled out? > > - Perhaps maxlength -> maxBytes to be more clear? > > - getBodyAsByteBufferSource -- if the same iterator is always returned why not return the iterator rather than an iterable? > > > > HttpConnectionCache.CachedConnection:: > - I would expect this to be abstract and that client providers would extend. > > - getCache() to return the client provider. > > > On Aug 7 2012, at 16:09 , Michael McMahon wrote: > >> Hi, >> >> A new revision of the Http client API planned for jdk 8 can be viewed >> at the following link >> >> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> We would like to review the api on this mailing list. >> So, all comments are welcome. >> >> Thanks >> Michael McMahon. > From shirishk at linux.vnet.ibm.com Thu Aug 9 03:16:58 2012 From: shirishk at linux.vnet.ibm.com (Shirish Kuncolienkar) Date: Thu, 09 Aug 2012 15:46:58 +0530 Subject: Problem with getFlags() method in NetworkInterface.c Message-ID: <50238E1A.6090604@linux.vnet.ibm.com> Hi, The return value from the getFlags() method in NetworkInterface.c is interpreted in 2 ways. - If the value is negative an Exception is thrown - Else the return value is considered as the flag mask obtained via the ioctl call. In rare cases is it possible the value in the ifr_flags could be negative. One such case is VIPA interfaces. any calls like isUp() on such network interfaces would end up in a Socket Exception. I have patch for this. Anyone would like to take a look ? http://cr.openjdk.java.net/~luchsh/webrev20120809/ -Shirish From chris.hegarty at oracle.com Thu Aug 9 04:25:59 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 09 Aug 2012 12:25:59 +0100 Subject: Problem with getFlags() method in NetworkInterface.c In-Reply-To: <50238E1A.6090604@linux.vnet.ibm.com> References: <50238E1A.6090604@linux.vnet.ibm.com> Message-ID: <50239E47.8030805@oracle.com> Shirish, I am not familiar with VIPA interfaces, but I don't see any documentation that describes allowable values for flags that could cause the integer representing it to contain a negative value. I'm not opposed to the source changes, I just don't see that they are required. Can you please help explain? Thanks, -Chris. On 09/08/12 11:16, Shirish Kuncolienkar wrote: > Hi, > > The return value from the getFlags() method in NetworkInterface.c is > interpreted in 2 ways. > - If the value is negative an Exception is thrown > - Else the return value is considered as the flag mask obtained via the > ioctl call. > > In rare cases is it possible the value in the ifr_flags could be > negative. One such case is VIPA interfaces. any calls like isUp() on > such network interfaces would end up in a Socket Exception. > I have patch for this. Anyone would like to take a look ? > > http://cr.openjdk.java.net/~luchsh/webrev20120809/ > > -Shirish > From shirishk at linux.vnet.ibm.com Thu Aug 9 06:16:18 2012 From: shirishk at linux.vnet.ibm.com (Shirish Kuncolienkar) Date: Thu, 09 Aug 2012 18:46:18 +0530 Subject: Problem with getFlags() method in NetworkInterface.c In-Reply-To: <50239E47.8030805@oracle.com> References: <50238E1A.6090604@linux.vnet.ibm.com> <50239E47.8030805@oracle.com> Message-ID: <5023B822.1060404@linux.vnet.ibm.com> On 8/9/2012 4:55 PM, Chris Hegarty wrote: > Shirish, > > I am not familiar with VIPA interfaces, but I don't see any > documentation that describes allowable values for flags that could > cause the integer representing it to contain a negative value. > > I'm not opposed to the source changes, I just don't see that they are > required. Can you please help explain? > > Thanks, > -Chris. > > On 09/08/12 11:16, Shirish Kuncolienkar wrote: >> Hi, >> >> The return value from the getFlags() method in NetworkInterface.c is >> interpreted in 2 ways. >> - If the value is negative an Exception is thrown >> - Else the return value is considered as the flag mask obtained via the >> ioctl call. >> >> In rare cases is it possible the value in the ifr_flags could be >> negative. One such case is VIPA interfaces. any calls like isUp() on >> such network interfaces would end up in a Socket Exception. >> I have patch for this. Anyone would like to take a look ? >> >> http://cr.openjdk.java.net/~luchsh/webrev20120809/ >> >> -Shirish >> > Chris, I agree there is no general documentation available, AIX defines vipa interface flag as "0x80000000" Here is a similar bug report related to FreeBSD http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c6334146005c. A different fix was proposed here. Hope this helps. Thanks -Shirish From chris.hegarty at oracle.com Thu Aug 9 07:22:45 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 09 Aug 2012 15:22:45 +0100 Subject: Problem with getFlags() method in NetworkInterface.c In-Reply-To: <5023B822.1060404@linux.vnet.ibm.com> References: <50238E1A.6090604@linux.vnet.ibm.com> <50239E47.8030805@oracle.com> <5023B822.1060404@linux.vnet.ibm.com> Message-ID: <5023C7B5.7040508@oracle.com> On 09/08/12 14:16, Shirish Kuncolienkar wrote: > .... > I agree there is no general documentation available, AIX defines vipa > interface flag as "0x80000000" In which case I don't see any problems with your proposed source changes. One could argue that maybe they should go through the specific porting project ( since it's not directly relevant to existing supported platforms ), but I see this more of a clean up exercise. No need to carry such a trivial change in a project sub repo. Usually a new testcase is recommended, but in this case the functionality ( isUp, isXXX() ) is already exercised by many many tests so I think we can leave it to the other tests. I filed a new bug to track this issue, CR 7190254: "NetworkInterface getFlags implementation should support full integer bit range for flags value." If you don't mind, I would like to take your patch to NetworkInterface.c and run some sanity builds and tests on it. I'd hope to get this done later today or early tomorrow. -Chris. > Here is a similar bug report related to FreeBSD > http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c6334146005c. > A different fix was proposed here. > > Hope this helps. > > Thanks > -Shirish > From shirishk at linux.vnet.ibm.com Thu Aug 9 07:38:36 2012 From: shirishk at linux.vnet.ibm.com (Shirish Kuncolienkar) Date: Thu, 09 Aug 2012 20:08:36 +0530 Subject: Problem with getFlags() method in NetworkInterface.c In-Reply-To: <5023C7B5.7040508@oracle.com> References: <50238E1A.6090604@linux.vnet.ibm.com> <50239E47.8030805@oracle.com> <5023B822.1060404@linux.vnet.ibm.com> <5023C7B5.7040508@oracle.com> Message-ID: <5023CB6C.8040402@linux.vnet.ibm.com> Chris, Please go ahead and run the sanity builds and tests. Thanks -Shirish On 8/9/2012 7:52 PM, Chris Hegarty wrote: > > On 09/08/12 14:16, Shirish Kuncolienkar wrote: >> .... >> I agree there is no general documentation available, AIX defines vipa >> interface flag as "0x80000000" > > In which case I don't see any problems with your proposed source > changes. One could argue that maybe they should go through the > specific porting project ( since it's not directly relevant to > existing supported platforms ), but I see this more of a clean up > exercise. No need to carry such a trivial change in a project sub repo. > > Usually a new testcase is recommended, but in this case the > functionality ( isUp, isXXX() ) is already exercised by many many > tests so I think we can leave it to the other tests. > > I filed a new bug to track this issue, > CR 7190254: "NetworkInterface getFlags implementation should support > full integer bit range for flags value." > > If you don't mind, I would like to take your patch to > NetworkInterface.c and run some sanity builds and tests on it. I'd > hope to get this done later today or early tomorrow. > > -Chris. > >> Here is a similar bug report related to FreeBSD >> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c6334146005c. >> A different fix was proposed here. >> >> Hope this helps. >> >> Thanks >> -Shirish >> > 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 chris.hegarty at oracle.com Thu Aug 9 11:15:52 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 09 Aug 2012 19:15:52 +0100 Subject: Http client API In-Reply-To: <5021A036.6020107@oracle.com> References: <5021A036.6020107@oracle.com> Message-ID: <5023FE58.9030008@oracle.com> Michael, Looking good, some comments. 1) Why the use of CookieManager, rather than CookieHandler? I would expect that CookieHandler would be a cleaner API 2) What is the impact on the sendHeader, setBody for HEAD requests? 3) I think HttpClient could be an interface and move the create method to a builder/factory, and make it as immutable as possible ( this came up a few times now ). 4) The Filter API looks a little funny, in that filter instances are added to the client, while the ByteBufferWrapper instances are presumably created by the implementation after registering the wrapper class with the filter instance. Probably best/cleaner to use the same style. It could also be an interface. 5) ByteBufferWrapper seems a little cluttered with implementation detail setSource() nor setWrapper()?? Maybe best to just provide an interface. 6) Upgrade handler, similar comment to 4. Why not just register an instance. 7) Exposing the filter list seems a little wrong, given the getter/ setter style. 8) java.net.httpclient.HttpConnectionCache.CachedConnection should probably be an interface. 9) How does the cache handle tunnels? endpoint address/proxy/etc 10) Missing fluent style return from HttpRequest.setRequestBodyLimit 11) Should sendHeaders be specified to allow a null return value. I'm thinking about when setSendExpectContinue is set. -Chris. On 08/08/12 00:09, Michael McMahon wrote: > Hi, > > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ > > We would like to review the api on this mailing list. > So, all comments are welcome. > > Thanks > Michael McMahon. 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 chris.hegarty at oracle.com Fri Aug 10 09:09:59 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Aug 2012 17:09:59 +0100 Subject: Problem with getFlags() method in NetworkInterface.c In-Reply-To: <5023CB6C.8040402@linux.vnet.ibm.com> References: <50238E1A.6090604@linux.vnet.ibm.com> <50239E47.8030805@oracle.com> <5023B822.1060404@linux.vnet.ibm.com> <5023C7B5.7040508@oracle.com> <5023CB6C.8040402@linux.vnet.ibm.com> Message-ID: <50253257.4040700@oracle.com> Shirish, There were some minor issues with your patch ( it did not build on all platforms ). I fixed these issues and also updated the Mac variant of getFlags. It now compiles and runs on all platforms. The test has been dropped ( as I indicated in the previous mail ). http://cr.openjdk.java.net/~chegar/7190254/webrev.00/webrev/ If Neil ( or someone else from IBM ) is to push this, you can grab the patch from the above webrev (and list me as a reviewer). Otherwise, I can push it for you. -Chris. On 09/08/2012 15:38, Shirish Kuncolienkar wrote: > Chris, > > Please go ahead and run the sanity builds and tests. > > Thanks > -Shirish > > On 8/9/2012 7:52 PM, Chris Hegarty wrote: >> >> On 09/08/12 14:16, Shirish Kuncolienkar wrote: >>> .... >>> I agree there is no general documentation available, AIX defines vipa >>> interface flag as "0x80000000" >> >> In which case I don't see any problems with your proposed source >> changes. One could argue that maybe they should go through the >> specific porting project ( since it's not directly relevant to >> existing supported platforms ), but I see this more of a clean up >> exercise. No need to carry such a trivial change in a project sub repo. >> >> Usually a new testcase is recommended, but in this case the >> functionality ( isUp, isXXX() ) is already exercised by many many >> tests so I think we can leave it to the other tests. >> >> I filed a new bug to track this issue, >> CR 7190254: "NetworkInterface getFlags implementation should support >> full integer bit range for flags value." >> >> If you don't mind, I would like to take your patch to >> NetworkInterface.c and run some sanity builds and tests on it. I'd >> hope to get this done later today or early tomorrow. >> >> -Chris. >> >>> Here is a similar bug report related to FreeBSD >>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c6334146005c. >>> A different fix was proposed here. >>> >>> Hope this helps. >>> >>> Thanks >>> -Shirish >>> >> > > From chris.hegarty at oracle.com Fri Aug 10 09:10:20 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Aug 2012 17:10:20 +0100 Subject: Crash due to missing synchronization on 'gconf_client' in 'jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c' In-Reply-To: <501B673F.9080702@schulte.it> References: <501A5C49.5020106@schulte.it> <501A9248.3090008@oracle.com> <501A9C76.2070007@oracle.com> <501B673F.9080702@schulte.it> Message-ID: <5025326C.6010009@oracle.com> Christian, I finally got back to this. Since init() is only ever called from the class initializer it is implicitly single threaded, so we only need to add the synchronized keyword to getSystemProxy(). I also added a test for completeness. Here is the final webrev that I intend to push ( listing 'Christian Schulte ' as the contributor ). http://cr.openjdk.java.net/~chegar/7188755/webrev.00/webrev/ -Chris. On 03/08/2012 06:53, Christian Schulte wrote: > Am 08/02/12 17:27, schrieb Chris Hegarty: >> Thanks for the cross post David. Yes, net-dev is the best place to >> discuss this issue ( bcc'ing off jdk7u-dev ). >> >> Thanks for reporting this issue Christian. I haven't looked at the >> proposed patch yet, but I agree we may want to simplify this if possible >> ( handling the synchronization at the Java level ). We also need to add >> support for gnome3 system proxies in the near future. We need to ensure >> we don't further complicate that. > > The attached patch moves synchronization to the Java level for all > platforms and also solves the issue here. > > Regards, > From Alan.Bateman at oracle.com Fri Aug 10 09:28:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Aug 2012 17:28:42 +0100 Subject: Crash due to missing synchronization on 'gconf_client' in 'jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c' In-Reply-To: <5025326C.6010009@oracle.com> References: <501A5C49.5020106@schulte.it> <501A9248.3090008@oracle.com> <501A9C76.2070007@oracle.com> <501B673F.9080702@schulte.it> <5025326C.6010009@oracle.com> Message-ID: <502536BA.9060108@oracle.com> On 10/08/2012 17:10, Chris Hegarty wrote: > Christian, > > I finally got back to this. > > Since init() is only ever called from the class initializer it is > implicitly single threaded, so we only need to add the synchronized > keyword to getSystemProxy(). > > I also added a test for completeness. Here is the final webrev that I > intend to push ( listing 'Christian Schulte ' as the > contributor ). > > http://cr.openjdk.java.net/~chegar/7188755/webrev.00/webrev/ > > -Chris. The change looks good to me. The test is fine took although I assume if any of the threads through an exception then it will not cause the test to fail (but of course if they crash it will). -Alan From chris.hegarty at oracle.com Fri Aug 10 09:53:55 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Aug 2012 17:53:55 +0100 Subject: Crash due to missing synchronization on 'gconf_client' in 'jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c' In-Reply-To: <502536BA.9060108@oracle.com> References: <501A5C49.5020106@schulte.it> <501A9248.3090008@oracle.com> <501A9C76.2070007@oracle.com> <501B673F.9080702@schulte.it> <5025326C.6010009@oracle.com> <502536BA.9060108@oracle.com> Message-ID: <50253CA3.7010206@oracle.com> On 10/08/12 17:28, Alan Bateman wrote: > On 10/08/2012 17:10, Chris Hegarty wrote: >> Christian, >> >> I finally got back to this. >> >> Since init() is only ever called from the class initializer it is >> implicitly single threaded, so we only need to add the synchronized >> keyword to getSystemProxy(). >> >> I also added a test for completeness. Here is the final webrev that I >> intend to push ( listing 'Christian Schulte ' as the >> contributor ). >> >> http://cr.openjdk.java.net/~chegar/7188755/webrev.00/webrev/ >> >> -Chris. > The change looks good to me. The test is fine took although I assume if > any of the threads through an exception then it will not cause the test > to fail (but of course if they crash it will). Right, the issue is a crash in native code. I tried it with jtreg and it fails most of the time ( without the fix ). The test will not do anything else useful. It should be fine. -Chris. > > -Alan 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 cs at schulte.it Fri Aug 10 13:52:32 2012 From: cs at schulte.it (Christian Schulte) Date: Fri, 10 Aug 2012 22:52:32 +0200 Subject: Crash due to missing synchronization on 'gconf_client' in 'jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c' In-Reply-To: <5025326C.6010009@oracle.com> References: <501A5C49.5020106@schulte.it> <501A9248.3090008@oracle.com> <501A9C76.2070007@oracle.com> <501B673F.9080702@schulte.it> <5025326C.6010009@oracle.com> Message-ID: <50257490.8030201@schulte.it> Am 08/10/12 18:10, schrieb Chris Hegarty: > Christian, > > I finally got back to this. > > Since init() is only ever called from the class initializer it is > implicitly single threaded, so we only need to add the synchronized > keyword to getSystemProxy(). > > I also added a test for completeness. Here is the final webrev that I > intend to push ( listing 'Christian Schulte ' as the > contributor ). > > http://cr.openjdk.java.net/~chegar/7188755/webrev.00/webrev/ > > -Chris. > Thank you. Regards, -- Christian 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 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 chris.hegarty at oracle.com Sun Aug 12 15:04:06 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 12 Aug 2012 23:04:06 +0100 Subject: Crash due to missing synchronization on 'gconf_client' in 'jdk/src/solaris/native/sun/net/spi/DefaultProxySelector.c' In-Reply-To: <50257490.8030201@schulte.it> References: <501A5C49.5020106@schulte.it> <501A9248.3090008@oracle.com> <501A9C76.2070007@oracle.com> <501B673F.9080702@schulte.it> <5025326C.6010009@oracle.com> <50257490.8030201@schulte.it> Message-ID: <50282856.4090909@oracle.com> To close the loop on this one, here is a link to the jdk8 changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7d125f2575b I'll propose a backport to jdk7u-dev once this has bake for a little in 8 first. While the changes actually ended up being quite small, this issue has haunted us for a while now. It gets mentioned on many forums. Hopefully, this will be an end to it. Christian, thanks for debugging and resolve this issue for us. -Chris. On 10/08/12 21:52, Christian Schulte wrote: > Am 08/10/12 18:10, schrieb Chris Hegarty: >> Christian, >> >> I finally got back to this. >> >> Since init() is only ever called from the class initializer it is >> implicitly single threaded, so we only need to add the synchronized >> keyword to getSystemProxy(). >> >> I also added a test for completeness. Here is the final webrev that I >> intend to push ( listing 'Christian Schulte ' as the >> contributor ). >> >> http://cr.openjdk.java.net/~chegar/7188755/webrev.00/webrev/ >> >> -Chris. >> > > Thank you. > > > Regards, 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 shirishk at linux.vnet.ibm.com Mon Aug 13 05:36:12 2012 From: shirishk at linux.vnet.ibm.com (Shirish Kuncolienkar) Date: Mon, 13 Aug 2012 18:06:12 +0530 Subject: Problem with getFlags() method in NetworkInterface.c In-Reply-To: <50253257.4040700@oracle.com> References: <50238E1A.6090604@linux.vnet.ibm.com> <50239E47.8030805@oracle.com> <5023B822.1060404@linux.vnet.ibm.com> <5023C7B5.7040508@oracle.com> <5023CB6C.8040402@linux.vnet.ibm.com> <50253257.4040700@oracle.com> Message-ID: <5028F4BC.6070101@linux.vnet.ibm.com> Chris, Thank you. Could you please push the changes ? Thanks Shirish On 8/10/2012 9:39 PM, Chris Hegarty wrote: > Shirish, > > There were some minor issues with your patch ( it did not build on all > platforms ). I fixed these issues and also updated the Mac variant of > getFlags. It now compiles and runs on all platforms. > > The test has been dropped ( as I indicated in the previous mail ). > > http://cr.openjdk.java.net/~chegar/7190254/webrev.00/webrev/ > > If Neil ( or someone else from IBM ) is to push this, you can grab the > patch from the above webrev (and list me as a reviewer). Otherwise, I > can push it for you. > > -Chris. > > On 09/08/2012 15:38, Shirish Kuncolienkar wrote: >> Chris, >> >> Please go ahead and run the sanity builds and tests. >> >> Thanks >> -Shirish >> >> On 8/9/2012 7:52 PM, Chris Hegarty wrote: >>> >>> On 09/08/12 14:16, Shirish Kuncolienkar wrote: >>>> .... >>>> I agree there is no general documentation available, AIX defines vipa >>>> interface flag as "0x80000000" >>> >>> In which case I don't see any problems with your proposed source >>> changes. One could argue that maybe they should go through the >>> specific porting project ( since it's not directly relevant to >>> existing supported platforms ), but I see this more of a clean up >>> exercise. No need to carry such a trivial change in a project sub repo. >>> >>> Usually a new testcase is recommended, but in this case the >>> functionality ( isUp, isXXX() ) is already exercised by many many >>> tests so I think we can leave it to the other tests. >>> >>> I filed a new bug to track this issue, >>> CR 7190254: "NetworkInterface getFlags implementation should support >>> full integer bit range for flags value." >>> >>> If you don't mind, I would like to take your patch to >>> NetworkInterface.c and run some sanity builds and tests on it. I'd >>> hope to get this done later today or early tomorrow. >>> >>> -Chris. >>> >>>> Here is a similar bug report related to FreeBSD >>>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c6334146005c. >>>> >>>> A different fix was proposed here. >>>> >>>> Hope this helps. >>>> >>>> Thanks >>>> -Shirish >>>> >>> >> >> > 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 chris.hegarty at oracle.com Mon Aug 13 05:54:38 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 Aug 2012 13:54:38 +0100 Subject: Problem with getFlags() method in NetworkInterface.c In-Reply-To: <5028F4BC.6070101@linux.vnet.ibm.com> References: <50238E1A.6090604@linux.vnet.ibm.com> <50239E47.8030805@oracle.com> <5023B822.1060404@linux.vnet.ibm.com> <5023C7B5.7040508@oracle.com> <5023CB6C.8040402@linux.vnet.ibm.com> <50253257.4040700@oracle.com> <5028F4BC.6070101@linux.vnet.ibm.com> Message-ID: <5028F90E.1090700@oracle.com> On 13/08/2012 13:36, Shirish Kuncolienkar wrote: > Chris, > > Thank you. Could you please push the changes ? Done. http://hg.openjdk.java.net/jdk8/tl/jdk/rev/399c2adf3ad6 Thanks for the contribution Shirish. -Chris. > > Thanks > Shirish > > On 8/10/2012 9:39 PM, Chris Hegarty wrote: >> Shirish, >> >> There were some minor issues with your patch ( it did not build on all >> platforms ). I fixed these issues and also updated the Mac variant of >> getFlags. It now compiles and runs on all platforms. >> >> The test has been dropped ( as I indicated in the previous mail ). >> >> http://cr.openjdk.java.net/~chegar/7190254/webrev.00/webrev/ >> >> If Neil ( or someone else from IBM ) is to push this, you can grab the >> patch from the above webrev (and list me as a reviewer). Otherwise, I >> can push it for you. >> >> -Chris. >> >> On 09/08/2012 15:38, Shirish Kuncolienkar wrote: >>> Chris, >>> >>> Please go ahead and run the sanity builds and tests. >>> >>> Thanks >>> -Shirish >>> >>> On 8/9/2012 7:52 PM, Chris Hegarty wrote: >>>> >>>> On 09/08/12 14:16, Shirish Kuncolienkar wrote: >>>>> .... >>>>> I agree there is no general documentation available, AIX defines vipa >>>>> interface flag as "0x80000000" >>>> >>>> In which case I don't see any problems with your proposed source >>>> changes. One could argue that maybe they should go through the >>>> specific porting project ( since it's not directly relevant to >>>> existing supported platforms ), but I see this more of a clean up >>>> exercise. No need to carry such a trivial change in a project sub repo. >>>> >>>> Usually a new testcase is recommended, but in this case the >>>> functionality ( isUp, isXXX() ) is already exercised by many many >>>> tests so I think we can leave it to the other tests. >>>> >>>> I filed a new bug to track this issue, >>>> CR 7190254: "NetworkInterface getFlags implementation should support >>>> full integer bit range for flags value." >>>> >>>> If you don't mind, I would like to take your patch to >>>> NetworkInterface.c and run some sanity builds and tests on it. I'd >>>> hope to get this done later today or early tomorrow. >>>> >>>> -Chris. >>>> >>>>> Here is a similar bug report related to FreeBSD >>>>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c6334146005c. >>>>> >>>>> A different fix was proposed here. >>>>> >>>>> Hope this helps. >>>>> >>>>> Thanks >>>>> -Shirish >>>>> >>>> >>> >>> >> > > 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 shirishk at linux.vnet.ibm.com Mon Aug 13 08:11:21 2012 From: shirishk at linux.vnet.ibm.com (Shirish Kuncolienkar) Date: Mon, 13 Aug 2012 20:41:21 +0530 Subject: Problem with getFlags() method in NetworkInterface.c In-Reply-To: <5028F90E.1090700@oracle.com> References: <50238E1A.6090604@linux.vnet.ibm.com> <50239E47.8030805@oracle.com> <5023B822.1060404@linux.vnet.ibm.com> <5023C7B5.7040508@oracle.com> <5023CB6C.8040402@linux.vnet.ibm.com> <50253257.4040700@oracle.com> <5028F4BC.6070101@linux.vnet.ibm.com> <5028F90E.1090700@oracle.com> Message-ID: <50291919.7090703@linux.vnet.ibm.com> Thank you Chris -Shirish On 8/13/2012 6:24 PM, Chris Hegarty wrote: > On 13/08/2012 13:36, Shirish Kuncolienkar wrote: >> Chris, >> >> Thank you. Could you please push the changes ? > > Done. > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/399c2adf3ad6 > > Thanks for the contribution Shirish. > -Chris. > >> >> Thanks >> Shirish >> >> On 8/10/2012 9:39 PM, Chris Hegarty wrote: >>> Shirish, >>> >>> There were some minor issues with your patch ( it did not build on all >>> platforms ). I fixed these issues and also updated the Mac variant of >>> getFlags. It now compiles and runs on all platforms. >>> >>> The test has been dropped ( as I indicated in the previous mail ). >>> >>> http://cr.openjdk.java.net/~chegar/7190254/webrev.00/webrev/ >>> >>> If Neil ( or someone else from IBM ) is to push this, you can grab the >>> patch from the above webrev (and list me as a reviewer). Otherwise, I >>> can push it for you. >>> >>> -Chris. >>> >>> On 09/08/2012 15:38, Shirish Kuncolienkar wrote: >>>> Chris, >>>> >>>> Please go ahead and run the sanity builds and tests. >>>> >>>> Thanks >>>> -Shirish >>>> >>>> On 8/9/2012 7:52 PM, Chris Hegarty wrote: >>>>> >>>>> On 09/08/12 14:16, Shirish Kuncolienkar wrote: >>>>>> .... >>>>>> I agree there is no general documentation available, AIX defines >>>>>> vipa >>>>>> interface flag as "0x80000000" >>>>> >>>>> In which case I don't see any problems with your proposed source >>>>> changes. One could argue that maybe they should go through the >>>>> specific porting project ( since it's not directly relevant to >>>>> existing supported platforms ), but I see this more of a clean up >>>>> exercise. No need to carry such a trivial change in a project sub >>>>> repo. >>>>> >>>>> Usually a new testcase is recommended, but in this case the >>>>> functionality ( isUp, isXXX() ) is already exercised by many many >>>>> tests so I think we can leave it to the other tests. >>>>> >>>>> I filed a new bug to track this issue, >>>>> CR 7190254: "NetworkInterface getFlags implementation should support >>>>> full integer bit range for flags value." >>>>> >>>>> If you don't mind, I would like to take your patch to >>>>> NetworkInterface.c and run some sanity builds and tests on it. I'd >>>>> hope to get this done later today or early tomorrow. >>>>> >>>>> -Chris. >>>>> >>>>>> Here is a similar bug report related to FreeBSD >>>>>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c6334146005c. >>>>>> >>>>>> >>>>>> A different fix was proposed here. >>>>>> >>>>>> Hope this helps. >>>>>> >>>>>> Thanks >>>>>> -Shirish >>>>>> >>>>> >>>> >>>> >>> >> >> > From michael.x.mcmahon at oracle.com Mon Aug 13 09:24:33 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 Aug 2012 17:24:33 +0100 Subject: Http client API In-Reply-To: <5021A036.6020107@oracle.com> References: <5021A036.6020107@oracle.com> Message-ID: <50292A41.7040908@oracle.com> To everyone who has commented on the API so far, thank you! It is much appreciated. We will be getting back on all the issues raised in the coming days. I am just about to send out a request on jdk8-dev (which covers all JDK groups) to solicit feedback from as many people as possible. Thanks again, Michael. On 08/08/12 00:09, Michael McMahon wrote: > Hi, > > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ > > We would like to review the api on this mailing list. > So, all comments are welcome. > > Thanks > Michael McMahon. From michael.x.mcmahon at oracle.com Mon Aug 13 09:33:03 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 Aug 2012 17:33:03 +0100 Subject: Review of new Http client API Message-ID: <50292C3F.8030808@oracle.com> Hi, We have just published a draft of a proposed new Http client API [1] for JDK 8. This message has been bcc'd to jdk8-dev so that as many people as possible know about it, but the discussion will be on the net-dev list (net-dev at openjdk.java.net). So, folks will have to join that list [2], in order to take part. Thanks, Michael. [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev 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 dingxmin at linux.vnet.ibm.com Mon Aug 13 20:11:38 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Tue, 14 Aug 2012 11:11:38 +0800 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX In-Reply-To: <5020ABB8.7080507@linux.vnet.ibm.com> References: <5020ABB8.7080507@linux.vnet.ibm.com> Message-ID: <5029C1EA.4030406@linux.vnet.ibm.com> On 8/7/2012 1:46 PM, Frank Ding wrote: > Hi all, > In source code > "jdk\src\solaris\native\java\net\PlainDatagramSocketImpl.c", there are > several macros in the form of > > #ifdef AF_INET6 > #if defined(__solaris__) || defined(MACOSX) > // code for solaris and macosx (unix) [1] > #endif > #ifdef __linux__ > // code for linux > #endif > #else > // code for non AF_INET6 > #endif /* AF_INET6 */ > > The code blocks enclosed by the macro are method invocations of > mcast_set_if_by_addr_v6(), mcast_set_if_by_addr_v4(), > mcast_set_loop_v4(), mcast_set_loop_v6(), setHopLimit() and setTTL(). > > Other unix-like os, i.e. AIX, BSD and some other need exact calling > sequence coded in block [1]. So I made a patch that transformed the > above code into the following pattern > > #ifdef AF_INET6 > #ifdef __linux__ > // code for linux > #else /* __linux__ not defined */ > // code for UNIX > #endif /* __linux__ */ > #else > // non AF_INET6 > #endif /* AF_INET6 */ > > Could anybody take a look at my patch below and make comment? > http://cr.openjdk.java.net/~youdwei/ojdk-533/webrev.00/ > > Thanks & Best regards, > Frank Hi all, Is there anybody who is interested in the patch and who can take a look and comment? Thanks, Frank From michael.x.mcmahon at oracle.com Tue Aug 14 05:01:44 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 14 Aug 2012 13:01:44 +0100 Subject: Review of new Http client API Message-ID: <502A3E28.7080708@oracle.com> Hi, (apologies for sending this again) We have just published a draft of a proposed new Http client API [1] for JDK 8. This message has been cc'd to jdk8-dev so that as many people as possible know about it, but the discussion will be on the net-dev list (net-dev at openjdk.java.net). So, folks will have to join that list [2], in order to take part. Thanks, Michael. [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev From michael.x.mcmahon at oracle.com Tue Aug 14 05:49:14 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 14 Aug 2012 13:49:14 +0100 Subject: Http client API In-Reply-To: <50225733.5040207@oracle.com> References: <5021A036.6020107@oracle.com> <50225733.5040207@oracle.com> Message-ID: <502A494A.8010506@oracle.com> Xuelei, We have no particular requirement on HostnameVerifier. So, if I understood you correctly, HostnameVerifier is redundant in new APIs and it is possible to control hostname verification through the SSLParameters class (and an X509ExtendedTrustManager). So, we can drop HostnameVerifier from our API. Is that correct? Thanks Michael On 08/08/12 13:10, Xuelei Fan wrote: > From JDK 7, JSSE introduces a new hostname verifying approach. It is > call "endpoint identification" in JSSE context. It can be used to > replace the HostnameVerifier on SSLSession. A typical user case looks like: > > 1. implement a X509ExtendedTrustManager. It is required to check the > endpoint identification in the following methods: > checkClientTrusted(X509Certificate[], String, Socket) > checkClientTrusted(X509Certificate[], String, SSLEngine) > checkServerTrusted(X509Certificate[], String, Socket) > checkServerTrusted(X509Certificate[], String, SSLEngine) > > 2. initialize a SSLParameters to enable the endpoint identification: > sslParameter.setEndpointIdentificationAlgorithm("https"); > > 3. set the SSLParameters to SSLSocket or SSLEngine, the instance of > X509ExtendedTrustManager will check the endpoint (hostname) during > handshaking. > > Considering the java.net.httpclient.HttpsConfigurator, it is an > implementation of HostnameVerifier. So it would support both > HostnameVerifier and the above endpoint identification. I think as may > be redundant if no compatibility concerns. I was wondering maybe it is > OK to detach the HostnameVerifier interface and remove the verify() method. > > Maybe, you have other concerns that the HttpsConfigurator.verify() > method is really needed. > > Thanks, > Xuelei > > On 8/8/2012 7:09 AM, Michael McMahon wrote: >> Hi, >> >> A new revision of the Http client API planned for jdk 8 can be viewed >> at the following link >> >> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> We would like to review the api on this mailing list. >> So, all comments are welcome. >> >> Thanks >> Michael McMahon. From Alan.Bateman at oracle.com Tue Aug 14 05:11:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Aug 2012 13:11:32 +0100 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX In-Reply-To: <5029C1EA.4030406@linux.vnet.ibm.com> References: <5020ABB8.7080507@linux.vnet.ibm.com> <5029C1EA.4030406@linux.vnet.ibm.com> Message-ID: <502A4074.9070402@oracle.com> On 14/08/2012 04:11, Frank Ding wrote: > On 8/7/2012 1:46 PM, Frank Ding wrote: >> : >> >> Could anybody take a look at my patch below and make comment? >> http://cr.openjdk.java.net/~youdwei/ojdk-533/webrev.00/ >> >> Thanks & Best regards, >> Frank > > Hi all, > Is there anybody who is interested in the patch and who can take a > look and comment? It looks okay to me but I don't have time at the moment to sponsor it. Can you confirm that you've run the tests with this change? -Alan From michael.x.mcmahon at oracle.com Tue Aug 14 07:54:25 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 14 Aug 2012 15:54:25 +0100 Subject: cross protocol redirects ( was:Re: Http client API ) In-Reply-To: <5022CD80.6030601@oracle.com> References: <5021A036.6020107@oracle.com> <5022AEA3.9030403@gmail.com> <5022CD80.6030601@oracle.com> Message-ID: <502A66A1.3060108@oracle.com> On 08/08/12 21:35, Chris Hegarty wrote: > Great suggestion Anthony, > > This is something that comes up from time to time. With the clear > distinction between java.net.HttpURLConnection and > javax.net.ssl.HttpsURLConnection API's then it was a little difficult > to do in the existing API, but there is a clear opportunity with the > new API to avoid this issue in the future. > > Kurchi just informed me (off-list) that the current prototype > implementation in the java.net project [1], supports cross protocol > redirects. Though, this may be by accident! We need to do some further > investigating to determine if the security concerns related to 4620571 > are still valid. If so, and we cannot continue with automatic cross > protocol redirects, then an explicit API ( like you suggested ) should > be added. > Chris, That behavior isn't accidental. It's one reason why SSL configuration is a "property" of HttpClient rather than defined in a sub-class like HttpsClient. I agree the security concern needs to be understood (though I'm not sure I see a problem right now). The exact behavior of these classes isn't fully defined yet, in the context of a security manager. - Michael. From chris.hegarty at oracle.com Tue Aug 14 07:42:20 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Aug 2012 15:42:20 +0100 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX In-Reply-To: <502A4074.9070402@oracle.com> References: <5020ABB8.7080507@linux.vnet.ibm.com> <5029C1EA.4030406@linux.vnet.ibm.com> <502A4074.9070402@oracle.com> Message-ID: <502A63CC.4050305@oracle.com> On 14/08/12 13:11, Alan Bateman wrote: > On 14/08/2012 04:11, Frank Ding wrote: >> On 8/7/2012 1:46 PM, Frank Ding wrote: >>> : >>> >>> Could anybody take a look at my patch below and make comment? >>> http://cr.openjdk.java.net/~youdwei/ojdk-533/webrev.00/ >>> >>> Thanks & Best regards, >>> Frank >> >> Hi all, >> Is there anybody who is interested in the patch and who can take a >> look and comment? > It looks okay to me but I don't have time at the moment to sponsor it. > Can you confirm that you've run the tests with this change? I filed 7191275: "Cleanup OS specific blocks in PlainDatagramSocketImpl.c to support more unix-like platforms",for this issue. I can sponsor this patch and help get it in. Can answer Alan's question about testing? And confirm that it builds on all platforms? Thanks, -Chris. > > -Alan From Xuelei.Fan at Oracle.Com Tue Aug 14 08:38:54 2012 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 14 Aug 2012 23:38:54 +0800 Subject: Http client API In-Reply-To: <502A494A.8010506@oracle.com> References: <5021A036.6020107@oracle.com> <50225733.5040207@oracle.com> <502A494A.8010506@oracle.com> Message-ID: <8690F823-CE7B-4E54-88F8-6AD5246B38C0@Oracle.Com> On Aug 14, 2012, at 8:49 PM, Michael McMahon wrote: > Xuelei, > > We have no particular requirement on HostnameVerifier. So, > if I understood you correctly, HostnameVerifier is redundant in new APIs > and it is possible to control hostname verification through the SSLParameters class > (and an X509ExtendedTrustManager). > > So, we can drop HostnameVerifier from our API. Is that correct? > Yes. Xuelei > Thanks > Michael > > On 08/08/12 13:10, Xuelei Fan wrote: >> From JDK 7, JSSE introduces a new hostname verifying approach. It is >> call "endpoint identification" in JSSE context. It can be used to >> replace the HostnameVerifier on SSLSession. A typical user case looks like: >> >> 1. implement a X509ExtendedTrustManager. It is required to check the >> endpoint identification in the following methods: >> checkClientTrusted(X509Certificate[], String, Socket) >> checkClientTrusted(X509Certificate[], String, SSLEngine) >> checkServerTrusted(X509Certificate[], String, Socket) >> checkServerTrusted(X509Certificate[], String, SSLEngine) >> >> 2. initialize a SSLParameters to enable the endpoint identification: >> sslParameter.setEndpointIdentificationAlgorithm("https"); >> >> 3. set the SSLParameters to SSLSocket or SSLEngine, the instance of >> X509ExtendedTrustManager will check the endpoint (hostname) during >> handshaking. >> >> Considering the java.net.httpclient.HttpsConfigurator, it is an >> implementation of HostnameVerifier. So it would support both >> HostnameVerifier and the above endpoint identification. I think as may >> be redundant if no compatibility concerns. I was wondering maybe it is >> OK to detach the HostnameVerifier interface and remove the verify() method. >> >> Maybe, you have other concerns that the HttpsConfigurator.verify() >> method is really needed. >> >> Thanks, >> Xuelei >> >> On 8/8/2012 7:09 AM, Michael McMahon wrote: >>> Hi, >>> >>> A new revision of the Http client API planned for jdk 8 can be viewed >>> at the following link >>> >>> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >>> >>> We would like to review the api on this mailing list. >>> So, all comments are welcome. >>> >>> Thanks >>> Michael McMahon. > 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 michael.x.mcmahon at oracle.com Wed Aug 15 09:06:55 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 Aug 2012 17:06:55 +0100 Subject: Http client API In-Reply-To: <20BA6568-5487-4BF2-8578-5AAEB24D3CA0@oracle.com> References: <5021A036.6020107@oracle.com> <20BA6568-5487-4BF2-8578-5AAEB24D3CA0@oracle.com> Message-ID: <502BC91F.7050809@oracle.com> Mike. Thanks for the comments. I have commented on most of your points. There are a few I'm not sure about, and maybe others will chime in. - Michael. On 08/08/2012 23:33, Mike Duigou wrote: > General:: > - It's probably already been mentioned but having the classes in the httpclient package and most of them begin with "Http" seems redundant. I think I'd agree if type names were always written as fully qualified names, or if it were possible to import partial package names eg. import java.net.* and then refer to httpclient.Request or httpclient.Response but I don't think that is possible. Maybe we don't need a sub-package for httpclient but it is a convenient grouping from a readability point of view. What do other folks think? > - Package JavaDoc is missing for both packages. right we need to add that > - Is the SPI package needed for just one class? I suspect not. We probably should just bring it into the main package. > - I am unsure if sendRequest should be a method of Client or Request. > That question arose before and there seems to be two differing preferences. We probably should enumerate the arguments for and against the two. > HttpClientProvider:: > > - HttpClientProvider JavaDoc uses inconsistent capitalization of HTTP. > > - createAsynchronousHttpClient() Since there's only one create method why bother to mention that it's "Asynchronous"? > > - It's not clear how loadFromExternal() is different from provider(). > > - provider enumeration, request alternate providers? Yes, the provider needs work. I agree with the above. Though I don't know about the necessity to provide multiple alternate providers. > > > HttpClient:: > > - There's no way to identify the source of the HttpClient(). ie. it is returned by provider() but there's no way to tell what you got. Would be useful for debugging to log to the file what provider you received. I'm not sure I follow the comment above. Does it just relate to implementation rather than the API? > - HttpClient createClient() -- is this the same as HttpClientProvider.provider().createAsynchronousHttpClient()? yes, and that needs to be documented. > - There doesn't seem to be a way to be truly thread safe about changes to configuration other than to set all configuration options before sharing an HttpClient instance and then never changing the configuration. Is changing the configuration *after* sharing realistic or should perhaps configuration be immutable (perhaps using a Builder pattern for HttpClient instances, ie. createClient() becomes clientBuilder()). Seeing that the set methods return HttpClient (the same instance unfortunately) it looks like you are considering or have considered using a builder style construction. Right. I agree (as others have suggested) a builder pattern for mutable state is a good idea. The current behavior of returning the same client instance was more about simply a "fluent" programming style. > - Why expose the connection cache? Seems like just a good way to mess things up. Have you considered provider scope for connection cache? ie. all clients from the same provider share a cache? The idea behind connection cache was to allow applications more control over opening, closing and caching of TCP connections. But, it's possibly not 100% right yet. I figured that its scope would be at client level. If there were a higher level notion of an application in Java SE, then it probably would be associated at that level imo. In what way do you think it would be easy to mess things up? > - setProxy lacks proxy authentication features. (sorry, I just said that to annoy you. :-) ) Yes. Authentication is one missing piece of the puzzle. We want to implement authentication as a Filter, but it still needs a public API. But, it will be through that API where proxy authentication happens also. > - Does the proxy default to system properties and respect the nonProxyHosts? ie: > http.proxyHost (default:) > http.proxyPort (default: 80 if http.proxyHost specified) > http.nonProxyHosts (default:) Currently no. Since this is a new API, I'm not sure about the benefit of re-using the legacy properties. Perhaps there could be value in allowing system proxy settings to be used. > - Is the default cookie manager from CookieHandler.getDefault() or is there no default? Currently no default, which means no special treatment of cookie headers, which I think is reasonable > - Default is not specified for setAllowPipeLineMode() Presumably it is "false" right. we need to specify default is "false" > - There's no discussion of pipeline mode and connection cache. ok > - sendHeaders/sendRequest : presumably it is an error to use an HttpRequest from a different HttpClient. that was one reason why the sendXXX methods made sense on HttpRequest, because otherwise the possibility for sending a request on the wrong client has to be considered. So, we will have to specify that if we keep it as it is. > - setResponseBodyBufferLimit - like timeout this is a default. Perhaps setDefaultResponseBodyBufferLimit (long I know). > > - What happens with sendHeaders when the request already has a body? right. should have an @exception IllegalStateException > - Impact of closing the OutputStream returned from sendHeaders(). chunked mode vs. non-chucked. There could be an IOException if writing or closing the stream in-appropriately. This should be specified more explicitly in sendHeaders() > - getResponse : java.util.concurrent.TimeoutException has a nice name but is an odd exception to be throwing. java.net.SocketTimeoutException seems more appropriate. possibly, though the j.u.c.TimeoutException can be thrown when using a Future So, the idea was to use the same exception class for all timeouts. It's an awkward choice though. > - I'm curious why setUpgradeHandler() takes a class rather than an instance. maybe Danny can comment on that. > - getHttpsConfigurator() -- since a default is established before first invocation why not never return null. ie. implement the default behaviour in getHttpsConfigurator() and have the impl call getHttpsConfigurator(). good idea. It's always good to avoid nulls where possible. > - I missed the "s" in setHttpsConfigurator until I looked at the method in more detail. It doesn't really stand out. maybe setSSLConfigurator() and change HttpsConfigurator to SSLConfigurator? > - getFilters() -- this is the only modify-in-place API. Kinda weird. I think having setFilters() would be better. Do you mean getFilters() returns a copy and setFilters() would just set the actual list? Whatever works best with the builder model, I suppose is what we should do. > > > HttpUpgradeHandler:: > > - perhaps in the spi package? > > - Method or methods to identify the UpgradeHandler. ie. getName(), getProtocols. > > > > UpgradeConnection:: > > - Perhaps "Upgrade**d**Connection"? > > - There's no way to get back the UpdgradeHandler or source client. > > > > SimpleConnectionClass:: > > - Package private? It was supposed to be usable directly by application code. So, I don't think it could be package private. > > > HttpRequest:: > > - copy() vs clone()? > > - setFollowRedirects should get a default from HttpClient (or remove defaults for timeout and buffer limits). Asymmetry is annoying. will probably add a default for follow redirects > - setBody(Iterable, boolean isRestartable) -- This seems heinous. Non-restartable Iterables should be avoided. I like the suggestion of additional setBody(Iterable) method instead. Ok. So, a setBody(Iterator) then ? > - setRequestURI() -- eliminate this unless there is a really good reason to keep it. Alternately, perhaps copy(URI) instead? right. We need to clarify why that was put in there. > - getMethod() -- missing. ok > > > HttpHeaders:: > > - getValues() how about return empty result when there is no header of that name? Right. The docs are inconsistent on that point. Empty list is what it should be > - getValues() -- the returned list is unmodifiable, correct? Right. > - contains() -- IAE for null. ok > - getFirstValue() -- IAE for null name. It has to consistently be either IAE or NPE. ok > - getAllHeaderNames() -- unmodifiable list, correct? right > > > HttpResponse:: > > - getBodyAsBytes(byte[], int) - I would rather the return the number of bytes put into the buffer. yes. Actually the number of bytes read needs to be returned somewhere. It should return an int or long > - getBodyAsBytes(byte[], int) - Why would I ever want a max size less than the size of my byte buffer? I originally wanted to implement the no-arg getBodyAsBytes() using the other method. Maybe it's better to replace them both with: long getBodyAsBytes(byte[] buffer) - buffer can't be null, use entire buffer, return # bytes read byte[] getBodyAsBytes() - size limited by HttpClient.getResponseBodyBufferLimit() > - getBodyAsBytes -- Document handling for content-length> Integer.MAX_VALUE dealt with implicitly from above change and the response body buffer limit itself. > - getBodyAsByteBuffers -- handling for not enough space in the array needs to be documented. Unused entries nulled out? situation would only arise through ByteBuffer allocation failure, and presumably OOM exception would be thrown. Is it necessary to document this? > - Perhaps maxlength -> maxBytes to be more clear? > > - getBodyAsByteBufferSource -- if the same iterator is always returned why not return the iterator rather than an iterable? The idea was to allow for use of the foreach convenience. eg Iterable buffers = response.getBodyAsByteBufferSource(); for (ByteBuffer buffer : buffers) { // handle data in buffer } This raises the same concern then about the Iterable being non-restartable, which in this case it clearly can't be. This is a "one-shot" streaming API. I notice that the documentation for Iterable is rather terse and doesn't say whether this usage is encouraged or discouraged. So, I'm not sure now. The question is if programmers would really be confused by the fact that the Iterable can only be used to return one Iterator instance. > > > HttpConnectionCache.CachedConnection:: > - I would expect this to be abstract and that client providers would extend. > > - getCache() to return the client provider. > > > On Aug 7 2012, at 16:09 , Michael McMahon wrote: > >> Hi, >> >> A new revision of the Http client API planned for jdk 8 can be viewed >> at the following link >> >> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> We would like to review the api on this mailing list. >> So, all comments are welcome. >> >> Thanks >> Michael McMahon. From michael.x.mcmahon at oracle.com Wed Aug 15 09:20:39 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 Aug 2012 17:20:39 +0100 Subject: Use Builder pattern ( was: Re: Http client API) In-Reply-To: <502387EC.90505@oracle.com> References: <5021A036.6020107@oracle.com> <502387EC.90505@oracle.com> Message-ID: <502BCC57.4010906@oracle.com> On 09/08/12 10:50, Chris Hegarty wrote: > On 09/08/12 00:00, Jed Wesley-Smith wrote: >> Michael McMahon writes: >> >>> A new revision of the Http client API planned for jdk 8 can be viewed >>> at the following link >>> >>> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >>> >>> We would like to review the api on this mailing list. >>> So, all comments are welcome. >> >> Can you separate the domain objects (in particular HttpClient, >> HttpRequest) >> and their set-up (all the mutators) into separate concerns (Builders >> perhaps, >> see Guava for instance)? > > +1, I agree with your comment. > > Wherever possible we should try to use a builder pattern to build > immutable objects ( or limit its mutability as much as possible ). I > think Mike made a very similar comment too. Maybe the spi and > factory/builder could be separated out, I think this would be much > cleaner. > > As you say, you get thread-safety by default, which would appear to be > a nice property for this API, given its different programming models. > I agree. The various mutable set() type methods should be in builders and the resulting HttpClient and HttpRequests should be immutable. Will look into that now. Thanks, Michael. From kurchi.subhra.hazra at oracle.com Wed Aug 15 08:27:10 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Wed, 15 Aug 2012 08:27:10 -0700 Subject: Http client API In-Reply-To: <502BC91F.7050809@oracle.com> References: <5021A036.6020107@oracle.com> <20BA6568-5487-4BF2-8578-5AAEB24D3CA0@oracle.com> <502BC91F.7050809@oracle.com> Message-ID: <502BBFCE.1050308@oracle.com> >> - HttpClient createClient() -- is this the same as >> HttpClientProvider.provider().createAsynchronousHttpClient()? > yes, and that needs to be documented. Just on this one, the method name createAsynchronousHttpClient() looks like a remnant of our previous API iterations, and I think this should just be renamed to createHttpClient() or createClient(). - Kurchi From kurchi.subhra.hazra at oracle.com Wed Aug 15 08:32:46 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Wed, 15 Aug 2012 08:32:46 -0700 Subject: Http client API In-Reply-To: <502BC91F.7050809@oracle.com> References: <5021A036.6020107@oracle.com> <20BA6568-5487-4BF2-8578-5AAEB24D3CA0@oracle.com> <502BC91F.7050809@oracle.com> Message-ID: <502BC11E.8040503@oracle.com> Just as a reminder, for reading the response, we had originally decided to simply terminate whatever bytebuffer/byte arrays we have with a -1 to indicate EOF. But if returning the number of bytes read results in cleaner code, maybe we should do this. >> >> HttpResponse:: >> >> - getBodyAsBytes(byte[], int) - I would rather the return the number >> of bytes put into the buffer. > yes. Actually the number of bytes read needs to be returned somewhere. > It should return > an int or long >> - getBodyAsBytes(byte[], int) - Why would I ever want a max size less >> than the size of my byte buffer? > I originally wanted to implement the no-arg getBodyAsBytes() using the > other method. > Maybe it's better to replace them both with: > > long getBodyAsBytes(byte[] buffer) - buffer can't be null, use entire > buffer, return # bytes read > byte[] getBodyAsBytes() - size limited by > HttpClient.getResponseBodyBufferLimit() > >> - getBodyAsBytes -- Document handling for content-length> >> Integer.MAX_VALUE > dealt with implicitly from above change and the response body buffer > limit itself. >> - getBodyAsByteBuffers -- handling for not enough space in the array >> needs to be documented. Unused entries nulled out? > situation would only arise through ByteBuffer allocation failure, and > presumably OOM exception would be thrown. > Is it necessary to document this? >> - Perhaps maxlength -> maxBytes to be more clear? >> >> - getBodyAsByteBufferSource -- if the same iterator is always >> returned why not return the iterator rather than an iterable? > The idea was to allow for use of the foreach convenience. eg > > Iterable buffers = response.getBodyAsByteBufferSource(); > for (ByteBuffer buffer : buffers) { > // handle data in buffer > } > > > This raises the same concern then about the Iterable being > non-restartable, which in this case > it clearly can't be. This is a "one-shot" streaming API. I notice that > the documentation for > Iterable is rather terse and doesn't say whether > this usage is encouraged or discouraged. So, I'm not sure now. The > question is if programmers would > really be confused by the fact that the Iterable can only be used to > return one Iterator instance. >> >> >> HttpConnectionCache.CachedConnection:: >> - I would expect this to be abstract and that client providers would >> extend. >> >> - getCache() to return the client provider. >> >> >> On Aug 7 2012, at 16:09 , Michael McMahon wrote: >> >>> Hi, >>> >>> A new revision of the Http client API planned for jdk 8 can be viewed >>> at the following link >>> >>> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >>> >>> We would like to review the api on this mailing list. >>> So, all comments are welcome. >>> >>> Thanks >>> Michael McMahon. > > From michael.x.mcmahon at oracle.com Wed Aug 15 09:53:37 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 Aug 2012 17:53:37 +0100 Subject: Http client API In-Reply-To: <50230934.8020101@redhat.com> References: <5021A036.6020107@oracle.com> <50230934.8020101@redhat.com> Message-ID: <502BD411.5020600@oracle.com> On 09/08/12 01:49, David M. Lloyd wrote: > On 08/07/2012 06:09 PM, Michael McMahon wrote: >> Hi, >> >> A new revision of the Http client API planned for jdk 8 can be viewed >> at the following link >> >> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> We would like to review the api on this mailing list. >> So, all comments are welcome. > > Why not javax.net.httpclient? Having it be backportable to earlier > JDKs would definitely help adoption IMO. > David The API is dependent on the asynchronous NIO capability that first appeared in jdk7. So, that would limit how far back it could be ported. Technically, I don't see a problem with using a javax. package name but I'm not sure what precedent there is for doing core platform APIs under the javax namespace. What do others think? - Michael From mike.duigou at oracle.com Wed Aug 15 08:59:47 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 15 Aug 2012 08:59:47 -0700 Subject: Http client API In-Reply-To: <502BC91F.7050809@oracle.com> References: <5021A036.6020107@oracle.com> <20BA6568-5487-4BF2-8578-5AAEB24D3CA0@oracle.com> <502BC91F.7050809@oracle.com> Message-ID: On Aug 15 2012, at 09:06 , Michael McMahon wrote: >> HttpClientProvider:: >> >> - HttpClientProvider JavaDoc uses inconsistent capitalization of HTTP. >> >> - createAsynchronousHttpClient() Since there's only one create method why bother to mention that it's "Asynchronous"? >> >> - It's not clear how loadFromExternal() is different from provider(). >> >> - provider enumeration, request alternate providers? > Yes, the provider needs work. I agree with the above. Though I don't know about the > necessity to provide multiple alternate providers. If there is only ever going to be one provider then why include a provider interface. I suspect that HttpClient will have about as many implementations as there are JCE providers, ie. less than 10 but it is possible that someone may have more than one simultaneously and want to select a particular provider. >> >> >> HttpClient:: >> >> - There's no way to identify the source of the HttpClient(). ie. it is returned by provider() but there's no way to tell what you got. Would be useful for debugging to log to the file what provider you received. > I'm not sure I follow the comment above. Does it just relate to implementation rather than the API? Yes. Mostly for diagnostic purposes. Since the provider isn't associated with the JDK I need to be able to get version information about the provider to record to logs, use in bug reports, etc. >> - Why expose the connection cache? Seems like just a good way to mess things up. Have you considered provider scope for connection cache? ie. all clients from the same provider share a cache? > The idea behind connection cache was to allow applications more control over opening, closing and caching of TCP > connections. But, it's possibly not 100% right yet. I figured that its scope would be at client level. If there were a higher > level notion of an application in Java SE, then it probably would be associated at that level imo. > In what way do you think it would be easy to mess things up? Failure to return connections mostly. Resource leakage. >> - I missed the "s" in setHttpsConfigurator until I looked at the method in more detail. It doesn't really stand out. > maybe setSSLConfigurator() and change HttpsConfigurator to SSLConfigurator? It would certainly stand out more though TLS is hopeful used. >> - getFilters() -- this is the only modify-in-place API. Kinda weird. I think having setFilters() would be better. > Do you mean getFilters() returns a copy and setFilters() would just set the actual list? Yes. >> - setBody(Iterable, boolean isRestartable) -- This seems heinous. Non-restartable Iterables should be avoided. I like the suggestion of additional setBody(Iterable) method instead. > Ok. So, a setBody(Iterator) then ? Yes. >> - getBodyAsByteBuffers -- handling for not enough space in the array needs to be documented. Unused entries nulled out? > situation would only arise through ByteBuffer allocation failure, and presumably OOM exception would be thrown. > Is it necessary to document this? Probably not. OOM is an Error rather than an exception to it wouldn't be reasonable for developers to try to catch it. >> - Perhaps maxlength -> maxBytes to be more clear? >> >> - getBodyAsByteBufferSource -- if the same iterator is always returned why not return the iterator rather than an iterable? > The idea was to allow for use of the foreach convenience. eg > > Iterable buffers = response.getBodyAsByteBufferSource(); > for (ByteBuffer buffer : buffers) { > // handle data in buffer > } > > > This raises the same concern then about the Iterable being non-restartable, which in this case > it clearly can't be. This is a "one-shot" streaming API. I notice that the documentation for > Iterable is rather terse and doesn't say whether > this usage is encouraged or discouraged. So, I'm not sure now. One-shot Iterables are definitely discouraged Mike From Alan.Bateman at oracle.com Wed Aug 15 09:32:39 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Aug 2012 17:32:39 +0100 Subject: Http client API In-Reply-To: References: <5021A036.6020107@oracle.com> <20BA6568-5487-4BF2-8578-5AAEB24D3CA0@oracle.com> <502BC91F.7050809@oracle.com> Message-ID: <502BCF27.8040502@oracle.com> On 15/08/2012 16:59, Mike Duigou wrote: > On Aug 15 2012, at 09:06 , Michael McMahon wrote: > >>> : >> Yes, the provider needs work. I agree with the above. Though I don't know about the >> necessity to provide multiple alternate providers. > If there is only ever going to be one provider then why include a provider interface. I suspect that HttpClient will have about as many implementations as there are JCE providers, ie. less than 10 but it is possible that someone may have more than one simultaneously and want to select a particular provider. > I haven't studied this API in much detail yet but I assume that HttpClientProvider is just a factory for HttpClients and when you invoke HttpClient.createClient it just delegates to the system-wise provider to create the HttpClient. Once the javadoc is fleshed out more then I assume that it will document how the system-wise default provider is chosen. I assume it just uses ServiceLoader with a system property or some means to override. This approach would be consistent with how several other provider interfaces work in the JDK. The approach also doesn't preclude using multiple providers at the same time although if you want a specific HttpClient then I assume it means getting a reference to the provider and invoking its factory method directly. It's the same thing with the NIO provider interfaces although the number of provider implementations there will be a less than what I expect here. -Alan. From michael.x.mcmahon at oracle.com Wed Aug 15 10:48:36 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 Aug 2012 18:48:36 +0100 Subject: Http client API In-Reply-To: References: <5021A036.6020107@oracle.com> <20BA6568-5487-4BF2-8578-5AAEB24D3CA0@oracle.com> <502BC91F.7050809@oracle.com> Message-ID: <502BE0F4.3080204@oracle.com> On 15/08/12 16:59, Mike Duigou wrote: > On Aug 15 2012, at 09:06 , Michael McMahon wrote: > >>> HttpClientProvider:: >>> >>> - HttpClientProvider JavaDoc uses inconsistent capitalization of HTTP. >>> >>> - createAsynchronousHttpClient() Since there's only one create method why bother to mention that it's "Asynchronous"? >>> >>> - It's not clear how loadFromExternal() is different from provider(). >>> >>> - provider enumeration, request alternate providers? >> Yes, the provider needs work. I agree with the above. Though I don't know about the >> necessity to provide multiple alternate providers. > If there is only ever going to be one provider then why include a provider interface. I suspect that HttpClient will have about as many implementations as there are JCE providers, ie. less than 10 but it is possible that someone may have more than one simultaneously and want to select a particular provider. JCE is slightly different in that different providers potentially implement different algorithms. What I was thinking is that there would be a default provider, and if someone wants to use a different implementation then they just need some way to specify an alternate to the default. I think it is unlikely that there would be more than one alternate implementation. On the Iterable vs Iterator question, I take your point. Thanks, Michael >>> >>> HttpClient:: >>> >>> - There's no way to identify the source of the HttpClient(). ie. it is returned by provider() but there's no way to tell what you got. Would be useful for debugging to log to the file what provider you received. >> I'm not sure I follow the comment above. Does it just relate to implementation rather than the API? > Yes. Mostly for diagnostic purposes. Since the provider isn't associated with the JDK I need to be able to get version information about the provider to record to logs, use in bug reports, etc. > >>> - Why expose the connection cache? Seems like just a good way to mess things up. Have you considered provider scope for connection cache? ie. all clients from the same provider share a cache? >> The idea behind connection cache was to allow applications more control over opening, closing and caching of TCP >> connections. But, it's possibly not 100% right yet. I figured that its scope would be at client level. If there were a higher >> level notion of an application in Java SE, then it probably would be associated at that level imo. >> In what way do you think it would be easy to mess things up? > Failure to return connections mostly. Resource leakage. >>> - I missed the "s" in setHttpsConfigurator until I looked at the method in more detail. It doesn't really stand out. >> maybe setSSLConfigurator() and change HttpsConfigurator to SSLConfigurator? > It would certainly stand out more though TLS is hopeful used. > >>> - getFilters() -- this is the only modify-in-place API. Kinda weird. I think having setFilters() would be better. >> Do you mean getFilters() returns a copy and setFilters() would just set the actual list? > Yes. > >>> - setBody(Iterable, boolean isRestartable) -- This seems heinous. Non-restartable Iterables should be avoided. I like the suggestion of additional setBody(Iterable) method instead. >> Ok. So, a setBody(Iterator) then ? > Yes. >>> - getBodyAsByteBuffers -- handling for not enough space in the array needs to be documented. Unused entries nulled out? >> situation would only arise through ByteBuffer allocation failure, and presumably OOM exception would be thrown. >> Is it necessary to document this? > Probably not. OOM is an Error rather than an exception to it wouldn't be reasonable for developers to try to catch it. > >>> - Perhaps maxlength -> maxBytes to be more clear? >>> >>> - getBodyAsByteBufferSource -- if the same iterator is always returned why not return the iterator rather than an iterable? >> The idea was to allow for use of the foreach convenience. eg >> >> Iterable buffers = response.getBodyAsByteBufferSource(); >> for (ByteBuffer buffer : buffers) { >> // handle data in buffer >> } >> >> >> This raises the same concern then about the Iterable being non-restartable, which in this case >> it clearly can't be. This is a "one-shot" streaming API. I notice that the documentation for >> Iterable is rather terse and doesn't say whether >> this usage is encouraged or discouraged. So, I'm not sure now. > One-shot Iterables are definitely discouraged > > Mike 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 dingxmin at linux.vnet.ibm.com Thu Aug 16 02:21:06 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Thu, 16 Aug 2012 17:21:06 +0800 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX In-Reply-To: <502A63CC.4050305@oracle.com> References: <5020ABB8.7080507@linux.vnet.ibm.com> <5029C1EA.4030406@linux.vnet.ibm.com> <502A4074.9070402@oracle.com> <502A63CC.4050305@oracle.com> Message-ID: <502CBB82.8000109@linux.vnet.ibm.com> On 8/14/2012 10:42 PM, Chris Hegarty wrote: > On 14/08/12 13:11, Alan Bateman wrote: >> On 14/08/2012 04:11, Frank Ding wrote: >>> On 8/7/2012 1:46 PM, Frank Ding wrote: >>>> : >>>> >>>> Could anybody take a look at my patch below and make comment? >>>> http://cr.openjdk.java.net/~youdwei/ojdk-533/webrev.00/ >>>> >>>> Thanks & Best regards, >>>> Frank >>> >>> Hi all, >>> Is there anybody who is interested in the patch and who can take a >>> look and comment? >> It looks okay to me but I don't have time at the moment to sponsor it. >> Can you confirm that you've run the tests with this change? > > I filed 7191275: "Cleanup OS specific blocks in > PlainDatagramSocketImpl.c to support more unix-like platforms",for > this issue. > > I can sponsor this patch and help get it in. Can answer Alan's > question about testing? And confirm that it builds on all platforms? > > Thanks, > -Chris. > >> >> -Alan > Hi Chris and Alan, Thank you for taking time to help this issue. I have built using latest openjdk 8 repo on Windows 64 and Linux 32/64. Since it's a macro change in path "src/solaris", I only did jtreg tests for Linux 32 and 64 build. The jtreg tests I ran are restricted to package "java/net". Please let me know if you need me to do more tests or on more platforms (such as Solaris). Best regards, Frank 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 michael.x.mcmahon at oracle.com Thu Aug 16 05:16:18 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 16 Aug 2012 13:16:18 +0100 Subject: Http client API In-Reply-To: References: <5021A036.6020107@oracle.com> Message-ID: <502CE492.907@oracle.com> On 08/08/12 20:09, Ian Robertston wrote: > Instead of HttpRequest having > > void setBody(Iterable buffers, boolean isRestartable) > > what about having two methods: > > void setBody(Iterable buffers) // presumed restartable > void setBody(Iterator buffers) // clearly not restartable > > Not only does this avoid a potentially confusing boolean parameter, but it also > avoids forcing people to create "dishonest" Iterables, where they know the > iterator() method cannot be called more than once. > > - Ian > Ian, Thanks for the comment. I agree this is probably the way to do it. Having two separate methods gives scope to explain the difference clearly in the javadoc. - Michael. From Dmitry.Samersoff at oracle.com Thu Aug 16 04:25:41 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 16 Aug 2012 15:25:41 +0400 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX In-Reply-To: <502CBB82.8000109@linux.vnet.ibm.com> References: <5020ABB8.7080507@linux.vnet.ibm.com> <5029C1EA.4030406@linux.vnet.ibm.com> <502A4074.9070402@oracle.com> <502A63CC.4050305@oracle.com> <502CBB82.8000109@linux.vnet.ibm.com> Message-ID: <502CD8B5.9000303@oracle.com> Chris, Sorry for being later at the party. 1. Could you explain why you are calling both mcast_set_if_by_addr_v4 mcast_set_if_by_addr_v6 for Linux and only mcast_set_if_by_addr_v6 for other OS-es. 2. If it's really necessary did you consider of writing special variant of mcast_set_if_by_addr_v6 combined both functionality for linux to reduce number of JNI (FindClass) calls and macros inside code ? -Dmitry On 2012-08-16 13:21, Frank Ding wrote: > On 8/14/2012 10:42 PM, Chris Hegarty wrote: >> On 14/08/12 13:11, Alan Bateman wrote: >>> On 14/08/2012 04:11, Frank Ding wrote: >>>> On 8/7/2012 1:46 PM, Frank Ding wrote: >>>>> : >>>>> >>>>> Could anybody take a look at my patch below and make comment? >>>>> http://cr.openjdk.java.net/~youdwei/ojdk-533/webrev.00/ >>>>> >>>>> Thanks & Best regards, >>>>> Frank >>>> >>>> Hi all, >>>> Is there anybody who is interested in the patch and who can take a >>>> look and comment? >>> It looks okay to me but I don't have time at the moment to sponsor it. >>> Can you confirm that you've run the tests with this change? >> >> I filed 7191275: "Cleanup OS specific vinblocks in >> PlainDatagramSocketImpl.c to support more unix-like platforms",for >> this issue. >> >> I can sponsor this patch and help get it in. Can answer Alan's >> question about testing? And confirm that it builds on all platforms? >> >> Thanks, >> -Chris. >> >>> >>> -Alan >> > Hi Chris and Alan, > Thank you for taking time to help this issue. I have built using > latest openjdk 8 repo on Windows 64 and Linux 32/64. Since it's a macro > change in path "src/solaris", I only did jtreg tests for Linux 32 and 64 > build. The jtreg tests I ran are restricted to package "java/net". > Please let me know if you need me to do more tests or on more platforms > (such as Solaris). > > Best regards, > Frank > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From chris.hegarty at oracle.com Thu Aug 16 05:23:58 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 16 Aug 2012 13:23:58 +0100 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX In-Reply-To: <502CD8B5.9000303@oracle.com> References: <5020ABB8.7080507@linux.vnet.ibm.com> <5029C1EA.4030406@linux.vnet.ibm.com> <502A4074.9070402@oracle.com> <502A63CC.4050305@oracle.com> <502CBB82.8000109@linux.vnet.ibm.com> <502CD8B5.9000303@oracle.com> Message-ID: <502CE65E.50801@oracle.com> Dmitry, You already know this, but to be clear, Frank's changes are simply changing the definitions so that platforms like AIX will use the same implementation as Solaris, Mac, etc. There will be no behavior changes from this. You're just asking general questions, right? On 16/08/2012 12:25, Dmitry Samersoff wrote: > Chris, > > Sorry for being later at the party. > > 1. > > Could you explain why you are calling both > > mcast_set_if_by_addr_v4 > mcast_set_if_by_addr_v6 > > for Linux > > and only > > mcast_set_if_by_addr_v6 > > for other OS-es. There is a lot of history here and many bugs over the years. I'll try to summarize. It was found that the dual stack on Linux requires that both the IPv4 and IPv6 socket options (IP_MULTICAST_IF & IPV6_MULTICAST_IF) are required to set the outgoing interface for sending multicast packets. Similarly for other sockets options. This was introduced under CR 4742177 [1]. From 4742177: "So with regard to ipv4 and ipv6 socket option, Solaris behaves this way :- - ipv4 options can be set for ipv4 socket fd, and ipv6 options for ipv6 socket fd. Otherwise, an error will occur. - effective options are those belong to the same family of socket fd. Meanwhile, Linux behaves this way :- - both ipv4 options and ipv6 options can be set for a socket fd. - effective options are those belong to the same family of destination address." > 2. If it's really necessary > did you consider of writing special variant of mcast_set_if_by_addr_v6 > combined both functionality for linux to reduce number of JNI > (FindClass) calls and macros inside code ? Unfortunately, this behavior is necessary. I agree, the code is not all that pretty, and there is a lot that could be done to clean it up, but I would like to keep this issue confined to Franks's particular problem. -Chris. [1] http://bugs.sun.com/view_bug.do?bug_id=4742177 > > > -Dmitry > > > On 2012-08-16 13:21, Frank Ding wrote: >> On 8/14/2012 10:42 PM, Chris Hegarty wrote: >>> On 14/08/12 13:11, Alan Bateman wrote: >>>> On 14/08/2012 04:11, Frank Ding wrote: >>>>> On 8/7/2012 1:46 PM, Frank Ding wrote: >>>>>> : >>>>>> >>>>>> Could anybody take a look at my patch below and make comment? >>>>>> http://cr.openjdk.java.net/~youdwei/ojdk-533/webrev.00/ >>>>>> >>>>>> Thanks& Best regards, >>>>>> Frank >>>>> >>>>> Hi all, >>>>> Is there anybody who is interested in the patch and who can take a >>>>> look and comment? >>>> It looks okay to me but I don't have time at the moment to sponsor it. >>>> Can you confirm that you've run the tests with this change? >>> >>> I filed 7191275: "Cleanup OS specific vinblocks in >>> PlainDatagramSocketImpl.c to support more unix-like platforms",for >>> this issue. >>> >>> I can sponsor this patch and help get it in. Can answer Alan's >>> question about testing? And confirm that it builds on all platforms? >>> >>> Thanks, >>> -Chris. >>> >>>> >>>> -Alan >>> >> Hi Chris and Alan, >> Thank you for taking time to help this issue. I have built using >> latest openjdk 8 repo on Windows 64 and Linux 32/64. Since it's a macro >> change in path "src/solaris", I only did jtreg tests for Linux 32 and 64 >> build. The jtreg tests I ran are restricted to package "java/net". >> Please let me know if you need me to do more tests or on more platforms >> (such as Solaris). >> >> Best regards, >> Frank >> > > From Dmitry.Samersoff at oracle.com Thu Aug 16 05:49:09 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 16 Aug 2012 16:49:09 +0400 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX In-Reply-To: <502CE65E.50801@oracle.com> References: <5020ABB8.7080507@linux.vnet.ibm.com> <5029C1EA.4030406@linux.vnet.ibm.com> <502A4074.9070402@oracle.com> <502A63CC.4050305@oracle.com> <502CBB82.8000109@linux.vnet.ibm.com> <502CD8B5.9000303@oracle.com> <502CE65E.50801@oracle.com> Message-ID: <502CEC45.2070505@oracle.com> Chris, Yes, I'm asking more general question - it's why I address it to you but Frank. IMHO, logic cleanup would take almost the same time as just reformatting macros (in all cases testing is required) and create almost the same disturbance for people porting openjdk to other platforms. So (on my opinion) it's better to do it once. Also do we really supports linux 2.2 kernel in jdk8? I think not, and all related macros should be removed within a scope of any bug touching the file. -Dmitry On 2012-08-16 16:23, Chris Hegarty wrote: > You already know this, but to be clear, Frank's changes are simply > changing the definitions so that platforms like AIX will use the same > implementation as Solaris, Mac, etc. There will be no behavior changes > from this. You're just asking general questions, right? > > On 16/08/2012 12:25, Dmitry Samersoff wrote: >> Chris, >> >> Sorry for being later at the party. >> >> 1. >> >> Could you explain why you are calling both >> >> mcast_set_if_by_addr_v4 >> mcast_set_if_by_addr_v6 >> >> for Linux >> >> and only >> >> mcast_set_if_by_addr_v6 >> >> for other OS-es. > > There is a lot of history here and many bugs over the years. I'll try to > summarize. > > It was found that the dual stack on Linux requires that both the IPv4 > and IPv6 socket options (IP_MULTICAST_IF & IPV6_MULTICAST_IF) are > required to set the outgoing interface for sending multicast packets. > Similarly for other sockets options. > > This was introduced under CR 4742177 [1]. From 4742177: > "So with regard to ipv4 and ipv6 socket option, Solaris behaves this > way :- > - ipv4 options can be set for ipv4 socket fd, and ipv6 options for > ipv6 socket fd. Otherwise, an error will occur. > - effective options are those belong to the same family of socket > fd. > > Meanwhile, Linux behaves this way :- > - both ipv4 options and ipv6 options can be set for a socket fd. > - effective options are those belong to the same family of > destination address." > >> 2. If it's really necessary >> did you consider of writing special variant of mcast_set_if_by_addr_v6 >> combined both functionality for linux to reduce number of JNI >> (FindClass) calls and macros inside code ? > > Unfortunately, this behavior is necessary. I agree, the code is not all > that pretty, and there is a lot that could be done to clean it up, but I > would like to keep this issue confined to Franks's particular problem. > > -Chris. > > [1] http://bugs.sun.com/view_bug.do?bug_id=4742177 > >> >> >> -Dmitry >> >> >> On 2012-08-16 13:21, Frank Ding wrote: >>> On 8/14/2012 10:42 PM, Chris Hegarty wrote: >>>> On 14/08/12 13:11, Alan Bateman wrote: >>>>> On 14/08/2012 04:11, Frank Ding wrote: >>>>>> On 8/7/2012 1:46 PM, Frank Ding wrote: >>>>>>> : >>>>>>> >>>>>>> Could anybody take a look at my patch below and make comment? >>>>>>> http://cr.openjdk.java.net/~youdwei/ojdk-533/webrev.00/ >>>>>>> >>>>>>> Thanks& Best regards, >>>>>>> Frank >>>>>> >>>>>> Hi all, >>>>>> Is there anybody who is interested in the patch and who can take a >>>>>> look and comment? >>>>> It looks okay to me but I don't have time at the moment to sponsor it. >>>>> Can you confirm that you've run the tests with this change? >>>> >>>> I filed 7191275: "Cleanup OS specific vinblocks in >>>> PlainDatagramSocketImpl.c to support more unix-like platforms",for >>>> this issue. >>>> >>>> I can sponsor this patch and help get it in. Can answer Alan's >>>> question about testing? And confirm that it builds on all platforms? >>>> >>>> Thanks, >>>> -Chris. >>>> >>>>> >>>>> -Alan >>>> >>> Hi Chris and Alan, >>> Thank you for taking time to help this issue. I have built using >>> latest openjdk 8 repo on Windows 64 and Linux 32/64. Since it's a macro >>> change in path "src/solaris", I only did jtreg tests for Linux 32 and 64 >>> build. The jtreg tests I ran are restricted to package "java/net". >>> Please let me know if you need me to do more tests or on more platforms >>> (such as Solaris). >>> >>> Best regards, >>> Frank >>> >> >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... 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 chris.hegarty at oracle.com Fri Aug 17 01:14:21 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 Aug 2012 09:14:21 +0100 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX In-Reply-To: <502CBB82.8000109@linux.vnet.ibm.com> References: <5020ABB8.7080507@linux.vnet.ibm.com> <5029C1EA.4030406@linux.vnet.ibm.com> <502A4074.9070402@oracle.com> <502A63CC.4050305@oracle.com> <502CBB82.8000109@linux.vnet.ibm.com> Message-ID: <502DFD5D.2030204@oracle.com> On 16/08/12 10:21, Frank Ding wrote: > .... > Hi Chris and Alan, > Thank you for taking time to help this issue. I have built using > latest openjdk 8 repo on Windows 64 and Linux 32/64. Since it's a macro > change in path "src/solaris", I only did jtreg tests for Linux 32 and 64 > build. The jtreg tests I ran are restricted to package "java/net". > Please let me know if you need me to do more tests or on more platforms > (such as Solaris). I ran some builds and tests on all ( Solaris, Linux & Mac ) platforms. All looks good. You can list me as a reviewer. I can push this for you, or can have someone else from IBM do the push, just let me know. Thanks for the contribution, -Chris. > > Best regards, > Frank > 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 luchsh at linux.vnet.ibm.com Fri Aug 17 02:20:48 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 17 Aug 2012 17:20:48 +0800 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX In-Reply-To: <502DFD5D.2030204@oracle.com> References: <5020ABB8.7080507@linux.vnet.ibm.com> <5029C1EA.4030406@linux.vnet.ibm.com> <502A4074.9070402@oracle.com> <502A63CC.4050305@oracle.com> <502CBB82.8000109@linux.vnet.ibm.com> <502DFD5D.2030204@oracle.com> Message-ID: <502E0CF0.5080501@linux.vnet.ibm.com> On 08/17/2012 04:14 PM, Chris Hegarty wrote: > On 16/08/12 10:21, Frank Ding wrote: >> .... >> Hi Chris and Alan, >> Thank you for taking time to help this issue. I have built using >> latest openjdk 8 repo on Windows 64 and Linux 32/64. Since it's a macro >> change in path "src/solaris", I only did jtreg tests for Linux 32 and 64 >> build. The jtreg tests I ran are restricted to package "java/net". >> Please let me know if you need me to do more tests or on more platforms >> (such as Solaris). > > I ran some builds and tests on all ( Solaris, Linux & Mac ) platforms. > All looks good. > > You can list me as a reviewer. I can push this for you, or can have > someone else from IBM do the push, just let me know. > > Thanks for the contribution, > -Chris. > >> >> Best regards, >> Frank >> > Hello Chris, Thanks for review, I've pushed the change @ http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4993f8aa7f2e changeset: 5704:4993f8aa7f2e tag: tip user: dingxmin date: Fri Aug 17 17:10:56 2012 +0800 files: src/solaris/native/java/net/PlainDatagramSocketImpl.c description: 7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to support more unix-like platforms Reviewed-by: chegar And to Frank, pls verify the change set. Thanks Jonathan From dingxmin at linux.vnet.ibm.com Fri Aug 17 02:48:01 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Fri, 17 Aug 2012 17:48:01 +0800 Subject: Suggestion of combining some macros of processing solaris, macosx with other UNIX In-Reply-To: <502E0CF0.5080501@linux.vnet.ibm.com> References: <5020ABB8.7080507@linux.vnet.ibm.com> <5029C1EA.4030406@linux.vnet.ibm.com> <502A4074.9070402@oracle.com> <502A63CC.4050305@oracle.com> <502CBB82.8000109@linux.vnet.ibm.com> <502DFD5D.2030204@oracle.com> <502E0CF0.5080501@linux.vnet.ibm.com> Message-ID: <502E1351.2060306@linux.vnet.ibm.com> Hi Chris and Jonathan, Thank you all. The change set is OK. Best regards, Frank On 8/17/2012 5:20 PM, Jonathan Lu wrote: > On 08/17/2012 04:14 PM, Chris Hegarty wrote: >> On 16/08/12 10:21, Frank Ding wrote: >>> .... >>> Hi Chris and Alan, >>> Thank you for taking time to help this issue. I have built using >>> latest openjdk 8 repo on Windows 64 and Linux 32/64. Since it's a >>> macro >>> change in path "src/solaris", I only did jtreg tests for Linux 32 >>> and 64 >>> build. The jtreg tests I ran are restricted to package "java/net". >>> Please let me know if you need me to do more tests or on more platforms >>> (such as Solaris). >> >> I ran some builds and tests on all ( Solaris, Linux & Mac ) >> platforms. All looks good. >> >> You can list me as a reviewer. I can push this for you, or can have >> someone else from IBM do the push, just let me know. >> >> Thanks for the contribution, >> -Chris. >> >>> >>> Best regards, >>> Frank >>> >> > Hello Chris, > > Thanks for review, I've pushed the change @ > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4993f8aa7f2e > > changeset: 5704:4993f8aa7f2e > tag: tip > user: dingxmin > date: Fri Aug 17 17:10:56 2012 +0800 > files: src/solaris/native/java/net/PlainDatagramSocketImpl.c > description: > 7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to > support more unix-like platforms > Reviewed-by: chegar > > And to Frank, pls verify the change set. > > Thanks > Jonathan From michael.x.mcmahon at oracle.com Fri Aug 17 03:30:58 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 17 Aug 2012 11:30:58 +0100 Subject: Http client API In-Reply-To: <5023FE58.9030008@oracle.com> References: <5021A036.6020107@oracle.com> <5023FE58.9030008@oracle.com> Message-ID: <502E1D62.5010105@oracle.com> Chris, Thanks for the comments. Some responses below: On 09/08/12 19:15, Chris Hegarty wrote: > Michael, > > Looking good, some comments. > > 1) Why the use of CookieManager, rather than CookieHandler? I would > expect that CookieHandler would be a cleaner API > CookieHandler is a very low level API, which doesn't offer much functionality beyond managing the cookies yourself, which is what you would have to do, if there were no cookie capabilities in the http api. So, I don't know what we would gain from using it. While CookieManager isn't perfect (and we'd like to suggest a few improvements) it is a higher level API that does take care of cookie management with some common policies pre-defined. > 2) What is the impact on the sendHeader, setBody for HEAD requests? > Ah yes, HEAD needs special treatment - though not with respect to the methods above as HEAD is identical to GET except with respect to any returned response body. So, we need to clarify that HttpResponse.getContentLength() returns the value of the content-length header in the case of HEAD responses. Also, I think we should clarify how empty response bodies are treated. Something like:- - an InputStream that returns EOF on first read - empty byte[] or ByteBuffer[] with one element that is empty - HttpResponseHandler calls onBodyPart() once with last=true and an empty ByteBuffer - Iterator where hasNext() returns false on first call. > 3) I think HttpClient could be an interface and move the create method > to a builder/factory, and make it as immutable as possible ( this > came up a few times now ). > Right. Am looking into that now. > 4) The Filter API looks a little funny, in that filter instances are > added to the client, while the ByteBufferWrapper instances are > presumably created by the implementation after registering the > wrapper class with the filter instance. Probably best/cleaner > to use the same style. It could also be an interface. > ByteBufferWrapper implementations could be generally useful (eg content encoders/decoders) but each Filter will be associated with zero or one specific ByteBufferWrapper implementation. Though, perhaps Filter could return ByteBufferWrapper instances rather than the class ... What do you think the advantage of Filter being an interface is? In that case, implementers would have to implement both methods in all cases. I think there will be many cases where filters are interested in either the request or the response, but not both. > 5) ByteBufferWrapper seems a little cluttered with implementation detail > setSource() nor setWrapper()?? Maybe best to just provide an > interface. > That comment about setSource() is wrong and needs to be removed. I agree setWrapper() is implementation detail as it only needs to be called by the implementation. Maybe it could be package private... > 6) Upgrade handler, similar comment to 4. Why not just register an > instance. > Danny? > 7) Exposing the filter list seems a little wrong, given the getter/ > setter style. > We'll look at that again with the builder changes > 8) java.net.httpclient.HttpConnectionCache.CachedConnection should > probably be an interface. > Yes, we were thinking about doing that. > 9) How does the cache handle tunnels? endpoint address/proxy/etc > good point. That needs to be clarified. > 10) Missing fluent style return from HttpRequest.setRequestBodyLimit > ok > 11) Should sendHeaders be specified to allow a null return value. I'm > thinking about when setSendExpectContinue is set. > Do you mean if a 417 "expectation failed" is received? Yes, in that case it probably does make sense to return null. It's a slightly awkward special case, but would have to be documented. We're trying to handle the normal situation as transparently as possible. The idea is that a blocking application will just block until the 100 continue is received, before being allowed to send the body. An asynchronous application will just not be "called back" to get the body until the 100 is received. Thanks Michael > -Chris. > > > On 08/08/12 00:09, Michael McMahon wrote: >> Hi, >> >> A new revision of the Http client API planned for jdk 8 can be viewed >> at the following link >> >> http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> We would like to review the api on this mailing list. >> So, all comments are welcome. >> >> Thanks >> Michael McMahon. From frank.carver at googlemail.com Fri Aug 17 03:59:09 2012 From: frank.carver at googlemail.com (Frank Carver) Date: Fri, 17 Aug 2012 11:59:09 +0100 Subject: Http client API In-Reply-To: <502E1D62.5010105@oracle.com> References: <5021A036.6020107@oracle.com> <5023FE58.9030008@oracle.com> <502E1D62.5010105@oracle.com> Message-ID: On 17 August 2012 11:30, Michael McMahon wrote: >> 2) What is the impact on the sendHeader, setBody for HEAD requests? > Ah yes, HEAD needs special treatment - though not with respect to the methods above as HEAD is identical to GET except with respect to any returned response body. > > So, we need to clarify that HttpResponse.getContentLength() returns the value of the content-length header in the case of HEAD responses. That worries me. I would much prefer that HttpResponse.getContentLength() always returns the actual content length, which in the case of a HEAD would presumably be zero. This has the massive benefit that any code which reads and processes a response can be completely generic and re-usable, does not need to know anything about the request, and even relatively naive code will not break if given a bodiless response from a HEAD request. Code written specifically for a response from a HEAD is highly likely to just iterate through or cherry-pick the returned headers, including content-length, transfer-encoding and any other headers which have implications for how the body should be processed. My preference would be to leave the headers alone so the original data is available if anyone wants it, but make sure any special-case accessor methods always return directly usable values. Frank. From michael.x.mcmahon at oracle.com Fri Aug 17 04:38:05 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 17 Aug 2012 12:38:05 +0100 Subject: Http client API In-Reply-To: References: <5021A036.6020107@oracle.com> <5023FE58.9030008@oracle.com> <502E1D62.5010105@oracle.com> Message-ID: <502E2D1D.7020001@oracle.com> On 17/08/12 11:59, Frank Carver wrote: > On 17 August 2012 11:30, Michael McMahon wrote: >>> 2) What is the impact on the sendHeader, setBody for HEAD requests? >> Ah yes, HEAD needs special treatment - though not with respect to the methods above as HEAD is identical to GET except with respect to any returned response body. >> >> So, we need to clarify that HttpResponse.getContentLength() returns the value of the content-length header in the case of HEAD responses. > That worries me. > > I would much prefer that HttpResponse.getContentLength() always > returns the actual content length, which in the case of a HEAD would > presumably be zero. > > This has the massive benefit that any code which reads and processes a > response can be completely generic and re-usable, does not need to > know anything about the request, and even relatively naive code will > not break if given a bodiless response from a HEAD request. > > Code written specifically for a response from a HEAD is highly likely > to just iterate through or cherry-pick the returned headers, including > content-length, transfer-encoding and any other headers which have > implications for how the body should be processed. > > My preference would be to leave the headers alone so the original data > is available if anyone wants it, but make sure any special-case > accessor methods always return directly usable values. I take your point Frank. I agree, it's probably wrong to complicate the overwhelmingly common situation with this special case. Maybe we could just add some text to the HttpResponse.getContentLength() method. "Note. This method will always return zero in response to a HEAD request. The response headers must be queried directly to get the Content-length from a HEAD response." - Michael > Frank. 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 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 vasiliy.baranov at oracle.com Mon Aug 20 06:59:08 2012 From: vasiliy.baranov at oracle.com (Vasiliy Baranov) Date: Mon, 20 Aug 2012 17:59:08 +0400 Subject: Http client API In-Reply-To: <502E1D62.5010105@oracle.com> References: <5021A036.6020107@oracle.com> <5023FE58.9030008@oracle.com> <502E1D62.5010105@oracle.com> Message-ID: <503242AC.7020907@oracle.com> On 17.08.2012 14:30, Michael McMahon wrote: > On 09/08/12 19:15, Chris Hegarty wrote: >> Michael, >> >> Looking good, some comments. >> >> 1) Why the use of CookieManager, rather than CookieHandler? I would >> expect that CookieHandler would be a cleaner API >> > > CookieHandler is a very low level API, which doesn't offer much > functionality > beyond managing the cookies yourself, which is what you would have to > do, if there > were no cookie capabilities in the http api. So, I don't know what we > would gain from using it. > > While CookieManager isn't perfect (and we'd like to suggest a few > improvements) > it is a higher level API that does take care of cookie management with > some common > policies pre-defined. java.net.CookieHandler is an abstract class, almost an interface, that represents everything an HTTP client needs to manage cookies. java.net.CookieManager is a concrete implementation of java.net.CookieHandler. At least that is the case in the current java.net.* design. That said, shouldn't new HttpClient depend on the more abstract java.net.CookieHandler, rather than the more concrete java.net.CookieManager, for the sake of API cleanness and extensibility? If one prefers java.net.CookieManager over java.net.CookieHandler, it is possible to use the former everywhere where the latter is expected, but not the other way around. As a side note, in the plugin environment, it might be more natural and less invasive to interface the browser cookie store via java.net.CookieHandler rather than java.net.CookieManager. FWIW, the current plug-in implementation, com.sun.deploy.net.cookie.DeployCookieSelector, does extend java.net.CookieHandler. Just my two cents. Thank you, -- Vasiliy From shirishk at linux.vnet.ibm.com Mon Aug 20 08:04:52 2012 From: shirishk at linux.vnet.ibm.com (Shirish Kuncolienkar) Date: Mon, 20 Aug 2012 20:34:52 +0530 Subject: Parsing of URL's which contain Windows Path separator In-Reply-To: <50237A80.7020002@linux.vnet.ibm.com> References: <50237A80.7020002@linux.vnet.ibm.com> Message-ID: <50325214.9000307@linux.vnet.ibm.com> Any thoughts on the following It will be good if the one could create relative url from other url which is based on windows style path. example "hello.html" relative "http://someserver/foo/bar" becomes "http://someserver/foo/hello.html" In the similar way "hello.html"relative to "file:///C:\foo\bar" can be resolved to "file:///C:/foo/hello.html" currently the URL parser resolves it to "file:////hello.html" (this behavior is correct going by the api spec, since windows file separator character is considered as a special character) 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 chris.hegarty at oracle.com Mon Aug 20 14:35:32 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Aug 2012 22:35:32 +0100 Subject: Parsing of URL's which contain Windows Path separator In-Reply-To: <50325214.9000307@linux.vnet.ibm.com> References: <50237A80.7020002@linux.vnet.ibm.com> <50325214.9000307@linux.vnet.ibm.com> Message-ID: <5032ADA4.1080006@oracle.com> Shirish, Oooh, I'm not sure that any change to URL of this kind would be compatible. It may have been desirable to have this kind of behavior when URL was being originally created, but it is a legacy class, now replaced with URI, and I'm not sure a change like this could be done in a way to preserve compatibility with existing code. -Chris On 20/08/12 16:04, Shirish Kuncolienkar wrote: > Any thoughts on the following > > It will be good if the one could create relative url from other url > which is based on windows style path. > example "hello.html" relative "http://someserver/foo/bar" becomes > "http://someserver/foo/hello.html" > > In the similar way "hello.html"relative to "file:///C:\foo\bar" can be > resolved to "file:///C:/foo/hello.html" > currently the URL parser resolves it to "file:////hello.html" (this > behavior is correct going by the api spec, since windows file separator > character is considered as a special character) > From Alan.Bateman at oracle.com Tue Aug 21 01:46:03 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Aug 2012 09:46:03 +0100 Subject: Parsing of URL's which contain Windows Path separator In-Reply-To: <5032ADA4.1080006@oracle.com> References: <50237A80.7020002@linux.vnet.ibm.com> <50325214.9000307@linux.vnet.ibm.com> <5032ADA4.1080006@oracle.com> Message-ID: <50334ACB.2060506@oracle.com> On 20/08/2012 22:35, Chris Hegarty wrote: > Shirish, > > Oooh, I'm not sure that any change to URL of this kind would be > compatible. It may have been desirable to have this kind of behavior > when URL was being originally created, but it is a legacy class, now > replaced with URI, and I'm not sure a change like this could be done > in a way to preserve compatibility with existing code. > > -Chris The other thing you can't reliably using a file path as a URL path component anyway so I don't think the example makes sense anyway. -Alan. 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 michael.x.mcmahon at oracle.com Tue Aug 21 06:57:23 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 21 Aug 2012 14:57:23 +0100 Subject: Review of new Http client API In-Reply-To: References: Message-ID: <503393C3.7010707@oracle.com> Sam, Thanks for the comments. Some discussion below. On 17/08/12 00:13, Sam Pullara wrote: > I suggest that you make it a more fluent API rather than having > multiple callback methods in your callback interface. As it stands it > isn't compatible with lambdas. You might take some inspiration for the > asynchronous callbacks from my work porting Twitter's Future/Promise > to JDK8: I agree with the above. In a previous version of the API the main callback was lambda compatible. Originally we used HttpResponse to encapsulate everything related to a response including errors. But, some preferred to keep HttpResponse aligned to an actual response from a server in all cases. There might be other ways to get around that by combining HttpResponseHeadersHandler.{onError(), onHeaders()} back into a single method. Maybe, drop the onError() method and add the exception/throwable as a parameter to onHeaders() But, we also wanted to provide notification of body data (through the sub-interface HttpResponseHandler). Keeping the two interfaces distinct meant that applications could get asynchronous notification of the response headers, but then possibly read the response body in a blocking manner. Or alternatively, applications can use the handler to be notified of both headers and body. So, if we revert HttpResponseHeadersHandler back to having a single method, the sub-interface now would have two methods (instead of three). One way around that could be to have two unrelated interfaces: interface HttpResponseHeadersHandler { public void onHeaders(HttpResponse response, Exception e); } interface HttpResponseBodyHandler { public void onBodyPart(HttpResponse resp, ByteBuffer buffer, boolean last); } // Then a HttpResponseBodyHandler would be added to HttpClient.sendRequest() as below: public void sendRequest(HttpRequest, HttpResponseHeadersHandler, HttpResponseBodyHandler); Both of the interfaces would be lambda compatible (again) though at the cost of having to specify two separate handlers. So, the following might be how it could be used (and using a builder for HttpClient) HttpClient client = HttpClient.createBuilder() .setAsynchronousChannelGroup (..) .setCookieManager(..) .setDefaultTimeout(..) .setProxy(...) .addFilter(...) .buildClient(); HttpRequest request = client.createRequest(new URI("http://www.foo.com/")) .setBody("Hello world".getBytes()) .setMethod(HttpMethod.POST); client.sendRequest ( request, // handle headers (HttpResponse response, Exception e) -> { if (response.getResponseCode() != 200) { // handle error response } // handle normal case }, // handle body (HttpResponse response, ByteBuffer buf, boolean last) -> { // handle data in buf } ); It seems fairly readable still, I think. Another thing that this usage points to, is the usefulness of being able to hang some user context off of the HttpResponse or HttpRequest objects. That would be the only way to share some user state between the two handlers above, in this Lambda style. > https://github.com/spullara/java-future-jdk8 > > Another consideration might be to make sure that it is compatible with > an implementation that is using SPDY under the covers for connectivity > as I suspect that HTTP as a wire protocol has peaked though the HTTP > semantics will survive. Right. This is important. One area where there will be changes is with pipe-lining. We need to ensure that our pipe-lining API is not restricted to only Http 1.1 pipe-lining Are you aware of other areas that could have an impact on the API? Thanks Michael. > Sam > > On Tue, Aug 14, 2012 at 5:01 AM, Michael McMahon > wrote: >> Hi, >> >> (apologies for sending this again) >> We have just published a draft of a proposed new Http client API [1] for JDK >> 8. >> >> This message has been cc'd to jdk8-dev so that as many people as possible >> know about it, but the discussion will be on the net-dev list >> (net-dev at openjdk.java.net). >> So, folks will have to join that list [2], in order to take part. >> >> Thanks, >> Michael. >> >> [1]http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> [2]http://mail.openjdk.java.net/mailman/listinfo/net-dev 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 tjg at tgustafson.com Tue Aug 21 20:07:51 2012 From: tjg at tgustafson.com (Tim Gustafson) Date: Tue, 21 Aug 2012 20:07:51 -0700 Subject: OpenJDK 7 SNI Implementation Message-ID: Hi, I'm not sure if this is the right list to post this to or not, so please forgive me if it is not. If this is not the correct list, would someone please direct me to the correct place? I'm creating a Java application that implements a custom SSL server. By "custom", I mean "implements its own KeyManager and TrustManager". Specifically, I am storing certificate and key information in a password-protected Derby database so that my certificate information can be stored in the same encrypted database as all my other application data, and also because I'm doing certificate validation a bit differently than the stock Java key store does. 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. 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. 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? If so, where does that host name information show up in the chooseServerAlias function? Thanks for any help in advance! -- Tim Gustafson tjg at tgustafson.com http://tgustafson.com/ From chris.hegarty at oracle.com Wed Aug 22 07:29:57 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 Aug 2012 15:29:57 +0100 Subject: Review of new Http client API In-Reply-To: <503393C3.7010707@oracle.com> References: <503393C3.7010707@oracle.com> Message-ID: <5034ECE5.2020506@oracle.com> Michael what you have looks good. But, I think what Sam is suggesting ( or maybe not, but I like it ;-) ), is something like this. (I'd need to think more about what effect this has on the different modes, async/blocking ) class HttpResponse { HttpResponse onHeaders(Block); HttpResponse onError(BiBlock); HttpResponse onBodyPart(BiBlock); } response.onHeaders(r -> headers(r)) .onError((r,t) -> error(t)) .onBodyPart((r,bb) -> body(r, bb)); Alternatively, I believe something like this would also be compatible with lambda (since there is a default implementation for on Error): interface HTTPResponseHandler { public void onHeaders(HttpResponse resp); public void onError(HttpRequest request, Throwable exception) default { throw exception; } } -Chris. On 21/08/2012 14:57, Michael McMahon wrote: > Sam, > > Thanks for the comments. Some discussion below. > > > On 17/08/12 00:13, Sam Pullara wrote: >> I suggest that you make it a more fluent API rather than having >> multiple callback methods in your callback interface. As it stands it >> isn't compatible with lambdas. You might take some inspiration for the >> asynchronous callbacks from my work porting Twitter's Future/Promise >> to JDK8: > > I agree with the above. In a previous version of the API the main > callback was lambda compatible. > Originally we used HttpResponse to encapsulate everything related to a > response > including errors. But, some preferred to keep HttpResponse aligned to an > actual response > from a server in all cases. There might be other ways to get around that > by combining > HttpResponseHeadersHandler.{onError(), onHeaders()} back into a single > method. > Maybe, drop the onError() method and add the exception/throwable as a > parameter to onHeaders() > > But, we also wanted to provide notification of body data (through the > sub-interface HttpResponseHandler). > Keeping the two interfaces distinct meant that applications could get > asynchronous notification of > the response headers, but then possibly read the response body in a > blocking manner. > Or alternatively, applications can use the handler to be notified of > both headers and body. > > So, if we revert HttpResponseHeadersHandler back to having a single > method, the sub-interface > now would have two methods (instead of three). > > One way around that could be to have two unrelated interfaces: > > interface HttpResponseHeadersHandler { > public void onHeaders(HttpResponse response, Exception e); > } > > interface HttpResponseBodyHandler { > public void onBodyPart(HttpResponse resp, ByteBuffer buffer, boolean last); > } > > // Then a HttpResponseBodyHandler would be added to > HttpClient.sendRequest() as below: > > public void sendRequest(HttpRequest, HttpResponseHeadersHandler, > HttpResponseBodyHandler); > > > Both of the interfaces would be lambda compatible (again) though at the > cost > of having to specify two separate handlers. So, the following might be how > it could be used (and using a builder for HttpClient) > > HttpClient client = HttpClient.createBuilder() > .setAsynchronousChannelGroup (..) > .setCookieManager(..) > .setDefaultTimeout(..) > .setProxy(...) > .addFilter(...) > .buildClient(); > > HttpRequest request = client.createRequest(new URI("http://www.foo.com/")) > .setBody("Hello world".getBytes()) > .setMethod(HttpMethod.POST); > > client.sendRequest ( > request, > > // handle headers > (HttpResponse response, Exception e) -> { > if (response.getResponseCode() != 200) { > // handle error response > } > // handle normal case > }, > > // handle body > (HttpResponse response, ByteBuffer buf, boolean last) -> { > // handle data in buf > } > ); > > It seems fairly readable still, I think. > > Another thing that this usage points to, is the usefulness of being able > to hang some user context > off of the HttpResponse or HttpRequest objects. That would be the only > way to share some user state > between the two handlers above, in this Lambda style. >> https://github.com/spullara/java-future-jdk8 >> >> Another consideration might be to make sure that it is compatible with >> an implementation that is using SPDY under the covers for connectivity >> as I suspect that HTTP as a wire protocol has peaked though the HTTP >> semantics will survive. > Right. This is important. One area where there will be changes is with > pipe-lining. > We need to ensure that our pipe-lining API is not restricted to only > Http 1.1 pipe-lining > Are you aware of other areas that could have an impact on the API? > > Thanks > Michael. > >> Sam >> >> On Tue, Aug 14, 2012 at 5:01 AM, Michael McMahon >> wrote: >>> Hi, >>> >>> (apologies for sending this again) >>> We have just published a draft of a proposed new Http client API [1] >>> for JDK >>> 8. >>> >>> This message has been cc'd to jdk8-dev so that as many people as >>> possible >>> know about it, but the discussion will be on the net-dev list >>> (net-dev at openjdk.java.net). >>> So, folks will have to join that list [2], in order to take part. >>> >>> Thanks, >>> Michael. >>> >>> [1]http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >>> >>> [2]http://mail.openjdk.java.net/mailman/listinfo/net-dev > > From michael.x.mcmahon at oracle.com Wed Aug 22 13:05:01 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 22 Aug 2012 21:05:01 +0100 Subject: Review of new Http client API In-Reply-To: <5034ECE5.2020506@oracle.com> References: <503393C3.7010707@oracle.com> <5034ECE5.2020506@oracle.com> Message-ID: <50353B6D.1030102@oracle.com> On 22/08/12 15:29, Chris Hegarty wrote: > Michael what you have looks good. > > But, I think what Sam is suggesting ( or maybe not, but I like it ;-) > ), is something like this. (I'd need to think more about what effect > this has on the different modes, async/blocking ) > > class HttpResponse { > HttpResponse onHeaders(Block); > HttpResponse onError(BiBlock); > HttpResponse onBodyPart(BiBlock); > } > Right. I see what you mean in terms of making the setting of the callbacks fluent. I assume that Block and BiBlock are types associated with Lambda somehow, but otherwise this is unfamiliar territory to me .... > response.onHeaders(r -> headers(r)) > .onError((r,t) -> error(t)) > .onBodyPart((r,bb) -> body(r, bb)); > So, headers() and body() would be methods on HttpResponse ... Right ? What is error()? - Michael. > Alternatively, I believe something like this would also be compatible > with lambda (since there is a default implementation for on Error): > > interface HTTPResponseHandler { > public void onHeaders(HttpResponse resp); > > public void onError(HttpRequest request, Throwable exception) > default { throw exception; } > } > > -Chris. > > > On 21/08/2012 14:57, Michael McMahon wrote: >> Sam, >> >> Thanks for the comments. Some discussion below. >> >> >> On 17/08/12 00:13, Sam Pullara wrote: >>> I suggest that you make it a more fluent API rather than having >>> multiple callback methods in your callback interface. As it stands it >>> isn't compatible with lambdas. You might take some inspiration for the >>> asynchronous callbacks from my work porting Twitter's Future/Promise >>> to JDK8: >> >> I agree with the above. In a previous version of the API the main >> callback was lambda compatible. >> Originally we used HttpResponse to encapsulate everything related to a >> response >> including errors. But, some preferred to keep HttpResponse aligned to an >> actual response >> from a server in all cases. There might be other ways to get around that >> by combining >> HttpResponseHeadersHandler.{onError(), onHeaders()} back into a single >> method. >> Maybe, drop the onError() method and add the exception/throwable as a >> parameter to onHeaders() >> >> But, we also wanted to provide notification of body data (through the >> sub-interface HttpResponseHandler). >> Keeping the two interfaces distinct meant that applications could get >> asynchronous notification of >> the response headers, but then possibly read the response body in a >> blocking manner. >> Or alternatively, applications can use the handler to be notified of >> both headers and body. >> >> So, if we revert HttpResponseHeadersHandler back to having a single >> method, the sub-interface >> now would have two methods (instead of three). >> >> One way around that could be to have two unrelated interfaces: >> >> interface HttpResponseHeadersHandler { >> public void onHeaders(HttpResponse response, Exception e); >> } >> >> interface HttpResponseBodyHandler { >> public void onBodyPart(HttpResponse resp, ByteBuffer buffer, boolean >> last); >> } >> >> // Then a HttpResponseBodyHandler would be added to >> HttpClient.sendRequest() as below: >> >> public void sendRequest(HttpRequest, HttpResponseHeadersHandler, >> HttpResponseBodyHandler); >> >> >> Both of the interfaces would be lambda compatible (again) though at the >> cost >> of having to specify two separate handlers. So, the following might >> be how >> it could be used (and using a builder for HttpClient) >> >> HttpClient client = HttpClient.createBuilder() >> .setAsynchronousChannelGroup (..) >> .setCookieManager(..) >> .setDefaultTimeout(..) >> .setProxy(...) >> .addFilter(...) >> .buildClient(); >> >> HttpRequest request = client.createRequest(new >> URI("http://www.foo.com/")) >> .setBody("Hello world".getBytes()) >> .setMethod(HttpMethod.POST); >> >> client.sendRequest ( >> request, >> >> // handle headers >> (HttpResponse response, Exception e) -> { >> if (response.getResponseCode() != 200) { >> // handle error response >> } >> // handle normal case >> }, >> >> // handle body >> (HttpResponse response, ByteBuffer buf, boolean last) -> { >> // handle data in buf >> } >> ); >> >> It seems fairly readable still, I think. >> >> Another thing that this usage points to, is the usefulness of being able >> to hang some user context >> off of the HttpResponse or HttpRequest objects. That would be the only >> way to share some user state >> between the two handlers above, in this Lambda style. >>> https://github.com/spullara/java-future-jdk8 >>> >>> Another consideration might be to make sure that it is compatible with >>> an implementation that is using SPDY under the covers for connectivity >>> as I suspect that HTTP as a wire protocol has peaked though the HTTP >>> semantics will survive. >> Right. This is important. One area where there will be changes is with >> pipe-lining. >> We need to ensure that our pipe-lining API is not restricted to only >> Http 1.1 pipe-lining >> Are you aware of other areas that could have an impact on the API? >> >> Thanks >> Michael. >> >>> Sam >>> >>> On Tue, Aug 14, 2012 at 5:01 AM, Michael McMahon >>> wrote: >>>> Hi, >>>> >>>> (apologies for sending this again) >>>> We have just published a draft of a proposed new Http client API [1] >>>> for JDK >>>> 8. >>>> >>>> This message has been cc'd to jdk8-dev so that as many people as >>>> possible >>>> know about it, but the discussion will be on the net-dev list >>>> (net-dev at openjdk.java.net). >>>> So, folks will have to join that list [2], in order to take part. >>>> >>>> Thanks, >>>> Michael. >>>> >>>> [1]http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >>>> >>>> [2]http://mail.openjdk.java.net/mailman/listinfo/net-dev >> >> From chris.hegarty at oracle.com Wed Aug 22 13:17:13 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 Aug 2012 21:17:13 +0100 Subject: Review of new Http client API In-Reply-To: <50353B6D.1030102@oracle.com> References: <503393C3.7010707@oracle.com> <5034ECE5.2020506@oracle.com> <50353B6D.1030102@oracle.com> Message-ID: <50353E49.1040902@oracle.com> On 22/08/12 21:05, Michael McMahon wrote: > On 22/08/12 15:29, Chris Hegarty wrote: >> Michael what you have looks good. >> >> But, I think what Sam is suggesting ( or maybe not, but I like it ;-) >> ), is something like this. (I'd need to think more about what effect >> this has on the different modes, async/blocking ) >> >> class HttpResponse { >> HttpResponse onHeaders(Block); >> HttpResponse onError(BiBlock); >> HttpResponse onBodyPart(BiBlock); >> } >> > Right. I see what you mean in terms of making the setting of the callbacks > fluent. I assume that Block and BiBlock are types associated with Lambda Right, these are types defined in the lambda repo, that will most likely be part of JDK8. Worth a look, and we should also confirm with the lambda folks before build them into this API. > somehow, > but otherwise this is unfamiliar territory to me .... >> response.onHeaders(r -> headers(r)) >> .onError((r,t) -> error(t)) >> .onBodyPart((r,bb) -> body(r, bb)); >> > So, headers() and body() would be methods on HttpResponse ... Right ? > What is error()? No, sorry for the confusion. headers(), error(), and body() are just examples of what some user code could be ( rather than cluttering the example with too much code ). -Chris. > > - Michael. >> Alternatively, I believe something like this would also be compatible >> with lambda (since there is a default implementation for on Error): >> >> interface HTTPResponseHandler { >> public void onHeaders(HttpResponse resp); >> >> public void onError(HttpRequest request, Throwable exception) >> default { throw exception; } >> } >> >> -Chris. >> >> >> On 21/08/2012 14:57, Michael McMahon wrote: >>> Sam, >>> >>> Thanks for the comments. Some discussion below. >>> >>> >>> On 17/08/12 00:13, Sam Pullara wrote: >>>> I suggest that you make it a more fluent API rather than having >>>> multiple callback methods in your callback interface. As it stands it >>>> isn't compatible with lambdas. You might take some inspiration for the >>>> asynchronous callbacks from my work porting Twitter's Future/Promise >>>> to JDK8: >>> >>> I agree with the above. In a previous version of the API the main >>> callback was lambda compatible. >>> Originally we used HttpResponse to encapsulate everything related to a >>> response >>> including errors. But, some preferred to keep HttpResponse aligned to an >>> actual response >>> from a server in all cases. There might be other ways to get around that >>> by combining >>> HttpResponseHeadersHandler.{onError(), onHeaders()} back into a single >>> method. >>> Maybe, drop the onError() method and add the exception/throwable as a >>> parameter to onHeaders() >>> >>> But, we also wanted to provide notification of body data (through the >>> sub-interface HttpResponseHandler). >>> Keeping the two interfaces distinct meant that applications could get >>> asynchronous notification of >>> the response headers, but then possibly read the response body in a >>> blocking manner. >>> Or alternatively, applications can use the handler to be notified of >>> both headers and body. >>> >>> So, if we revert HttpResponseHeadersHandler back to having a single >>> method, the sub-interface >>> now would have two methods (instead of three). >>> >>> One way around that could be to have two unrelated interfaces: >>> >>> interface HttpResponseHeadersHandler { >>> public void onHeaders(HttpResponse response, Exception e); >>> } >>> >>> interface HttpResponseBodyHandler { >>> public void onBodyPart(HttpResponse resp, ByteBuffer buffer, boolean >>> last); >>> } >>> >>> // Then a HttpResponseBodyHandler would be added to >>> HttpClient.sendRequest() as below: >>> >>> public void sendRequest(HttpRequest, HttpResponseHeadersHandler, >>> HttpResponseBodyHandler); >>> >>> >>> Both of the interfaces would be lambda compatible (again) though at the >>> cost >>> of having to specify two separate handlers. So, the following might >>> be how >>> it could be used (and using a builder for HttpClient) >>> >>> HttpClient client = HttpClient.createBuilder() >>> .setAsynchronousChannelGroup (..) >>> .setCookieManager(..) >>> .setDefaultTimeout(..) >>> .setProxy(...) >>> .addFilter(...) >>> .buildClient(); >>> >>> HttpRequest request = client.createRequest(new >>> URI("http://www.foo.com/")) >>> .setBody("Hello world".getBytes()) >>> .setMethod(HttpMethod.POST); >>> >>> client.sendRequest ( >>> request, >>> >>> // handle headers >>> (HttpResponse response, Exception e) -> { >>> if (response.getResponseCode() != 200) { >>> // handle error response >>> } >>> // handle normal case >>> }, >>> >>> // handle body >>> (HttpResponse response, ByteBuffer buf, boolean last) -> { >>> // handle data in buf >>> } >>> ); >>> >>> It seems fairly readable still, I think. >>> >>> Another thing that this usage points to, is the usefulness of being able >>> to hang some user context >>> off of the HttpResponse or HttpRequest objects. That would be the only >>> way to share some user state >>> between the two handlers above, in this Lambda style. >>>> https://github.com/spullara/java-future-jdk8 >>>> >>>> Another consideration might be to make sure that it is compatible with >>>> an implementation that is using SPDY under the covers for connectivity >>>> as I suspect that HTTP as a wire protocol has peaked though the HTTP >>>> semantics will survive. >>> Right. This is important. One area where there will be changes is with >>> pipe-lining. >>> We need to ensure that our pipe-lining API is not restricted to only >>> Http 1.1 pipe-lining >>> Are you aware of other areas that could have an impact on the API? >>> >>> Thanks >>> Michael. >>> >>>> Sam >>>> >>>> On Tue, Aug 14, 2012 at 5:01 AM, Michael McMahon >>>> wrote: >>>>> Hi, >>>>> >>>>> (apologies for sending this again) >>>>> We have just published a draft of a proposed new Http client API [1] >>>>> for JDK >>>>> 8. >>>>> >>>>> This message has been cc'd to jdk8-dev so that as many people as >>>>> possible >>>>> know about it, but the discussion will be on the net-dev list >>>>> (net-dev at openjdk.java.net). >>>>> So, folks will have to join that list [2], in order to take part. >>>>> >>>>> Thanks, >>>>> Michael. >>>>> >>>>> [1]http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >>>>> >>>>> [2]http://mail.openjdk.java.net/mailman/listinfo/net-dev >>> >>> > 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 michael.x.mcmahon at oracle.com Thu Aug 23 03:23:15 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 23 Aug 2012 11:23:15 +0100 Subject: Review of new Http client API In-Reply-To: References: <503393C3.7010707@oracle.com> <5034ECE5.2020506@oracle.com> <50353B6D.1030102@oracle.com> <50353E49.1040902@oracle.com> Message-ID: <50360493.507@oracle.com> On 22/08/12 22:09, Sam Pullara wrote: > On Aug 22, 2012, at 1:17 PM, Chris Hegarty wrote: >> On 22/08/12 21:05, Michael McMahon wrote: >>> On 22/08/12 15:29, Chris Hegarty wrote: >>>> Michael what you have looks good. >>>> >>>> But, I think what Sam is suggesting ( or maybe not, but I like it ;-) >>>> ), is something like this. (I'd need to think more about what effect >>>> this has on the different modes, async/blocking ) > Yep, this is exactly what I was suggesting. Thanks for clarifying with code. > >>>> class HttpResponse { >>>> HttpResponse onHeaders(Block); >>>> HttpResponse onError(BiBlock); >>>> HttpResponse onBodyPart(BiBlock); >>>> } >>>> >>> Right. I see what you mean in terms of making the setting of the callbacks >>> fluent. I assume that Block and BiBlock are types associated with Lambda >> Right, these are types defined in the lambda repo, that will most likely be part of JDK8. Worth a look, and we should also confirm with the lambda folks before build them into this API. > Briant Goetz would be the right person to ask. In the meantime, there shouldn't be an issue using custom interfaces with a single method (HeaderCallback, ErrorCallback, BodyCallback, etc). Yes, I think that gives us a good fall back in case things develop differently in Lambda. For the moment, I will use three different interfaces, and put some text in the apidoc suggesting they might be replaced with standard Lambda types before JDK8 is finished. Thanks Michael. > Sam > >>> somehow, >>> but otherwise this is unfamiliar territory to me .... >>>> response.onHeaders(r -> headers(r)) >>>> .onError((r,t) -> error(t)) >>>> .onBodyPart((r,bb) -> body(r, bb)); >>>> >>> So, headers() and body() would be methods on HttpResponse ... Right ? >>> What is error()? >> No, sorry for the confusion. headers(), error(), and body() are just examples of what some user code could be ( rather than cluttering the example with too much code ). >> >> -Chris. >> >>> - Michael. >>>> Alternatively, I believe something like this would also be compatible >>>> with lambda (since there is a default implementation for on Error): >>>> >>>> interface HTTPResponseHandler { >>>> public void onHeaders(HttpResponse resp); >>>> >>>> public void onError(HttpRequest request, Throwable exception) >>>> default { throw exception; } >>>> } >>>> >>>> -Chris. >>>> >>>> >>>> On 21/08/2012 14:57, Michael McMahon wrote: >>>>> Sam, >>>>> >>>>> Thanks for the comments. Some discussion below. >>>>> >>>>> >>>>> On 17/08/12 00:13, Sam Pullara wrote: >>>>>> I suggest that you make it a more fluent API rather than having >>>>>> multiple callback methods in your callback interface. As it stands it >>>>>> isn't compatible with lambdas. You might take some inspiration for the >>>>>> asynchronous callbacks from my work porting Twitter's Future/Promise >>>>>> to JDK8: >>>>> I agree with the above. In a previous version of the API the main >>>>> callback was lambda compatible. >>>>> Originally we used HttpResponse to encapsulate everything related to a >>>>> response >>>>> including errors. But, some preferred to keep HttpResponse aligned to an >>>>> actual response >>>>> from a server in all cases. There might be other ways to get around that >>>>> by combining >>>>> HttpResponseHeadersHandler.{onError(), onHeaders()} back into a single >>>>> method. >>>>> Maybe, drop the onError() method and add the exception/throwable as a >>>>> parameter to onHeaders() >>>>> >>>>> But, we also wanted to provide notification of body data (through the >>>>> sub-interface HttpResponseHandler). >>>>> Keeping the two interfaces distinct meant that applications could get >>>>> asynchronous notification of >>>>> the response headers, but then possibly read the response body in a >>>>> blocking manner. >>>>> Or alternatively, applications can use the handler to be notified of >>>>> both headers and body. >>>>> >>>>> So, if we revert HttpResponseHeadersHandler back to having a single >>>>> method, the sub-interface >>>>> now would have two methods (instead of three). >>>>> >>>>> One way around that could be to have two unrelated interfaces: >>>>> >>>>> interface HttpResponseHeadersHandler { >>>>> public void onHeaders(HttpResponse response, Exception e); >>>>> } >>>>> >>>>> interface HttpResponseBodyHandler { >>>>> public void onBodyPart(HttpResponse resp, ByteBuffer buffer, boolean >>>>> last); >>>>> } >>>>> >>>>> // Then a HttpResponseBodyHandler would be added to >>>>> HttpClient.sendRequest() as below: >>>>> >>>>> public void sendRequest(HttpRequest, HttpResponseHeadersHandler, >>>>> HttpResponseBodyHandler); >>>>> >>>>> >>>>> Both of the interfaces would be lambda compatible (again) though at the >>>>> cost >>>>> of having to specify two separate handlers. So, the following might >>>>> be how >>>>> it could be used (and using a builder for HttpClient) >>>>> >>>>> HttpClient client = HttpClient.createBuilder() >>>>> .setAsynchronousChannelGroup (..) >>>>> .setCookieManager(..) >>>>> .setDefaultTimeout(..) >>>>> .setProxy(...) >>>>> .addFilter(...) >>>>> .buildClient(); >>>>> >>>>> HttpRequest request = client.createRequest(new >>>>> URI("http://www.foo.com/")) >>>>> .setBody("Hello world".getBytes()) >>>>> .setMethod(HttpMethod.POST); >>>>> >>>>> client.sendRequest ( >>>>> request, >>>>> >>>>> // handle headers >>>>> (HttpResponse response, Exception e) -> { >>>>> if (response.getResponseCode() != 200) { >>>>> // handle error response >>>>> } >>>>> // handle normal case >>>>> }, >>>>> >>>>> // handle body >>>>> (HttpResponse response, ByteBuffer buf, boolean last) -> { >>>>> // handle data in buf >>>>> } >>>>> ); >>>>> >>>>> It seems fairly readable still, I think. >>>>> >>>>> Another thing that this usage points to, is the usefulness of being able >>>>> to hang some user context >>>>> off of the HttpResponse or HttpRequest objects. That would be the only >>>>> way to share some user state >>>>> between the two handlers above, in this Lambda style. >>>>>> https://github.com/spullara/java-future-jdk8 >>>>>> >>>>>> Another consideration might be to make sure that it is compatible with >>>>>> an implementation that is using SPDY under the covers for connectivity >>>>>> as I suspect that HTTP as a wire protocol has peaked though the HTTP >>>>>> semantics will survive. >>>>> Right. This is important. One area where there will be changes is with >>>>> pipe-lining. >>>>> We need to ensure that our pipe-lining API is not restricted to only >>>>> Http 1.1 pipe-lining >>>>> Are you aware of other areas that could have an impact on the API? >>>>> >>>>> Thanks >>>>> Michael. >>>>> >>>>>> Sam >>>>>> >>>>>> On Tue, Aug 14, 2012 at 5:01 AM, Michael McMahon >>>>>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> (apologies for sending this again) >>>>>>> We have just published a draft of a proposed new Http client API [1] >>>>>>> for JDK >>>>>>> 8. >>>>>>> >>>>>>> This message has been cc'd to jdk8-dev so that as many people as >>>>>>> possible >>>>>>> know about it, but the discussion will be on the net-dev list >>>>>>> (net-dev at openjdk.java.net). >>>>>>> So, folks will have to join that list [2], in order to take part. >>>>>>> >>>>>>> Thanks, >>>>>>> Michael. >>>>>>> >>>>>>> [1]http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >>>>>>> >>>>>>> [2]http://mail.openjdk.java.net/mailman/listinfo/net-dev >>>>> 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 paul.sandoz at oracle.com Thu Aug 23 07:20:37 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 23 Aug 2012 16:20:37 +0200 Subject: Review of new Http client API In-Reply-To: <502A3E28.7080708@oracle.com> References: <502A3E28.7080708@oracle.com> Message-ID: Hi, A potential simplification of the HttpResponseHeadersHandler interface is to turn it into a functional interface: HttpResponseHandler onHeaders(Future dresp) throws InterruptedException, ExecutionException; [Chris, i am not sure if an interface with two methods, one default, is classified as a functional interface.] - mirrors the pull-based asynchronous approach - dresp.isDone() always returns true - the Future encapsulates the underling exception, if any - harder to swallow errors, since the exception from drep.get() will propagate if not caught. - a return of a null HttpResponseHandler means "not interested in the body". FWIW the use of Future is the approach i chose for the Jersey client. HttpResponseHandler would also be a functional interface: void onBodyPart(Future bb) throws InterruptedException, ExecutionException - there is no inheritance relationship between HttpResponseHeadersHandler and HttpResponseHandler. - a "bb" with a capacity of 0 indicates the last part. - the HttpResponse is not required as a parameter because the implementation can obtain it from the onHeaders method. If the use of Future is a bit extreme for some :-) then things can still be simplified by following the above approach with an additional, and optional, functional interface to handle errors when HttpClient.sendRequest is called. -- Rather than setting the bytes on the HttpRequest with numerous methods i wonder if it is better to have a functional interfaces for both OutputStream and the NIO equivalent: interface EntityWriter { // Oh for disjunct types! /** * @return true if there is more to write */ boolean write(T t) throws IOException; } I believe the above can support all the existing functionality currently expressed as methods, including the Iterable/Iterator. There can be instances of EntityWriter for common functionality: EntityWriters.fromBytes(byte[] b, ...); The same might be applicable to HttpResponse with an EntityReader: interface EntityReader { U read(T t) throws IOException; } Of course i might be missing something obvious here in terms of optimisation currently performed by the implementation! -- It somewhat bugs me that blocking and asynchronous pull/push functionality is all defined using the same artifacts. But, my imagination is currently is failing me on how to improve on such matters. Perhaps something better may come out of fluent-based API? Paul. On Aug 14, 2012, at 2:01 PM, Michael McMahon wrote: > Hi, > > (apologies for sending this again) > We have just published a draft of a proposed new Http client API [1] for JDK 8. > > This message has been cc'd to jdk8-dev so that as many people as possible > know about it, but the discussion will be on the net-dev list (net-dev at openjdk.java.net). > So, folks will have to join that list [2], in order to take part. > > Thanks, > Michael. > > [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ > > [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev From chris.hegarty at oracle.com Thu Aug 23 08:05:04 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Aug 2012 16:05:04 +0100 Subject: Review of new Http client API In-Reply-To: References: <502A3E28.7080708@oracle.com> Message-ID: <503646A0.8040602@oracle.com> Paul, All good feedback, and I will leave it to Michael to reply to the specifics. On thought I had on separation of modes is something list this: interface HeaderHandler { onHeaders(HttpResponse); } interface ErrorHandler { onError(HttpResponse, Throwable); } interface BodyHandler { onBodyPart(HttpResponse, ByteBuffer, boolean); } class HttpRequest { .... AsyncHttpRequest async(HttpRequest); .... } class AsyncHttpRequest extends HttpRequest { // no public constructors .... AsyncHttpRequest onHeaders(HeaderHandler); AsyncHttpRequest onError(ErrorHandler); AsyncHttpRequest onBodyPart(BodyHandler); } class HttpClient { .... OutputStream sendHeaders(HttpRequest request, long contentLength) Future sendRequest(HttpRequest req) void sendRequest(AsyncHttpRequest req) } Then user code may do: AsyncHttpRequest request.async() .onHeaders(r -> dumpHeaders(r)) .onError((r,t) -> handleError(r,t)); .onBodyPart((r,bb,c) -> transformBody(r,bb,t)); client.sendRequest(request); .... void dumpHeaders(HttpResponse r) { System.out.println(r); } void handleError(HttpResponse r, t) { throw t; } void transformBody(HttpResponse r, bb, boolean complete) { System.out.println("Hello there!"); } Some experimentation is necessary to find a good balance here. -Chris. On 23/08/2012 15:20, Paul Sandoz wrote: > Hi, > > A potential simplification of the HttpResponseHeadersHandler interface is to turn it into a functional interface: > > HttpResponseHandler onHeaders(Future dresp) throws InterruptedException, ExecutionException; > > [Chris, i am not sure if an interface with two methods, one default, is classified as a functional interface.] > > - mirrors the pull-based asynchronous approach > > - dresp.isDone() always returns true > > - the Future encapsulates the underling exception, if any > > - harder to swallow errors, since the exception from drep.get() will propagate if not caught. > > - a return of a null HttpResponseHandler means "not interested in the body". > > FWIW the use of Future is the approach i chose for the Jersey client. > > HttpResponseHandler would also be a functional interface: > > void onBodyPart(Future bb) throws InterruptedException, ExecutionException > > - there is no inheritance relationship between HttpResponseHeadersHandler and HttpResponseHandler. > > - a "bb" with a capacity of 0 indicates the last part. > > - the HttpResponse is not required as a parameter because the implementation can obtain it from the onHeaders method. > > If the use of Future is a bit extreme for some :-) then things can still be simplified by following the above approach with an additional, and optional, functional interface to handle errors when HttpClient.sendRequest is called. > > -- > > Rather than setting the bytes on the HttpRequest with numerous methods i wonder if it is better to have a functional interfaces for both OutputStream and the NIO equivalent: > > interface EntityWriter { // Oh for disjunct types! > /** > * @return true if there is more to write > */ > boolean write(T t) throws IOException; > } > > I believe the above can support all the existing functionality currently expressed as methods, including the Iterable/Iterator. There can be instances of EntityWriter for common functionality: > > EntityWriters.fromBytes(byte[] b, ...); > > The same might be applicable to HttpResponse with an EntityReader: > > interface EntityReader { > U read(T t) throws IOException; > } > > Of course i might be missing something obvious here in terms of optimisation currently performed by the implementation! > > -- > > It somewhat bugs me that blocking and asynchronous pull/push functionality is all defined using the same artifacts. But, my imagination is currently is failing me on how to improve on such matters. Perhaps something better may come out of fluent-based API? > > Paul. > > On Aug 14, 2012, at 2:01 PM, Michael McMahon wrote: > >> Hi, >> >> (apologies for sending this again) >> We have just published a draft of a proposed new Http client API [1] for JDK 8. >> >> This message has been cc'd to jdk8-dev so that as many people as possible >> know about it, but the discussion will be on the net-dev list (net-dev at openjdk.java.net). >> So, folks will have to join that list [2], in order to take part. >> >> Thanks, >> Michael. >> >> [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev > From michael.x.mcmahon at oracle.com Thu Aug 23 08:16:32 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 23 Aug 2012 16:16:32 +0100 Subject: Review of new Http client API In-Reply-To: References: <502A3E28.7080708@oracle.com> Message-ID: <50364950.1080103@oracle.com> Paul, Thanks for looking at it. Yes, this is an area that needs some more work. The current thinking is along the lines that Chris just posted and I hope to have another version of the API to look at tomorrow. What you suggest seems like an unusual usage of Future<> as we have tried to provide a mode of operation where applications can get a Future which would work in the conventional way of returning the result "in the future". But, it raises a question in that while we currently have callback interfaces for both headers and data, we only have a Future based interface for headers (but not data). - Michael On 23/08/12 15:20, Paul Sandoz wrote: > Hi, > > A potential simplification of the HttpResponseHeadersHandler interface is to turn it into a functional interface: > > HttpResponseHandler onHeaders(Future dresp) throws InterruptedException, ExecutionException; > > [Chris, i am not sure if an interface with two methods, one default, is classified as a functional interface.] > > - mirrors the pull-based asynchronous approach > > - dresp.isDone() always returns true > > - the Future encapsulates the underling exception, if any > > - harder to swallow errors, since the exception from drep.get() will propagate if not caught. > > - a return of a null HttpResponseHandler means "not interested in the body". > > FWIW the use of Future is the approach i chose for the Jersey client. > > HttpResponseHandler would also be a functional interface: > > void onBodyPart(Future bb) throws InterruptedException, ExecutionException > > - there is no inheritance relationship between HttpResponseHeadersHandler and HttpResponseHandler. > > - a "bb" with a capacity of 0 indicates the last part. > > - the HttpResponse is not required as a parameter because the implementation can obtain it from the onHeaders method. > > If the use of Future is a bit extreme for some :-) then things can still be simplified by following the above approach with an additional, and optional, functional interface to handle errors when HttpClient.sendRequest is called. > > -- > > Rather than setting the bytes on the HttpRequest with numerous methods i wonder if it is better to have a functional interfaces for both OutputStream and the NIO equivalent: > > interface EntityWriter { // Oh for disjunct types! > /** > * @return true if there is more to write > */ > boolean write(T t) throws IOException; > } > > I believe the above can support all the existing functionality currently expressed as methods, including the Iterable/Iterator. There can be instances of EntityWriter for common functionality: > > EntityWriters.fromBytes(byte[] b, ...); > > The same might be applicable to HttpResponse with an EntityReader: > > interface EntityReader { > U read(T t) throws IOException; > } > > Of course i might be missing something obvious here in terms of optimisation currently performed by the implementation! > > -- > > It somewhat bugs me that blocking and asynchronous pull/push functionality is all defined using the same artifacts. But, my imagination is currently is failing me on how to improve on such matters. Perhaps something better may come out of fluent-based API? > > Paul. > > On Aug 14, 2012, at 2:01 PM, Michael McMahon wrote: > >> Hi, >> >> (apologies for sending this again) >> We have just published a draft of a proposed new Http client API [1] for JDK 8. >> >> This message has been cc'd to jdk8-dev so that as many people as possible >> know about it, but the discussion will be on the net-dev list (net-dev at openjdk.java.net). >> So, folks will have to join that list [2], in order to take part. >> >> Thanks, >> Michael. >> >> [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >> >> [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev From paul.sandoz at oracle.com Thu Aug 23 08:34:45 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 23 Aug 2012 17:34:45 +0200 Subject: Review of new Http client API In-Reply-To: <503646A0.8040602@oracle.com> References: <502A3E28.7080708@oracle.com> <503646A0.8040602@oracle.com> Message-ID: <44FFF167-DA74-4344-A5EE-7F5F40214B9A@oracle.com> On Aug 23, 2012, at 5:05 PM, Chris Hegarty wrote: > Paul, > > All good feedback, and I will leave it to Michael to reply to the specifics. On thought I had on separation of modes is something list this: > > interface HeaderHandler { > onHeaders(HttpResponse); > } > interface ErrorHandler { > onError(HttpResponse, Throwable); > } > interface BodyHandler { > onBodyPart(HttpResponse, ByteBuffer, boolean); > } > > class HttpRequest { > .... > AsyncHttpRequest async(HttpRequest); > .... > } > > class AsyncHttpRequest extends HttpRequest { > // no public constructors > .... > AsyncHttpRequest onHeaders(HeaderHandler); > AsyncHttpRequest onError(ErrorHandler); > AsyncHttpRequest onBodyPart(BodyHandler); > } > > class HttpClient { > .... > OutputStream sendHeaders(HttpRequest request, long contentLength) > Future sendRequest(HttpRequest req) > void sendRequest(AsyncHttpRequest req) > } > OK, i would be inclined to separate out the instance used for building from the instance passed around, so one cannot muck around with the state of the latter. > Then user code may do: > > AsyncHttpRequest request.async() > .onHeaders(r -> dumpHeaders(r)) > .onError((r,t) -> handleError(r,t)); > .onBodyPart((r,bb,c) -> transformBody(r,bb,t)); > client.sendRequest(request); > If these calls are on* calls are optional and one is not interested in when the headers have been received one could omit the onHeaders call, infact all those methods could be optional. That certainly simplifies things. > .... > > void dumpHeaders(HttpResponse r) { > System.out.println(r); > } > void handleError(HttpResponse r, t) { > throw t; > } > void transformBody(HttpResponse r, bb, boolean complete) { > System.out.println("Hello there!"); > } > FWIW you could use method references: AsyncHttpRequest request.async() .onHeaders(whateverthatclassiscalled::dumpHeaders) ... Paul. > Some experimentation is necessary to find a good balance here. > > -Chris. From paul.sandoz at oracle.com Thu Aug 23 08:40:13 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 23 Aug 2012 17:40:13 +0200 Subject: Review of new Http client API In-Reply-To: <50364950.1080103@oracle.com> References: <502A3E28.7080708@oracle.com> <50364950.1080103@oracle.com> Message-ID: <3F8DF75B-C729-47AF-891F-B0651F3E0257@oracle.com> On Aug 23, 2012, at 5:16 PM, Michael McMahon wrote: > Paul, > > Thanks for looking at it. Yes, this is an area that needs some more work. > The current thinking is along the lines that Chris just posted and I hope to > have another version of the API to look at tomorrow. > > What you suggest seems like an unusual usage of Future<> as we have tried to provide > a mode of operation where applications can get a Future > which would work in the conventional way of returning the result "in the future". Agreed, it fit well with the underlying asynchronous support in Jersey, which was already using the Future, and it bugged me using callback interfaces with two methods, where most of the time the error would be swallowed. If there was a listener concept for Future in the JDK I would have used that instead. I think the approach Chris shows easily allows for a default handler when one is not supplied. > But, it raises a question in that while we currently have callback interfaces for both > headers and data, we only have a Future based interface for headers (but not data). > Indeed! Paul. > - Michael > > On 23/08/12 15:20, Paul Sandoz wrote: >> Hi, >> >> A potential simplification of the HttpResponseHeadersHandler interface is to turn it into a functional interface: >> >> HttpResponseHandler onHeaders(Future dresp) throws InterruptedException, ExecutionException; >> >> [Chris, i am not sure if an interface with two methods, one default, is classified as a functional interface.] >> >> - mirrors the pull-based asynchronous approach >> >> - dresp.isDone() always returns true >> >> - the Future encapsulates the underling exception, if any >> >> - harder to swallow errors, since the exception from drep.get() will propagate if not caught. >> >> - a return of a null HttpResponseHandler means "not interested in the body". >> >> FWIW the use of Future is the approach i chose for the Jersey client. >> >> HttpResponseHandler would also be a functional interface: >> >> void onBodyPart(Future bb) throws InterruptedException, ExecutionException >> >> - there is no inheritance relationship between HttpResponseHeadersHandler and HttpResponseHandler. >> >> - a "bb" with a capacity of 0 indicates the last part. >> >> - the HttpResponse is not required as a parameter because the implementation can obtain it from the onHeaders method. >> >> If the use of Future is a bit extreme for some :-) then things can still be simplified by following the above approach with an additional, and optional, functional interface to handle errors when HttpClient.sendRequest is called. >> >> -- >> >> Rather than setting the bytes on the HttpRequest with numerous methods i wonder if it is better to have a functional interfaces for both OutputStream and the NIO equivalent: >> >> interface EntityWriter { // Oh for disjunct types! >> /** >> * @return true if there is more to write >> */ >> boolean write(T t) throws IOException; >> } >> >> I believe the above can support all the existing functionality currently expressed as methods, including the Iterable/Iterator. There can be instances of EntityWriter for common functionality: >> >> EntityWriters.fromBytes(byte[] b, ...); >> >> The same might be applicable to HttpResponse with an EntityReader: >> >> interface EntityReader { >> U read(T t) throws IOException; >> } >> >> Of course i might be missing something obvious here in terms of optimisation currently performed by the implementation! >> >> -- >> >> It somewhat bugs me that blocking and asynchronous pull/push functionality is all defined using the same artifacts. But, my imagination is currently is failing me on how to improve on such matters. Perhaps something better may come out of fluent-based API? >> >> Paul. >> >> On Aug 14, 2012, at 2:01 PM, Michael McMahon wrote: >> >>> Hi, >>> >>> (apologies for sending this again) >>> We have just published a draft of a proposed new Http client API [1] for JDK 8. >>> >>> This message has been cc'd to jdk8-dev so that as many people as possible >>> know about it, but the discussion will be on the net-dev list (net-dev at openjdk.java.net). >>> So, folks will have to join that list [2], in order to take part. >>> >>> Thanks, >>> Michael. >>> >>> [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ >>> >>> [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev > From chris.hegarty at oracle.com Thu Aug 23 08:40:50 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Aug 2012 16:40:50 +0100 Subject: Review of new Http client API In-Reply-To: <44FFF167-DA74-4344-A5EE-7F5F40214B9A@oracle.com> References: <502A3E28.7080708@oracle.com> <503646A0.8040602@oracle.com> <44FFF167-DA74-4344-A5EE-7F5F40214B9A@oracle.com> Message-ID: <50364F02.7070706@oracle.com> On 23/08/2012 16:34, Paul Sandoz wrote: > ... > > OK, i would be inclined to separate out the instance used for building from the instance passed around, so one cannot muck around with the state of the latter. Agreed, HttpResponse could use a builder pattern. >> Then user code may do: >> >> AsyncHttpRequest request.async() >> .onHeaders(r -> dumpHeaders(r)) >> .onError((r,t) -> handleError(r,t)); >> .onBodyPart((r,bb,c) -> transformBody(r,bb,t)); >> client.sendRequest(request); >> > > If these calls are on* calls are optional and one is not interested in when the headers have been received one could omit the onHeaders call, infact all those methods could be optional. That certainly simplifies things. Right. >> .... >> >> void dumpHeaders(HttpResponse r) { >> System.out.println(r); >> } >> void handleError(HttpResponse r, t) { >> throw t; >> } >> void transformBody(HttpResponse r, bb, boolean complete) { >> System.out.println("Hello there!"); >> } >> > > FWIW you could use method references: > > AsyncHttpRequest request.async() > .onHeaders(whateverthatclassiscalled::dumpHeaders) Ok, great. -Chris. > ... > > Paul. > > >> Some experimentation is necessary to find a good balance here. >> >> -Chris. From shirishk at linux.vnet.ibm.com Thu Aug 23 10:50:23 2012 From: shirishk at linux.vnet.ibm.com (Shirish Kuncolienkar) Date: Thu, 23 Aug 2012 23:20:23 +0530 Subject: Code review request 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() Message-ID: <50366D5F.4070606@linux.vnet.ibm.com> Could I get the change reviewed please This behavior is seen on Windows. Logic in URLClassPath.getLoader() does not take care of an URL which looks like "jar:file:/C:/test/xyz.jar!/". The logic ends up choosing a FileLoader instead of a JarLoader. JarLoader has provision for closing file handles, so choosing a JarLoader will solve the problem. Secondly the constructor of JarLoader blindly adds a prefix and suffix to the provided URL to make it look like a jar URL. Changed the code here to conditionally append/prepend The change set can be found at http://cr.openjdk.java.net/~shirishk/7183373/webrev.0/ -Shirish From michael.x.mcmahon at oracle.com Fri Aug 24 05:09:37 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 24 Aug 2012 13:09:37 +0100 Subject: Code review request 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() In-Reply-To: <50366D5F.4070606@linux.vnet.ibm.com> References: <50366D5F.4070606@linux.vnet.ibm.com> Message-ID: <50376F01.5010601@oracle.com> On 23/08/12 18:50, Shirish Kuncolienkar wrote: > Could I get the change reviewed please > > This behavior is seen on Windows. > Logic in URLClassPath.getLoader() does not take care of an URL which > looks like "jar:file:/C:/test/xyz.jar!/". The logic ends up choosing a > FileLoader instead of a JarLoader. JarLoader has provision for > closing file handles, so choosing a JarLoader will solve the problem. > Secondly the constructor of JarLoader blindly adds a prefix and suffix > to the provided URL to make it look like a jar URL. Changed the code > here to conditionally append/prepend > > The change set can be found at > http://cr.openjdk.java.net/~shirishk/7183373/webrev.0/ > > -Shirish > Shirish, I have a slight concern that this would modify the Loader class to be used in some circumstances completely independent of the requirements of URLClassLoader.close(). This is very sensitive code. Would it be possible to fix this within the context of whatever loader is currently being invoked? - Michael From shirishk at linux.vnet.ibm.com Fri Aug 24 09:02:24 2012 From: shirishk at linux.vnet.ibm.com (Shirish Kuncolienkar) Date: Fri, 24 Aug 2012 21:32:24 +0530 Subject: Code review request 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() In-Reply-To: <50376F01.5010601@oracle.com> References: <50366D5F.4070606@linux.vnet.ibm.com> <50376F01.5010601@oracle.com> Message-ID: <5037A590.90904@linux.vnet.ibm.com> On 8/24/2012 5:39 PM, Michael McMahon wrote: > On 23/08/12 18:50, Shirish Kuncolienkar wrote: >> Could I get the change reviewed please >> >> This behavior is seen on Windows. >> Logic in URLClassPath.getLoader() does not take care of an URL which >> looks like "jar:file:/C:/test/xyz.jar!/". The logic ends up choosing >> a FileLoader instead of a JarLoader. JarLoader has provision for >> closing file handles, so choosing a JarLoader will solve the problem. >> Secondly the constructor of JarLoader blindly adds a prefix and >> suffix to the provided URL to make it look like a jar URL. Changed >> the code here to conditionally append/prepend >> >> The change set can be found at >> http://cr.openjdk.java.net/~shirishk/7183373/webrev.0/ >> >> -Shirish >> > Shirish, > > I have a slight concern that this would modify the Loader class to be > used in some circumstances > completely independent of the requirements of URLClassLoader.close(). > This is very sensitive code. > Would it be possible to fix this within the context of whatever loader > is currently being invoked? > > - Michael > Michael, Thanks for the review comments. The second version of the fix is uploaded at http://cr.openjdk.java.net/~shirishk/7183373/webrev.2/ Could you please take a look at this one ? Description of the fix: URLClassPath.Loader.findResource() method opens a connection to the provided URL to test whether the URL is good. Here the Jar file gets opened but does not get closed because the created stream as setUseCaches set to true. Just out of curiosity I would like to know bit more on "some circumstances completely independent of the requirements of URLClassLoader.close()". I see that the Loader classes are private in nature and are being used within the context of the URLClassPath. We create an instance of JarLoader for all the jars that are on the extension class loader path by adding "jar" , "!/" to the file url which comes as the input. The reason behind the first fix was that if we have a url like this why not use a JarLoader instance. - Shirish 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 chris.hegarty at oracle.com Tue Aug 28 02:00:05 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 28 Aug 2012 10:00:05 +0100 Subject: [7u8] Request for Approval for CR 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c Message-ID: <503C8895.6090802@oracle.com> Hi, This is a request for approval to backport the fix for 7188755 from JDK8 to 7u8. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188755 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c JDK8 changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7d125f2575b The fix is a contribution from Christian Schulte and has been reviewed by me ( chegar ). Thanks, Chris. From sean.coffey at oracle.com Tue Aug 28 02:02:41 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 28 Aug 2012 10:02:41 +0100 Subject: [7u8] Request for Approval for CR 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c In-Reply-To: <503C8895.6090802@oracle.com> References: <503C8895.6090802@oracle.com> Message-ID: <503C8931.3000103@oracle.com> Approved. regards, Sean. On 28/08/2012 10:00, Chris Hegarty wrote: > Hi, > > This is a request for approval to backport the fix for 7188755 from > JDK8 to 7u8. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188755 > > 7188755: Crash due to missing synchronization on gconf_client in > DefaultProxySelector.c > > JDK8 changeset: > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7d125f2575b > > The fix is a contribution from Christian Schulte and has been reviewed > by me ( chegar ). > > Thanks, > Chris. 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: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 edvard.wendelin at oracle.com Tue Aug 28 02:01:21 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 28 Aug 2012 11:01:21 +0200 Subject: [7u8] Request for Approval for CR 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c In-Reply-To: <503C8895.6090802@oracle.com> References: <503C8895.6090802@oracle.com> Message-ID: <503C88E1.7070009@oracle.com> Approved. On 08/28/2012 11:00 AM, Chris Hegarty wrote: > Hi, > > This is a request for approval to backport the fix for 7188755 from > JDK8 to 7u8. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188755 > > 7188755: Crash due to missing synchronization on gconf_client in > DefaultProxySelector.c > > JDK8 changeset: > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7d125f2575b > > The fix is a contribution from Christian Schulte and has been reviewed > by me ( chegar ). > > Thanks, > Chris. 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 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 shirishk at linux.vnet.ibm.com Tue Aug 28 20:58:32 2012 From: shirishk at linux.vnet.ibm.com (Shirish Kuncolienkar) Date: Wed, 29 Aug 2012 09:28:32 +0530 Subject: Code review request 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() In-Reply-To: <5037A590.90904@linux.vnet.ibm.com> References: <50366D5F.4070606@linux.vnet.ibm.com> <50376F01.5010601@oracle.com> <5037A590.90904@linux.vnet.ibm.com> Message-ID: <503D9368.9080502@linux.vnet.ibm.com> On 8/24/2012 9:32 PM, Shirish Kuncolienkar wrote: > On 8/24/2012 5:39 PM, Michael McMahon wrote: >> On 23/08/12 18:50, Shirish Kuncolienkar wrote: >>> Could I get the change reviewed please >>> >>> This behavior is seen on Windows. >>> Logic in URLClassPath.getLoader() does not take care of an URL which >>> looks like "jar:file:/C:/test/xyz.jar!/". The logic ends up choosing >>> a FileLoader instead of a JarLoader. JarLoader has provision for >>> closing file handles, so choosing a JarLoader will solve the >>> problem. Secondly the constructor of JarLoader blindly adds a prefix >>> and suffix to the provided URL to make it look like a jar URL. >>> Changed the code here to conditionally append/prepend >>> >>> The change set can be found at >>> http://cr.openjdk.java.net/~shirishk/7183373/webrev.0/ >>> >>> -Shirish >>> >> Shirish, >> >> I have a slight concern that this would modify the Loader class to be >> used in some circumstances >> completely independent of the requirements of URLClassLoader.close(). >> This is very sensitive code. >> Would it be possible to fix this within the context of whatever >> loader is currently being invoked? >> >> - Michael >> > Michael, > > Thanks for the review comments. The second version of the fix is > uploaded at http://cr.openjdk.java.net/~shirishk/7183373/webrev.2/ > Could you please take a look at this one ? > > Description of the fix: > URLClassPath.Loader.findResource() method opens a connection to the > provided URL to test whether the URL is good. Here the Jar file gets > opened but does not get closed because the created stream as > setUseCaches set to true. > > Just out of curiosity I would like to know bit more on "some > circumstances completely independent of the requirements of > URLClassLoader.close()". I see that the Loader classes are private in > nature and are being used within the context of the URLClassPath. > We create an instance of JarLoader for all the jars that are on the > extension class loader path by adding "jar" , "!/" to the file url > which comes as the input. The reason behind the first fix was that if > we have a url like this why not use a JarLoader instance. > > - Shirish > Michael, Did you get a chance to look at the new patch? -Shirish From kurchi.subhra.hazra at oracle.com Wed Aug 29 16:55:52 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 29 Aug 2012 16:55:52 -0700 Subject: In-Reply-To: References: Message-ID: <503EAC08.5040508@oracle.com> Forwarding this to the networking mailing list. Do you know of any way to reproduce the problem, like a small test case that we(I) could try? Thanks, Kurchi On 8/29/2012 4:45 PM, Earle Nietzel wrote: > Seeing the following Warning multiple times every few seconds. > > Aug 29, 2012 7:09:26 PM sun.rmi.transport.tcp.TCPTransport$AcceptLoop > executeAcceptLoop > WARNING: RMI TCP Accept-1099: accept loop for > ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=1099] throws > java.net.SocketException: Invalid argument > at java.net.PlainSocketImpl.socketAccept(Native Method) > at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398) > at java.net.ServerSocket.implAccept(ServerSocket.java:522) > at java.net.ServerSocket.accept(ServerSocket.java:490) > at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387) > at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359) > at java.lang.Thread.run(Thread.java:722) > > > OSX 10.8.1 > > java version "1.7.0_06" > Java(TM) SE Runtime Environment (build 1.7.0_06-b24) > Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode) > > The closest thread I found seems to be this one: > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000229.html > > No issues when using JAVA 6 JDK's. > > These warnings appear constantly when working with ActiveMQ 5.4.0, 5.6.0. > > Forgive for me if this post seems irrelevant to this list :) > > Earle -- -Kurchi 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 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 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 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