From abhi.saha at oracle.com Mon Nov 1 05:10:53 2010 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Mon, 01 Nov 2010 05:10:53 +0000 Subject: hg: jdk7/tl/corba: 6996356: Changes for 6891766 break build Message-ID: <20101101051055.4167A475AB@hg.openjdk.java.net> Changeset: 046be5aaff1c Author: asaha Date: 2010-10-31 22:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/046be5aaff1c 6996356: Changes for 6891766 break build Summary: JPRT build passed Reviewed-by: alanb ! make/com/sun/corba/minclude/com_sun_corba_se_impl_io.jmk From xuelei.fan at oracle.com Mon Nov 1 14:59:03 2010 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 01 Nov 2010 14:59:03 +0000 Subject: hg: jdk7/tl/jdk: 6792180: Enhance to reject weak algorithms or conform to crypto recommendations Message-ID: <20101101145918.B17D3475C0@hg.openjdk.java.net> Changeset: d26730767789 Author: xuelei Date: 2010-11-01 07:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d26730767789 6792180: Enhance to reject weak algorithms or conform to crypto recommendations Reviewed-by: mullan, weijun, wetmore + src/share/classes/java/security/AlgorithmConstraints.java + src/share/classes/java/security/CryptoPrimitive.java ! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java + src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/validator/Validator.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows From kumar.x.srinivasan at oracle.com Mon Nov 1 17:13:27 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 01 Nov 2010 17:13:27 +0000 Subject: hg: jdk7/tl/jdk: 6995674: (launcher) make of jli fails on windows if directory exists Message-ID: <20101101171342.8CC6F475C5@hg.openjdk.java.net> Changeset: 2eade65eab5b Author: ksrini Date: 2010-11-01 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2eade65eab5b 6995674: (launcher) make of jli fails on windows if directory exists Reviewed-by: darcy, ohair ! make/java/jli/Makefile From mandy.chung at oracle.com Mon Nov 1 17:56:24 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 01 Nov 2010 10:56:24 -0700 Subject: Code Review Request for 6994413: JDK_GetVersionInfo0 only expects a two digit build number In-Reply-To: <4CCB8FEF.6010104@oracle.com> References: <4CC4D236.2070007@oracle.com> <4CCB3EE6.20306@oracle.com> <4CCB82B4.5080201@oracle.com> <4CCB8687.4000100@oracle.com> <4CCB8FEF.6010104@oracle.com> Message-ID: <4CCEFF48.6080402@oracle.com> On 10/29/10 20:24, David Holmes wrote: > By the way, shouldn't we use isdigit rather than: > > if (jdk_build_string[i] >= '0' && jdk_build_string[i] <= '9') { > Yes, it'd be good to use isdigit and I cleaned this up as part of this fix. http://cr.openjdk.java.net/~mchung/6994413/webrev.01/ Thanks Mandy > David > ----- > > Mandy Chung said the following on 10/30/10 12:44: >> On 10/29/10 7:28 PM, David Holmes wrote: >>> Hi Mandy, >>> >>> Mandy Chung said the following on 10/30/10 07:38: >>>> I have a fix for: >>>> 6994413 JDK_GetVersionInfo0 only expects a two digit build number >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~mchung/6994413/webrev.00/ >>> >>> If the build "number" consists of just 'b' then you'll end up doing >>> atoi on an empty string - will that have the right effect? >>> >> Good catch. line 60 should check that it has to contain at least 2 >> characters (as the behavior of atoi in the case of error is undefined): >> >> line 60 if (jdk_build_string[0] == 'b' && len >= 2) { >> >>> Otherwise change looks ok, but I didn't review the test case (which >>> doesn't seem directly related to this fixc anyway). >>> >> >> This test fails with the current jdk 7 build but passes with this >> fix. sun.misc.Version.* methods provide access to the >> jdk_version_info and jvm_version_info. i.e. the jdkBuildNumber() >> method basically returns the build number from the jdk_version_info. >> Rather than testing just the jdk build number, I have the test to >> verify the entire version string (as well as the jvm version). >> >> Thanks >> Mandy >>> David >>> >>>> Can you please review it? >>>> >>>> Thanks >>>> Mandy >>>> >>>> On 10/24/10 5:41 PM, David Holmes wrote: >>>>> FYI I just filed: >>>>> >>>>> 6994413 JDK_GetVersionInfo0 only expects a two digit build number >>>>> >>>>> Since b100 we've lost the build number from the version string >>>>> made available to the VM. The above is filed under >>>>> java->java->build but that may not be the right place. >>>>> >>>>> Cheers, >>>>> David Holmes >>>> >> From mandy.chung at oracle.com Mon Nov 1 18:01:38 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 01 Nov 2010 18:01:38 +0000 Subject: hg: jdk7/tl/jdk: 6994413: JDK_GetVersionInfo0 only expects a two digit build number Message-ID: <20101101180148.A222F475C8@hg.openjdk.java.net> Changeset: e95c7f8979ee Author: mchung Date: 2010-11-01 10:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e95c7f8979ee 6994413: JDK_GetVersionInfo0 only expects a two digit build number Reviewed-by: dholmes ! src/share/native/common/jdk_util.c + test/sun/misc/Version/Version.java From xuelei.fan at oracle.com Mon Nov 1 23:00:48 2010 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 02 Nov 2010 07:00:48 +0800 Subject: hg: jdk7/tl/jdk: 4873188: Support TLS 1.1 In-Reply-To: <55B54537-CE5C-4A54-8DED-FF082E09F800@oxy.edu> References: <20101030104801.8CCF647548@hg.openjdk.java.net> <55B54537-CE5C-4A54-8DED-FF082E09F800@oxy.edu> Message-ID: <4CCF46A0.6010200@oracle.com> On 11/2/2010 1:27 AM, Henry B. Hotz wrote: > TLS 1.2? > This is the implementation of TLS 1.1. Andrew > On Oct 30, 2010, at 3:47 AM, xuelei.fan at oracle.com wrote: > >> Changeset: 93cd7e89adb8 >> Author: xuelei >> Date: 2010-10-30 18:39 +0800 >> URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93cd7e89adb8 >> >> 4873188: Support TLS 1.1 >> Reviewed-by: wetmore, weijun >> >> ! src/share/classes/javax/net/ssl/SSLSocketFactory.java >> ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java >> ! src/share/classes/sun/security/internal/spec/TlsMasterSecretParameterSpec.java >> ! src/share/classes/sun/security/ssl/CipherBox.java >> ! src/share/classes/sun/security/ssl/CipherSuite.java >> ! src/share/classes/sun/security/ssl/ClientHandshaker.java >> ! src/share/classes/sun/security/ssl/Debug.java >> ! src/share/classes/sun/security/ssl/HandshakeMessage.java >> ! src/share/classes/sun/security/ssl/Handshaker.java >> ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java >> ! src/share/classes/sun/security/ssl/MAC.java >> ! src/share/classes/sun/security/ssl/ProtocolList.java >> ! src/share/classes/sun/security/ssl/ProtocolVersion.java >> ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java >> ! src/share/classes/sun/security/ssl/Record.java >> ! src/share/classes/sun/security/ssl/SSLEngineImpl.java >> ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java >> ! src/share/classes/sun/security/ssl/SSLSocketImpl.java >> ! src/share/classes/sun/security/ssl/ServerHandshaker.java >> ! src/share/classes/sun/security/ssl/SunJSSE.java >> ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java >> ! src/share/classes/sun/security/ssl/krb5/KerberosPreMasterSecret.java >> ! test/sun/security/pkcs11/fips/CipherTest.java >> ! test/sun/security/pkcs11/sslecc/CipherTest.java >> + test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java >> + test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java >> + test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java >> + test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java >> + test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java >> ! test/sun/security/ssl/sanity/interop/CipherTest.java > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu > > > From jonathan.gibbons at oracle.com Tue Nov 2 02:29:40 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 02 Nov 2010 02:29:40 +0000 Subject: hg: jdk7/tl/langtools: 6996626: Scope fix issues for ImportScope Message-ID: <20101102022944.D969A4762E@hg.openjdk.java.net> Changeset: 6ce6ee1b831a Author: jjg Date: 2010-11-01 19:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6ce6ee1b831a 6996626: Scope fix issues for ImportScope Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Scope.java From xuelei.fan at oracle.com Tue Nov 2 05:03:40 2010 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 02 Nov 2010 05:03:40 +0000 Subject: hg: jdk7/tl/jdk: 6916074: Add support for TLS 1.2; ... Message-ID: <20101102050415.EFF7147634@hg.openjdk.java.net> Changeset: 9d6a9f65d2bf Author: xuelei Date: 2010-11-01 22:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d6a9f65d2bf 6916074: Add support for TLS 1.2 6985179: To support Server Name Indication extension for JSSE client Summary: Introduces the algorithm constraints to support signature and hash algorithm selection. Includes contributions from wetmore and weijung. Reviewed-by: wetmore, weijun ! src/share/classes/com/sun/crypto/provider/AESCrypt.java ! src/share/classes/com/sun/crypto/provider/ARCFOURCipher.java ! src/share/classes/com/sun/crypto/provider/DESedeCipher.java ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/com/sun/crypto/provider/DHPublicKey.java ! src/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsRsaPremasterSecretGenerator.java + src/share/classes/javax/net/ssl/ExtendedSSLSession.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLServerSocket.java ! src/share/classes/javax/net/ssl/SSLSocket.java + src/share/classes/javax/net/ssl/X509ExtendedTrustManager.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/internal/spec/TlsMasterSecretParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsPrfParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsRsaPremasterSecretParameterSpec.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java + src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java + src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java ! test/com/sun/crypto/provider/TLS/TestKeyMaterial.java ! test/com/sun/crypto/provider/TLS/TestMasterSecret.java ! test/com/sun/crypto/provider/TLS/TestPRF.java + test/com/sun/crypto/provider/TLS/TestPRF12.java ! test/com/sun/crypto/provider/TLS/TestPremaster.java ! test/com/sun/crypto/provider/TLS/Utils.java + test/com/sun/crypto/provider/TLS/prf12data.txt ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java ! test/sun/security/pkcs11/tls/TestKeyMaterial.java ! test/sun/security/pkcs11/tls/TestMasterSecret.java ! test/sun/security/pkcs11/tls/TestPRF.java ! test/sun/security/pkcs11/tls/TestPremaster.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Basics.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/TestAllSuites.java ! test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java From alan.bateman at oracle.com Tue Nov 2 11:29:11 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 02 Nov 2010 11:29:11 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20101102112950.1C1C547646@hg.openjdk.java.net> Changeset: 5a6c63deacf3 Author: alanb Date: 2010-11-02 10:05 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5a6c63deacf3 6993126: (aio) remove AsynchronousDatagramChannel Reviewed-by: chegar ! make/java/nio/FILES_java.gmk - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java ! src/solaris/classes/sun/nio/ch/LinuxAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/SolarisAsynchronousChannelProvider.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousChannelProvider.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/Provider1.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/Provider2.java Changeset: 88462abbf774 Author: alanb Date: 2010-11-02 10:07 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/88462abbf774 6431343: (dc) DatagramChannel may not report its local address correctly after connect or disconnect Reviewed-by: chegar ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java + test/java/nio/channels/DatagramChannel/ChangingAddress.java Changeset: fdcb0f667b7d Author: alanb Date: 2010-11-02 10:15 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fdcb0f667b7d Merge From maurizio.cimadamore at oracle.com Tue Nov 2 12:13:15 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 02 Nov 2010 12:13:15 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20101102121321.6A9C04764A@hg.openjdk.java.net> Changeset: 20659c8c917d Author: mcimadamore Date: 2010-11-02 12:00 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/20659c8c917d 6996415: Override bridges causes compiler-generated code to end up with synthetic infinite loop Summary: temporarily disable fix for override bridges (6337171) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! test/tools/javac/generics/OverrideBridge.java Changeset: fadc6d3e63f4 Author: mcimadamore Date: 2010-11-02 12:01 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fadc6d3e63f4 6939780: add a warning to detect diamond sites Summary: added hidden compiler flag '-XDfindDiamond' to detect 'diamondifiable' sites Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/DiamondRedundantArgs.java + test/tools/javac/diags/examples/DiamondRedundantArgs1.java + test/tools/javac/generics/diamond/T6939780.java + test/tools/javac/generics/diamond/T6939780.out From vincent.x.ryan at oracle.com Tue Nov 2 15:07:35 2010 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 02 Nov 2010 15:07:35 +0000 Subject: hg: jdk7/tl/jdk: 6945529: Apply fix for CR 6921001 to platform-specific java.security configuration files Message-ID: <20101102150745.9807347652@hg.openjdk.java.net> Changeset: e127cb5c2fbd Author: vinnie Date: 2010-11-02 15:04 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e127cb5c2fbd 6945529: Apply fix for CR 6921001 to platform-specific java.security configuration files Reviewed-by: mullan ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows From alan.bateman at oracle.com Tue Nov 2 18:42:51 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 02 Nov 2010 18:42:51 +0000 Subject: hg: jdk7/tl/corba: 6996740: Yet more breakage caused by 6891766 Message-ID: <20101102184252.902914766F@hg.openjdk.java.net> Changeset: 76aeef3afc04 Author: alanb Date: 2010-11-02 18:27 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/76aeef3afc04 6996740: Yet more breakage caused by 6891766 Summary: Restore com.sun.corba.se.simpl.io.IIOPInputStream that 6891766 nuked in error Reviewed-by: asaha ! make/com/sun/corba/minclude/com_sun_corba_se_impl_io.jmk + src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java From kumar.x.srinivasan at oracle.com Tue Nov 2 21:10:44 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 02 Nov 2010 14:10:44 -0700 Subject: Please review java.util.jar.pack.* exceptions Message-ID: <4CD07E54.3040603@oracle.COM> Hi, These are simple changes to the java.util.jar.pack: * fixes JCK failures, specifically throwing unexpected exceptions * minor fixes to the ClassFormatException * added a new test to catch the JCK type failures up-front, which is bulk of the code changes. http://cr.openjdk.java.net/~ksrini/6985763/webrev.00/ Thanks Kumar From john.r.rose at oracle.com Tue Nov 2 22:03:16 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 2 Nov 2010 15:03:16 -0700 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: <4CD07E54.3040603@oracle.COM> References: <4CD07E54.3040603@oracle.COM> Message-ID: On Nov 2, 2010, at 2:10 PM, Kumar Srinivasan wrote: > These are simple changes to the java.util.jar.pack: > * fixes JCK failures, specifically throwing unexpected exceptions > * minor fixes to the ClassFormatException > * added a new test to catch the JCK type failures up-front, which is > bulk of the code changes. > > http://cr.openjdk.java.net/~ksrini/6985763/webrev.00/ That's good; reviewed. -- John From mike.duigou at oracle.com Tue Nov 2 22:04:10 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 2 Nov 2010 15:04:10 -0700 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: <4CD07E54.3040603@oracle.COM> References: <4CD07E54.3040603@oracle.COM> Message-ID: - ClassReader.java: I think the change of the copyright date is incorrect. It should be "2001, 2005, 2010" or "2001, 2005-2010". - In PackerImpl if the exception thrown is an IOException it is not re-thrown. By not initializing inFiles this code path would have been seen as "inFiles not initialized" at the inFiles.size() expression. Mike On Nov 2 2010, at 14:10 , Kumar Srinivasan wrote: > Hi, > > These are simple changes to the java.util.jar.pack: > * fixes JCK failures, specifically throwing unexpected exceptions > * minor fixes to the ClassFormatException > * added a new test to catch the JCK type failures up-front, which is > bulk of the code changes. > > http://cr.openjdk.java.net/~ksrini/6985763/webrev.00/ > > Thanks > Kumar > From john.r.rose at oracle.com Tue Nov 2 22:12:30 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 2 Nov 2010 15:12:30 -0700 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: References: <4CD07E54.3040603@oracle.COM> Message-ID: <7DE635AE-892B-4E77-A209-32DDC7C4967E@oracle.com> On Nov 2, 2010, at 3:04 PM, Mike Duigou wrote: > - ClassReader.java: I think the change of the copyright date is incorrect. It should be "2001, 2005, 2010" or "2001, 2005-2010". Standard Oracle copyright format has just the first and last year, no ranges and no other years. -- John From David.Holmes at oracle.com Wed Nov 3 01:28:44 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 03 Nov 2010 11:28:44 +1000 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: References: <4CD07E54.3040603@oracle.COM> Message-ID: <4CD0BACC.7030201@oracle.com> On 3/11/2010 8:04 AM, Mike Duigou wrote: > - In PackerImpl if the exception thrown is an IOException it is not > re-thrown. By not initializing inFiles this code path would have been > seen as "inFiles not initialized" at the inFiles.size() expression. Also a minor nit in UnpackerImpl: 91 * @param in an InputStream. 92 * @param out a JarOutputStream. 93 * @exception IOException if an error is encountered. 94 */ 95 public void unpack(InputStream in0, JarOutputStream out) throws IOException { the "@param in" should be "@param in0". Further for both modified methods the NullPointerException should have an accompanying @throws doc comment. David > Mike > > > On Nov 2 2010, at 14:10 , Kumar Srinivasan wrote: > >> Hi, >> >> These are simple changes to the java.util.jar.pack: * fixes JCK >> failures, specifically throwing unexpected exceptions * minor fixes to >> the ClassFormatException * added a new test to catch the JCK type >> failures up-front, which is bulk of the code changes. >> >> http://cr.openjdk.java.net/~ksrini/6985763/webrev.00/ >> >> Thanks Kumar >> > From Alan.Bateman at oracle.com Wed Nov 3 11:50:03 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 03 Nov 2010 11:50:03 +0000 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: <4CD07E54.3040603@oracle.COM> References: <4CD07E54.3040603@oracle.COM> Message-ID: <4CD14C6B.3040409@oracle.com> Kumar Srinivasan wrote: > Hi, > > These are simple changes to the java.util.jar.pack: > * fixes JCK failures, specifically throwing unexpected exceptions > * minor fixes to the ClassFormatException > * added a new test to catch the JCK type failures up-front, which is > bulk of the code changes. > > http://cr.openjdk.java.net/~ksrini/6985763/webrev.00/ > > Thanks > Kumar > Kumar - would it be better if scanJar just handled the closed JAR case by catching the IllegalStateException and re-throwing it as an IOException? I assume other runtime exceptions are other bugs that you won't have translated into I/O exceptions. -Alan. From kumar.x.srinivasan at oracle.com Wed Nov 3 13:28:47 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 03 Nov 2010 06:28:47 -0700 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: <4CD14C6B.3040409@oracle.com> References: <4CD07E54.3040603@oracle.COM> <4CD14C6B.3040409@oracle.com> Message-ID: <4CD1638F.3040205@oracle.COM> I will look into incorporating all the comments, watch out for the next version. Kumar > Kumar Srinivasan wrote: >> Hi, >> >> These are simple changes to the java.util.jar.pack: >> * fixes JCK failures, specifically throwing unexpected exceptions >> * minor fixes to the ClassFormatException >> * added a new test to catch the JCK type failures up-front, which is >> bulk of the code changes. >> >> http://cr.openjdk.java.net/~ksrini/6985763/webrev.00/ >> >> Thanks >> Kumar >> > Kumar - would it be better if scanJar just handled the closed JAR case > by catching the IllegalStateException and re-throwing it as an > IOException? I assume other runtime exceptions are other bugs that you > won't have translated into I/O exceptions. > > -Alan. From kumar.x.srinivasan at oracle.COM Wed Nov 3 22:12:34 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 03 Nov 2010 15:12:34 -0700 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: <4CD14C6B.3040409@oracle.com> References: <4CD07E54.3040603@oracle.COM> <4CD14C6B.3040409@oracle.com> Message-ID: <4CD1DE52.1000401@oracle.COM> Thanks for all the reviews and suggestions! the new version is at: http://cr.openjdk.java.net/~ksrini/6985763/webrev.01 In this revision: 1. the input parameter is renamed to "in", btw. we call out throwing of NPEs at the package level documentation http://download.oracle.com/javase/6/docs/api/java/util/jar/Pack200.html I copied the same verbiage to the interfaces sections as well. 2. moved the exception check into scanJar, per Alan's suggestion where it is isolated to catch IllegalStateException and wraps it up into an IOE. Thanks Kumar > Kumar Srinivasan wrote: >> Hi, >> >> These are simple changes to the java.util.jar.pack: >> * fixes JCK failures, specifically throwing unexpected exceptions >> * minor fixes to the ClassFormatException >> * added a new test to catch the JCK type failures up-front, which is >> bulk of the code changes. >> >> http://cr.openjdk.java.net/~ksrini/6985763/webrev.00/ >> >> Thanks >> Kumar >> > Kumar - would it be better if scanJar just handled the closed JAR case > by catching the IllegalStateException and re-throwing it as an > IOException? I assume other runtime exceptions are other bugs that you > won't have translated into I/O exceptions. > > -Alan. From mandy.chung at oracle.com Wed Nov 3 22:21:31 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 03 Nov 2010 15:21:31 -0700 Subject: Code Review Request for 6720170: ByteArrayInputStream.skip(long) can overflow internally Message-ID: <4CD1E06B.1000005@oracle.com> 6720170: ByteArrayInputStream.skip(long) can overflow internally Webrev at: http://cr.openjdk.java.net/~mchung/6720170/webrev.00/ This fixes the read method and the skip method of ByteArrayInputStream to be overflow conscious. Thanks Mandy From David.Holmes at oracle.com Wed Nov 3 22:22:06 2010 From: David.Holmes at oracle.com (David Holmes - Oracle) Date: Thu, 04 Nov 2010 09:22:06 +1100 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: <4CD1DE52.1000401@oracle.COM> References: <4CD07E54.3040603@oracle.COM> <4CD14C6B.3040409@oracle.com> <4CD1DE52.1000401@oracle.COM> Message-ID: <4CD1E08E.8060500@oracle.com> Hi Kumar, This looks okay to me. I prefer this form - only converting the IllegalStateException - as well. David On 11/04/10 09:12, Kumar Srinivasan wrote: > Thanks for all the reviews and suggestions! > > the new version is at: > http://cr.openjdk.java.net/~ksrini/6985763/webrev.01 > > In this revision: > 1. the input parameter is renamed to "in", > btw. we call out throwing of NPEs at the package level documentation > > http://download.oracle.com/javase/6/docs/api/java/util/jar/Pack200.html > I copied the same verbiage to the interfaces sections as well. > > 2. moved the exception check into scanJar, per Alan's suggestion > where it is > isolated to catch IllegalStateException and wraps it up into an IOE. > > > Thanks > Kumar > >> Kumar Srinivasan wrote: >>> Hi, >>> >>> These are simple changes to the java.util.jar.pack: >>> * fixes JCK failures, specifically throwing unexpected exceptions >>> * minor fixes to the ClassFormatException >>> * added a new test to catch the JCK type failures up-front, which is >>> bulk of the code changes. >>> >>> http://cr.openjdk.java.net/~ksrini/6985763/webrev.00/ >>> >>> Thanks >>> Kumar >>> >> Kumar - would it be better if scanJar just handled the closed JAR >> case by catching the IllegalStateException and re-throwing it as an >> IOException? I assume other runtime exceptions are other bugs that >> you won't have translated into I/O exceptions. >> >> -Alan. > From mike.duigou at oracle.com Wed Nov 3 22:32:16 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 3 Nov 2010 15:32:16 -0700 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: <4CD1DE52.1000401@oracle.COM> References: <4CD07E54.3040603@oracle.COM> <4CD14C6B.3040409@oracle.com> <4CD1DE52.1000401@oracle.COM> Message-ID: Looks good. - You may want to consider using getLocalizedMessage() rather than getMessage(). If there is a localized version of the IllegalStateException message then the result will be a stack dump that begins with the unlocalized version of the message followed by a "Caused by" section which will display the localized version. Mike On Nov 3 2010, at 15:12 , Kumar Srinivasan wrote: > Thanks for all the reviews and suggestions! > > the new version is at: > http://cr.openjdk.java.net/~ksrini/6985763/webrev.01 > > In this revision: > 1. the input parameter is renamed to "in", > btw. we call out throwing of NPEs at the package level documentation > http://download.oracle.com/javase/6/docs/api/java/util/jar/Pack200.html > I copied the same verbiage to the interfaces sections as well. > > 2. moved the exception check into scanJar, per Alan's suggestion where it is > isolated to catch IllegalStateException and wraps it up into an IOE. > > > Thanks > Kumar > >> Kumar Srinivasan wrote: >>> Hi, >>> >>> These are simple changes to the java.util.jar.pack: >>> * fixes JCK failures, specifically throwing unexpected exceptions >>> * minor fixes to the ClassFormatException >>> * added a new test to catch the JCK type failures up-front, which is >>> bulk of the code changes. >>> >>> http://cr.openjdk.java.net/~ksrini/6985763/webrev.00/ >>> >>> Thanks >>> Kumar >>> >> Kumar - would it be better if scanJar just handled the closed JAR case by catching the IllegalStateException and re-throwing it as an IOException? I assume other runtime exceptions are other bugs that you won't have translated into I/O exceptions. >> >> -Alan. > From mandy.chung at oracle.com Thu Nov 4 02:32:32 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 03 Nov 2010 19:32:32 -0700 Subject: Code Review Request for 6720170: ByteArrayInputStream.skip(long) can overflow internally In-Reply-To: <4CD1E06B.1000005@oracle.com> References: <4CD1E06B.1000005@oracle.com> Message-ID: <4CD21B40.6000801@oracle.com> New webrev at: http://cr.openjdk.java.net/~mchung/6720170/webrev.01/ that implements a simpler fix that David suggests (thanks). Mandy On 11/3/10 3:21 PM, Mandy Chung wrote: > 6720170: ByteArrayInputStream.skip(long) can overflow internally > > Webrev at: > http://cr.openjdk.java.net/~mchung/6720170/webrev.00/ > > This fixes the read method and the skip method of ByteArrayInputStream > to be overflow conscious. > > Thanks > Mandy From David.Holmes at oracle.com Thu Nov 4 08:02:42 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 04 Nov 2010 18:02:42 +1000 Subject: Code Review Request for 6720170: ByteArrayInputStream.skip(long) can overflow internally In-Reply-To: <4CD21B40.6000801@oracle.com> References: <4CD1E06B.1000005@oracle.com> <4CD21B40.6000801@oracle.com> Message-ID: <4CD268A2.6060105@oracle.com> Hi Mandy, Looks ok. Thanks, David On 4/11/2010 12:32 PM, Mandy Chung wrote: > New webrev at: > http://cr.openjdk.java.net/~mchung/6720170/webrev.01/ > > that implements a simpler fix that David suggests (thanks). > > Mandy > > On 11/3/10 3:21 PM, Mandy Chung wrote: >> 6720170: ByteArrayInputStream.skip(long) can overflow internally >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/6720170/webrev.00/ >> >> This fixes the read method and the skip method of ByteArrayInputStream to >> be overflow conscious. >> >> Thanks >> Mandy > From Alan.Bateman at oracle.com Thu Nov 4 10:53:03 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Nov 2010 10:53:03 +0000 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: <4CD1DE52.1000401@oracle.COM> References: <4CD07E54.3040603@oracle.COM> <4CD14C6B.3040409@oracle.com> <4CD1DE52.1000401@oracle.COM> Message-ID: <4CD2908F.7090106@oracle.com> Kumar Srinivasan wrote: > Thanks for all the reviews and suggestions! > > the new version is at: > http://cr.openjdk.java.net/~ksrini/6985763/webrev.01 > > In this revision: > 1. the input parameter is renamed to "in", > btw. we call out throwing of NPEs at the package level documentation > > http://download.oracle.com/javase/6/docs/api/java/util/jar/Pack200.html > I copied the same verbiage to the interfaces sections as well. > > 2. moved the exception check into scanJar, per Alan's suggestion > where it is > isolated to catch IllegalStateException and wraps it up into an IOE. > > > Thanks > Kumar This looks much better. It may be slightly better to limit the handling of the IllegalStateException to just the call to the JarFile's entries method but I can't see anything else that might throw it so what you have is fine with me. On the test, I notice you compile with -XDignore.symbol.file but I don't think that is needed. Also, it might be better to eliminate the reference to a JCK test. -Alan. From Alan.Bateman at oracle.com Thu Nov 4 10:59:41 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Nov 2010 10:59:41 +0000 Subject: Code Review Request for 6720170: ByteArrayInputStream.skip(long) can overflow internally In-Reply-To: <4CD21B40.6000801@oracle.com> References: <4CD1E06B.1000005@oracle.com> <4CD21B40.6000801@oracle.com> Message-ID: <4CD2921D.8070005@oracle.com> Mandy Chung wrote: > New webrev at: > http://cr.openjdk.java.net/~mchung/6720170/webrev.01/ > > that implements a simpler fix that David suggests (thanks). > > Mandy This looks good to me too, and thanks for taking it and including a useful test. -Alan. From chris.hegarty at oracle.com Thu Nov 4 11:44:05 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 04 Nov 2010 11:44:05 +0000 Subject: Code Review 6988618: JCK test setDaemon0101 hangs on specific machine Message-ID: <4CD29C85.6000206@oracle.com> David, Alan, There is a race, if the thread being created completes before the starting thread has a chance to complete its start method ( and decrement the groups nUnstartedThreads count ), then when the newly started threads exit method notifies the group that it is terminating the group will not be destroyed because it believes it still as an unstarted thread in it. Basically we decrement the unstarted thread count in threadStarting. Since the thread is added to the group the reason for the unstarted thread count is no longer applicable, i.e. the thread is a real member of the group. We rectify the unstarted thread count if start fails, allowing a subsequent attempt to start the thread (this is consistent with current behavior). Webrev: http://cr.openjdk.java.net/~chegar/6988618/webrev.00/webrev/ Thanks, -Chris. From David.Holmes at oracle.com Thu Nov 4 11:44:36 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 04 Nov 2010 21:44:36 +1000 Subject: Code Review 6988618: JCK test setDaemon0101 hangs on specific machine In-Reply-To: <4CD29C85.6000206@oracle.com> References: <4CD29C85.6000206@oracle.com> Message-ID: <4CD29CA4.9070804@oracle.com> Chris, Looks good to me. Thanks, David On 4/11/2010 9:44 PM, Chris Hegarty wrote: > David, Alan, > > There is a race, if the thread being created completes before the starting > thread has a chance to complete its start method ( and decrement the groups > nUnstartedThreads count ), then when the newly started threads exit method > notifies the group that it is terminating the group will not be destroyed > because it believes it still as an unstarted thread in it. > > Basically we decrement the unstarted thread count in threadStarting. > Since the thread is added to the group the reason for the unstarted > thread count is no longer applicable, i.e. the thread is a real member > of the group. We rectify the unstarted thread count if start fails, > allowing a subsequent attempt to start the thread (this is consistent > with current behavior). > > Webrev: > http://cr.openjdk.java.net/~chegar/6988618/webrev.00/webrev/ > > Thanks, > -Chris. From Alan.Bateman at oracle.com Thu Nov 4 12:13:23 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Nov 2010 12:13:23 +0000 Subject: Code Review 6988618: JCK test setDaemon0101 hangs on specific machine In-Reply-To: <4CD29C85.6000206@oracle.com> References: <4CD29C85.6000206@oracle.com> Message-ID: <4CD2A363.9070904@oracle.com> Chris Hegarty wrote: > David, Alan, > > There is a race, if the thread being created completes before the > starting thread has a chance to complete its start method ( and > decrement the groups nUnstartedThreads count ), then when the newly > started threads exit method notifies the group that it is terminating > the group will not be destroyed because it believes it still as an > unstarted thread in it. > > Basically we decrement the unstarted thread count in threadStarting. > Since the thread is added to the group the reason for the unstarted > thread count is no longer applicable, i.e. the thread is a real member > of the group. We rectify the unstarted thread count if start fails, > allowing a subsequent attempt to start the thread (this is consistent > with current behavior). > > Webrev: > http://cr.openjdk.java.net/~chegar/6988618/webrev.00/webrev/ > > Thanks, > -Chris. Looks good to me. Do you think it would be feasible to include a regression test or would it be too problematic? -Alan From maurizio.cimadamore at oracle.com Thu Nov 4 13:00:56 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 04 Nov 2010 13:00:56 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20101104130102.183B8476D7@hg.openjdk.java.net> Changeset: f2048d9c666e Author: mcimadamore Date: 2010-11-04 12:57 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f2048d9c666e 6993963: Project Coin: Use precise exception analysis for effectively final catch parameters Summary: More precise rethrow analysis should be extended to effectively-final exception parameters. Multicatch parameters should be made implicitly final. Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/code/Flags.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/resources/compiler.properties - test/tools/javac/diags/examples/MulticatchMustBeFinal.java + test/tools/javac/multicatch/Neg01eff_final.java + test/tools/javac/multicatch/Neg01eff_final.out ! test/tools/javac/multicatch/Neg02.java ! test/tools/javac/multicatch/Neg02.out + test/tools/javac/multicatch/Neg02eff_final.java + test/tools/javac/multicatch/Neg02eff_final.out ! test/tools/javac/multicatch/Neg03.java ! test/tools/javac/multicatch/Neg03.out + test/tools/javac/multicatch/Neg04eff_final.java + test/tools/javac/multicatch/Neg04eff_final.out + test/tools/javac/multicatch/Neg05.java + test/tools/javac/multicatch/Neg05.out + test/tools/javac/multicatch/Pos06.java + test/tools/javac/multicatch/Pos07.java + test/tools/javac/multicatch/model/Check.java + test/tools/javac/multicatch/model/Member.java + test/tools/javac/multicatch/model/Model01.java + test/tools/javac/multicatch/model/ModelChecker.java Changeset: e9e41c88b03e Author: mcimadamore Date: 2010-11-04 12:58 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e9e41c88b03e 6714835: Safe cast is rejected (with warning) by javac Summary: Rules for unchecked cast conversion do not take into account type-containment Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/cast/6467183/T6467183a.out + test/tools/javac/cast/6714835/T6714835.java + test/tools/javac/cast/6714835/T6714835.out From kumar.x.srinivasan at oracle.COM Thu Nov 4 13:03:04 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 04 Nov 2010 06:03:04 -0700 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: <4CD2908F.7090106@oracle.com> References: <4CD07E54.3040603@oracle.COM> <4CD14C6B.3040409@oracle.com> <4CD1DE52.1000401@oracle.COM> <4CD2908F.7090106@oracle.com> Message-ID: <4CD2AF08.4040808@oracle.COM> On 11/4/2010 3:53 AM, Alan Bateman wrote: > Kumar Srinivasan wrote: >> Thanks for all the reviews and suggestions! >> >> the new version is at: >> http://cr.openjdk.java.net/~ksrini/6985763/webrev.01 >> >> In this revision: >> 1. the input parameter is renamed to "in", >> btw. we call out throwing of NPEs at the package level >> documentation >> >> http://download.oracle.com/javase/6/docs/api/java/util/jar/Pack200.html >> I copied the same verbiage to the interfaces sections as well. >> >> 2. moved the exception check into scanJar, per Alan's suggestion >> where it is >> isolated to catch IllegalStateException and wraps it up into an IOE. >> >> >> Thanks >> Kumar > This looks much better. It may be slightly better to limit the > handling of the IllegalStateException to just the call to the > JarFile's entries method but I can't see anything else that might > throw it so what you have is fine with me. > > On the test, I notice you compile with -XDignore.symbol.file but I > don't think that is needed. Also, it might be better No the -XD is needed the Utils.java is dependent on sun.* apis, which will not be accessible when compiling and testing with a built SDK, which is required for Pack200 testing. > to eliminate the reference to a JCK test. ok will yank it out, and will also use the getLocalizedMessage to get the exception message per Mike's suggestion. Do you guys need to see another webrev revision ? Kumar > > -Alan. From Alan.Bateman at oracle.com Thu Nov 4 13:37:10 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Nov 2010 13:37:10 +0000 Subject: Please review java.util.jar.pack.* exceptions In-Reply-To: <4CD2AF08.4040808@oracle.COM> References: <4CD07E54.3040603@oracle.COM> <4CD14C6B.3040409@oracle.com> <4CD1DE52.1000401@oracle.COM> <4CD2908F.7090106@oracle.com> <4CD2AF08.4040808@oracle.COM> Message-ID: <4CD2B706.3020809@oracle.com> Kumar Srinivasan wrote: > No the -XD is needed the Utils.java is dependent on sun.* apis, > which will not be accessible when compiling and testing with a built > SDK, which is required for Pack200 testing. Sorry, I missed that (Utils.java isn't changed and so isn't in the webrev). > > ok will yank it out, and will also use the getLocalizedMessage to get > the exception message per Mike's suggestion. > > Do you guys need to see another webrev revision ? I think you'll all set. -Alan. From ptisnovs at redhat.com Thu Nov 4 14:09:14 2010 From: ptisnovs at redhat.com (ptisnovs at redhat.com) Date: Thu, 04 Nov 2010 14:09:14 +0000 Subject: hg: jdk7/tl/hotspot: 6997495: correction of regression test compiler/6857159/Test6857159 Message-ID: <20101104140916.AE6EE476DA@hg.openjdk.java.net> Changeset: 086898a88056 Author: ptisnovs Date: 2010-11-04 14:03 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/086898a88056 6997495: correction of regression test compiler/6857159/Test6857159 Summary: Testcase correction. Reviewed-by: never ! test/compiler/6857159/Test6857159.java From chris.hegarty at oracle.com Thu Nov 4 14:57:24 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 04 Nov 2010 14:57:24 +0000 Subject: Code Review 6988618: JCK test setDaemon0101 hangs on specific machine In-Reply-To: <4CD2A363.9070904@oracle.com> References: <4CD29C85.6000206@oracle.com> <4CD2A363.9070904@oracle.com> Message-ID: <4CD2C9D4.90300@oracle.com> On 04/11/2010 12:13, Alan Bateman wrote: > Chris Hegarty wrote: >> David, Alan, >> >> There is a race, if the thread being created completes before the >> starting thread has a chance to complete its start method ( and >> decrement the groups nUnstartedThreads count ), then when the newly >> started threads exit method notifies the group that it is terminating >> the group will not be destroyed because it believes it still as an >> unstarted thread in it. >> >> Basically we decrement the unstarted thread count in threadStarting. >> Since the thread is added to the group the reason for the unstarted >> thread count is no longer applicable, i.e. the thread is a real member >> of the group. We rectify the unstarted thread count if start fails, >> allowing a subsequent attempt to start the thread (this is consistent >> with current behavior). >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/6988618/webrev.00/webrev/ >> >> Thanks, >> -Chris. > Looks good to me. Do you think it would be feasible to include a > regression test or would it be too problematic? Creating a reliable test would be problematic. I'll proceed with the changes as they are. Thanks for the review. -Chris. > > -Alan From mandy.chung at oracle.com Thu Nov 4 21:20:15 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 04 Nov 2010 21:20:15 +0000 Subject: hg: jdk7/tl/jdk: 6720170: ByteArrayInputStream.skip(long) can overflow internally Message-ID: <20101104212032.BF8FC476F0@hg.openjdk.java.net> Changeset: 4983c4edc535 Author: mchung Date: 2010-11-04 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4983c4edc535 6720170: ByteArrayInputStream.skip(long) can overflow internally Reviewed-by: dholmes, alanb ! src/share/classes/java/io/ByteArrayInputStream.java + test/java/io/ByteArrayInputStream/Skip.java From mandy.chung at oracle.com Thu Nov 4 21:43:01 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 04 Nov 2010 21:43:01 +0000 Subject: hg: jdk7/tl/jdk: 6985875: Change servicetags registration to refer to Oracle SSO and MSO 5.2 release Message-ID: <20101104214310.AE730476F2@hg.openjdk.java.net> Changeset: bc7d400cd749 Author: mchung Date: 2010-11-04 14:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc7d400cd749 6985875: Change servicetags registration to refer to Oracle SSO and MSO 5.2 release Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/com/sun/servicetag/resources/register.html ! src/share/classes/com/sun/servicetag/resources/register_ja.html ! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html From chris.hegarty at oracle.com Fri Nov 5 09:07:54 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 05 Nov 2010 09:07:54 +0000 Subject: hg: jdk7/tl/jdk: 6988618: JCK test setDaemon0101 hangs on specific machine Message-ID: <20101105090815.8F91447721@hg.openjdk.java.net> Changeset: 8e5c27614fec Author: chegar Date: 2010-11-05 09:07 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8e5c27614fec 6988618: JCK test setDaemon0101 hangs on specific machine Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java From sean.coffey at oracle.com Fri Nov 5 13:50:45 2010 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 05 Nov 2010 13:50:45 +0000 Subject: hg: jdk7/tl/jdk: 6696028: JMXServiceURL like service:jmx:rmi:///jndi/iiop:// should be rejected by the RMI conn provider.; ... Message-ID: <20101105135105.A8FCA4772C@hg.openjdk.java.net> Changeset: aed81a97aae3 Author: coffeys Date: 2010-11-05 13:52 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aed81a97aae3 6696028: JMXServiceURL like service:jmx:rmi:///jndi/iiop:// should be rejected by the RMI conn provider. 6984520: NPE IN RMIConnector.connect Reviewed-by: emcmanus, kevinw ! src/share/classes/javax/management/remote/rmi/RMIConnector.java + test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java From assembling.signals at yandex.ru Fri Nov 5 14:57:03 2010 From: assembling.signals at yandex.ru (assembling signals) Date: Fri, 05 Nov 2010 15:57:03 +0100 Subject: micro-RFE for java.dyn Message-ID: <196191288969024@web33.yandex.ru> Hello, everyone! Sorry, not sure if it's the right mailinglist, here [ http://mail.openjdk.java.net/mailman/listinfo ] there were no mailinglist listed for java.dyn. I have a little RFE for java.dyn.Linkage. Could it be possible to add another "registerBootstrapMethod(...)" method which would accept Runnable as parameter instead of String. This would have two litte advantages: 1) If would be refactoring-proof (normally, renaming of bootstrap method would depend on also renaming the string argument); 2) There would be no warning about some unused private static method. Best regards, Ivan G S From lana.steuck at oracle.com Fri Nov 5 15:20:32 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Nov 2010 15:20:32 +0000 Subject: hg: jdk7/tl/corba: 4 new changesets Message-ID: <20101105152035.9DB8147732@hg.openjdk.java.net> Changeset: da7561d479e0 Author: cl Date: 2010-10-14 19:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/da7561d479e0 Added tag jdk7-b114 for changeset 88fddb73c5c4 ! .hgtags Changeset: 98c028de4301 Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/98c028de4301 Added tag jdk7-b115 for changeset da7561d479e0 ! .hgtags Changeset: fa502e4834da Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/fa502e4834da Added tag jdk7-b116 for changeset 98c028de4301 ! .hgtags Changeset: 8260ec509a10 Author: lana Date: 2010-11-04 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/8260ec509a10 Merge From lana.steuck at oracle.com Fri Nov 5 15:20:46 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Nov 2010 15:20:46 +0000 Subject: hg: jdk7/tl: 11 new changesets Message-ID: <20101105152046.49A9947733@hg.openjdk.java.net> Changeset: 73c9023ae9b0 Author: cl Date: 2010-10-14 19:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/73c9023ae9b0 Added tag jdk7-b114 for changeset 27985a5c6e52 ! .hgtags Changeset: 1fa39984ba8c Author: igor Date: 2010-09-03 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/1fa39984ba8c 6978977: Productivity: use ant for java part of build Reviewed-by: mduigou, herrick, ohair, ngthomas ! .hgignore ! make/deploy-rules.gmk Changeset: 85736b9f2026 Author: herrick Date: 2010-09-17 07:08 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/85736b9f2026 Merge Changeset: d4a7e4600b21 Author: herrick Date: 2010-09-17 07:10 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/d4a7e4600b21 Merge Changeset: 810a461889ab Author: igor Date: 2010-09-28 10:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/810a461889ab 6982520: Move kernel to install ws Reviewed-by: herrick, billyh ! make/deploy-rules.gmk Changeset: 2a7813a9b529 Author: herrick Date: 2010-10-02 11:08 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/2a7813a9b529 Merge Changeset: fd3a1c515903 Author: jqzuo Date: 2010-10-04 16:36 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/fd3a1c515903 6983855: The jre combo bundle target needs to be added in the makefile Reviewed-by: billyh, paulk ! make/install-rules.gmk Changeset: 5cc9bb94398a Author: jqzuo Date: 2010-10-12 13:29 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/5cc9bb94398a Merge Changeset: e8ebdf41b9c0 Author: jqzuo Date: 2010-10-18 11:13 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/e8ebdf41b9c0 Merge Changeset: 94e9a1bfba8b Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/94e9a1bfba8b Added tag jdk7-b115 for changeset e8ebdf41b9c0 ! .hgtags Changeset: 7220e60b097f Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/7220e60b097f Added tag jdk7-b116 for changeset 94e9a1bfba8b ! .hgtags From lana.steuck at oracle.com Fri Nov 5 15:21:14 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Nov 2010 15:21:14 +0000 Subject: hg: jdk7/tl/hotspot: 49 new changesets Message-ID: <20101105152241.E018647734@hg.openjdk.java.net> Changeset: 477faa484f91 Author: cl Date: 2010-10-14 19:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/477faa484f91 Added tag jdk7-b114 for changeset 68d6141ea19d ! .hgtags Changeset: 1c52033222eb Author: trims Date: 2010-10-01 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1c52033222eb Added tag hs20-b01 for changeset 5511edd5d719 ! .hgtags Changeset: c77e8f982901 Author: never Date: 2010-09-15 20:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c77e8f982901 6984979: OptimizeFill misses some cases with an odd memory graph Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: fd5d4527cdf5 Author: iveresov Date: 2010-09-21 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fd5d4527cdf5 6986270: guarantee(*bcp != Bytecodes::_monitorenter || exec_mode != Deoptimization::Unpack_exception) fails Summary: Propagate the compiler type of the deopting method to vframeArrayElement::unpack_on_stack() Reviewed-by: jrose, never ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 5867d89c129b Author: never Date: 2010-09-22 13:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5867d89c129b 6982537: Crash in Node*step_through_mergemem Reviewed-by: kvn ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/memnode.cpp Changeset: 87b64980e2f1 Author: never Date: 2010-09-22 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/87b64980e2f1 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld Reviewed-by: kvn ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp Changeset: c40600e85311 Author: never Date: 2010-09-22 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c40600e85311 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub Reviewed-by: kvn, twisti ! src/share/vm/opto/stringopts.cpp Changeset: c93c652551b5 Author: twisti Date: 2010-09-24 03:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c93c652551b5 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site Reviewed-by: never, kvn ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/ci/ciMethod.cpp Changeset: f02a8bbe6ed4 Author: roland Date: 2009-12-29 19:08 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f02a8bbe6ed4 6986046: C1 valuestack cleanup Summary: fixes an historical oddity in C1 with inlining where all of the expression stacks are kept in the topmost ValueStack instead of being in their respective ValueStacks. Reviewed-by: never Contributed-by: Christian Wimmer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.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_LIR.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/includeDB_compiler1 Changeset: 861f533d12b0 Author: roland Date: 2010-09-24 13:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/861f533d12b0 Merge Changeset: df015ec64052 Author: iveresov Date: 2010-09-27 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/df015ec64052 6987115: Non-tiered compilation policy creates unnecessary C1 threads Summary: Fixed NonTieredCompPolicy::compiler_count() to return correct thread count. Reviewed-by: twisti, kvn ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 1375bc8922e4 Author: never Date: 2010-09-27 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1375bc8922e4 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified Reviewed-by: roland, kvn, iveresov ! src/share/vm/c1/c1_ValueStack.hpp Changeset: 8aa5fd5d2046 Author: twisti Date: 2010-09-29 00:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8aa5fd5d2046 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument Reviewed-by: never, kvn ! src/share/vm/opto/doCall.cpp Changeset: ad0638ff8ea4 Author: roland Date: 2010-09-29 18:53 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ad0638ff8ea4 6988303: 6986046 breaks build with recent gcc Summary: fixes build break Reviewed-by: never, kvn ! src/share/vm/c1/c1_Instruction.hpp Changeset: 80c9354976b0 Author: iveresov Date: 2010-09-29 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/80c9354976b0 6988346: 6986046 breaks tiered Summary: adjusted profiling code generation to use the new ValueStack implementation; lowered optimization level for c1_LinearScan.cpp on solaris x64. Reviewed-by: kvn, never ! make/solaris/makefiles/amd64.make ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 56601ef83436 Author: kvn Date: 2010-09-30 18:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/56601ef83436 6916062: assert(_inserts <= _insert_limit,"hash table overflow") in NodeHash::hash_insert Summary: Missing check for not empty worklist when puting memory node back on worklist and expecting address type update. Reviewed-by: never ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp Changeset: 52e82a6bedaf Author: never Date: 2010-10-04 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/52e82a6bedaf 6968348: Byteswapped memory access can point to wrong location after JIT Reviewed-by: twisti, kvn, iveresov ! src/cpu/x86/vm/x86_64.ad + test/compiler/6968348/Test6968348.java Changeset: 3f9a70eb8b1f Author: iveresov Date: 2010-10-05 00:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f9a70eb8b1f 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux Summary: Fix ciMethod::instructions_size() to return correct value Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp Changeset: fe08403130db Author: kvn Date: 2010-10-05 08:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fe08403130db 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big Summary: Set upper limit 256 for ObjectAlignmentInBytes value. Reviewed-by: never, iveresov ! src/share/vm/runtime/arguments.cpp Changeset: a3f7f95b0165 Author: never Date: 2010-10-05 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a3f7f95b0165 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler Reviewed-by: iveresov, kvn, kamg ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: a50abfc67f31 Author: never Date: 2010-10-05 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a50abfc67f31 6989736: fix mapfile warnings on solaris Reviewed-by: kvn, iveresov, jcoomes ! make/linux/adlc_updater ! make/solaris/adlc_updater ! make/solaris/makefiles/reorder_COMPILER1_i486 ! make/solaris/makefiles/reorder_COMPILER1_sparc ! make/solaris/makefiles/reorder_TIERED_amd64 ! make/solaris/makefiles/reorder_TIERED_i486 ! make/solaris/makefiles/reorder_TIERED_sparc ! make/solaris/makefiles/reorder_TIERED_sparcv9 Changeset: 22e4420d19f7 Author: kvn Date: 2010-10-06 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/22e4420d19f7 Merge ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 8b10f48633dc Author: jmasa Date: 2010-09-20 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8b10f48633dc 6984287: Regularize how GC parallel workers are specified. Summary: Associate number of GC workers with the workgang as opposed to the task. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.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/g1RemSet.cpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 22cace5e30b5 Author: jcoomes Date: 2010-09-08 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/22cace5e30b5 6983296: build sanity checks for jdk7 should require SS12u1 Reviewed-by: ohair ! make/solaris/makefiles/sparcWorks.make Changeset: 4805b9f4779e Author: johnc Date: 2010-09-28 09:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4805b9f4779e 6941395: G1: Use only lock-free versions of region stack push() and pop() Summary: Re-enable use of the lock-free versions of region stack push() and pop() by recording aborted regions in a thread-local structure, which are then processed when scanning of the region stack restarts. The previous locking versions of these routines are retained for diagnostic purposes. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 894b1d7c7e01 Author: jcoomes Date: 2010-09-28 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/894b1d7c7e01 6423256: GC stacks should use a better data structure 6942771: SEGV in ParScanThreadState::take_from_overflow_stack Reviewed-by: apetrusenko, ysr, pbk ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_serial ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + src/share/vm/utilities/stack.hpp + src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: c99c53f07c14 Author: ysr Date: 2010-09-29 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c99c53f07c14 6692906: CMS: parallel concurrent marking may be prone to hanging or stalling mutators for periods of time Summary: Inserted missing yield(check)s in closures used during the work-stealing phase of parallel concurrent marking, a missing synchronous yield-request in the cms perm gen allocation path, and a terminator-terminator for the offer_termination invocation that monitors the yield status of the concurrent marking task. Elaborated some documentation comments and made some task queue termination loop flags configurable at start-up to aid debugging in the field. Reviewed-by: jmasa, johnc, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 8f6f7587d292 Author: jcoomes Date: 2010-09-30 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8f6f7587d292 6988678: fatal error deadlock handling was unintentionally disabled Reviewed-by: ysr ! src/share/vm/runtime/thread.cpp Changeset: e41cd7fd68a6 Author: ysr Date: 2010-10-01 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e41cd7fd68a6 6794422: Perm gen expansion policy for concurrent collectors Summary: Concurrent collectors should expand the perm gen without a full STW GC, but possibly by triggering a concurrent collection. Temporary band-aid for G1 where no concurrent collection is kicked off since the perm gen is not collected concurrently. Reviewed-by: johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/permGen.hpp Changeset: 4e0094bc41fa Author: johnc Date: 2010-10-01 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4e0094bc41fa 6983311: G1: LoopTest hangs when run with -XX:+ExplicitInvokesConcurrent Summary: Clear the concurrent marking "in progress" flag while the FullGCCount_lock is held. This avoids a race that can cause back to back System.gc() calls, when ExplicitGCInvokesConcurrent is enabled, to fail to initiate a marking cycle causing the requesting thread to hang. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 32a1f7bf0c21 Author: johnc Date: 2010-10-01 21:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/32a1f7bf0c21 Merge Changeset: 6e0aac35bfa9 Author: tonyp Date: 2010-10-01 16:43 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6e0aac35bfa9 6980838: G1: guarantee(false) failed: thread has an unexpected active value in its SATB queue Summary: Under certain circumstances a safepoint could happen between a JavaThread object being created and that object being added to the Java threads list. This could cause the active field of that thread's SATB queue to get out-of-sync with respect to the other Java threads. The solution is to activate the SATB queue, when necessary, before adding the thread to the Java threads list, not when the JavaThread object is created. The changeset also includes a small fix to rename the surrogate locker thread from "Surrogate Locker Thread (CMS)" to "Surrogate Locker Thread (Concurrent GC)" since it's also used in G1. Reviewed-by: iveresov, ysr, johnc, jcoomes ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 0715f0cf171d Author: jcoomes Date: 2010-10-08 09:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0715f0cf171d Merge ! src/share/vm/includeDB_core ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 75588558f1bf Author: never Date: 2010-10-07 21:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/75588558f1bf 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/runtime.cpp Changeset: a222fcfba398 Author: twisti Date: 2010-10-08 02:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a222fcfba398 6990549: Zero and Shark fixes after 6978355 and 6953144 Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/interpreterRT_zero.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/shark/sharkCompiler.hpp Changeset: d55217dc206f Author: twisti Date: 2010-10-11 04:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d55217dc206f 6829194: JSR 292 needs to support compressed oops Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/oop.inline.hpp Changeset: a932f331ef90 Author: twisti Date: 2010-10-12 02:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a932f331ef90 6991065: missed a review comment in 6829194 Reviewed-by: kvn ! src/share/vm/classfile/classFileParser.cpp Changeset: c393f046f4c5 Author: iveresov Date: 2010-10-12 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c393f046f4c5 6991512: G1 barriers fail with 64bit C1 Summary: Fix compare-and-swap intrinsic problem with G1 post-barriers and issue with branch ranges in G1 stubs on sparc Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 5beba6174298 Author: twisti Date: 2010-10-13 01:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5beba6174298 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC Reviewed-by: never, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp + test/compiler/6987555/Test6987555.java Changeset: ecca2e3e2767 Author: twisti Date: 2010-10-13 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ecca2e3e2767 Merge Changeset: 357451a9ae6a Author: roland Date: 2010-10-13 10:29 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/357451a9ae6a 6991211: assert failure on sparc: "can not have caller-save register operands at calls" Summary: fixes sparc only assert failure following 6972540 Reviewed-by: never ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp Changeset: 94d77a279225 Author: roland Date: 2010-10-13 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/94d77a279225 Merge Changeset: b98784e85f71 Author: kvn Date: 2010-10-14 10:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b98784e85f71 Merge Changeset: 52f19c724d96 Author: trims Date: 2010-10-14 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/52f19c724d96 Merge ! .hgtags Changeset: 570870354f86 Author: trims Date: 2010-10-14 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/570870354f86 6992267: Bump the HS20 build number to 02 Summary: Update the HS20 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: bdbc48857210 Author: trims Date: 2010-10-20 16:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bdbc48857210 Merge ! .hgtags Changeset: 96b3f2a7add0 Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/96b3f2a7add0 Added tag jdk7-b115 for changeset bdbc48857210 ! .hgtags Changeset: 806d0c037e6b Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/806d0c037e6b Added tag jdk7-b116 for changeset 96b3f2a7add0 ! .hgtags Changeset: 26cd5261f8c6 Author: lana Date: 2010-11-04 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/26cd5261f8c6 Merge From lana.steuck at oracle.com Fri Nov 5 15:23:46 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Nov 2010 15:23:46 +0000 Subject: hg: jdk7/tl/jaxp: 3 new changesets Message-ID: <20101105152346.956AB47735@hg.openjdk.java.net> Changeset: dc1612e1d3ac Author: cl Date: 2010-10-14 19:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/dc1612e1d3ac Added tag jdk7-b114 for changeset d57197d22c2b ! .hgtags Changeset: f8d4e6c6cfce Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/f8d4e6c6cfce Added tag jdk7-b115 for changeset dc1612e1d3ac ! .hgtags Changeset: 9ee4d96e8934 Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/9ee4d96e8934 Added tag jdk7-b116 for changeset f8d4e6c6cfce ! .hgtags From lana.steuck at oracle.com Fri Nov 5 15:23:52 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Nov 2010 15:23:52 +0000 Subject: hg: jdk7/tl/jaxws: 3 new changesets Message-ID: <20101105152352.318FC47736@hg.openjdk.java.net> Changeset: 824cc44bd6eb Author: cl Date: 2010-10-14 19:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/824cc44bd6eb Added tag jdk7-b114 for changeset 400f494c81c5 ! .hgtags Changeset: 376ac153078d Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/376ac153078d Added tag jdk7-b115 for changeset 824cc44bd6eb ! .hgtags Changeset: 1320fb3bb588 Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/1320fb3bb588 Added tag jdk7-b116 for changeset 376ac153078d ! .hgtags From lana.steuck at oracle.com Fri Nov 5 15:26:45 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Nov 2010 15:26:45 +0000 Subject: hg: jdk7/tl/jdk: 58 new changesets Message-ID: <20101105153605.685D947737@hg.openjdk.java.net> Changeset: 0613978371d8 Author: cl Date: 2010-10-14 19:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0613978371d8 Added tag jdk7-b114 for changeset e250cef36ea0 ! .hgtags Changeset: f96548542368 Author: igor Date: 2010-08-12 23:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f96548542368 6976516: Add support for compiling deploy ws without compiling j2se Reviewed-by: herrick, ohair ! make/common/internal/Resources.gmk Changeset: 6841ece60936 Author: herrick Date: 2010-08-20 14:48 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6841ece60936 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: ea7e333308ed Author: igor Date: 2010-09-01 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea7e333308ed 6981436: Variable gets hidden if Defs-javadoc is included Reviewed-by: ohair ! make/common/shared/Defs-javadoc.gmk ! make/docs/Makefile Changeset: 72136d9a079f Author: jqzuo Date: 2010-09-02 09:23 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/72136d9a079f Merge - src/share/classes/sun/java2d/pisces/PiscesMath.java - src/share/classes/sun/java2d/pisces/Transform4.java - test/tools/pack200/Pack200Simple.sh - test/tools/pack200/SegmentLimit.java Changeset: a7fa35166b92 Author: igor Date: 2010-09-07 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a7fa35166b92 6982774: HOTSPOT_IMPORT_PATH detection does not work as expected Reviewed-by: herrick, ohair ! make/common/shared/Defs.gmk Changeset: 0dc672582a47 Author: igor Date: 2010-09-07 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0dc672582a47 6982499: ant detection is fragile on windows. especially using cygwin Reviewed-by: ohair ! make/common/shared/Defs.gmk Changeset: af2d0f81e1ac Author: herrick Date: 2010-09-16 12:19 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/af2d0f81e1ac Merge Changeset: e463b0e829c8 Author: herrick Date: 2010-09-17 07:11 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e463b0e829c8 Merge Changeset: dc1bb8cf6ff6 Author: herrick Date: 2010-10-02 11:09 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dc1bb8cf6ff6 Merge - src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java - src/share/native/sun/java2d/cmm/lcms/cmscam97.c - src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c - src/share/native/sun/java2d/cmm/lcms/icc34.h - src/share/native/sun/java2d/cmm/lcms/lcms.h - src/solaris/classes/sun/net/spi/SdpProvider.java - src/solaris/native/sun/net/spi/SdpProvider.c - test/java/util/Locale/data/deflocale.exe - test/java/util/Locale/data/deflocale.jds3 - test/java/util/Locale/data/deflocale.rhel4 - test/java/util/Locale/data/deflocale.winvista - test/java/util/Locale/data/deflocale.winxp - test/tools/launcher/VerifyExceptions.java Changeset: 0dcee22ced98 Author: jqzuo Date: 2010-10-12 13:34 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0dcee22ced98 Merge Changeset: 449bad8d67b5 Author: jqzuo Date: 2010-10-18 11:25 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/449bad8d67b5 Merge - make/common/Rules-SCCS.gmk ! make/common/shared/Defs.gmk - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 9c4165d5661c Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9c4165d5661c Added tag jdk7-b115 for changeset 449bad8d67b5 ! .hgtags Changeset: b96e6b8761bc Author: bae Date: 2010-10-05 10:23 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b96e6b8761bc 6976076: sun/java2d/pipe/MutableColorTest/MutableColorTest.java failed Reviewed-by: igor, prr ! test/sun/java2d/pipe/MutableColorTest/MutableColorTest.java Changeset: 93d0daa9aa7a Author: bae Date: 2010-10-06 12:19 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93d0daa9aa7a 6853488: REGRESSION : A black background is seen for a transparent animated gif image for splash screen Reviewed-by: igor, prr ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c Changeset: 6cb79067ea7a Author: bae Date: 2010-10-07 12:25 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6cb79067ea7a 6975884: sun/java2d/SunGraphics2D/DrawImageBilinear.java failed Reviewed-by: prr ! test/sun/java2d/SunGraphics2D/DrawImageBilinear.java Changeset: 4a50631c9910 Author: bae Date: 2010-10-15 10:42 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a50631c9910 6725821: Compiler warnings in medialib code Reviewed-by: igor, prr ! make/sun/image/generic/Makefile ! src/share/native/sun/awt/medialib/mlib_ImageLookUp_64.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpS32S16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpS32U16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpSIS32S16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpSIS32U16Func.c Changeset: 37df0a178978 Author: bae Date: 2010-10-15 11:26 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/37df0a178978 6773022: java.awt.image.SampleModel.getDataElements() does't throw ArrayIndexOutOfBoundsEx for Integer.MAX_V Reviewed-by: igor, prr ! src/share/classes/java/awt/image/SampleModel.java + test/java/awt/image/GetDataElementsTest.java Changeset: a7cdcd3541d4 Author: bae Date: 2010-10-15 12:02 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a7cdcd3541d4 6984033: imageio vendor references need to change (jdk7 only) Reviewed-by: prr, ohair ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageWriterSpi.java ! src/share/classes/com/sun/imageio/spi/FileImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/FileImageOutputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/InputStreamImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/OutputStreamImageOutputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/RAFImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/RAFImageOutputStreamSpi.java Changeset: 0a53abebf6e9 Author: jgodinez Date: 2010-10-15 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0a53abebf6e9 6804454: RFE: Provide a way to control the printing dpi resolution from MSIE browser print. See also 6801859 Reviewed-by: igor, prr ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java Changeset: b9c24a76093d Author: lana Date: 2010-10-18 12:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b9c24a76093d Merge - make/common/Rules-SCCS.gmk ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 1b658b8bd49d Author: art Date: 2010-10-05 18:12 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1b658b8bd49d 6829546: Modal dialog causes underlying parent JFrame to be set to "Always on top". Reviewed-by: anthony, dcherepanov ! src/windows/native/sun/windows/awt_Dialog.cpp + test/java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java Changeset: e804b396307b Author: art Date: 2010-10-05 18:13 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e804b396307b 6828273: javax/swing/system/6799345/TestShutdown.java test fails with RuntimeException. Reviewed-by: anthony, dcherepanov ! src/solaris/classes/sun/awt/X11/XToolkit.java ! test/javax/swing/system/6799345/TestShutdown.java Changeset: 16265781795b Author: art Date: 2010-10-06 16:42 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16265781795b 6979541: closed/javax/swing/plaf/basic/AWTEventListenerLeak/AWTEventListenerLeak.java fails Reviewed-by: anthony, ant ! src/share/classes/sun/awt/SunToolkit.java Changeset: 335093475c11 Author: anthony Date: 2010-10-12 15:52 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/335093475c11 6895647: Frame may jump to an unpredicted location upon entering the non-opaque mode on X11 Summary: Make sure the size hints are set before mapping the window on the screen Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java + test/java/awt/Frame/FrameLocation/FrameLocation.java Changeset: a8bd5f04f4fb Author: anthony Date: 2010-10-12 18:20 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a8bd5f04f4fb 6990352: SplashScreen.getSplashScreen() does not return null for implicitly closed splash screen Summary: Mark the splash screen closed when it happens implicitly Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Window.java Changeset: 278bd32a15de Author: dav Date: 2010-10-13 17:03 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/278bd32a15de 6973199: java/awt/Robot/RobotWheelTest/RobotWheelTest.html failed on JDK7 b102 bug passed on b101 Reviewed-by: art, yan ! src/solaris/classes/sun/awt/X11/XWindow.java Changeset: c595c2730226 Author: art Date: 2010-10-14 14:07 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c595c2730226 6989721: awt native code compiler warnings Reviewed-by: yan, uta ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/native/sun/awt/libpng/pngrtran.c ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/native/sun/awt/awt.h ! src/solaris/native/sun/awt/awt_DrawingSurface.c ! src/solaris/native/sun/awt/awt_InputMethod.c ! src/solaris/native/sun/awt/awt_Robot.c ! src/solaris/native/sun/awt/awt_UNIXToolkit.c ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/solaris/native/sun/xawt/awt_Desktop.c ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.h ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 8022709a306d Author: dcherepanov Date: 2010-10-14 18:24 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8022709a306d 6991992: Need to forward-port AWT's part of the fix for 6691674 Reviewed-by: art ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/InfoWindow.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: f55be3060347 Author: anthony Date: 2010-10-14 18:59 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f55be3060347 6979568: Test failure: test\closed\java\awt\Component\VisibleHwInLwContTest\VisibleHwInLwContTest.html Summary: Extend iteration to this container in isRecursivelyVisibleUpToHeavyweightContainer() Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Container.java Changeset: b183180e8bb7 Author: dcherepanov Date: 2010-10-14 18:56 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b183180e8bb7 6838089: java.awt.Window.setOpacity() doesn't throw IllegalComponentStateException for two-display conf Reviewed-by: art, anthony ! src/share/classes/java/awt/Canvas.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java + test/java/awt/Multiscreen/TranslucencyThrowsExceptionWhenFullScreen/TranslucencyThrowsExceptionWhenFullScreen.java Changeset: 69eeb1cea943 Author: lana Date: 2010-10-17 19:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/69eeb1cea943 Merge - make/common/Rules-SCCS.gmk ! src/solaris/native/sun/awt/awt_InputMethod.c - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 70a695f74efb Author: lana Date: 2010-10-18 21:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/70a695f74efb Merge ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c Changeset: e26eef6ac0d6 Author: rupashka Date: 2010-10-07 12:48 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e26eef6ac0d6 6979793: closed/javax/swing/JFileChooser/6396844/TwentyThousandTest fails due FileNotFound exc. Reviewed-by: malenkov + test/javax/swing/JFileChooser/6396844/TwentyThousandTest.java Changeset: 93871607047a Author: amenkov Date: 2010-10-07 18:13 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93871607047a 6984047: sound sources needs vendor rebranding changes (jdk7 only) Reviewed-by: ohair ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/share/classes/javax/sound/sampled/AudioSystem.java Changeset: 958ddd568d4e Author: amenkov Date: 2010-10-07 18:23 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/958ddd568d4e 6986335: 10 regtest failures (test/javax/sound/midi/Gervil) due AudioFloatConverter.PCM_FLOAT not found Reviewed-by: dav ! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java Changeset: 940fed1764b4 Author: peytoia Date: 2010-10-08 09:50 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/940fed1764b4 6970930: RuleBasedCollator.compare(String,null) throws IAE (should be NPE) Reviewed-by: okutsu ! src/share/classes/java/text/RuleBasedCollator.java + test/java/text/Collator/Bug6970930.java Changeset: b2cfe62ef802 Author: naoto Date: 2010-10-12 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b2cfe62ef802 6989440: tomcat test from dacapo benchmark fails with ConcurrentModificationException Reviewed-by: okutsu Contributed-by: y.umaoka at gmail.com ! src/share/classes/sun/util/LocaleServiceProviderPool.java + test/java/util/Locale/Bug6989440.java Changeset: 23fd99021d35 Author: malenkov Date: 2010-10-13 15:18 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/23fd99021d35 6603635: links to tutorials broken in JTable API doc Reviewed-by: alexp ! src/share/classes/javax/swing/JTable.java Changeset: 1d56dff60eb1 Author: rupashka Date: 2010-10-14 13:33 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1d56dff60eb1 6984643: Unable to instantiate JFileChooser with a minimal BasicL&F descendant installed Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java + test/javax/swing/plaf/basic/Test6984643.java Changeset: d3c60dbfce57 Author: alexp Date: 2010-10-14 18:46 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3c60dbfce57 6986385: JLayer should implement accessible interface Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java + test/javax/accessibility/6986385/bug6986385.java Changeset: cdbb6e073c60 Author: naoto Date: 2010-10-14 11:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cdbb6e073c60 6575419: Solaris : XSetICFoucs is not called with Java application at appropriate timing Reviewed-by: okutsu ! src/solaris/classes/sun/awt/X11InputMethod.java Changeset: abc171d85be6 Author: naoto Date: 2010-10-14 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abc171d85be6 6991013: Serialized form for java.util.Locale contains typos Reviewed-by: peytoia ! src/share/classes/java/util/Locale.java Changeset: 308130a84ab7 Author: okutsu Date: 2010-10-15 16:46 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/308130a84ab7 6638110: (tz) TimeZone.getDisplayName(...) spec is inconsistent with implementation for unavailable locales Reviewed-by: peytoia ! src/share/classes/java/util/TimeZone.java Changeset: bcb09768ba1e Author: lana Date: 2010-10-15 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bcb09768ba1e Merge - make/common/Rules-SCCS.gmk - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 954b5eb4a256 Author: naoto Date: 2010-10-18 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/954b5eb4a256 6992272: I18N: Locale.getDisplayName() and toString() return empty if just script is set Reviewed-by: srl Contributed-by: y.umaoka at gmail.com ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: cf13977eb9c0 Author: lana Date: 2010-10-18 21:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cf13977eb9c0 Merge Changeset: faccd8fcd36c Author: lana Date: 2010-10-18 21:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/faccd8fcd36c Merge Changeset: 4e04d1e8f533 Author: lana Date: 2010-10-21 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4e04d1e8f533 Merge Changeset: 5c761cdf28e8 Author: lana Date: 2010-10-21 17:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5c761cdf28e8 6993984: PIT: b116 - Many of the swing test are failing on Solaris Reviewed-by: anthony, prr ! src/share/classes/java/awt/event/InputEvent.java Changeset: f9dee02df0eb Author: lana Date: 2010-10-26 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f9dee02df0eb Merge Changeset: e45cac3fe09b Author: herrick Date: 2010-10-08 11:43 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e45cac3fe09b Merge Changeset: 7713900ff391 Author: igor Date: 2010-10-14 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7713900ff391 Merge - make/common/Rules-SCCS.gmk ! make/common/shared/Defs.gmk - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 7363e68ccce4 Author: herrick Date: 2010-10-16 12:17 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7363e68ccce4 Merge Changeset: 1657ed4e1d86 Author: jqzuo Date: 2010-10-26 19:48 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1657ed4e1d86 Merge Changeset: 3e6726bbf80a Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3e6726bbf80a Added tag jdk7-b116 for changeset 1657ed4e1d86 ! .hgtags Changeset: 28be97898e83 Author: lana Date: 2010-11-04 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/28be97898e83 Merge Changeset: fdb611a9fdce Author: lana Date: 2010-11-05 08:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fdb611a9fdce Merge From lana.steuck at oracle.com Fri Nov 5 15:37:52 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Nov 2010 15:37:52 +0000 Subject: hg: jdk7/tl/langtools: 6 new changesets Message-ID: <20101105153805.95E4347738@hg.openjdk.java.net> Changeset: 01e8ac5fbefd Author: cl Date: 2010-10-14 19:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/01e8ac5fbefd Added tag jdk7-b114 for changeset e4e7408cdc5b ! .hgtags Changeset: b7f12ec175bb Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b7f12ec175bb Added tag jdk7-b115 for changeset 01e8ac5fbefd ! .hgtags Changeset: 2187e78b7980 Author: lana Date: 2010-10-18 21:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2187e78b7980 Merge Changeset: 857bfcea3f30 Author: lana Date: 2010-10-26 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/857bfcea3f30 Merge Changeset: 2129a046f117 Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2129a046f117 Added tag jdk7-b116 for changeset 857bfcea3f30 ! .hgtags Changeset: e406f0645b7e Author: lana Date: 2010-11-04 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e406f0645b7e Merge From sean.coffey at oracle.com Fri Nov 5 17:12:50 2010 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 05 Nov 2010 17:12:50 +0000 Subject: hg: jdk7/tl/jdk: 6957378: JMX memory leak Message-ID: <20101105171300.8CA944773C@hg.openjdk.java.net> Changeset: 5de001f5f8b4 Author: coffeys Date: 2010-11-05 17:15 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5de001f5f8b4 6957378: JMX memory leak Reviewed-by: emcmanus, kevinw ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java + test/javax/management/remote/mandatory/notif/DeadListenerTest.java From forax at univ-mlv.fr Fri Nov 5 21:03:07 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 05 Nov 2010 22:03:07 +0100 Subject: micro-RFE for java.dyn In-Reply-To: <196191288969024@web33.yandex.ru> References: <196191288969024@web33.yandex.ru> Message-ID: <4CD4710B.9040708@univ-mlv.fr> Le 05/11/2010 15:57, assembling signals a ?crit : > Hello, everyone! > > Sorry, not sure if it's the right mailinglist, here [ http://mail.openjdk.java.net/mailman/listinfo ] there were no mailinglist listed for java.dyn. > This is the wrong mailing list, the right one is mlvm http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > I have a little RFE for java.dyn.Linkage. > Could it be possible to add another "registerBootstrapMethod(...)" method which would accept Runnable as parameter instead of String. > This class disappears in latest update. The spec was updated to allow to specify a boostrap method for each invokedynamic. Anyway, I think I don't really understand what you want to do with your Runnable. The boostrap method must return a CallSite and Runnable.run() return void. > This would have two litte advantages: > 1) If would be refactoring-proof (normally, renaming of bootstrap method would depend on also renaming the string argument); > 2) There would be no warning about some unused private static method. > If there is a way to express constant method handles in Java, you also have the these two properties. We're working on that ! > Best regards, > Ivan G S > R?mi From kumar.x.srinivasan at oracle.com Fri Nov 5 21:16:17 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 05 Nov 2010 21:16:17 +0000 Subject: hg: jdk7/tl/jdk: 6985763: Pack200.Packer.pack(...) and Pack200.Unpacker.unpack(...) throw unspecified exceptions Message-ID: <20101105211636.1F1744774C@hg.openjdk.java.net> Changeset: dd3afa184407 Author: ksrini Date: 2010-11-05 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd3afa184407 6985763: Pack200.Packer.pack(...) and Pack200.Unpacker.unpack(...) throw unspecified exceptions Reviewed-by: jrose, dholmes, alanb, mduigou ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/java/util/jar/Pack200.java + test/tools/pack200/TestExceptions.java From Lance.Andersen at oracle.com Fri Nov 5 21:51:36 2010 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 5 Nov 2010 17:51:36 -0400 Subject: hg: jdk7/tl/jdk: 6843995: RowSet 1.1 updates In-Reply-To: <4C83AF57.8060202@univ-mlv.fr> References: <20100904175939.EA37F4770B@hg.openjdk.java.net> <4C83AF57.8060202@univ-mlv.fr> Message-ID: Hi Remi (and team), I made changes to SyncFactory and one other class for a similar error. Also cleaned up a couple of other minor issues in these classes. The webrev can be found at http://cr.openjdk.java.net/~lancea/6982530/ Thank you for catching the error. Regards Lance On Sep 5, 2010, at 10:55 AM, R?mi Forax wrote: > Le 04/09/2010 19:59, lance.andersen at oracle.com a ?crit : >> Changeset: d44696691445 >> Author: lancea >> Date: 2010-09-04 13:56 -0400 >> URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d44696691445 >> >> 6843995: RowSet 1.1 updates >> Reviewed-by: darcy, valeriep >> >> + src/share/classes/com/sun/rowset/RowSetFactoryImpl.java >> ! src/share/classes/javax/sql/rowset/CachedRowSet.java >> + src/share/classes/javax/sql/rowset/RowSetFactory.java >> + src/share/classes/javax/sql/rowset/RowSetProvider.java >> ! src/share/classes/javax/sql/rowset/package.html >> ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java >> ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java >> > > There is a bug in SyncFactory, it uses the double checked locking pattern, > which is broken in Java :) > > R?mi Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.duigou at oracle.com Fri Nov 5 23:29:34 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 5 Nov 2010 16:29:34 -0700 Subject: minor javadoc review Message-ID: <1D75A549-F134-4A52-8446-3441486BB7AA@oracle.com> Hello all; For your consideration a minor javadoc fix to review for TreeMap. This change makes the TreeMap documentation consistent with the SortedMap documentation. The primary fix is to add the word "sorted" in the sentence : > This is so because the Map interface is defined in terms of the {@code equals} operation, but a +++sorted+++ map performs all key comparisons using its {@code compareTo} (or {@code compare}) method, so two keys that are deemed equal by this method are, from the standpoint of the sorted map, equal. The other changes are to replace -> and ... -> {@code ...} 6465367: (coll) Typo in TreeMap documentation webrev @ http://cr.openjdk.java.net/~mduigou/6465367.0/webrev Thanks! Mike From weijun.wang at oracle.com Sat Nov 6 01:12:22 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 06 Nov 2010 01:12:22 +0000 Subject: hg: jdk7/tl/jdk: 6997740: ktab entry related test compilation error Message-ID: <20101106011242.DE71B47756@hg.openjdk.java.net> Changeset: 856843c444a0 Author: weijun Date: 2010-11-06 09:11 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856843c444a0 6997740: ktab entry related test compilation error Reviewed-by: valeriep ! test/sun/security/krb5/auto/MoreKvno.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/W83.java ! test/sun/security/krb5/ktab/KeyTabIndex.java From schlosna at gmail.com Sat Nov 6 06:04:24 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Sat, 6 Nov 2010 02:04:24 -0400 Subject: hg: jdk7/tl/jdk: 6843995: RowSet 1.1 updates In-Reply-To: References: <20100904175939.EA37F4770B@hg.openjdk.java.net> <4C83AF57.8060202@univ-mlv.fr> Message-ID: On Fri, Nov 5, 2010 at 5:51 PM, Lance Andersen - Oracle wrote: > > Hi Remi (and team), > I made changes to SyncFactory and one other class for a similar error. ?Also cleaned up a couple of other minor issues in these classes. > The webrev can be found at?http://cr.openjdk.java.net/~lancea/6982530/ > Thank you for catching the error. > Regards > Lance Lance, I had a few questions and comments: In?JdbcRowSetResourceBundle.java - private static String fileName is unused, can this be removed? My only hesitation is that the class is Serializable, and although the field is a static, the specification lists "Deleting fields" as an incompatible change without qualifying whether this implies deleting static fields is serial version incompatible (I wouldn't think it should be incompatible as statics aren't serialized by default, but I'm not a serialization expert by any means). In SyncFactory.java - the following fields are unused, can these be removed? private static String default_provider private static Level rsLevel private static Object logSync private static java.io.PrintWriter logWriter In SyncFactory.initJNDIContext(), isn't there still a potential visibility problem with reads of static Context field ic because the write is done under the class' monitor (in setJNDIContext), while the read is not? This could lead to a race condition which would possibly allow duplicate initialization under concurrent calls. Also, the static boolean field lazyJNDICtxRefresh does not seem to have any visibility guarantees, leading to similar problems. To fix this, should initJNDIContext() be synchronized? In SyncFactory.java, this is more stylistic, but I'm curious why a volatile double-checked lock was chosen over the (cleaner IMHO) lazy initialize-on-demand idiom described in Java Concurrency in Practice [Brian Goetz et al., 2006 p348]. The tradeoff I see is a mutable static volatile field versus the overhead of an additional class file. I'm just curious as I've been cleaning up a lot of unsafe double-checked locks in some code at work and I'd like to understand the rationale better from the core-libs perspective. I'd envisaged something along these lines with the removal of the private static volatile SyncFactory syncFactory: /** * Returns the {@code SyncFactory} singleton. * * @return the {@code SyncFactory} instance */ public static SyncFactory getSyncFactory() { // This method uses the thread safe lazy initialization holder class // idiom [Brian Goetz et al. Java Concurrency in Practice, 2006 p348] return Singleton.syncFactory; } private static class Singleton { static final SyncFactory syncFactory = new SyncFactory(); } Thanks, Dave From jonathan.gibbons at oracle.com Sat Nov 6 21:03:51 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 06 Nov 2010 21:03:51 +0000 Subject: hg: jdk7/tl/langtools: 6998063: new Scope impl to fix Scope performance issues Message-ID: <20101106210356.4BDE847781@hg.openjdk.java.net> Changeset: 9427a3c795fc Author: jjg Date: 2010-11-06 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9427a3c795fc 6998063: new Scope impl to fix Scope performance issues Reviewed-by: jjg Contributed-by: per.bothner at oracle.com ! src/share/classes/com/sun/tools/javac/code/Scope.java + test/tools/javac/6996626/Main.java + test/tools/javac/6996626/pack1/Symbol.java From Lance.Andersen at oracle.com Sat Nov 6 21:31:54 2010 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Sat, 6 Nov 2010 17:31:54 -0400 Subject: hg: jdk7/tl/jdk: 6843995: RowSet 1.1 updates In-Reply-To: References: <20100904175939.EA37F4770B@hg.openjdk.java.net> <4C83AF57.8060202@univ-mlv.fr> Message-ID: Hi David, Thanks for the feedback. Please see below. On Nov 6, 2010, at 2:04 AM, David Schlosnagle wrote: > On Fri, Nov 5, 2010 at 5:51 PM, Lance Andersen - Oracle > wrote: >> >> Hi Remi (and team), >> I made changes to SyncFactory and one other class for a similar error. Also cleaned up a couple of other minor issues in these classes. >> The webrev can be found at http://cr.openjdk.java.net/~lancea/6982530/ >> Thank you for catching the error. >> Regards >> Lance > > Lance, > > I had a few questions and comments: > > In JdbcRowSetResourceBundle.java - private static String fileName is > unused, can this be removed? My only hesitation is that the class is > Serializable, and although the field is a static, the specification > > lists "Deleting fields" as an incompatible change without qualifying > whether this implies deleting static fields is serial version > incompatible (I wouldn't think it should be incompatible as statics > aren't serialized by default, but I'm not a serialization expert by > any means). Static fields are not serialized and this field was also never used so it could be deleted. I have additional clean up that needs done and I plan to use a different CR than the one for the synchronization issue. So I will make this change in a different putback > > In SyncFactory.java - the following fields are unused, can these be removed? > private static String default_provider > private static Level rsLevel > private static Object logSync > private static java.io.PrintWriter logWriter Yes they can go. It looks like the original author forgot to remove these fields when they ended up not getting used. I will do this in a separate putback though. > > In SyncFactory.initJNDIContext(), isn't there still a potential > visibility problem with reads of static Context field ic because the > write is done under the class' monitor (in setJNDIContext), while the > read is not? This could lead to a race condition which would possibly > allow duplicate initialization under concurrent calls. Also, the > static boolean field lazyJNDICtxRefresh does not seem to have any > visibility guarantees, leading to similar problems. To fix this, > should initJNDIContext() be synchronized? Yes, initJNDIContext() should also be a synchronized method. I have updated the webrev > > In SyncFactory.java, this is more stylistic, but I'm curious why a > volatile double-checked lock was chosen over the (cleaner IMHO) lazy > initialize-on-demand idiom described in Java Concurrency in Practice > [Brian Goetz et al., 2006 p348]. The tradeoff I see is a mutable > static volatile field versus the overhead of an additional class file. > I'm just curious as I've been cleaning up a lot of unsafe > double-checked locks in some code at work and I'd like to understand > the rationale better from the core-libs perspective. I'd envisaged > something along these lines with the removal of the private static > volatile SyncFactory syncFactory: > > /** > * Returns the {@code SyncFactory} singleton. > * > * @return the {@code SyncFactory} instance > */ > public static SyncFactory getSyncFactory() { > // This method uses the thread safe lazy initialization holder class > // idiom [Brian Goetz et al. Java Concurrency in Practice, 2006 p348] > return Singleton.syncFactory; > } > > private static class Singleton { > static final SyncFactory syncFactory = new SyncFactory(); > } > Good question. I had considered changing it but decided against it. However you made me reflect on it again so I decided to. Effective Java 2nd Edition, ITEM 71, suggests that you should use this idom for static fields instead of DCL as it is slightly more performant. It still suggest DCL for instance fields for performance. I have pushed the new webrev out. Regards, Lance > Thanks, > Dave Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: From aruld at acm.org Sun Nov 7 06:03:28 2010 From: aruld at acm.org (Arul Dhesiaseelan) Date: Sun, 7 Nov 2010 00:03:28 -0600 Subject: java.util.Objects.equals() fails to compile with static import Message-ID: Hello, Sorry, if I am posting to the wrong mailing list. It looks the java.util.Objects proposal was originally discussed in this forum. I have a related question about the implementation. I was playing with the java.util.Objects API in the recent JDK 7 build (b117) and it looks like the equals() method fails to compile if I statically import it, with the following error: method equals in class Object cannot be applied to given types; It clashes with java.lang.Object's equals() method. I am not sure if this a known limitation or a bug. -Arul -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Nov 7 10:35:32 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 07 Nov 2010 11:35:32 +0100 Subject: java.util.Objects.equals() fails to compile with static import In-Reply-To: References: Message-ID: <4CD680F4.1020505@univ-mlv.fr> Le 07/11/2010 07:03, Arul Dhesiaseelan a ?crit : > Hello, > > Sorry, if I am posting to the wrong mailing list. It looks the > java.util.Objects proposal was originally discussed in this forum. I > have a related question about the implementation. I was playing with > the java.util.Objects API in the recent JDK 7 build (b117) and it > looks like the equals() method fails to compile if I statically import > it, with the following error: > > method equals in class Object cannot be applied to given types; > > It clashes with java.lang.Object's equals() method. I am not sure if > this a known limitation or a bug. > > -Arul It's a known limitation of the static import feature. R?mi From aruld at acm.org Sun Nov 7 16:52:59 2010 From: aruld at acm.org (Arul Dhesiaseelan) Date: Sun, 7 Nov 2010 09:52:59 -0700 Subject: java.util.Objects.equals() fails to compile with static import In-Reply-To: <4CD680F4.1020505@univ-mlv.fr> References: <4CD680F4.1020505@univ-mlv.fr> Message-ID: I stand corrected. Thanks Remi. On Sun, Nov 7, 2010 at 3:35 AM, R?mi Forax wrote: > Le 07/11/2010 07:03, Arul Dhesiaseelan a ?crit : > > Hello, >> >> Sorry, if I am posting to the wrong mailing list. It looks the >> java.util.Objects proposal was originally discussed in this forum. I have a >> related question about the implementation. I was playing with the >> java.util.Objects API in the recent JDK 7 build (b117) and it looks like the >> equals() method fails to compile if I statically import it, with the >> following error: >> >> method equals in class Object cannot be applied to given types; >> >> It clashes with java.lang.Object's equals() method. I am not sure if this >> a known limitation or a bug. >> >> -Arul >> > > It's a known limitation of the static import feature. > > R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Nov 8 12:18:18 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Nov 2010 12:18:18 +0000 Subject: minor javadoc review In-Reply-To: <1D75A549-F134-4A52-8446-3441486BB7AA@oracle.com> References: <1D75A549-F134-4A52-8446-3441486BB7AA@oracle.com> Message-ID: <4CD7EA8A.50508@oracle.com> Mike Duigou wrote: > Hello all; > > For your consideration a minor javadoc fix to review for TreeMap. This change makes the TreeMap documentation consistent with the SortedMap documentation. The primary fix is to add the word "sorted" in the sentence : > > >> This is so because the Map interface is defined in terms of the {@code equals} operation, but a +++sorted+++ map performs all key comparisons using its {@code compareTo} (or {@code compare}) method, so two keys that are deemed equal by this method are, from the standpoint of the sorted map, equal. >> > > The other changes are to replace -> and ... -> {@code ...} > > 6465367: (coll) Typo in TreeMap documentation > webrev @ http://cr.openjdk.java.net/~mduigou/6465367.0/webrev > > Thanks! > > Mike Looks okay to me. I wonder would it be worth changing all usages of the to {@code ... } while you are there. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Nov 8 14:03:09 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 08 Nov 2010 14:03:09 +0000 Subject: Code Review 6993789: LinkedBlockingDeque iterator/descendingIterator loops and owns lock forever Message-ID: <4CD8031D.9060602@oracle.com> Doug, David, This webrev contains the fix for CR 6993789: "LinkedBlockingDeque iterator/descendingIterator loops and owns lock forever", and also contains some other minor changes that we inherit for free when syncing to the latest LBQ in Dougs CVS, "optimize toString methods", and "Move more allocations outside of locks to reduce footprint". Webrev: http://cr.openjdk.java.net/~chegar/6993789/webrev.00/webrev/ Thanks, -Chris. From sean.mullan at oracle.com Mon Nov 8 16:34:12 2010 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 08 Nov 2010 16:34:12 +0000 Subject: hg: jdk7/tl/jdk: 6994717: expired certificate in test ValidateCertPath Message-ID: <20101108163433.AD219477EA@hg.openjdk.java.net> Changeset: 34faa22a8ce8 Author: mullan Date: 2010-11-08 11:33 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/34faa22a8ce8 6994717: expired certificate in test ValidateCertPath Reviewed-by: vinnie ! test/java/security/cert/CertPathValidator/nameConstraintsRFC822/ValidateCertPath.java From forax at univ-mlv.fr Mon Nov 8 18:11:34 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 08 Nov 2010 19:11:34 +0100 Subject: Code Review 6993789: LinkedBlockingDeque iterator/descendingIterator loops and owns lock forever In-Reply-To: <4CD8031D.9060602@oracle.com> References: <4CD8031D.9060602@oracle.com> Message-ID: <4CD83D56.8070702@univ-mlv.fr> Le 08/11/2010 15:03, Chris Hegarty a ?crit : > Doug, David, > > This webrev contains the fix for CR 6993789: "LinkedBlockingDeque > iterator/descendingIterator loops and owns lock forever", and also > contains some other minor changes that we inherit for free when > syncing to the latest LBQ in Dougs CVS, "optimize toString methods", > and "Move more allocations outside of locks to reduce footprint". > > Webrev: > http://cr.openjdk.java.net/~chegar/6993789/webrev.00/webrev/ > > Thanks, > -Chris. Is there a reason to not inline succ() ? R?mi From mark.reinhold at oracle.com Mon Nov 8 20:08:12 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 08 Nov 2010 12:08:12 -0800 Subject: hg: jdk7/tl/corba: 8 new changesets In-Reply-To: sunita.koppar@sun.com; Mon, 08 Nov 2010 15:41:04 GMT; <20101108154109.01A72477E3@hg.openjdk.java.net> Message-ID: <20101108200812.9397517CB@eggemoggin.niobe.net> FYI I've rolled back these changesets, together with the merge changesets that followed them, and I've added the first changeset in the sequence (2ded3bb14529) to the jcheck blacklist. The tip revision in jdk7/tl/corba is now: changeset: 207:8260ec509a10 parent: 203:76aeef3afc04 parent: 206:fa502e4834da user: lana date: Thu Nov 04 14:05:29 2010 -0700 summary: Merge - Mark -------------- next part -------------- An embedded message was scrubbed... From: sunita.koppar at Sun.COM Subject: hg: jdk7/tl/corba: 8 new changesets Date: Mon, 08 Nov 2010 15:41:04 +0000 Size: 6053 URL: From kelly.ohair at oracle.com Mon Nov 8 20:19:54 2010 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Mon, 08 Nov 2010 20:19:54 +0000 Subject: hg: jdk7/tl/jdk: 6792706: Add JAR file to bootclasspath when using AggressiveOpts Message-ID: <20101108202015.F419C477F5@hg.openjdk.java.net> Changeset: a12112af843c Author: ohair Date: 2010-11-08 09:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a12112af843c 6792706: Add JAR file to bootclasspath when using AggressiveOpts Reviewed-by: alanb, kvn, darcy ! make/Makefile + make/altclasses/Makefile ! test/java/lang/reflect/Generics/Probe.java ! test/java/util/NavigableMap/LockStep.java From weijun.wang at oracle.com Tue Nov 9 00:36:04 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 09 Nov 2010 00:36:04 +0000 Subject: hg: jdk7/tl/jdk: 6952519: kdc_timeout is not being honoured when using TCP Message-ID: <20101109003615.12FB3477FF@hg.openjdk.java.net> Changeset: e27ad63b0f54 Author: weijun Date: 2010-11-09 08:34 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e27ad63b0f54 6952519: kdc_timeout is not being honoured when using TCP Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/KrbKdcReq.java + src/share/classes/sun/security/krb5/internal/NetClient.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java + test/sun/security/krb5/auto/TcpTimeout.java From chris.hegarty at oracle.com Tue Nov 9 09:11:42 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 09 Nov 2010 09:11:42 +0000 Subject: Code Review 6993789: LinkedBlockingDeque iterator/descendingIterator loops and owns lock forever In-Reply-To: <4CD83D56.8070702@univ-mlv.fr> References: <4CD8031D.9060602@oracle.com> <4CD83D56.8070702@univ-mlv.fr> Message-ID: <4CD9104E.9010609@oracle.com> R?mi Forax wrote: > Le 08/11/2010 15:03, Chris Hegarty a ?crit : >> Doug, David, >> >> This webrev contains the fix for CR 6993789: "LinkedBlockingDeque >> iterator/descendingIterator loops and owns lock forever", and also >> contains some other minor changes that we inherit for free when >> syncing to the latest LBQ in Dougs CVS, "optimize toString methods", >> and "Move more allocations outside of locks to reduce footprint". >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/6993789/webrev.00/webrev/ >> >> Thanks, >> -Chris. > > Is there a reason to not inline succ() ? I don't believe there is any specific reason why succ() is not simply in line, but (for me at least) it is more readable in it's own method. -Chris. > > R?mi From eliasen at mindspring.com Tue Nov 9 09:44:31 2010 From: eliasen at mindspring.com (Alan Eliasen) Date: Tue, 09 Nov 2010 02:44:31 -0700 Subject: Mercurial repositories no longer work? Message-ID: <4CD917FF.9060505@mindspring.com> When attempting to update my working copy of JDK 1.7, I attempted to perform a "hg fpull" and got the error: TypeError: transaction() takes exactly 2 arguments (1 given) A little research indicates a few things: * The mercurial "forest" extension is no longer maintained. * It is incompatible with Mercurial 1.6. * Forest maintainers suggest you switch to subrepos. * No updated version of the "forest" extension exists. * OpenJDK documents contain no information about this issue and point to outdated, broken extensions: http://openjdk.java.net/guide/repositories.html * This giant repository was built on an untested, unmaintained experimental third-party extension. * It appears to be impossible for developers to update their repositories with the information given. So how does one update a working repository? And what is being done about the problem? This would appear to have major implications for the viability of the OpenJDK project. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From Alan.Bateman at oracle.com Tue Nov 9 10:13:34 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Nov 2010 10:13:34 +0000 Subject: Mercurial repositories no longer work? In-Reply-To: <4CD917FF.9060505@mindspring.com> References: <4CD917FF.9060505@mindspring.com> Message-ID: <4CD91ECE.5060007@oracle.com> Alan Eliasen wrote: > When attempting to update my working copy of JDK 1.7, I attempted to > perform a "hg fpull" and got the error: > > TypeError: transaction() takes exactly 2 arguments (1 given) > > A little research indicates a few things: > > * The mercurial "forest" extension is no longer maintained. > * It is incompatible with Mercurial 1.6. > * Forest maintainers suggest you switch to subrepos. > * No updated version of the "forest" extension exists. > * OpenJDK documents contain no information about this issue and point > to outdated, broken extensions: > http://openjdk.java.net/guide/repositories.html > * This giant repository was built on an untested, unmaintained > experimental third-party extension. > * It appears to be impossible for developers to update their > repositories with the information given. > > So how does one update a working repository? And what is being done > about the problem? This would appear to have major implications for the > viability of the OpenJDK project. > > The web-discuss mailing list is the place for infrastructure discussion. As it happens, someone started a discussion about this issue just a few days ago: http://mail.openjdk.java.net/pipermail/web-discuss/2010-November/000139.html -Alan. From eliasen at mindspring.com Tue Nov 9 11:42:21 2010 From: eliasen at mindspring.com (Alan Eliasen) Date: Tue, 09 Nov 2010 04:42:21 -0700 Subject: Mercurial repositories no longer work? In-Reply-To: <4CD91ECE.5060007@oracle.com> References: <4CD917FF.9060505@mindspring.com> <4CD91ECE.5060007@oracle.com> Message-ID: <4CD9339D.8020106@mindspring.com> On 11/09/2010 03:13 AM, Alan Bateman wrote: > The web-discuss mailing list is the place for infrastructure discussion. > As it happens, someone started a discussion about this issue just a few > days ago: > > http://mail.openjdk.java.net/pipermail/web-discuss/2010-November/000139.html Since this is an issue that affects every single OpenJDK contributor, that may or may not be subscribed to every list, (I doubt most of us are,) it is critical that information about accessing the central repository (which is now effectively broken to anyone that uses current versions of Mercurial, especially because the Forest extension is no longer maintained) is pushed to contributors, and the solutions to that problem get actively published to every list, and are published to the official pages that explain how to check out and update OpenJDK as soon as possible, which they haven't been. (This is critical for an open-source project.) Is there a contact at Oracle that is responsible for making the OpenJDK open and accessible? Who is the maintainer of the pages that discuss how to check out and update OpenJDK? Those pages are obsolete and broken. Mercurial's forest extension is apparently obsolete and officially unmaintained. What is the strategy to move OpenJDK forward? I'm not subscribed to the web-discuss list, and its archive pages are marked as "nofollow" for web robots, so nobody will find it with a web search. You are asking that web robots do not follow links to any messages in the archive. I searched but couldn't find it for this reason. The thread posted above is not a solution; the only reply is a dreadful hardcoded large program that kludges around the real problem and will break again in the future if any subdirectory is added. It does not fix the problem that the official instructions to check out and update OpenJDK sources no longer work, and that the official way to check out (the unsupported Forest extension) is no longer usable. This is a major issue that must be addressed on all lists. I hope that paid Oracle employees will communicate the necessary fix to all contributors on all lists, who try to contribute value to their products for free. Please forward this to the web-discuss list. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From kelly.ohair at oracle.com Tue Nov 9 16:23:56 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 9 Nov 2010 08:23:56 -0800 Subject: Mercurial repositories no longer work? In-Reply-To: <4CD9339D.8020106@mindspring.com> References: <4CD917FF.9060505@mindspring.com> <4CD91ECE.5060007@oracle.com> <4CD9339D.8020106@mindspring.com> Message-ID: <76E01B25-C960-4293-9826-74EB3E422260@oracle.com> On Nov 9, 2010, at 3:42 AM, Alan Eliasen wrote: > On 11/09/2010 03:13 AM, Alan Bateman wrote: >> The web-discuss mailing list is the place for infrastructure >> discussion. >> As it happens, someone started a discussion about this issue just a >> few >> days ago: >> >> http://mail.openjdk.java.net/pipermail/web-discuss/2010-November/000139.html > > Since this is an issue that affects every single OpenJDK > contributor, > that may or may not be subscribed to every list, (I doubt most of us > are,) it is critical that information about accessing the central > repository (which is now effectively broken to anyone that uses > current > versions of Mercurial, especially because the Forest extension is no > longer maintained) is pushed to contributors, and the solutions to > that > problem get actively published to every list, and are published to the > official pages that explain how to check out and update OpenJDK as > soon > as possible, which they haven't been. (This is critical for an > open-source project.) I think you have made a bigger issue out of this than need be. Simply stop using the forest extension and instead of one fclone command you can use multiple clone commands, e.g. hg clone http://hg.openjdk.java.net/jdk7/jdk7 jdk7 hg clone http://hg.openjdk.java.net/jdk7/jdk7/corba jdk7/corba hg clone http://hg.openjdk.java.net/jdk7/jdk7/jaxp jdk7/jaxp hg clone http://hg.openjdk.java.net/jdk7/jdk7/jaxws jdk7/jaxws hg clone http://hg.openjdk.java.net/jdk7/jdk7/langtools jdk7/ langtools hg clone http://hg.openjdk.java.net/jdk7/jdk7/jdk jdk7/jdk hg clone http://hg.openjdk.java.net/jdk7/jdk7/hotspot jdk7/ hotspot -OR- for i in jdk7 jdk7/corba jdk7/jaxp jdk7/jaxws jdk7/langtools jdk7/ jdk jdk7/hotspot ; do hg clone http://hg.openjdk.java.net/jdk7/$i $i done Creating your clone is typically a one time affair, so this pain is limited and can easily be scripted. Every openjdk repository is an independent Mercurial repository, and most developers only work in one of these repositories anyway. Repeated operations on all repositories can easily be done with a simple shell loop, e.g. for i in `find . -type d -name .hg` ; do ( cd ${i}/.. && hg pull -u ) done I'll be adding some scripts to the jdk7 repo soon to help out with these operations. The forest extension was simply a helper extension and was never critical to the use of nested repositories. > > Is there a contact at Oracle that is responsible for making the > OpenJDK open and accessible? Who is the maintainer of the pages that > discuss how to check out and update OpenJDK? Those pages are obsolete > and broken. Mercurial's forest extension is apparently obsolete and > officially unmaintained. What is the strategy to move OpenJDK > forward? I see the lack of a forest extension as no serious impact on openjdk development. Just a minor bump in the road. > > I'm not subscribed to the web-discuss list, and its archive pages > are > marked as "nofollow" for web robots, so nobody will find it with a web > search. You are asking that web robots do not follow links to any > messages in the archive. I searched but couldn't find it for this > reason. The thread posted above is not a solution; the only reply > is a > dreadful hardcoded large program that kludges around the real problem > and will break again in the future if any subdirectory is added. It > does not fix the problem that the official instructions to check out > and > update OpenJDK sources no longer work, and that the official way to > check out (the unsupported Forest extension) is no longer usable. Eventually we will correct the documentation, and I'll try and send out some email or do some blogs on ways to get around it. You might try looking at: http://blogs.sun.com/kto/entry/mercurial_forest_pet_shell_trick > > This is a major issue that must be addressed on all lists. I hope > that paid Oracle employees will communicate the necessary fix to all > contributors on all lists, who try to contribute value to their > products > for free. Please forward this to the web-discuss list. I really don't see this as a major issue, but I do feel it is an important issue. We are all well aware of the problems with the forest extension and have been thinking about alternatives. The fact that external mercurial extensions are broken so easily with each Mercurial release has been a pain we have been living with for a long time. It is nothing new to us, we live with it, fix it when we can or find an alternative and move forward. -kto > > -- > Alan Eliasen > eliasen at mindspring.com > http://futureboy.us/ From chris.hegarty at oracle.com Tue Nov 9 16:36:08 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 09 Nov 2010 16:36:08 +0000 Subject: hg: jdk7/tl/jdk: 6998250: Remove redundant src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Message-ID: <20101109163628.A94A847822@hg.openjdk.java.net> Changeset: 00d9ecc5dceb Author: chegar Date: 2010-11-09 16:34 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/00d9ecc5dceb 6998250: Remove redundant src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Reviewed-by: alanb - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java From andreas.kohn at fredhopper.com Tue Nov 9 19:31:24 2010 From: andreas.kohn at fredhopper.com (Andreas Kohn) Date: Tue, 09 Nov 2010 20:31:24 +0100 Subject: Differences in Process#destroy() between Windows and Unix implementations Message-ID: <1289331084.8235.92.camel@tiamaria.ams.fredhopper.com> Hi, there seems to be a difference in behavior between Process#destroy() implementations on Windows and !Windows: on Windows TerminateProcess() [1] is called, which gives the process no way to react or in any way intercept the termination, while on Unix a simple SIGTERM is send which the process can just decide to ignore. [2] Is this intentional? I do prefer the Windows behavior, mainly because I do create processes once in a while that simply fail to terminate due to bugs in their implementation, and having Process#destroy() as a last, and terminal, resort is very helpful to work-around those issues. Regards, -- Andreas [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d87c1c06bbf9/src/windows/native/java/lang/ProcessImpl_md.c [2] http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d87c1c06bbf9/src/solaris/native/java/lang/UNIXProcess_md.c -- Never attribute to malice that which can be adequately explained by stupidity. -- Hanlon's Razor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From David.Holmes at oracle.com Tue Nov 9 20:02:09 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 10 Nov 2010 06:02:09 +1000 Subject: Differences in Process#destroy() between Windows and Unix implementations In-Reply-To: <1289331084.8235.92.camel@tiamaria.ams.fredhopper.com> References: <1289331084.8235.92.camel@tiamaria.ams.fredhopper.com> Message-ID: <4CD9A8C1.3070307@oracle.com> Hi Andreas, On 10/11/2010 5:31 AM, Andreas Kohn wrote: > there seems to be a difference in behavior between Process#destroy() > implementations on Windows and !Windows: on Windows TerminateProcess() > [1] is called, which gives the process no way to react or in any way > intercept the termination, while on Unix a simple SIGTERM is send which > the process can just decide to ignore. [2] > > Is this intentional? As I understand it: yes and no. :) The problem is that neither version is necessarily what you always want. SIGTERM is nice in that it allows the process to execute cleanup handlers etc (such as an exec'ed JVM!) but I don't think Windows has an equivalent, so we have to use TerminateProcess. On the flip side if SIGTERM fails we have no way to really kill an errant process. What we really need is two destroy methods: one that tries to terminate nicely and one with "extrene prejudice". But again I'm not sure that Windows would support that. I suppose we could also define the destroy() method to try both approaches, if available, eg SIGTERM wait a while SIGKILL. But then we need a way to specify "wait a while". David Holmes > I do prefer the Windows behavior, mainly because I do create processes > once in a while that simply fail to terminate due to bugs in their > implementation, and having Process#destroy() as a last, and terminal, > resort is very helpful to work-around those issues. > > Regards, > -- > Andreas > > [1] > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d87c1c06bbf9/src/windows/native/java/lang/ProcessImpl_md.c > [2] > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d87c1c06bbf9/src/solaris/native/java/lang/UNIXProcess_md.c > > From alan.bateman at oracle.com Tue Nov 9 20:42:37 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 09 Nov 2010 20:42:37 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101109204306.4270D4782D@hg.openjdk.java.net> Changeset: c164d0d59465 Author: alanb Date: 2010-11-09 18:56 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c164d0d59465 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException Reviewed-by: forax, sherman, chegar ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/Interruptible.java + test/java/nio/channels/FileChannel/ClosedByInterrupt.java Changeset: c70ba0987e05 Author: alanb Date: 2010-11-09 18:57 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c70ba0987e05 Merge - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java From jonathan.gibbons at oracle.com Wed Nov 10 01:50:07 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 10 Nov 2010 01:50:07 +0000 Subject: hg: jdk7/tl/langtools: 6997958: test tools/javac/api/T6412669.java fails in PIT Message-ID: <20101110015008.EF40047844@hg.openjdk.java.net> Changeset: a0d9d642f65b Author: jjg Date: 2010-11-09 17:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a0d9d642f65b 6997958: test tools/javac/api/T6412669.java fails in PIT Reviewed-by: darcy ! test/tools/javac/api/T6412669.java From sunita.koppar at sun.com Mon Nov 8 15:41:04 2010 From: sunita.koppar at sun.com (sunita.koppar at sun.com) Date: Mon, 08 Nov 2010 15:41:04 +0000 Subject: hg: jdk7/tl/corba: 8 new changesets Message-ID: <20101108154109.01A72477E3@hg.openjdk.java.net> Changeset: 2ded3bb14529 Author: skoppar Date: 2010-10-07 00:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/2ded3bb14529 6893109: memory leak in readObject() and writeObject() using idlj from jdk 1.6.0_14 Summary: Ken has reviewed this fix Reviewed-by: asaha ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/Stub.java Changeset: cd7abebaa49b Author: skoppar Date: 2010-10-07 00:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/cd7abebaa49b 6896157: unsynchronized hashmap in com.sun.corba.se.impl.transport.SelectorImpl.createReaderThread Summary: Ken has reviewed this fix Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java Changeset: 0952dcf251f6 Author: skoppar Date: 2010-10-07 00:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/0952dcf251f6 6929137: java-corba: Locking too broad in com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl Summary: Ken has reviewed this fix Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java Changeset: b2bd68ca8ff4 Author: skoppar Date: 2010-10-07 00:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/b2bd68ca8ff4 6714797: InitialContext.close does not close NIO socket connections Summary: Ken has reviewed this fix Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/transport/CorbaConnectionCacheBase.java ! src/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java ! src/share/classes/com/sun/corba/se/pept/transport/ConnectionCache.java ! src/share/classes/com/sun/corba/se/spi/transport/CorbaConnection.java Changeset: ecf821480d09 Author: skoppar Date: 2010-10-07 01:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/ecf821480d09 6948223: Corba issue, fail to reload object Summary: Ken has reviewed this fix Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/oa/poa/AOMEntry.java ! src/share/classes/com/sun/corba/se/impl/oa/poa/POAPolicyMediatorBase_R.java Changeset: 4632f4298f86 Author: skoppar Date: 2010-10-08 06:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/4632f4298f86 Merge Changeset: 712e34e074b0 Author: skoppar Date: 2010-11-04 03:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/712e34e074b0 Merge ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: 772549eec5d8 Author: skoppar Date: 2010-11-08 06:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/772549eec5d8 Merge From sunita.koppar at sun.com Mon Nov 8 15:50:46 2010 From: sunita.koppar at sun.com (sunita.koppar at sun.com) Date: Mon, 08 Nov 2010 15:50:46 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20101108155047.75C63477E4@hg.openjdk.java.net> Changeset: 8f4e775d469e Author: skoppar Date: 2010-11-08 06:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/8f4e775d469e Merge Changeset: 6b2e400a33bb Author: skoppar Date: 2010-11-08 07:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/6b2e400a33bb Merge From sunita.koppar at sun.com Mon Nov 8 16:00:33 2010 From: sunita.koppar at sun.com (sunita.koppar at sun.com) Date: Mon, 08 Nov 2010 16:00:33 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20101108160035.1C4E7477E6@hg.openjdk.java.net> Changeset: 1d81c2dae207 Author: skoppar Date: 2010-11-08 06:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/1d81c2dae207 Merge Changeset: 2ea2ad56756e Author: skoppar Date: 2010-11-08 07:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/2ea2ad56756e Merge From sunita.koppar at sun.com Mon Nov 8 16:10:25 2010 From: sunita.koppar at sun.com (sunita.koppar at sun.com) Date: Mon, 08 Nov 2010 16:10:25 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20101108161026.B93F0477E7@hg.openjdk.java.net> Changeset: f134ad3db749 Author: skoppar Date: 2010-11-08 06:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/f134ad3db749 Merge Changeset: 76dc6c257c5c Author: skoppar Date: 2010-11-08 08:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/76dc6c257c5c Merge From sunita.koppar at sun.com Mon Nov 8 16:20:16 2010 From: sunita.koppar at sun.com (sunita.koppar at sun.com) Date: Mon, 08 Nov 2010 16:20:16 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20101108162017.A505A477E8@hg.openjdk.java.net> Changeset: c3e970e8f2cb Author: skoppar Date: 2010-11-08 06:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/c3e970e8f2cb Merge Changeset: dcece16c706c Author: skoppar Date: 2010-11-08 08:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/dcece16c706c Merge From andreas.kohn at fredhopper.com Wed Nov 10 09:46:17 2010 From: andreas.kohn at fredhopper.com (Andreas Kohn) Date: Wed, 10 Nov 2010 10:46:17 +0100 Subject: Differences in Process#destroy() between Windows and Unix implementations In-Reply-To: <4CD9A8C1.3070307@oracle.com> References: <1289331084.8235.92.camel@tiamaria.ams.fredhopper.com> <4CD9A8C1.3070307@oracle.com> Message-ID: <1289382377.8235.103.camel@tiamaria.ams.fredhopper.com> On Wed, 2010-11-10 at 06:02 +1000, David Holmes wrote: > Hi Andreas, > > On 10/11/2010 5:31 AM, Andreas Kohn wrote: > > there seems to be a difference in behavior between Process#destroy() > > implementations on Windows and !Windows: on Windows TerminateProcess() > > [1] is called, which gives the process no way to react or in any way > > intercept the termination, while on Unix a simple SIGTERM is send which > > the process can just decide to ignore. [2] > > > > Is this intentional? > > As I understand it: yes and no. :) > > The problem is that neither version is necessarily what you always want. > SIGTERM is nice in that it allows the process to execute cleanup handlers > etc (such as an exec'ed JVM!) but I don't think Windows has an equivalent, > so we have to use TerminateProcess. On the flip side if SIGTERM fails we > have no way to really kill an errant process. > Thanks for the confirmation that this is an unfortunate leak of the OS details into the java library. Looking through the bugdatabase I found various related bugs now, so I did not file a new RFE just now: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4073195 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4333183 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6960070 > What we really need is two destroy methods: one that tries to terminate > nicely and one with "extrene prejudice". But again I'm not sure that Windows > would support that. I suppose we could also define the destroy() method to > try both approaches, if available, eg SIGTERM wait a while SIGKILL. But then > we need a way to specify "wait a while". I think if you have the ability as API user to indicate to Process whether it should "stop, please" or "die!" it would be perfectly enough. Windows may not provide the APIs for the "please" part, but then again this is as mentioned above and in the bugs very system specific, so having the Windows implementation do nothing in the "please" case should be fine, as this would be still classify as "best effort". Windows: Process#stop() { // nothing, windows doesn't do it } Process#destroy() { TerminateProcess(); } Unix: Process#stop() { kill(SIGTERM); } Process#destroy() { kill(SIGKILL); } Regards, -- Andreas > David Holmes > > > I do prefer the Windows behavior, mainly because I do create processes > > once in a while that simply fail to terminate due to bugs in their > > implementation, and having Process#destroy() as a last, and terminal, > > resort is very helpful to work-around those issues. > > > > Regards, > > -- > > Andreas > > > > [1] > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d87c1c06bbf9/src/windows/native/java/lang/ProcessImpl_md.c > > [2] > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d87c1c06bbf9/src/solaris/native/java/lang/UNIXProcess_md.c > > > > -- Never attribute to malice that which can be adequately explained by stupidity. -- Hanlon's Razor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From forax at univ-mlv.fr Wed Nov 10 10:48:39 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 10 Nov 2010 11:48:39 +0100 Subject: Differences in Process#destroy() between Windows and Unix implementations In-Reply-To: <1289382377.8235.103.camel@tiamaria.ams.fredhopper.com> References: <1289331084.8235.92.camel@tiamaria.ams.fredhopper.com> <4CD9A8C1.3070307@oracle.com> <1289382377.8235.103.camel@tiamaria.ams.fredhopper.com> Message-ID: <4CDA7887.7070002@univ-mlv.fr> The soft way to kill a process on windows to send a WM_CLOSE/WM_QUIT. http://stackoverflow.com/questions/2055753/how-to-gracefully-terminate-a-process R?mi Le 10/11/2010 10:46, Andreas Kohn a ?crit : > On Wed, 2010-11-10 at 06:02 +1000, David Holmes wrote: > >> Hi Andreas, >> >> On 10/11/2010 5:31 AM, Andreas Kohn wrote: >> >>> there seems to be a difference in behavior between Process#destroy() >>> implementations on Windows and !Windows: on Windows TerminateProcess() >>> [1] is called, which gives the process no way to react or in any way >>> intercept the termination, while on Unix a simple SIGTERM is send which >>> the process can just decide to ignore. [2] >>> >>> Is this intentional? >>> >> As I understand it: yes and no. :) >> >> The problem is that neither version is necessarily what you always want. >> SIGTERM is nice in that it allows the process to execute cleanup handlers >> etc (such as an exec'ed JVM!) but I don't think Windows has an equivalent, >> so we have to use TerminateProcess. On the flip side if SIGTERM fails we >> have no way to really kill an errant process. >> >> > Thanks for the confirmation that this is an unfortunate leak of the OS > details into the java library. Looking through the bugdatabase I found > various related bugs now, so I did not file a new RFE just now: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4073195 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4333183 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6960070 > > >> What we really need is two destroy methods: one that tries to >> > terminate > >> nicely and one with "extrene prejudice". But again I'm not sure that Windows >> would support that. I suppose we could also define the destroy() method to >> try both approaches, if available, eg SIGTERM wait a while SIGKILL. But then >> we need a way to specify "wait a while". >> > I think if you have the ability as API user to indicate to Process > whether it should "stop, please" or "die!" it would be perfectly enough. > > Windows may not provide the APIs for the "please" part, but then again > this is as mentioned above and in the bugs very system specific, so > having the Windows implementation do nothing in the "please" case should > be fine, as this would be still classify as "best effort". > > Windows: > Process#stop() { > // nothing, windows doesn't do it > } > Process#destroy() { > TerminateProcess(); > } > > Unix: > Process#stop() { > kill(SIGTERM); > } > Process#destroy() { > kill(SIGKILL); > } > > Regards, > -- > Andreas > > >> David Holmes >> >> >>> I do prefer the Windows behavior, mainly because I do create processes >>> once in a while that simply fail to terminate due to bugs in their >>> implementation, and having Process#destroy() as a last, and terminal, >>> resort is very helpful to work-around those issues. >>> >>> Regards, >>> -- >>> Andreas >>> >>> [1] >>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d87c1c06bbf9/src/windows/native/java/lang/ProcessImpl_md.c >>> [2] >>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d87c1c06bbf9/src/solaris/native/java/lang/UNIXProcess_md.c >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Nov 10 12:38:46 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 10 Nov 2010 12:38:46 +0000 Subject: hg: jdk7/tl/langtools: 6996914: Diamond inference: problem when accessing protected constructor Message-ID: <20101110123848.AD3374785E@hg.openjdk.java.net> Changeset: bce19889597e Author: mcimadamore Date: 2010-11-10 12:37 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bce19889597e 6996914: Diamond inference: problem when accessing protected constructor Summary: special resolution scheme for diamond inference needs to open up protected constructors in anon inner class creation Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/6996914/T6996914a.java + test/tools/javac/generics/diamond/6996914/T6996914b.java From anthony.petrov at oracle.com Wed Nov 10 12:49:17 2010 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 10 Nov 2010 15:49:17 +0300 Subject: Differences in Process#destroy() between Windows and Unix implementations In-Reply-To: <4CDA7887.7070002@univ-mlv.fr> References: <1289331084.8235.92.camel@tiamaria.ams.fredhopper.com> <4CD9A8C1.3070307@oracle.com> <1289382377.8235.103.camel@tiamaria.ams.fredhopper.com> <4CDA7887.7070002@univ-mlv.fr> Message-ID: <4CDA94CD.9000606@oracle.com> On 11/10/2010 1:48 PM, R?mi Forax wrote: > The soft way to kill a process on windows to send a WM_CLOSE/WM_QUIT. > http://stackoverflow.com/questions/2055753/how-to-gracefully-terminate-a-process This only works for GUI applications that process window messages (e.g. AWT or Swing apps). If an application is GUI-less and doesn't create native windows, there's nothing to send this message to. -- best regards, Anthony > > R?mi > > > Le 10/11/2010 10:46, Andreas Kohn a ?crit : >> On Wed, 2010-11-10 at 06:02 +1000, David Holmes wrote: >> >>> Hi Andreas, >>> >>> On 10/11/2010 5:31 AM, Andreas Kohn wrote: >>> >>>> there seems to be a difference in behavior between Process#destroy() >>>> implementations on Windows and !Windows: on Windows TerminateProcess() >>>> [1] is called, which gives the process no way to react or in any way >>>> intercept the termination, while on Unix a simple SIGTERM is send which >>>> the process can just decide to ignore. [2] >>>> >>>> Is this intentional? >>>> >>> As I understand it: yes and no. :) >>> >>> The problem is that neither version is necessarily what you always want. >>> SIGTERM is nice in that it allows the process to execute cleanup handlers >>> etc (such as an exec'ed JVM!) but I don't think Windows has an equivalent, >>> so we have to use TerminateProcess. On the flip side if SIGTERM fails we >>> have no way to really kill an errant process. >>> >>> >> Thanks for the confirmation that this is an unfortunate leak of the OS >> details into the java library. Looking through the bugdatabase I found >> various related bugs now, so I did not file a new RFE just now: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4073195 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4333183 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6960070 >> >> >>> What we really need is two destroy methods: one that tries to >>> >> terminate >> >>> nicely and one with "extrene prejudice". But again I'm not sure that Windows >>> would support that. I suppose we could also define the destroy() method to >>> try both approaches, if available, eg SIGTERM wait a while SIGKILL. But then >>> we need a way to specify "wait a while". >>> >> I think if you have the ability as API user to indicate to Process >> whether it should "stop, please" or "die!" it would be perfectly enough. >> >> Windows may not provide the APIs for the "please" part, but then again >> this is as mentioned above and in the bugs very system specific, so >> having the Windows implementation do nothing in the "please" case should >> be fine, as this would be still classify as "best effort". >> >> Windows: >> Process#stop() { >> // nothing, windows doesn't do it >> } >> Process#destroy() { >> TerminateProcess(); >> } >> >> Unix: >> Process#stop() { >> kill(SIGTERM); >> } >> Process#destroy() { >> kill(SIGKILL); >> } >> >> Regards, >> -- >> Andreas >> >> >>> David Holmes >>> >>> >>>> I do prefer the Windows behavior, mainly because I do create processes >>>> once in a while that simply fail to terminate due to bugs in their >>>> implementation, and having Process#destroy() as a last, and terminal, >>>> resort is very helpful to work-around those issues. >>>> >>>> Regards, >>>> -- >>>> Andreas >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d87c1c06bbf9/src/windows/native/java/lang/ProcessImpl_md.c >>>> [2] >>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d87c1c06bbf9/src/solaris/native/java/lang/UNIXProcess_md.c >>>> >>>> >>>> >> > From Alan.Bateman at oracle.com Wed Nov 10 12:55:44 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Nov 2010 12:55:44 +0000 Subject: Differences in Process#destroy() between Windows and Unix implementations In-Reply-To: <4CDA7887.7070002@univ-mlv.fr> References: <1289331084.8235.92.camel@tiamaria.ams.fredhopper.com> <4CD9A8C1.3070307@oracle.com> <1289382377.8235.103.camel@tiamaria.ams.fredhopper.com> <4CDA7887.7070002@univ-mlv.fr> Message-ID: <4CDA9650.8050305@oracle.com> R?mi Forax wrote: > The soft way to kill a process on windows to send a WM_CLOSE/WM_QUIT. > http://stackoverflow.com/questions/2055753/how-to-gracefully-terminate-a-process > > R?mi Yes, that could work for graphical/foreground applications but there is also the issue of services or applications that don't have a UI. In general, this request to destroy a process is just one of many things that need to be done to improve the support (and notion) of process in the API. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From john_platts at hotmail.com Wed Nov 10 14:59:32 2010 From: john_platts at hotmail.com (John Platts) Date: Wed, 10 Nov 2010 08:59:32 -0600 Subject: Java SE Mobile Profile Message-ID: Here are the reasons why a Java SE Mobile Profile is really needed: - Java ME does not support all of the Java SE 5, 6, and 7 language features. - Even though the Android platform is not a Java SE or Java ME implementation, the Android platform supports Java SE 5 and 6 language features plus API's found in Java SE 5 and 6 but missing in Java ME. - Some Java ME implementations do not comply with the Java SE 5 or later memory model. Requiring support for the Java SE 5 and later memory model will improve portability of mobile applications to both desktop platforms and other mobile platforms. Furthermore, many mobile devices use processors that are not based on the x86 architecture, and requiring support for the Java SE 5 and later memory model will improve consistency across mobile platforms since some of these devices have processors that require memory barriers to ensure correctness of volatile reads, volatile writes, and synchronization. - Some of the Java SE 5 and later core API's are not available on Java ME platforms, although implementations of many of the Java SE 5, 6, and 7 core API's are usable on mobile platforms. - Porting Java-based applications to mobile platforms is not always easy because Java ME lacks language features and API's available in Java SE 5 and later. - Supporting the Java SE Concurrency Utilities API (JSR 166) on mobile platforms improves portability, performance, and thread safety. - Some of the JVM programming languages are dependent on features not available on the Java ME platform. Adding support for API's that these programming languages depend upon will enable mobile applications to be developed in other programming languages. One of the API's that would be provided in the Java SE Mobile Profile is support for JSR 292, which provides support for dynamically typed languages on the Java SE platform. - The standard profile of Java SE has a lot of classes that are currently required by the Java SE specification, but providing a mobile profile that does not require the implementation of all of the classes required by the Java SE standard profile will reduce the footprint while retaining compatibility and portability. Java SE Mobile Profile implementations must implement all of the classes and methods required by the Java SE Mobile Profile specification. - Advances in mobile device technology allow for a footprint that is larger than the Java ME implementation. These mobile devices can take advantage of a Java SE Mobile Profile implementation, which has a smaller footprint than a typical Java SE implementation. Here are the goals of the Java SE Mobile Profile: - Provide a smaller footprint for mobile devices - Support all Java SE 5, 6, and 7 language features - Provide support for a subset of the Java SE 6 and 7 API's on mobile platform - Improve competition against Android-based devices, Apple iOS-based devices, and Microsoft Windows Mobile devices - Ease porting of Android-based and Java ME-based applications to the Java SE Mobile Profile - Improve portability of Java SE applications to mobile platforms - Make it easier to develop Java-based applications for mobile platforms - Make it easier to share code with both mobile platforms and desktop platforms (at both the binary and source code levels) - Support a mobile version of the NetBeans platform on the Java SE Mobile Profile. There is already a mobile version of the Eclipse Platform called eRCP, but eRCP is based on Java ME plus the Eclipse eSWT API. NetBeans Platform 6.9 and later is dependent on Java SE 6 APIs and language features. The Java SE Mobile Profile will make it possible to support a mobile version of the NetBeans platform. Here is a list of some of the packages that would be part of the Java SE Mobile Profile: - java.applet - java.awt - java.awt.color - java.awt.datatransfer - java.awt.event - java.awt.font - java.awt.geom - java.awt.im - java.awt.image - java.beans - java.dyn - java.io - java.lang - java.lang.ref - java.lang.reflect - java.math - java.net - java.nio.channels - java.nio.channels.spi - java.nio.charset - java.nio.charset.spi - java.nio.file - java.nio.file.attribute - java.nio.file.spi - java.rmi - java.rmi.registry - java.security - java.security.acl - java.security.cert - java.security.interfaces - java.security.spec - java.sql - java.text - java.util - java.util.concurrent - java.util.concurrent.atomic - java.util.concurrent.locks - java.util.jar - java.util.zip - javax.imageio - javax.imageio.event - javax.imageio.metadata - javax.imageio.stream - javax.security.auth.x500 - javax.sql - javax.swing - javax.swing.border - javax.swing.event - javax.swing.plaf - javax.swing.table - javax.swing.text - javax.swing.tree - javax.swing.undo A Java SE Mobile Profile implementation could be provided by adapting the OpenJDK7 class library and removing classes that are not needed on mobile devices. A VM implementation could be provided by either optimizing the HotSpot VM found in OpenJDK 7 to minimize the footprint and provide performance on mobile devices, or modifying the phoneME VM to support Java SE 5, 6, and 7 features and the Java SE mobile profile. JVM implementations targeting the Java SE mobile profile can be easily retargeted to support the Java SE standard profile in the following use cases: - Netbooks - Virtualized servers - Virtualized desktops From christian.thalinger at oracle.com Wed Nov 10 15:58:52 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 10 Nov 2010 16:58:52 +0100 Subject: crash in Java_sun_awt_X11_XToolkit_getNumberOfButtonsImpl on solaris-sparcv9 Message-ID: <84827863-9EED-41B0-9D78-1B9F6749AE15@oracle.com> While testing one of my changes with CompileTheWorld I hit a problem: CompileTheWorld (1411) : com/sun/java/swing/plaf/motif/ MotifInternalFrameTitlePane$Title = = = = = = ======================================================================== Unexpected Error ------------------------------------------------------------------------------ SIGBUS (0xa) at pc=0xffffffff76c05264, pid=20849, tid=1 Do you want to debug the problem? To debug, run 'dbx - 20849'; then switch to thread 1 Enter 'yes' to launch dbx automatically (PATH must include dbx) Otherwise, press RETURN to abort... = = = = = = ======================================================================== The debugger shows that it seems to be a problem in getNumButtons: ---- called from signal handler with signal 10 (SIGBUS) ------ [10] XListInputDevices(0x10118d0d0, 0xffffffff7fffb710, 0x1, 0x10172d218, 0x10172d3d8, 0x10172d554), at 0xffffffff76c05264 [11] getNumButtons() (optimized), at 0xffffffff77c1db40 (line ~950) in "XToolkit.c" [12] Java_sun_awt_X11_XToolkit_getNumberOfButtonsImpl(env = , cls = ) (optimized), at 0xffffffff77c1da34 (line ~925) in "XToolkit.c" Is this a known issue? I couldn't find anything related in Bugster but it also could be a VM problem. -- Christian From forax at univ-mlv.fr Wed Nov 10 17:00:54 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 10 Nov 2010 18:00:54 +0100 Subject: Differences in Process#destroy() between Windows and Unix implementations In-Reply-To: <4CDA9650.8050305@oracle.com> References: <1289331084.8235.92.camel@tiamaria.ams.fredhopper.com> <4CD9A8C1.3070307@oracle.com> <1289382377.8235.103.camel@tiamaria.ams.fredhopper.com> <4CDA7887.7070002@univ-mlv.fr> <4CDA9650.8050305@oracle.com> Message-ID: <4CDACFC6.4060204@univ-mlv.fr> Le 10/11/2010 13:55, Alan Bateman a ?crit : > R?mi Forax wrote: >> The soft way to kill a process on windows to send a WM_CLOSE/WM_QUIT. >> http://stackoverflow.com/questions/2055753/how-to-gracefully-terminate-a-process >> >> R?mi > Yes, that could work for graphical/foreground applications but there > is also the issue of services or applications that don't have a UI. For the record, I have seen several applications that aren't GUI based that spawn an event queue only to be gracefully killed and appearing as a task in the windows task panel. > > In general, this request to destroy a process is just one of many > things that need to be done to improve the support (and notion) of > process in the API. Agree. > > -Alan R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.petrov at oracle.com Wed Nov 10 17:04:09 2010 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 10 Nov 2010 20:04:09 +0300 Subject: crash in Java_sun_awt_X11_XToolkit_getNumberOfButtonsImpl on solaris-sparcv9 In-Reply-To: <84827863-9EED-41B0-9D78-1B9F6749AE15@oracle.com> References: <84827863-9EED-41B0-9D78-1B9F6749AE15@oracle.com> Message-ID: <4CDAD089.6040008@oracle.com> [ bcc'ing core-libs-dev@, and cc'ing awt-dev@ instead ] Hi Christian, I don't recall exactly this problem reported. Let's ask Andrei (CC'ed) about that. -- best regards, Anthony On 11/10/2010 6:58 PM, Christian Thalinger wrote: > While testing one of my changes with CompileTheWorld I hit a problem: > > CompileTheWorld (1411) : > com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane$Title > ============================================================================== > > Unexpected Error > ------------------------------------------------------------------------------ > > SIGBUS (0xa) at pc=0xffffffff76c05264, pid=20849, tid=1 > > Do you want to debug the problem? > > To debug, run 'dbx - 20849'; then switch to thread 1 > Enter 'yes' to launch dbx automatically (PATH must include dbx) > Otherwise, press RETURN to abort... > ============================================================================== > > > The debugger shows that it seems to be a problem in getNumButtons: > > ---- called from signal handler with signal 10 (SIGBUS) ------ > [10] XListInputDevices(0x10118d0d0, 0xffffffff7fffb710, 0x1, > 0x10172d218, 0x10172d3d8, 0x10172d554), at 0xffffffff76c05264 > [11] getNumButtons() (optimized), at 0xffffffff77c1db40 (line ~950) in > "XToolkit.c" > [12] Java_sun_awt_X11_XToolkit_getNumberOfButtonsImpl(env = , cls = ) > (optimized), at 0xffffffff77c1da34 (line ~925) in "XToolkit.c" > > Is this a known issue? I couldn't find anything related in Bugster but > it also could be a VM problem. > > -- Christian From weijun.wang at oracle.com Thu Nov 11 07:57:10 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 11 Nov 2010 07:57:10 +0000 Subject: hg: jdk7/tl/jdk: 6987827: security/util/Resources.java needs improvement Message-ID: <20101111075725.A37E2478D4@hg.openjdk.java.net> Changeset: 4565d120e514 Author: weijun Date: 2010-11-11 15:51 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4565d120e514 6987827: security/util/Resources.java needs improvement Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/NTDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTNumericCredential.java ! src/share/classes/com/sun/security/auth/NTSid.java ! src/share/classes/com/sun/security/auth/NTSidDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidPrimaryGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidUserPrincipal.java ! src/share/classes/com/sun/security/auth/NTUserPrincipal.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/PolicyParser.java ! src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisPrincipal.java ! src/share/classes/com/sun/security/auth/SubjectCodeSource.java ! src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/UnixPrincipal.java ! src/share/classes/com/sun/security/auth/X500Principal.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/login/AppConfigurationEntry.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/auth/x500/X500Principal.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/PolicyParser.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/JarSignerResources.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/util/AuthResources.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/util/Resources/NewNamesFormat.java + test/sun/security/util/Resources/NewResourcesNames.java From Alan.Bateman at oracle.com Thu Nov 11 09:59:48 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Nov 2010 09:59:48 +0000 Subject: hg: jdk7/tl/jdk: 6843995: RowSet 1.1 updates In-Reply-To: References: <20100904175939.EA37F4770B@hg.openjdk.java.net> <4C83AF57.8060202@univ-mlv.fr> Message-ID: <4CDBBE94.2050900@oracle.com> Lance Andersen - Oracle wrote: > Hi Remi (and team), > > I made changes to SyncFactory and one other class for a similar error. > Also cleaned up a couple of other minor issues in these classes. > > The webrev can be found at http://cr.openjdk.java.net/~lancea/6982530/ > > > Thank you for catching the error. > > Regards > Lance I've looked through the updated webrev, and I don't see anything obviously wrong. I assume getJdbcRowSetResourceBundle could be a little bit more efficient so that it only has to read jpResBundle twice rather than 3 times during initialization but it's probably not an issue. You know this already, but some of this code could do with more clean-up. The formatting and code style is a bit inconsistent in places and of course there are several unused static fields that someone else mentioned. Doing this with a different CR make sense to me. -Alan. From Lance.Andersen at oracle.com Thu Nov 11 11:15:52 2010 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 11 Nov 2010 06:15:52 -0500 Subject: hg: jdk7/tl/jdk: 6843995: RowSet 1.1 updates In-Reply-To: <4CDBBE94.2050900@oracle.com> References: <20100904175939.EA37F4770B@hg.openjdk.java.net> <4C83AF57.8060202@univ-mlv.fr> <4CDBBE94.2050900@oracle.com> Message-ID: Thank you Alan. Yes I am planning on doing additional clean up across the code utilizing a separate CR. Regards, Lance On Nov 11, 2010, at 4:59 AM, Alan Bateman wrote: > Lance Andersen - Oracle wrote: >> Hi Remi (and team), >> >> I made changes to SyncFactory and one other class for a similar error. Also cleaned up a couple of other minor issues in these classes. >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/6982530/ >> >> Thank you for catching the error. >> >> Regards >> Lance > I've looked through the updated webrev, and I don't see anything obviously wrong. I assume getJdbcRowSetResourceBundle could be a little bit more efficient so that it only has to read jpResBundle twice rather than 3 times during initialization but it's probably not an issue. You know this already, but some of this code could do with more clean-up. The formatting and code style is a bit inconsistent in places and of course there are several unused static fields that someone else mentioned. Doing this with a different CR make sense to me. > > -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.x.srinivasan at oracle.com Thu Nov 11 17:29:05 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 11 Nov 2010 09:29:05 -0800 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton Message-ID: <4CDC27E1.9000909@oracle.COM> Hi, Appreciate a review of the pack200 cleanup work, in the following areas: 1. General generification of Collections. 2. fixed worthy findbugs items. 3. fixed worthy Netbeans nags. 4. Elimination of array/generics combination. The webrev is here: http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/ Thanks Kumar From Alan.Bateman at oracle.com Thu Nov 11 18:15:27 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Nov 2010 18:15:27 +0000 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: <4CDC27E1.9000909@oracle.COM> References: <4CDC27E1.9000909@oracle.COM> Message-ID: <4CDC32BF.1020905@oracle.com> Kumar Srinivasan wrote: > Hi, > > Appreciate a review of the pack200 cleanup work, in the following areas: > > 1. General generification of Collections. > 2. fixed worthy findbugs items. > 3. fixed worthy Netbeans nags. > 4. Elimination of array/generics combination. > > The webrev is here: > http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/ > > Thanks > Kumar > Kumar - I just scanned this (sorry, I don't have time to do a detailed review). - is Attribute.isEmpty right? or rather should ""==null be replaced by false? - in BandStructure.java, can basicCodingIndexes be final? - can Package.getHighestClassVersion use for-each? Same thing in ClassWriter.writeAttributes. - the indentation in PackerImpl.java at line 143 - you've renamed locals in several places - is that because they are hiding fields or something else? - does the new switch statement in Driver.main need a default? (just wondering if FindBugs will notice that). -Alan. From brian.goetz at oracle.com Thu Nov 11 19:06:35 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 11 Nov 2010 14:06:35 -0500 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: <4CDC27E1.9000909@oracle.COM> References: <4CDC27E1.9000909@oracle.COM> Message-ID: <4CDC3EBB.20500@oracle.com> Mostly style issues, but at least one likely bug. In a few places, you've used @SuppressWarnings("unchecked"). While this may well be unavoidable, it is worth factoring this out into the smallest possible chunk. For BandStructure, you've applied it to the whole class, and there's some big methods that use it too. You can usually get it down to a small "makeArrayOfGenericFoo" method, since this is the most common source of non-fixable unchecked warnings. Also using an interface like Constants to import symbols is an antipattern and is better replaced with static imports. In ClassReader you've replaced use of new Integer() and friends with Integer.valueOf(), but its better style to go all the way and just use autoboxing. In Instruction the equals() method takes into account bc, w, length, and bytes, but the hashCode() method also takes into account pc. This may violate the "equal objects must have equal hashcodes" rule. Throughout you've changed loops from for (Iterator i=...) to for (Iterator i=...) but didn't go all the way and just use foreach loops. PropMap should extend TreeMap by composition, not extension. This implementation is subject to the hazards outlined in the Effective Java item "Prefer composition to extension." (For example you override put() but not putAll(), but this idiom cannot be made to work without tightly coupling it to the superclass implementation.) On 11/11/2010 12:29 PM, Kumar Srinivasan wrote: > Hi, > > Appreciate a review of the pack200 cleanup work, in the following areas: > > 1. General generification of Collections. > 2. fixed worthy findbugs items. > 3. fixed worthy Netbeans nags. > 4. Elimination of array/generics combination. > > The webrev is here: > http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/ > > Thanks > Kumar > From mike.duigou at oracle.com Thu Nov 11 19:08:31 2010 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 11 Nov 2010 19:08:31 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101111190900.BE459478F2@hg.openjdk.java.net> Changeset: aab6e875eb52 Author: mduigou Date: 2010-11-11 11:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aab6e875eb52 6465367: (coll) Typo in TreeMap documentation Reviewed-by: alanb, briangoetz ! src/share/classes/java/util/TreeMap.java Changeset: ca73653c0329 Author: mduigou Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ca73653c0329 Merge From kumar.x.srinivasan at oracle.com Thu Nov 11 19:26:35 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 11 Nov 2010 11:26:35 -0800 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: <4CDC3EBB.20500@oracle.com> References: <4CDC27E1.9000909@oracle.COM> <4CDC3EBB.20500@oracle.com> Message-ID: <4CDC436B.4030709@oracle.COM> On 11/11/2010 11:06 AM, Brian Goetz wrote: > Mostly style issues, but at least one likely bug. > > In a few places, you've used @SuppressWarnings("unchecked"). While > this may well be unavoidable, it is worth factoring this out into the > smallest possible chunk. For BandStructure, you've applied it to the > whole class, and there's some big methods that use it too. You can > usually get it down to a small "makeArrayOfGenericFoo" method, since > this is the most common source of non-fixable unchecked warnings. I will look into this, and see if I can break it up. > > Also using an interface like Constants to import symbols is an > antipattern and is better replaced with static imports. > will look into it. > In ClassReader you've replaced use of new Integer() and friends with > Integer.valueOf(), but its better style to go all the way and just use > autoboxing. will look into it. > > In Instruction the equals() method takes into account bc, w, length, > and bytes, but the hashCode() method also takes into account pc. This > may violate the "equal objects must have equal hashcodes" rule. will look into it. > > Throughout you've changed loops from > for (Iterator i=...) > to > for (Iterator i=...) > but didn't go all the way and just use foreach loops. ah, there are places where we need "i" those that don't have been replaced with for-each. > > PropMap should extend TreeMap by composition, not extension. This > implementation is subject to the hazards outlined in the Effective > Java item "Prefer composition to extension." (For example you > override put() but not putAll(), but this idiom cannot be made to work > without tightly coupling it to the superclass implementation.) I will see what I can do here. Kumar > > On 11/11/2010 12:29 PM, Kumar Srinivasan wrote: >> Hi, >> >> Appreciate a review of the pack200 cleanup work, in the following areas: >> >> 1. General generification of Collections. >> 2. fixed worthy findbugs items. >> 3. fixed worthy Netbeans nags. >> 4. Elimination of array/generics combination. >> >> The webrev is here: >> http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/ >> >> Thanks >> Kumar >> From kelly.ohair at oracle.com Thu Nov 11 19:34:45 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 11 Nov 2010 11:34:45 -0800 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: <4CDC27E1.9000909@oracle.COM> References: <4CDC27E1.9000909@oracle.COM> Message-ID: So some of these changes are using the new jdk7 language features? (diamond operator) Is this a first, or is this happening already? Just curious. http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/src/share/classes/com/sun/java/util/jar/pack/Attribute.java.sdiff.html 460 return (layout == null ? "" == null : layout.equals("")); I'd use return "".equals(layout); I wasn't able to look at much more, I'll try to later... Just thought I'd pass on what I saw. -kto On Nov 11, 2010, at 9:29 AM, Kumar Srinivasan wrote: > Hi, > > Appreciate a review of the pack200 cleanup work, in the following > areas: > > 1. General generification of Collections. > 2. fixed worthy findbugs items. > 3. fixed worthy Netbeans nags. > 4. Elimination of array/generics combination. > > The webrev is here: > http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/ > > Thanks > Kumar > From kumar.x.srinivasan at oracle.com Thu Nov 11 19:34:46 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 11 Nov 2010 11:34:46 -0800 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: <4CDC32BF.1020905@oracle.com> References: <4CDC27E1.9000909@oracle.COM> <4CDC32BF.1020905@oracle.com> Message-ID: <4CDC4556.5090009@oracle.COM> Hi Alan, Brian, Thanks! I will look into both your comments. > Kumar - I just scanned this (sorry, I don't have time to do a detailed > review). > > - is Attribute.isEmpty right? or rather should ""==null be replaced by > false? yes, I will redo this. > - in BandStructure.java, can basicCodingIndexes be final? it is final am I missing something ? > - can Package.getHighestClassVersion use for-each? Same thing in > ClassWriter.writeAttributes. oops I think I missed this one I think Brian also noticed this will fix them. > - the indentation in PackerImpl.java at line 143 will do. > - you've renamed locals in several places - is that because they are > hiding fields or something else? right it is a NB nag saying the variable hides a field. > - does the new switch statement in Driver.main need a default? (just > wondering if FindBugs will notice that). No it did not, but I will recheck. Kumar > > -Alan. From kumar.x.srinivasan at oracle.COM Thu Nov 11 19:38:15 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 11 Nov 2010 11:38:15 -0800 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: References: <4CDC27E1.9000909@oracle.COM> Message-ID: <4CDC4627.5020402@oracle.COM> > So some of these changes are using the new jdk7 language features? > (diamond operator) > Is this a first, or is this happening already? Just curious. decided to use it, put NB on autopilot. :-) > > http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/src/share/classes/com/sun/java/util/jar/pack/Attribute.java.sdiff.html > > 460 return (layout == null ? "" == null : > layout.equals("")); > I'd use return "".equals(layout); Will fix it. Thanks Kumar > > I wasn't able to look at much more, I'll try to later... Just thought > I'd pass on what I saw. > > -kto > > On Nov 11, 2010, at 9:29 AM, Kumar Srinivasan wrote: > >> Hi, >> >> Appreciate a review of the pack200 cleanup work, in the following areas: >> >> 1. General generification of Collections. >> 2. fixed worthy findbugs items. >> 3. fixed worthy Netbeans nags. >> 4. Elimination of array/generics combination. >> >> The webrev is here: >> http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/ >> >> Thanks >> Kumar >> > From forax at univ-mlv.fr Thu Nov 11 20:04:46 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 11 Nov 2010 21:04:46 +0100 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: References: <4CDC27E1.9000909@oracle.COM> Message-ID: <4CDC4C5E.8070804@univ-mlv.fr> Le 11/11/2010 20:34, Kelly O'Hair a ?crit : > So some of these changes are using the new jdk7 language features? > (diamond operator) > Is this a first, or is this happening already? Just curious. It's not the first time. I have seen it time to time. Mark (Reinhold) was the first to push a patch using the diamond operator in jigsaw tree. > > http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/src/share/classes/com/sun/java/util/jar/pack/Attribute.java.sdiff.html > > 460 return (layout == null ? "" == null : > layout.equals("")); > I'd use return "".equals(layout); > > I wasn't able to look at much more, I'll try to later... Just thought > I'd pass on what I saw. > > -kto R?mi From kumar.x.srinivasan at oracle.COM Thu Nov 11 21:56:53 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 11 Nov 2010 13:56:53 -0800 Subject: Please review -XshowSettings a java launcher option. Message-ID: <4CDC66A5.8000709@oracle.COM> Hi All, Please review the following: http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ This will print all the known settings/properties/locales supported and known to Java, this has been a long standing request. A sample output attached below. Note: the -X option specifically is being used so we can evolve this option and add more useful information, in future versions of java. Thanks Kumar -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: out.txt URL: From mandy.chung at oracle.com Thu Nov 11 23:09:46 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 Nov 2010 15:09:46 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDC66A5.8000709@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> Message-ID: <4CDC77BA.2010603@oracle.com> On 11/11/10 13:56, Kumar Srinivasan wrote: > Hi All, > > Please review the following: > > http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ Some comments: java.c line 1031: this doesn't catch invalid option if it has the -XshowSettings prefix e.g. -XshowSettingsJunk. line 1032: Perhaps you could store the suboption ("all", "vm", etc) rather than the entire option string. line 1507-1511: should these lines align with the argument "env" to CallStaticVoidMethod method in line 1506? LauncherHelper.java line 106-109: if optionFlag is just the suboption to -XshowSettings, these lines can be removed. line 150-152: Runtime.maxMemory() is not equivalent to -Xmx value. Perhaps -XshowSettings always prints Runtime.maxMemory() and print -Xmx if set in the command line? line 176, 188, 190-191, 195, and other lines in printPrintLocales and printLocale methods: - the assignment to the buf and out variable to itself (returned from StringBuffer.append() method) is not necessary. line 174: would it be better to pass the StringBuilder to the printPrintValue method so that it can avoid creating a new StringBuilder instance for each property? line 213-214: same comment as the above. And should it use StringBuilder instead? Mandy > > This will print all the known settings/properties/locales > supported and known to Java, this has been a long standing request. > > A sample output attached below. > > Note: the -X option specifically is being used so we can evolve this > option > and add more useful information, in future versions of java. > > Thanks > Kumar > > > From sean.coffey at oracle.com Thu Nov 11 23:41:15 2010 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 11 Nov 2010 23:41:15 +0000 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDC66A5.8000709@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> Message-ID: <4CDC7F1B.4010009@oracle.com> Kumar, Great to see this functionality being added. Another useful piece of data may be the tzdata version used by the JRE. I'll open up another thread on this with you. It should be possible to get some helper code added to parse tzdata version. This could always be added at a later date of course. regards, Sean. On 11/11/2010 21:56, Kumar Srinivasan wrote: > Hi All, > > Please review the following: > > http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ > > This will print all the known settings/properties/locales > supported and known to Java, this has been a long standing request. > > A sample output attached below. > > Note: the -X option specifically is being used so we can evolve this > option > and add more useful information, in future versions of java. > > Thanks > Kumar > > > From kumar.x.srinivasan at oracle.COM Fri Nov 12 00:42:47 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 11 Nov 2010 16:42:47 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDC77BA.2010603@oracle.com> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> Message-ID: <4CDC8D87.7030709@oracle.COM> Hi Mandy, > > java.c > line 1031: this doesn't catch invalid option if it has the > -XshowSettings prefix e.g. -XshowSettingsJunk. Will fix it. > line 1032: Perhaps you could store the suboption ("all", "vm", etc) > rather than the entire option string. I want to keep all the parsing logic as much as possible in java. > line 1507-1511: should these lines align with the argument "env" to > CallStaticVoidMethod method in line 1506? Fixed. > > LauncherHelper.java > line 106-109: if optionFlag is just the suboption to -XshowSettings, > these lines can be removed. > line 150-152: Runtime.maxMemory() is not equivalent to -Xmx value. > Perhaps -XshowSettings always prints Runtime.maxMemory() and print > -Xmx if set in the command line? That is exactly what is happening ie. if the launcher has been given the -Xmx flag then that is displayed, if not LauncherHelper will use some means to display any value it can get from Java libraries so for now we use Runtime.maxMemory(). > > line 176, 188, 190-191, 195, and other lines in printPrintLocales and > printLocale methods: > - the assignment to the buf and out variable to itself (returned from > StringBuffer.append() method) is not necessary. Yes fixed, I missed these. > > line 174: would it be better to pass the StringBuilder to the > printPrintValue method so that it can avoid creating a new > StringBuilder instance for each property? We have to create the StringBuilder somewhere it is either in the prettyPrintValue or the calling method, I will convert it to StringBuilder and pass it into prettyPrintValue. > > line 213-214: same comment as the above. And should it use > StringBuilder instead? Yes. Thanks for the review.! Kumar > > Mandy >> >> This will print all the known settings/properties/locales >> supported and known to Java, this has been a long standing request. >> >> A sample output attached below. >> >> Note: the -X option specifically is being used so we can evolve this >> option >> and add more useful information, in future versions of java. >> >> Thanks >> Kumar >> >> >> > From schlosna at gmail.com Fri Nov 12 01:47:12 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 11 Nov 2010 20:47:12 -0500 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDC8D87.7030709@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> Message-ID: Kumar, Do you need all of the StringBuilder/StringBuffer to buffer the output prior to writing to the PrintStream? Using the PrintStream directly would also allow it to handle the newlines. I was envisaging something like this: private static void printVmSettings(PrintStream ostream, long maxHeapSize, long stackSize, boolean isServer) { String maxHeapSizeString = scaleValue((maxHeapSize == 0) ? Runtime.getRuntime().maxMemory() : maxHeapSize); String stackSizeString = (stackSize == 0) ? "OS default" : scaleValue(stackSize); ostream.println(); ostream.println(VM_SETTINGS); ostream.print(INDENT + "Stack Size (-Xss): "); ostream.println(stackSizeString); ostream.print(INDENT + "Max. Heap Size (-Xmx): "); ostream.println(maxHeapSizeString); ostream.print(INDENT + "Ergonomics Class (server or client): "); ostream.println((isServer) ? "server" : "client"); ostream.print(INDENT + "Using VM: "); ostream.println(System.getProperty("java.vm.name")); } private static boolean isPath(String key) { return key.endsWith(".dirs") || key.endsWith(".path"); } private static void prettyPrintValue(PrintStream ostream, String key, String value) { ostream.print(INDENT); ostream.print(key); ostream.print(" = "); if (!isPath(key)) { ostream.println(value); return; } // pretty print the path values as a list String pathsep = System.getProperty("path.separator"); String[] values = value.split(pathsep); int len = values.length; int lastline = len - 1; for (int i = 0 ; i < len ; i++) { if (i == 0) { // first line treated specially ostream.print(values[i]); ostream.println(pathsep); } else { // following lines prefix with indents ostream.print(INDENT + INDENT); ostream.print(values[i]); if (i != lastline) { // if not the last line suffix the pathsep ostream.print(pathsep); } ostream.println(); } } } private static void printProperties(PrintStream ostream) { Properties p = System.getProperties(); List sortedPropertyKeys = new ArrayList<>(); sortedPropertyKeys.addAll(p.stringPropertyNames()); Collections.sort(sortedPropertyKeys); ostream.println(); ostream.println(PROP_SETTINGS); for (String x : sortedPropertyKeys) { prettyPrintValue(ostream, x, p.getProperty(x)); } } private static void prettyPrintLocales(PrintStream ostream) { ostream.println(); ostream.print(INDENT + "available locales = "); Locale[] locales = Locale.getAvailableLocales(); int len = locales.length; int lastline = len - 1 ; for (int i = 0 ; i < len ; i++) { ostream.print(locales[i]); if (i != lastline) { ostream.print(","); } // print columns of 8 if ((i + 1) % 8 == 0) { ostream.println(); ostream.print(INDENT + INDENT); } else { ostream.print(" "); } } } private static void printLocale(PrintStream ostream) { Locale locale = Locale.getDefault(); ostream.println(); ostream.println(LOCALE_SETTINGS); ostream.print(INDENT+"default locale: "); ostream.print(locale.getDisplayLanguage()); prettyPrintLocales(ostream); ostream.println(); } - Dave On Thu, Nov 11, 2010 at 7:42 PM, Kumar Srinivasan wrote: > > Hi Mandy, > >> >> java.c >> line 1031: this doesn't catch invalid option if it has the -XshowSettings prefix e.g. -XshowSettingsJunk. > > Will fix it. > >> line 1032: Perhaps you could store the suboption ("all", "vm", etc) rather than the entire option string. > > I want to keep all the parsing logic as much as possible ?in java. > >> line 1507-1511: should these lines align with the argument "env" ?to CallStaticVoidMethod method in line 1506? > > Fixed. >> >> LauncherHelper.java >> line 106-109: if optionFlag is just the suboption to -XshowSettings, these lines can be removed. >> line 150-152: Runtime.maxMemory() is not equivalent to -Xmx value. ?Perhaps -XshowSettings always prints Runtime.maxMemory() and print -Xmx if set in the command line? > > That is exactly what is happening ie. if the launcher has been given the -Xmx flag > then that is displayed, if not LauncherHelper will use some means to display any > value it can get from Java libraries so for now we use Runtime.maxMemory(). > > >> >> line 176, 188, 190-191, 195, and other lines in printPrintLocales and printLocale methods: >> - the assignment to the buf and out variable to itself (returned from StringBuffer.append() method) is not necessary. > > Yes fixed, I missed these. > >> >> line 174: would it be better to pass the StringBuilder to the printPrintValue method so that it can avoid creating a new StringBuilder instance for each property? > > We have to create the StringBuilder somewhere it is either in the prettyPrintValue or the calling > method, I will convert it to StringBuilder and pass it into prettyPrintValue. > >> >> line 213-214: same comment as the above. ? And should it use StringBuilder instead? > > Yes. > > Thanks for the review.! > > Kumar > >> >> Mandy >>> >>> This will print all the known settings/properties/locales >>> supported and known ?to Java, this has ?been a long standing request. >>> >>> A sample output attached below. >>> >>> Note: the -X option specifically is being used so we can evolve this option >>> and add more useful information, in future versions of java. >>> >>> Thanks >>> Kumar >>> >>> >>> >> > From mandy.chung at oracle.com Fri Nov 12 01:57:28 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 Nov 2010 17:57:28 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDC8D87.7030709@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> Message-ID: <4CDC9F08.4070101@oracle.com> On 11/11/10 4:42 PM, Kumar Srinivasan wrote: >> line 1032: Perhaps you could store the suboption ("all", "vm", etc) >> rather than the entire option string. > > I want to keep all the parsing logic as much as possible in java. It depends when you are going to detect if the option is valid or not. If java.c does the check, I think the suboption value is available; or you could do the check in LauncherHelper too. >> >> LauncherHelper.java >> line 106-109: if optionFlag is just the suboption to -XshowSettings, >> these lines can be removed. >> line 150-152: Runtime.maxMemory() is not equivalent to -Xmx value. >> Perhaps -XshowSettings always prints Runtime.maxMemory() and print >> -Xmx if set in the command line? > > That is exactly what is happening ie. if the launcher has been given > the -Xmx flag > then that is displayed, if not LauncherHelper will use some means to > display any > value it can get from Java libraries so for now we use > Runtime.maxMemory(). > What I meant is that it should make it clear that they are two different values. Perhaps you can show two lines: -Xmx : VM default Runtime.maxMemory : xxx GB The default -Xmx value (i.e. MaxHeapSize) is available in the VM. It could include the default MaxHeapSize in the future. Mandy From David.Holmes at oracle.com Fri Nov 12 02:01:28 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 12 Nov 2010 12:01:28 +1000 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDC66A5.8000709@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> Message-ID: <4CDC9FF8.10404@oracle.com> Hi Kumar, Is the purpose here to report what command-line options were used or to report what particular settings are in effect? If the former then you do not need any defaults for the "not set" case. If the latter then you should really defer this to the VM itself for the "VM options", because as it stands: - if -Xmx is not set then Runtime.maxMemory() is not equivalent, so you are misleading the user (And why not report -Xms?) - if -Xss is not set the resulting value is not an OS default but a VM default - ServerClassMachine() does not take into account -Xint possibility (and will need updating for Tiered compilation) I'd be tempted to just drop the "VM options" part of this, unless you are going to make a call into the VM to obtain them. David Kumar Srinivasan said the following on 11/12/10 07:56: > Hi All, > > Please review the following: > > http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ > > This will print all the known settings/properties/locales > supported and known to Java, this has been a long standing request. > > A sample output attached below. > > Note: the -X option specifically is being used so we can evolve this option > and add more useful information, in future versions of java. > > Thanks > Kumar > > > From kumar.x.srinivasan at oracle.com Fri Nov 12 02:20:32 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 11 Nov 2010 18:20:32 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> Message-ID: <4CDCA470.5000600@oracle.COM> Hi David, Good idea, but I did not use that method because of all the String concatenation PrintStream.print has to perform, if so then we can simply use a String. So my thinking was to use the StringBuilder to assemble the String and print it out in one shot. ostream(INDENT + INDENT); or instead: ostream.print(INDENT); ostream.print(INDENT); ... .... that would mean more io calls. I have a time pressure to get this in, I can fix/address this later as a bug if need be. Thanks for your review. Kumar > Kumar, > > Do you need all of the StringBuilder/StringBuffer to buffer the output > prior to writing to the PrintStream? Using the PrintStream directly > would also allow it to handle the newlines. I was envisaging something > like this: > > private static void printVmSettings(PrintStream ostream, long maxHeapSize, > long stackSize, boolean isServer) { > > String maxHeapSizeString = scaleValue((maxHeapSize == 0) > ? Runtime.getRuntime().maxMemory() > : maxHeapSize); > > String stackSizeString = (stackSize == 0) > ? "OS default" > : scaleValue(stackSize); > > ostream.println(); > ostream.println(VM_SETTINGS); > ostream.print(INDENT + "Stack Size (-Xss): "); > ostream.println(stackSizeString); > ostream.print(INDENT + "Max. Heap Size (-Xmx): "); > ostream.println(maxHeapSizeString); > ostream.print(INDENT + "Ergonomics Class (server or client): "); > ostream.println((isServer) ? "server" : "client"); > ostream.print(INDENT + "Using VM: "); > ostream.println(System.getProperty("java.vm.name")); > } > > private static boolean isPath(String key) { > return key.endsWith(".dirs") || key.endsWith(".path"); > } > > private static void prettyPrintValue(PrintStream ostream, String key, > String value) { > ostream.print(INDENT); > ostream.print(key); > ostream.print(" = "); > > if (!isPath(key)) { > ostream.println(value); > return; > } > > // pretty print the path values as a list > String pathsep = System.getProperty("path.separator"); > String[] values = value.split(pathsep); > int len = values.length; > int lastline = len - 1; > for (int i = 0 ; i< len ; i++) { > if (i == 0) { // first line treated specially > ostream.print(values[i]); > ostream.println(pathsep); > } else { // following lines prefix with indents > ostream.print(INDENT + INDENT); > ostream.print(values[i]); > if (i != lastline) { // if not the last line suffix the pathsep > ostream.print(pathsep); > } > ostream.println(); > } > } > } > > private static void printProperties(PrintStream ostream) { > Properties p = System.getProperties(); > List sortedPropertyKeys = new ArrayList<>(); > sortedPropertyKeys.addAll(p.stringPropertyNames()); > Collections.sort(sortedPropertyKeys); > ostream.println(); > ostream.println(PROP_SETTINGS); > for (String x : sortedPropertyKeys) { > prettyPrintValue(ostream, x, p.getProperty(x)); > } > } > > private static void prettyPrintLocales(PrintStream ostream) { > ostream.println(); > ostream.print(INDENT + "available locales = "); > Locale[] locales = Locale.getAvailableLocales(); > int len = locales.length; > int lastline = len - 1 ; > for (int i = 0 ; i< len ; i++) { > ostream.print(locales[i]); > if (i != lastline) { > ostream.print(","); > } > // print columns of 8 > if ((i + 1) % 8 == 0) { > ostream.println(); > ostream.print(INDENT + INDENT); > } else { > ostream.print(" "); > } > } > } > > private static void printLocale(PrintStream ostream) { > Locale locale = Locale.getDefault(); > ostream.println(); > ostream.println(LOCALE_SETTINGS); > ostream.print(INDENT+"default locale: "); > ostream.print(locale.getDisplayLanguage()); > prettyPrintLocales(ostream); > ostream.println(); > } > > - Dave > > On Thu, Nov 11, 2010 at 7:42 PM, Kumar Srinivasan > wrote: >> Hi Mandy, >> >>> java.c >>> line 1031: this doesn't catch invalid option if it has the -XshowSettings prefix e.g. -XshowSettingsJunk. >> Will fix it. >> >>> line 1032: Perhaps you could store the suboption ("all", "vm", etc) rather than the entire option string. >> I want to keep all the parsing logic as much as possible in java. >> >>> line 1507-1511: should these lines align with the argument "env" to CallStaticVoidMethod method in line 1506? >> Fixed. >>> LauncherHelper.java >>> line 106-109: if optionFlag is just the suboption to -XshowSettings, these lines can be removed. >>> line 150-152: Runtime.maxMemory() is not equivalent to -Xmx value. Perhaps -XshowSettings always prints Runtime.maxMemory() and print -Xmx if set in the command line? >> That is exactly what is happening ie. if the launcher has been given the -Xmx flag >> then that is displayed, if not LauncherHelper will use some means to display any >> value it can get from Java libraries so for now we use Runtime.maxMemory(). >> >> >>> line 176, 188, 190-191, 195, and other lines in printPrintLocales and printLocale methods: >>> - the assignment to the buf and out variable to itself (returned from StringBuffer.append() method) is not necessary. >> Yes fixed, I missed these. >> >>> line 174: would it be better to pass the StringBuilder to the printPrintValue method so that it can avoid creating a new StringBuilder instance for each property? >> We have to create the StringBuilder somewhere it is either in the prettyPrintValue or the calling >> method, I will convert it to StringBuilder and pass it into prettyPrintValue. >> >>> line 213-214: same comment as the above. And should it use StringBuilder instead? >> Yes. >> >> Thanks for the review.! >> >> Kumar >> >>> Mandy >>>> This will print all the known settings/properties/locales >>>> supported and known to Java, this has been a long standing request. >>>> >>>> A sample output attached below. >>>> >>>> Note: the -X option specifically is being used so we can evolve this option >>>> and add more useful information, in future versions of java. >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>>> From mike.duigou at oracle.com Fri Nov 12 02:53:32 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 11 Nov 2010 18:53:32 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: References: Message-ID: On Nov 11 2010, at 13:56 , Kumar Srinivasan wrote: > A sample output attached below. Fantastic! - The colons on the path components seem unnecessary if each element is also going to be separated by line breaks - In the output for the property 'line.seperator' would it be possible to convert this to "\n" "\n\r" or "\r" as rather than including the character directly? - I agree with David Holmes that it should be made clear that these settings and defaults are the result of the command line options being applied rather than an echoing of the command line options. - Is assertions and system assertions status (when enabled) included in the report? Mike From schlosna at gmail.com Fri Nov 12 03:12:07 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 11 Nov 2010 22:12:07 -0500 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDCA470.5000600@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> <4CDCA470.5000600@oracle.COM> Message-ID: Kumar, No problem, if you have time pressures, I definitely understand. This is welcome functionality, we have our own similar implementation internally but it will be nice to have in OpenJDK. I am curious though about the concern for string concatenation on something like (INDENT + INDENT). As INDENT is defined as a static final String INDENT = " ", this concatenation is done at compilation time since "the expression is a compile-time constant expression" per JLS 15.18.1 [1] and 15.28 [2]. Any concatenations of non-constant String would be transformed to an implicit StringBuilder. In regards to additional I/O, doesn't OpenJDK's java.io.PrintStream have its own BufferedWriter, so the additional writes would already be buffered anyway, and writes wouldn't be ? [1] http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#39990 [2] http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#5313 - Dave On Thu, Nov 11, 2010 at 9:20 PM, Kumar Srinivasan wrote: > Hi David, > > Good idea, but ?I did not use that method ?because of all the String > concatenation ?PrintStream.print has ?to perform, if so then we can > simply use a String. > > So my thinking was to use the StringBuilder to assemble the String and > print it out in one shot. > > ostream(INDENT + INDENT); > > or instead: > ostream.print(INDENT); > ostream.print(INDENT); > ... > .... > > that would mean more io calls. > > I have a time pressure to get this in, I can fix/address this later as a bug > if need be. > > Thanks for your review. > > Kumar > >> Kumar, >> >> Do you need all of the StringBuilder/StringBuffer to buffer the output >> prior to writing to the PrintStream? Using the PrintStream directly >> would also allow it to handle the newlines. I was envisaging something >> like this: >> >> private static void printVmSettings(PrintStream ostream, long maxHeapSize, >> ? ? ? ? long stackSize, boolean isServer) { >> >> ? ? String maxHeapSizeString = scaleValue((maxHeapSize == 0) >> ? ? ? ? ? ? ? Runtime.getRuntime().maxMemory() >> ? ? ? ? ? ? : maxHeapSize); >> >> ? ? String stackSizeString = (stackSize == 0) >> ? ? ? ? ? ? ? "OS default" >> ? ? ? ? ? ? : scaleValue(stackSize); >> >> ? ? ostream.println(); >> ? ? ostream.println(VM_SETTINGS); >> ? ? ostream.print(INDENT + "Stack Size (-Xss): "); >> ? ? ostream.println(stackSizeString); >> ? ? ostream.print(INDENT + "Max. Heap Size (-Xmx): "); >> ? ? ostream.println(maxHeapSizeString); >> ? ? ostream.print(INDENT + "Ergonomics Class (server or client): "); >> ? ? ostream.println((isServer) ? "server" : "client"); >> ? ? ostream.print(INDENT + "Using VM: "); >> ? ? ostream.println(System.getProperty("java.vm.name")); >> } >> >> private static boolean isPath(String key) { >> ? ? return key.endsWith(".dirs") || key.endsWith(".path"); >> } >> >> private static void prettyPrintValue(PrintStream ostream, String key, >> String value) { >> ? ? ostream.print(INDENT); >> ? ? ostream.print(key); >> ? ? ostream.print(" = "); >> >> ? ? if (!isPath(key)) { >> ? ? ? ? ostream.println(value); >> ? ? ? ? return; >> ? ? } >> >> ? ? // pretty print the path values as a list >> ? ? String pathsep = System.getProperty("path.separator"); >> ? ? String[] values = value.split(pathsep); >> ? ? int len = values.length; >> ? ? int lastline = len - 1; >> ? ? for (int i = 0 ; i< ?len ; i++) { >> ? ? ? ? if (i == 0) { // first line treated specially >> ? ? ? ? ? ? ostream.print(values[i]); >> ? ? ? ? ? ? ostream.println(pathsep); >> ? ? ? ? } else { // following lines prefix with indents >> ? ? ? ? ? ? ostream.print(INDENT + INDENT); >> ? ? ? ? ? ? ostream.print(values[i]); >> ? ? ? ? ? ? if (i != lastline) { // if not the last line suffix the >> pathsep >> ? ? ? ? ? ? ? ? ostream.print(pathsep); >> ? ? ? ? ? ? } >> ? ? ? ? ? ? ostream.println(); >> ? ? ? ? } >> ? ? } >> } >> >> private static void printProperties(PrintStream ostream) { >> ? ? Properties p = System.getProperties(); >> ? ? List ?sortedPropertyKeys = new ArrayList<>(); >> ? ? sortedPropertyKeys.addAll(p.stringPropertyNames()); >> ? ? Collections.sort(sortedPropertyKeys); >> ? ? ostream.println(); >> ? ? ostream.println(PROP_SETTINGS); >> ? ? for (String x : sortedPropertyKeys) { >> ? ? ? ? prettyPrintValue(ostream, x, p.getProperty(x)); >> ? ? } >> } >> >> private static void prettyPrintLocales(PrintStream ostream) { >> ? ? ostream.println(); >> ? ? ostream.print(INDENT + "available locales = "); >> ? ? Locale[] locales = Locale.getAvailableLocales(); >> ? ? int len = locales.length; >> ? ? int lastline = len - 1 ; >> ? ? for (int i = 0 ; i< ?len ; i++) { >> ? ? ? ? ostream.print(locales[i]); >> ? ? ? ? if (i != lastline) { >> ? ? ? ? ? ? ostream.print(","); >> ? ? ? ? } >> ? ? ? ? // print columns of 8 >> ? ? ? ? if ((i + 1) % 8 == 0) { >> ? ? ? ? ? ? ostream.println(); >> ? ? ? ? ? ? ostream.print(INDENT + INDENT); >> ? ? ? ? } else { >> ? ? ? ? ? ? ostream.print(" "); >> ? ? ? ? } >> ? ? } >> } >> >> private static void printLocale(PrintStream ostream) { >> ? ? Locale locale = Locale.getDefault(); >> ? ? ostream.println(); >> ? ? ostream.println(LOCALE_SETTINGS); >> ? ? ostream.print(INDENT+"default locale: "); >> ? ? ostream.print(locale.getDisplayLanguage()); >> ? ? prettyPrintLocales(ostream); >> ? ? ostream.println(); >> } >> >> - Dave >> >> On Thu, Nov 11, 2010 at 7:42 PM, Kumar Srinivasan >> ?wrote: >>> >>> Hi Mandy, >>> >>>> java.c >>>> line 1031: this doesn't catch invalid option if it has the >>>> -XshowSettings prefix e.g. -XshowSettingsJunk. >>> >>> Will fix it. >>> >>>> line 1032: Perhaps you could store the suboption ("all", "vm", etc) >>>> rather than the entire option string. >>> >>> I want to keep all the parsing logic as much as possible ?in java. >>> >>>> line 1507-1511: should these lines align with the argument "env" ?to >>>> CallStaticVoidMethod method in line 1506? >>> >>> Fixed. >>>> >>>> LauncherHelper.java >>>> line 106-109: if optionFlag is just the suboption to -XshowSettings, >>>> these lines can be removed. >>>> line 150-152: Runtime.maxMemory() is not equivalent to -Xmx value. >>>> ?Perhaps -XshowSettings always prints Runtime.maxMemory() and print -Xmx if >>>> set in the command line? >>> >>> That is exactly what is happening ie. if the launcher has been given the >>> -Xmx flag >>> then that is displayed, if not LauncherHelper will use some means to >>> display any >>> value it can get from Java libraries so for now we use >>> Runtime.maxMemory(). >>> >>> >>>> line 176, 188, 190-191, 195, and other lines in printPrintLocales and >>>> printLocale methods: >>>> - the assignment to the buf and out variable to itself (returned from >>>> StringBuffer.append() method) is not necessary. >>> >>> Yes fixed, I missed these. >>> >>>> line 174: would it be better to pass the StringBuilder to the >>>> printPrintValue method so that it can avoid creating a new StringBuilder >>>> instance for each property? >>> >>> We have to create the StringBuilder somewhere it is either in the >>> prettyPrintValue or the calling >>> method, I will convert it to StringBuilder and pass it into >>> prettyPrintValue. >>> >>>> line 213-214: same comment as the above. ? And should it use >>>> StringBuilder instead? >>> >>> Yes. >>> >>> Thanks for the review.! >>> >>> Kumar >>> >>>> Mandy >>>>> >>>>> This will print all the known settings/properties/locales >>>>> supported and known ?to Java, this has ?been a long standing request. >>>>> >>>>> A sample output attached below. >>>>> >>>>> Note: the -X option specifically is being used so we can evolve this >>>>> option >>>>> and add more useful information, in future versions of java. >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> >>>>> > > From kumar.x.srinivasan at oracle.COM Fri Nov 12 03:11:51 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 11 Nov 2010 19:11:51 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDC9FF8.10404@oracle.com> References: <4CDC66A5.8000709@oracle.COM> <4CDC9FF8.10404@oracle.com> Message-ID: <4CDCB077.2030208@oracle.COM> Hi Mr. Holmes, > Hi Kumar, > > Is the purpose here to report what command-line options were used or > to report what particular settings are in effect? If the former then > you do not need any defaults for the "not set" case. If the latter > then you should really defer this to the VM itself for the "VM > options", because as it stands: Right we need to defer it to the VM, jdk7++ ? I will file an RFE to do this. > > - if -Xmx is not set then Runtime.maxMemory() is not equivalent, so > you are misleading the user (And why not report -Xms?) No one beat me up on Xms so much as Xmx or max memory.:-) As for memory, IIRC I compared the values that java.lang.management.MemoryUsage.max which reports the same value as I get here. I will explain some of this in the help document, and maybe put a note next to one of these values such as 985M (approx.) > - if -Xss is not set the resulting value is not an OS default but a VM > default In the case of windows the VM has no preference so the launcher defaults back to the OS, but if the VM has a pref. then that would be reported, usually *nixes. > - ServerClassMachine() does not take into account -Xint possibility > (and will need updating for Tiered compilation) Absolutely when that becomes a reality. > > I'd be tempted to just drop the "VM options" part of this, unless you > are going to make a call into the VM to obtain them. I think I want to have it and put in the necessary VM hooks at a later stage. It would be good to get this in and get more feedback and enhance/evolve it in a future release. Thanks Kumar > > David > > Kumar Srinivasan said the following on 11/12/10 07:56: >> Hi All, >> >> Please review the following: >> >> http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ >> >> This will print all the known settings/properties/locales >> supported and known to Java, this has been a long standing request. >> >> A sample output attached below. >> >> Note: the -X option specifically is being used so we can evolve this >> option >> and add more useful information, in future versions of java. >> >> Thanks >> Kumar >> >> >> From xueming.shen at oracle.com Fri Nov 12 04:09:50 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Nov 2010 20:09:50 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDC66A5.8000709@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> Message-ID: <4CDCBE0E.5080002@oracle.com> Kumar, The scaleValue(longv) does not appear to handle the 1K, 1M, 1G and 1T correctly, shouldn't be v >= K/M/G/T ? 1024 for 1K is OK, byte number for 1M/G/T might be too much. Seems like you are "assembling" the bits yourself, why not use our "powerful" (sure, a little slower:-) j.u.Formatter, get a Formatter on top of a sb StringBuilder sb = new StringBuilder(); Formatter fm = new Formatter(sb); ... then pass the fm around and finally dump the sb.toString() to the out/err. This way you will have better control of the "spacing", the \n (with "%n") and might also bring in some "locale" sensitive benefits (maybe in the future). -Sherman On 11/11/2010 13:56, Kumar Srinivasan wrote: > Hi All, > > Please review the following: > > http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ > > This will print all the known settings/properties/locales > supported and known to Java, this has been a long standing request. > > A sample output attached below. > > Note: the -X option specifically is being used so we can evolve this > option > and add more useful information, in future versions of java. > > Thanks > Kumar > > > From David.Holmes at oracle.com Fri Nov 12 04:59:35 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 12 Nov 2010 14:59:35 +1000 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDCB077.2030208@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> <4CDC9FF8.10404@oracle.com> <4CDCB077.2030208@oracle.COM> Message-ID: <4CDCC9B7.9000002@oracle.com> Kumar Srinivasan said the following on 11/12/10 13:11: >> Is the purpose here to report what command-line options were used or >> to report what particular settings are in effect? If the former then >> you do not need any defaults for the "not set" case. If the latter >> then you should really defer this to the VM itself for the "VM >> options", because as it stands: > > Right we need to defer it to the VM, jdk7++ ? I will file an RFE to do > this. I'd rather see the VM print these things itself - one of the -XX options likely already prints this and a lot more - rather than providing an additional interface for the launcher to query the VM. In which case just drop this from the current scope of work and leave it for the VM. >> - if -Xmx is not set then Runtime.maxMemory() is not equivalent, so >> you are misleading the user (And why not report -Xms?) > No one beat me up on Xms so much as Xmx or max memory.:-) That aside it is inconsistent to report one but not the other. > As for memory, IIRC I compared the values that > java.lang.management.MemoryUsage.max > which reports the same value as I get here. That's fine as long as you don't claim that what you are reporting is the -Xmx value when it is not. > I will explain some of this in the help document, and maybe put a note > next to one of these > values such as 985M (approx.) > >> - if -Xss is not set the resulting value is not an OS default but a VM >> default > > In the case of windows the VM has no preference so the launcher defaults > back to the OS, > but if the VM has a pref. then that would be reported, usually *nixes. My point remains that saying "OS defaults" is inaccurate in general, and saying "VM or OS default" is unhelpful - it contains zero information so better to say nothing, or get the real ThreadStackSize from the VM > >> - ServerClassMachine() does not take into account -Xint possibility >> (and will need updating for Tiered compilation) > > Absolutely when that becomes a reality. You overlooked the -Xint part. I believe you will report "client" when -Xint is specified. >> I'd be tempted to just drop the "VM options" part of this, unless you >> are going to make a call into the VM to obtain them. > > I think I want to have it and put in the necessary VM hooks at a later > stage. It would be > good to get this in and get more feedback and enhance/evolve it in a > future release. I think the VM values should only come from the VM. The current proposal is ad-hoc, incomplete and inaccurate. (But that pretty much sums up the state of all our flags anyway: -foo vs -Xfoo vs -XX:foo :( ) David > > Thanks > > Kumar > >> >> David >> >> Kumar Srinivasan said the following on 11/12/10 07:56: >>> Hi All, >>> >>> Please review the following: >>> >>> http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ >>> >>> This will print all the known settings/properties/locales >>> supported and known to Java, this has been a long standing request. >>> >>> A sample output attached below. >>> >>> Note: the -X option specifically is being used so we can evolve this >>> option >>> and add more useful information, in future versions of java. >>> >>> Thanks >>> Kumar >>> >>> >>> > From xueming.shen at oracle.com Fri Nov 12 05:11:58 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Nov 2010 21:11:58 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDC8D87.7030709@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> Message-ID: <4CDCCC9E.3050204@oracle.com> On 11/11/2010 16:42, Kumar Srinivasan wrote: >> line 176, 188, 190-191, 195, and other lines in printPrintLocales and >> printLocale methods: >> - the assignment to the buf and out variable to itself (returned from >> StringBuffer.append() method) is not necessary. > > > Yes fixed, I missed these. The "intention" of returning the StringBuffer itself for those append() methods is that you can then write the code like private static void printLocale(PrintStream ostream) { ostream.println(new StringBuilder("\n" + LOCALE_SETTINGS + "\n") .append(INDENT) .append("default locale: ") .append(Locale.getDefault().getDisplayLanguage()) .append(prettyPrintLocales()) .toString()); } One more nit is that you might want to do something special for line.separator = to make it "readable" -Sherman From joe.darcy at oracle.com Fri Nov 12 09:00:32 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 12 Nov 2010 01:00:32 -0800 Subject: Changes planned to Throwable, 6991528 & 6998871 Message-ID: <4CDD0230.9060106@oracle.com> Hello. Mandy and David Holmes have already reviewed this change; however, I'm sending it out to the list in case anyone else is interested in having a look before the fix is pushed in the next day or two. For background, as identified on the coin-dev list, for example [1], it is problematic that all Throwable objects are mutable post-creation by calling addSuppressedExceptions since it is helpful that the VM be able to reuse immutable Throwable objects to provide better handling of conditions like OutOfMemoryError. To support this, the API of Throwable is modified to support making the corresponding field of Throwable immutable. Additionally, the method names related to suppressed exceptions will be shortened [2]. There is an analogous, and pre-existing issue with the stackTrace field. Due to technical complications encountered during this fix, making stackTrace immutable will be addressed in the follow-on bug 6998871. The webrev of the current round of changes is at: http://cr.openjdk.java.net/~darcy/6991528.11/ This involves several specification changes: to the serial specification of Throwable: // Sentinel value protocol added. /** * The list of suppressed exceptions, as returned by {@link * #getSuppressed()}. The list is initialized to a zero-element * unmodifiable sentinel list. When a serialized Throwable is * read in, if the {@code suppressedExceptions} field points to a * zero-element list, the field is reset to the sentinel value. * * @serial * @since 1.7 */ private List suppressedExceptions // New explicit specification of readObject /** * Read a {@code Throwable} from a stream, enforcing * well-formedness constraints on fields. Null entries and * self-pointers are not allowed in the list of {@code * suppressedExceptions}. Null entries are not allowed for stack * trace elements. * * Note that there are no constraints on the value the {@code * cause} field can hold; both {@code null} and this are valid * values for the field. */ private void readObject(ObjectInputStream s) In other parts of the specification, rename "addSuppressedException" to "addSuppressed", make the method final, and add the following paragraph and update @throws clause: * If the first exception to be suppressed is {@code null}, that * indicates suppressed exception information will not be * recorded for this exception. Subsequent calls to this method * will not record any suppressed exceptions. Otherwise, * attempting to suppress {@code null} after an exception has * already been successfully suppressed results in a {@code * NullPointerException}. * ... * @throws NullPointerException if {@code exception} is null and * an exception has already been suppressed by this exception Rename "getSuppressedExceptions" to "getSuppressed," make the method final, and add the following clarification: * If no exceptions were suppressed, an empty array is returned. Cheers, -Joe [1] http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002826.html [2] http://mail.openjdk.java.net/pipermail/coin-dev/2010-September/002909.html From Alan.Bateman at oracle.com Fri Nov 12 09:40:30 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Nov 2010 09:40:30 +0000 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDC9FF8.10404@oracle.com> References: <4CDC66A5.8000709@oracle.COM> <4CDC9FF8.10404@oracle.com> Message-ID: <4CDD0B8E.8040806@oracle.com> David Holmes wrote: > : > > I'd be tempted to just drop the "VM options" part of this, unless you > are going to make a call into the VM to obtain them. > I was wondering about this too, or rather thinking that -XshowsSettings might likely be used in conjunction with other options like -showversion or VM specific options. For example, someone might do this: java -XX+PrintCommandLineFlags -XshowSettings -showversion Foo and the logs will capture the heap settings, the properties and locale info printed by showSettings, and the HotSpot and JDK version printed by -showversion. The only one that I'm sure is the default stack limit (when -Xss or -XX:ThreadStackSize= isn't specified) as I don't think we have a VM option to print that (except with +PrintFlagsFinal dump of course). -Alan. From lance.andersen at oracle.com Fri Nov 12 12:19:24 2010 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 12 Nov 2010 12:19:24 +0000 Subject: hg: jdk7/tl/jdk: 6982530: javadoc update to SyncFactory & JdbcResource bundle for synchronization issues Message-ID: <20101112121943.EBF3F47934@hg.openjdk.java.net> Changeset: af2de4de1076 Author: lancea Date: 2010-11-12 07:15 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/af2de4de1076 6982530: javadoc update to SyncFactory & JdbcResource bundle for synchronization issues Reviewed-by: alanb ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java From maurizio.cimadamore at oracle.com Fri Nov 12 12:37:10 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 12 Nov 2010 12:37:10 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20101112123716.43A2D47935@hg.openjdk.java.net> Changeset: 58ceeff50af8 Author: mcimadamore Date: 2010-11-12 12:32 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/58ceeff50af8 6598108: com.sun.source.util.Trees.isAccessible incorrect Summary: JavacTrees' version of isAccessible should take into account enclosing class accessibility Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/api/6598108/T6598108.java Changeset: fdc67f5170e9 Author: mcimadamore Date: 2010-11-12 12:33 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fdc67f5170e9 6999067: cast for invokeExact call gets redundant cast to warnings Summary: Xlint:cast should not report cast used in order to specify target type in polymorphic signature calls Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/meth/XlintWarn.java Changeset: 6a99b741a1b0 Author: mcimadamore Date: 2010-11-12 12:34 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6a99b741a1b0 6970016: Clean up ARM/try-with-resources implementation Summary: changed Xlint option name from -Xlint:arm to -Xlint:try Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Lint.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/TryWithResources/ArmLint.java - test/tools/javac/TryWithResources/ArmLint.out ! test/tools/javac/TryWithResources/ImplicitFinal.out + test/tools/javac/TryWithResources/TwrLint.java + test/tools/javac/TryWithResources/TwrLint.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/diags/examples/ResourceClosed.java ! test/tools/javac/diags/examples/ResourceMayNotBeAssigned.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/ResourceNotReferenced.java ! test/tools/javac/diags/examples/TryResourceNotSupported.java From weijun.wang at oracle.com Fri Nov 12 13:34:25 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 12 Nov 2010 13:34:25 +0000 Subject: hg: jdk7/tl/jdk: 6960894: Better AS-REQ creation and processing Message-ID: <20101112133434.D3CAC47939@hg.openjdk.java.net> Changeset: 1e7dc87fad95 Author: weijun Date: 2010-11-12 21:33 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1e7dc87fad95 6960894: Better AS-REQ creation and processing Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptionKey.java + src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReq.java + src/share/classes/sun/security/krb5/KrbAsReqBuilder.java - src/share/classes/sun/security/krb5/KrbKdcReq.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/internal/KDCRep.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KerberosTime.java ! src/share/classes/sun/security/krb5/internal/PAData.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/NewSalt.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/W83.java From lance.andersen at oracle.com Fri Nov 12 13:43:53 2010 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 12 Nov 2010 13:43:53 +0000 Subject: hg: jdk7/tl/jdk: 6999086: Clarify that SyncFactory.setLogger can throw an NullPointerException Message-ID: <20101112134403.4E8B84793A@hg.openjdk.java.net> Changeset: c4a38022fdc1 Author: lancea Date: 2010-11-12 08:41 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c4a38022fdc1 6999086: Clarify that SyncFactory.setLogger can throw an NullPointerException Reviewed-by: alanb ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java From pbenedict at apache.org Fri Nov 12 15:08:07 2010 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 12 Nov 2010 09:08:07 -0600 Subject: Changes planned to Throwable, 6991528 & 6998871 In-Reply-To: <4CDD0230.9060106@oracle.com> References: <4CDD0230.9060106@oracle.com> Message-ID: Joe, The class documentation currently has a nice chronological history of Throwable's features: * "Prior to release 1.4, there were many throwables that had their own non-standard exception chaining mechanisms..." * "Further, as of release 1.4, many general purpose...." * "Also introduced in release 1.4 is the getStackTrace() method..." It's odd, however, that the suppressed exceptions feature is held off until the printStackTrace() method: "As of release 7, the platform supports the notion of suppressed exceptions..." For consistency, I recommend moving some of that documentation to the class level to continue the big picture. Paul On Fri, Nov 12, 2010 at 3:00 AM, Joe Darcy wrote: > Hello. > > Mandy and David Holmes have already reviewed this change; however, I'm > sending it out to the list in case anyone else is interested in having a > look before the fix is pushed in the next day or two. > > For background, as identified on the coin-dev list, for example [1], it is > problematic that all Throwable objects are mutable post-creation by calling > addSuppressedExceptions since it is helpful that the VM be able to reuse > immutable Throwable objects to provide better handling of conditions like > OutOfMemoryError. ?To support this, the API of Throwable is modified to > support making the corresponding field of Throwable immutable. > ?Additionally, the method names related to suppressed exceptions will be > shortened [2]. > > There is an analogous, and pre-existing issue with the stackTrace field. > ?Due to technical complications encountered during this fix, making > stackTrace immutable will be addressed in the follow-on bug 6998871. > > The webrev of the current round of changes is at: > > ? http://cr.openjdk.java.net/~darcy/6991528.11/ > > This involves several specification changes: to the serial specification of > Throwable: > > // Sentinel value protocol added. > ? ? /** > ? ? ?* The list of suppressed exceptions, as returned by {@link > ? ? ?* #getSuppressed()}. ?The list is initialized to a zero-element > ? ? ?* unmodifiable sentinel list. ?When a serialized Throwable is > ? ? ?* read in, if the {@code suppressedExceptions} field points to a > ? ? ?* zero-element list, the field is reset to the sentinel value. > ? ? ?* > ? ? ?* @serial > ? ? ?* @since 1.7 > ? ? ?*/ > ? ? private List suppressedExceptions > > // New explicit specification of readObject > ? ? /** > ? ? ?* Read a {@code Throwable} from a stream, enforcing > ? ? ?* well-formedness constraints on fields. ?Null entries and > ? ? ?* self-pointers are not allowed in the list of {@code > ? ? ?* suppressedExceptions}. ?Null entries are not allowed for stack > ? ? ?* trace elements. > ? ? ?* > ? ? ?* Note that there are no constraints on the value the {@code > ? ? ?* cause} field can hold; both {@code null} and this are valid > ? ? ?* values for the field. > ? ? ?*/ > ? ? private void readObject(ObjectInputStream s) > > In other parts of the specification, rename "addSuppressedException" to > "addSuppressed", make the method final, and add the following paragraph and > update @throws clause: > > ? ? ?* If the first exception to be suppressed is {@code null}, that > ? ? ?* indicates suppressed exception information will not be > ? ? ?* recorded for this exception. ?Subsequent calls to this method > ? ? ?* will not record any suppressed exceptions. ?Otherwise, > ? ? ?* attempting to suppress {@code null} after an exception has > ? ? ?* already been successfully suppressed results in a {@code > ? ? ?* NullPointerException}. > ? ? ?* > > ... > ? ? ?* @throws NullPointerException if {@code exception} is null and > ? ? ?* ? ? ? ? an exception has already been suppressed by this exception > > > Rename "getSuppressedExceptions" to "getSuppressed," make the method final, > and add the following clarification: > > * If no exceptions were suppressed, an empty array is returned. > > Cheers, > > -Joe > > [1] http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002826.html > [2] > http://mail.openjdk.java.net/pipermail/coin-dev/2010-September/002909.html > > > From kumar.x.srinivasan at oracle.com Fri Nov 12 15:16:12 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 12 Nov 2010 07:16:12 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDCC9B7.9000002@oracle.com> References: <4CDC66A5.8000709@oracle.COM> <4CDC9FF8.10404@oracle.com> <4CDCB077.2030208@oracle.COM> <4CDCC9B7.9000002@oracle.com> Message-ID: <4CDD5A3C.8080204@oracle.COM> >>> Is the purpose here to report what command-line options were used or >>> to report what particular settings are in effect? If the former then >>> you do not need any defaults for the "not set" case. If the latter >>> then you should really defer this to the VM itself for the "VM >>> options", because as it stands: >> >> Right we need to defer it to the VM, jdk7++ ? I will file an RFE to >> do this. > > I'd rather see the VM print these things itself - one of the -XX > options likely already prints this and a lot more - rather than > providing an additional interface for the launcher to query the VM. In > which case just drop this from the current scope of work and leave it > for the VM. The issue I am trying to solve is to provide 1 well documented flag to get the user all the *important* settings in java that he/she needs to know. It is next to impossible to keep track of all the undocumented -XX flags that the VM supports. [ this is a can of worms] > >>> - if -Xmx is not set then Runtime.maxMemory() is not equivalent, so >>> you are misleading the user (And why not report -Xms?) >> No one beat me up on Xms so much as Xmx or max memory.:-) > > That aside it is inconsistent to report one but not the other. I will add this later. > >> As for memory, IIRC I compared the values that >> java.lang.management.MemoryUsage.max >> which reports the same value as I get here. > > That's fine as long as you don't claim that what you are reporting is > the -Xmx value when it is not. Ok I will change/remove the flag hints. > >> I will explain some of this in the help document, and maybe put a >> note next to one of these >> values such as 985M (approx.) >> >>> - if -Xss is not set the resulting value is not an OS default but a >>> VM default >> >> In the case of windows the VM has no preference so the launcher >> defaults back to the OS, >> but if the VM has a pref. then that would be reported, usually *nixes. > > My point remains that saying "OS defaults" is inaccurate in general, > and saying "VM or OS default" is unhelpful - it contains zero > information so better to say nothing, or get the real ThreadStackSize > from the VM It is difficult to get this on windows, this is going back to the first issue, either we get the VM to print this using some api or have this information sent back to the launcher so that it can be printed via showSettings flag. For now I will remove the field if I cannot determine it. > >> >>> - ServerClassMachine() does not take into account -Xint possibility >>> (and will need updating for Tiered compilation) >> >> Absolutely when that becomes a reality. > > You overlooked the -Xint part. I believe you will report "client" when > -Xint is specified. On what class machine ? a server class ? in which case it reports "server" for me. The ServerClassMachine is set depending on the # of processors and amount of RAM on the system. If you are asking me to fix the launcher ergonomics that is beyond the scope of this work. > >>> I'd be tempted to just drop the "VM options" part of this, unless >>> you are going to make a call into the VM to obtain them. >> >> I think I want to have it and put in the necessary VM hooks at a >> later stage. It would be >> good to get this in and get more feedback and enhance/evolve it in a >> future release. > > I think the VM values should only come from the VM. The current > proposal is ad-hoc, incomplete and inaccurate. It is incomplete!, that is why I have the disclaimer and proposed it as "-X" flag. So that we can evolve this flag in future releases, and use jdk7 to get the feedback from users on what they would like to see for settings. > (But that pretty much sums up the state of all our flags anyway: -foo > vs -Xfoo vs -XX:foo :( ) Yeh I know and I rest my case for this flag. ;-) This is exactly why we need one interface to bring the whole Java setting story together. We cannot tell our users/support personnel, SQE etc. to use different flags to get the Java and VM settings. Thanks Kumar > > David > >> >> Thanks >> >> Kumar >> >>> >>> David >>> >>> Kumar Srinivasan said the following on 11/12/10 07:56: >>>> Hi All, >>>> >>>> Please review the following: >>>> >>>> http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ >>>> >>>> This will print all the known settings/properties/locales >>>> supported and known to Java, this has been a long standing request. >>>> >>>> A sample output attached below. >>>> >>>> Note: the -X option specifically is being used so we can evolve >>>> this option >>>> and add more useful information, in future versions of java. >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>>> >> From kumar.x.srinivasan at oracle.com Fri Nov 12 15:27:44 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 12 Nov 2010 07:27:44 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: References: Message-ID: <4CDD5CF0.8010009@oracle.COM> >> A sample output attached below. > Fantastic! > > - The colons on the path components seem unnecessary if each element is also going to be separated by line breaks yes, but I thought I will leave it there to remind users that is the pathseparator. > - In the output for the property 'line.seperator' would it be possible to convert this to "\n" "\n\r" or "\r" as rather than including the character directly? I will look into. > - I agree with David Holmes that it should be made clear that these settings and defaults are the result of the command line options being applied rather than an echoing of the command line options. Will remove the command line hints. > - Is assertions and system assertions status (when enabled) included in the report? I am planning on opening a Bug/RFE to collect feedback on the useful information that users would like to see. But is there a real need for this to be displayed ? Kumar > Mike > > > From kumar.x.srinivasan at oracle.com Fri Nov 12 15:40:13 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 12 Nov 2010 07:40:13 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDCBE0E.5080002@oracle.com> References: <4CDC66A5.8000709@oracle.COM> <4CDCBE0E.5080002@oracle.com> Message-ID: <4CDD5FDD.9000907@oracle.COM> Hi Sherman, > > The scaleValue(longv) does not appear to handle the 1K, 1M, 1G and 1T > correctly, shouldn't > be v >= K/M/G/T ? 1024 for 1K is OK, byte number for 1M/G/T might be > too much. I fixed this in my local repo, also Joe suggested I use BigDecimal to round off and set precision. > > Seems like you are "assembling" the bits yourself, why not use our > "powerful" (sure, a little slower:-) > j.u.Formatter, get a Formatter on top of a sb > > StringBuilder sb = new StringBuilder(); > Formatter fm = new Formatter(sb); I am using String.format. will send the new webrev shortly. Kumar > ... > > then pass the fm around and finally dump the sb.toString() to the > out/err. This way you will > have better control of the "spacing", the \n (with "%n") and might > also bring in some "locale" > sensitive benefits (maybe in the future). > > -Sherman > > > On 11/11/2010 13:56, Kumar Srinivasan wrote: >> Hi All, >> >> Please review the following: >> >> http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ >> >> This will print all the known settings/properties/locales >> supported and known to Java, this has been a long standing request. >> >> A sample output attached below. >> >> Note: the -X option specifically is being used so we can evolve this >> option >> and add more useful information, in future versions of java. >> >> Thanks >> Kumar >> >> >> > From joe.darcy at oracle.com Fri Nov 12 15:47:47 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 12 Nov 2010 07:47:47 -0800 Subject: Changes planned to Throwable, 6991528 & 6998871 In-Reply-To: References: <4CDD0230.9060106@oracle.com> Message-ID: <4CDD61A3.9010101@oracle.com> Paul Benedict wrote: > Joe, > > The class documentation currently has a nice chronological history of > Throwable's features: > > * "Prior to release 1.4, there were many throwables that had their own > non-standard exception chaining mechanisms..." > * "Further, as of release 1.4, many general purpose...." > * "Also introduced in release 1.4 is the getStackTrace() method..." > > It's odd, however, that the suppressed exceptions feature is held off > until the printStackTrace() method: > "As of release 7, the platform supports the notion of suppressed exceptions..." > > For consistency, I recommend moving some of that documentation to the > class level to continue the big picture. > > Paul > > Hello Paul. Yes, I had noticed that chronology too. However, the way I would make the current definition of the class consistent is to largely delete the history lesson ;-) Much of the text in question reads much better in release 1.4 than in 1.5, 6, or now 7. -Joe From David.Holmes at oracle.com Fri Nov 12 19:59:51 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 13 Nov 2010 05:59:51 +1000 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDD5A3C.8080204@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> <4CDC9FF8.10404@oracle.com> <4CDCB077.2030208@oracle.COM> <4CDCC9B7.9000002@oracle.com> <4CDD5A3C.8080204@oracle.COM> Message-ID: <4CDD9CB7.60809@oracle.com> Kumar Srinivasan said the following on 11/13/10 01:16: >>>> - ServerClassMachine() does not take into account -Xint possibility >>>> (and will need updating for Tiered compilation) >>> >>> Absolutely when that becomes a reality. >> >> You overlooked the -Xint part. I believe you will report "client" when >> -Xint is specified. > > On what class machine ? a server class ? in which case it reports > "server" for me. Okay, I wasn't sure if the ServerClassMachine() logic actually accounted for -Xint. I thought it did in which case it would return false and so you would assume client. Returning "server" is just as wrong here unless the intent is to simply show whether this is considered a server class machine regardless of whether -client or -Xint were specified. That said will -client cause ServerClassMachine() to return false? I don't know what the ergo policy logic does here: switch(GetErgoPolicy()) { case NEVER_SERVER_CLASS: return JNI_FALSE; case ALWAYS_SERVER_CLASS: return JNI_TRUE; In any case the issue is what this value is supposed to show - if it is just showing whether this is a server class machine, and that is not affected by specifying -client or -Xint then okay, but that wasn't completely clear to me - I would change: "Ergonomics Class (server or client): " to say "Ergonomics Machine Class (server or client): " > It is incomplete!, that is why I have the disclaimer and proposed it as > "-X" flag. > So that we can evolve this flag in future releases, and use jdk7 to get > the feedback > from users on what they would like to see for settings. > >> (But that pretty much sums up the state of all our flags anyway: -foo >> vs -Xfoo vs -XX:foo :( ) > > > Yeh I know and I rest my case for this flag. ;-) > This is exactly why we need one interface to bring the whole Java > setting story together. > We cannot tell our users/support personnel, SQE etc. to use different > flags to get the Java and VM settings. Then I would suggest that in parallel with this we add another -XX flag that takes a list of VM variables for which the final value should be printed. -Xshowsettings would then add -XX:PrintFlagValues=flag1,flag2 etc. Of course the launcher would not have control over the output format in that case and the output would not be consistent with what is proposed today (hence my reluctance to pursue this part of the RFE today). But this way it would be easy for the launcher to update the list of variables reported. David > > Thanks > > Kumar >> >> David >> >>> >>> Thanks >>> >>> Kumar >>> >>>> >>>> David >>>> >>>> Kumar Srinivasan said the following on 11/12/10 07:56: >>>>> Hi All, >>>>> >>>>> Please review the following: >>>>> >>>>> http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ >>>>> >>>>> This will print all the known settings/properties/locales >>>>> supported and known to Java, this has been a long standing request. >>>>> >>>>> A sample output attached below. >>>>> >>>>> Note: the -X option specifically is being used so we can evolve >>>>> this option >>>>> and add more useful information, in future versions of java. >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> >>>>> >>> > From kumar.x.srinivasan at oracle.com Fri Nov 12 20:03:43 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 12 Nov 2010 12:03:43 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDD9CB7.60809@oracle.com> References: <4CDC66A5.8000709@oracle.COM> <4CDC9FF8.10404@oracle.com> <4CDCB077.2030208@oracle.COM> <4CDCC9B7.9000002@oracle.com> <4CDD5A3C.8080204@oracle.COM> <4CDD9CB7.60809@oracle.com> Message-ID: <4CDD9D9F.9020904@oracle.COM> On 11/12/2010 11:59 AM, David Holmes wrote: > Kumar Srinivasan said the following on 11/13/10 01:16: >>>>> - ServerClassMachine() does not take into account -Xint >>>>> possibility (and will need updating for Tiered compilation) >>>> >>>> Absolutely when that becomes a reality. >>> >>> You overlooked the -Xint part. I believe you will report "client" >>> when -Xint is specified. >> >> On what class machine ? a server class ? in which case it reports >> "server" for me. > > Okay, I wasn't sure if the ServerClassMachine() logic actually > accounted for -Xint. I thought it did in which case it would return > false and so you would assume client. Returning "server" is just as > wrong here unless the intent is to simply show whether this is > considered a server class machine regardless of whether -client or > -Xint were specified. That said will -client cause > ServerClassMachine() to return false? I don't know what the ergo > policy logic does here: > > switch(GetErgoPolicy()) { > case NEVER_SERVER_CLASS: > return JNI_FALSE; > case ALWAYS_SERVER_CLASS: > return JNI_TRUE; > > In any case the issue is what this value is supposed to show - if it > is just showing whether this is a server class machine, and that is > not affected by specifying -client or -Xint then okay, but that wasn't > completely clear to me - I would change: > > "Ergonomics Class (server or client): " > > to say > > "Ergonomics Machine Class (server or client): " Yes the intention is to tell the user "Hey we think this is a Server Class Machine, but you are running a client vm". I will change it to your wordings. Kumar > > >> It is incomplete!, that is why I have the disclaimer and proposed it >> as "-X" flag. >> So that we can evolve this flag in future releases, and use jdk7 to >> get the feedback >> from users on what they would like to see for settings. >> >>> (But that pretty much sums up the state of all our flags anyway: >>> -foo vs -Xfoo vs -XX:foo :( ) >> >> >> Yeh I know and I rest my case for this flag. ;-) >> This is exactly why we need one interface to bring the whole Java >> setting story together. >> We cannot tell our users/support personnel, SQE etc. to use different >> flags to get the Java and VM settings. > > Then I would suggest that in parallel with this we add another -XX > flag that takes a list of VM variables for which the final value > should be printed. -Xshowsettings would then add > -XX:PrintFlagValues=flag1,flag2 etc. Of course the launcher would not > have control over the output format in that case and the output would > not be consistent with what is proposed today (hence my reluctance to > pursue this part of the RFE today). But this way it would be easy for > the launcher to update the list of variables reported. > > David > >> >> Thanks >> >> Kumar >>> >>> David >>> >>>> >>>> Thanks >>>> >>>> Kumar >>>> >>>>> >>>>> David >>>>> >>>>> Kumar Srinivasan said the following on 11/12/10 07:56: >>>>>> Hi All, >>>>>> >>>>>> Please review the following: >>>>>> >>>>>> http://cr.openjdk.java.net/~ksrini/6452854/webrev.00/ >>>>>> >>>>>> This will print all the known settings/properties/locales >>>>>> supported and known to Java, this has been a long standing >>>>>> request. >>>>>> >>>>>> A sample output attached below. >>>>>> >>>>>> Note: the -X option specifically is being used so we can evolve >>>>>> this option >>>>>> and add more useful information, in future versions of java. >>>>>> >>>>>> Thanks >>>>>> Kumar >>>>>> >>>>>> >>>>>> >>>> >> From kumar.x.srinivasan at oracle.com Fri Nov 12 20:17:35 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 12 Nov 2010 12:17:35 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDCCC9E.3050204@oracle.com> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> <4CDCCC9E.3050204@oracle.com> Message-ID: <4CDDA0DF.6020608@oracle.COM> Thanks for all the reviews!. Here are the fixes in this version: http://cr.openjdk.java.net/~ksrini/6452854/webrev.01 1. Fixed the representation of numbers and scaling using BigDecimal. 2. Argument processing checks for -XshowSettings and -XshowSetting:opt (added a test to catch the former, added some comments in java.c) 3. Replaced String* with PrintStream.print*, it makes the logic easier to read, so I decided to go with this. 4. Removed extraneous path.separators. 5. line.separator will be printed as ASCII symbols CR and LF 6. If the helper cannot determine the value that line will not be displayed. 7. In the case of the Max memory not gotten from the launcher (Estimated) is printed. 8. Removed the option hints -X* and so on in the labels. 9. Renamed Ergonomic Class -> Ergonomic Machine Class. Thanks Kumar > On 11/11/2010 16:42, Kumar Srinivasan wrote: >>> line 176, 188, 190-191, 195, and other lines in printPrintLocales >>> and printLocale methods: >>> - the assignment to the buf and out variable to itself (returned >>> from StringBuffer.append() method) is not necessary. >> >> >> Yes fixed, I missed these. > > The "intention" of returning the StringBuffer itself for those > append() methods is that > you can then write the code like > > > private static void printLocale(PrintStream ostream) { > ostream.println(new StringBuilder("\n" + LOCALE_SETTINGS + "\n") > .append(INDENT) > .append("default locale: ") > .append(Locale.getDefault().getDisplayLanguage()) > .append(prettyPrintLocales()) > .toString()); > } > > > One more nit is that you might want to do something special for > > line.separator = > > to make it "readable" > > -Sherman > From xueming.shen at oracle.com Sat Nov 13 04:23:35 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Nov 2010 20:23:35 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDDA0DF.6020608@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> <4CDCCC9E.3050204@oracle.com> <4CDDA0DF.6020608@oracle.COM> Message-ID: <4CDE12C7.6060304@oracle.com> (1)Setting.java#43-#47 "assignment" need to be updated as well. (2)LauncherHelper.java#189-190 While it's unlikely we are going to have a line.separator with byte value negative, I would prefer still do b & 0xff before passing in for formatting, just in case:-) And maybe it'd be better to simply let the j.u.Formatter do the formatting job for you? ostream.printf("0x%02X ", b & 0xff); (3) prettyPrintLocales() needs a "println() at the end? (4) OK, it's nit, but it's Friday night:-) so... a)any reason to use ":" after "default locale" and "=" after "available locales"? b)"lastline" is really "lastentry", and have to check it inside loop is really annoying, final int last = locales.length - 1; int i = 0; while (i < last) { ostream.print(locales[i++]); // print columns of 8 if (i % 8 == 0) { ostream.println(","); ostream.print(INDENT + INDENT); } else { ostream.print(", "); } } ostream.println(locales[i]); (5)it's really really a nit, but I have to say:-) why "pretty...", try to hint only the "Locales" and "Values" are prettily printed? On 11/12/2010 12:17, Kumar Srinivasan wrote: > Thanks for all the reviews!. > > Here are the fixes in this version: > http://cr.openjdk.java.net/~ksrini/6452854/webrev.01 > > 1. Fixed the representation of numbers and scaling using BigDecimal. > 2. Argument processing checks for -XshowSettings and -XshowSetting:opt > (added a test to catch the former, added some comments in java.c) > 3. Replaced String* with PrintStream.print*, it makes the logic easier > to read, so I decided to go with this. > 4. Removed extraneous path.separators. > 5. line.separator will be printed as ASCII symbols CR and LF > 6. If the helper cannot determine the value that line will not be > displayed. > 7. In the case of the Max memory not gotten from the launcher > (Estimated) is printed. > 8. Removed the option hints -X* and so on in the labels. > 9. Renamed Ergonomic Class -> Ergonomic Machine Class. > > Thanks > Kumar > > > > >> On 11/11/2010 16:42, Kumar Srinivasan wrote: >>>> line 176, 188, 190-191, 195, and other lines in printPrintLocales >>>> and printLocale methods: >>>> - the assignment to the buf and out variable to itself (returned >>>> from StringBuffer.append() method) is not necessary. >>> >>> >>> Yes fixed, I missed these. >> >> The "intention" of returning the StringBuffer itself for those >> append() methods is that >> you can then write the code like >> >> >> private static void printLocale(PrintStream ostream) { >> ostream.println(new StringBuilder("\n" + LOCALE_SETTINGS + "\n") >> .append(INDENT) >> .append("default locale: ") >> .append(Locale.getDefault().getDisplayLanguage()) >> .append(prettyPrintLocales()) >> .toString()); >> } >> >> >> One more nit is that you might want to do something special for >> >> line.separator = >> >> to make it "readable" >> >> -Sherman >> > From kumar.x.srinivasan at oracle.COM Sat Nov 13 15:04:24 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Sat, 13 Nov 2010 07:04:24 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDE12C7.6060304@oracle.com> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> <4CDCCC9E.3050204@oracle.com> <4CDDA0DF.6020608@oracle.COM> <4CDE12C7.6060304@oracle.com> Message-ID: <4CDEA8F8.6090702@oracle.COM> On 11/12/2010 8:23 PM, Xueming Shen wrote: > > (1)Setting.java#43-#47 "assignment" need to be updated as well. Yes fixed this > (2)LauncherHelper.java#189-190 > While it's unlikely we are going to have a line.separator with > byte value > negative, I would prefer still do b & 0xff before passing in for > formatting, > just in case:-) And maybe it'd be better to simply let the > j.u.Formatter do > the formatting job for you? > > ostream.printf("0x%02X ", b & 0xff); That simplifies it, done. > > (3) prettyPrintLocales() needs a "println() at the end? This is fine I am printing LFs at the end of the subsection. > > (4) OK, it's nit, but it's Friday night:-) so... > a)any reason to use ":" after "default locale" and "=" after > "available locales"? > b)"lastline" is really "lastentry", and have to check it inside > loop is really annoying, > > final int last = locales.length - 1; > int i = 0; > while (i < last) { > ostream.print(locales[i++]); > // print columns of 8 > if (i % 8 == 0) { > ostream.println(","); > ostream.print(INDENT + INDENT); > } else { > ostream.print(", "); > } > } > ostream.println(locales[i]); Done. > > (5)it's really really a nit, but I have to say:-) why "pretty...", try > to hint only the "Locales" > and "Values" are prettily printed? I see, you have a problem with the names ? alright, alright, I will make it consistent with the others. I think you are working too late on a Friday. ;-) and I am working too early on a Sat AM. :-( Kumar > > On 11/12/2010 12:17, Kumar Srinivasan wrote: >> Thanks for all the reviews!. >> >> Here are the fixes in this version: >> http://cr.openjdk.java.net/~ksrini/6452854/webrev.01 >> >> 1. Fixed the representation of numbers and scaling using BigDecimal. >> 2. Argument processing checks for -XshowSettings and -XshowSetting:opt >> (added a test to catch the former, added some comments in java.c) >> 3. Replaced String* with PrintStream.print*, it makes the logic easier >> to read, so I decided to go with this. >> 4. Removed extraneous path.separators. >> 5. line.separator will be printed as ASCII symbols CR and LF >> 6. If the helper cannot determine the value that line will not be >> displayed. >> 7. In the case of the Max memory not gotten from the launcher >> (Estimated) is printed. >> 8. Removed the option hints -X* and so on in the labels. >> 9. Renamed Ergonomic Class -> Ergonomic Machine Class. >> >> Thanks >> Kumar >> >> >> >> >>> On 11/11/2010 16:42, Kumar Srinivasan wrote: >>>>> line 176, 188, 190-191, 195, and other lines in printPrintLocales >>>>> and printLocale methods: >>>>> - the assignment to the buf and out variable to itself (returned >>>>> from StringBuffer.append() method) is not necessary. >>>> >>>> >>>> Yes fixed, I missed these. >>> >>> The "intention" of returning the StringBuffer itself for those >>> append() methods is that >>> you can then write the code like >>> >>> >>> private static void printLocale(PrintStream ostream) { >>> ostream.println(new StringBuilder("\n" + LOCALE_SETTINGS + "\n") >>> .append(INDENT) >>> .append("default locale: ") >>> .append(Locale.getDefault().getDisplayLanguage()) >>> .append(prettyPrintLocales()) >>> .toString()); >>> } >>> >>> >>> One more nit is that you might want to do something special for >>> >>> line.separator = >>> >>> to make it "readable" >>> >>> -Sherman >>> >> > From lana.steuck at oracle.com Sun Nov 14 06:39:47 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 14 Nov 2010 06:39:47 +0000 Subject: hg: jdk7/tl/corba: 5 new changesets Message-ID: <20101114063951.B1716479AD@hg.openjdk.java.net> Changeset: 16adbe677ef8 Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/16adbe677ef8 Added tag jdk7-b117 for changeset fa502e4834da ! .hgtags Changeset: e5819cb9b15e Author: lana Date: 2010-11-02 18:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/e5819cb9b15e Merge ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: 42e77836fded Author: lana Date: 2010-11-09 22:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/42e77836fded Merge Changeset: 39829414ae31 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/39829414ae31 Added tag jdk7-b118 for changeset 42e77836fded ! .hgtags Changeset: 75071e5568a9 Author: lana Date: 2010-11-13 18:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/75071e5568a9 Merge From lana.steuck at oracle.com Sun Nov 14 06:40:35 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 14 Nov 2010 06:40:35 +0000 Subject: hg: jdk7/tl: 2 new changesets Message-ID: <20101114064035.11D15479AE@hg.openjdk.java.net> Changeset: a12a9e78df8a Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/a12a9e78df8a Added tag jdk7-b117 for changeset 7220e60b097f ! .hgtags Changeset: 95f8f3994b9b Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/95f8f3994b9b Added tag jdk7-b118 for changeset a12a9e78df8a ! .hgtags From lana.steuck at oracle.com Sun Nov 14 06:41:05 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 14 Nov 2010 06:41:05 +0000 Subject: hg: jdk7/tl/hotspot: 37 new changesets Message-ID: <20101114064213.232C0479AF@hg.openjdk.java.net> Changeset: 62aa74bafa73 Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/62aa74bafa73 Added tag jdk7-b117 for changeset 806d0c037e6b ! .hgtags Changeset: 08f0f4a3ddd6 Author: trims Date: 2010-11-04 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/08f0f4a3ddd6 Added tag hs20-b02 for changeset 52f19c724d96 ! .hgtags Changeset: c32059ef4dc0 Author: johnc Date: 2010-10-12 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c32059ef4dc0 6971296: G1: simplify G1RemSet class hierarchy Summary: Remove G1RemSet base class and StupidG1RemSet class; rename HRInto_G1RemSet to just G1RemSet. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: b14ec34b1e07 Author: jcoomes Date: 2010-10-12 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b14ec34b1e07 6989448: G1: refactor and simplify G1ParScanThreadState Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: ee813f7b46e4 Author: jcoomes Date: 2010-10-14 11:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ee813f7b46e4 Merge Changeset: dfb38ea7da17 Author: zgu Date: 2010-09-30 12:05 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dfb38ea7da17 6988363: Rebrand vm vendor property settings (jdk7 only) Summary: Vendor properties should be initialized after JDK version is determined. Reviewed-by: kamg, ohair, dcubed, dholmes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp Changeset: 1c352af0135d Author: acorn Date: 2010-10-04 13:11 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1c352af0135d 6763959: java.util.concurrent.locks.LockSupport.parkUntil(0) blocks forever Summary: Absolute time 0 needs to return immediately. Reviewed-by: phh, dcubed, dholmes ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 644f98c78e33 Author: acorn Date: 2010-10-04 10:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/644f98c78e33 Merge Changeset: b6aedd1acdc0 Author: coleenp Date: 2010-10-07 08:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b6aedd1acdc0 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong Summary: min_stack_allowed is a compile time constant and Stack*Pages are settable Reviewed-by: dholmes, kvn ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/exceptions.cpp Changeset: 3dc12ef8735e Author: bobv Date: 2010-10-07 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3dc12ef8735e 6989297: Integrate additional portability improvements Reviewed-by: vladidan, dholmes ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/os/linux/vm/attachListener_linux.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 7491c8b96111 Author: bobv Date: 2010-10-07 15:14 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7491c8b96111 Merge Changeset: c77b5c592eab Author: kamg Date: 2010-10-12 10:57 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c77b5c592eab 6392697: Additional flag needed to supress Hotspot warning messages Summary: Apply PrintJvmWarnings flag to all warnings Reviewed-by: coleenp, phh ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 75b0735b4d04 Author: acorn Date: 2010-10-13 11:46 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/75b0735b4d04 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: beba40b26a79 Author: acorn Date: 2010-10-15 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/beba40b26a79 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: 07a218de38cb Author: never Date: 2010-10-15 14:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/07a218de38cb 6992477: fix for 6991512 broke sparc barriers Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 75ab0162aa84 Author: never Date: 2010-10-18 09:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/75ab0162aa84 Merge Changeset: 4e22405d98d6 Author: iveresov Date: 2010-10-19 11:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4e22405d98d6 6989669: Coops: -Xshare:dump causes crash Summary: Temporarily fix to disable compressed oops with CDS Reviewed-by: dholmes, twisti, kvn, never ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9eaf8ba53f3d Author: trims Date: 2010-10-20 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9eaf8ba53f3d Merge Changeset: a4c7fe54bf3f Author: kamg Date: 2010-10-21 10:10 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a4c7fe54bf3f 6991315: RedefineClasses fails with java.lang.VerifyError Summary: Repair stackmap table attribute when relocating bytecode Reviewed-by: acorn, never + src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/includeDB_core ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/relocator.hpp Changeset: fa83ab460c54 Author: acorn Date: 2010-10-22 15:59 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fa83ab460c54 6988353: refactor contended sync subsystem Summary: reduce complexity by factoring synchronizer.cpp Reviewed-by: dholmes, never, coleenp - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/includeDB_jvmti ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp + src/share/vm/prims/jvmtiRawMonitor.cpp + src/share/vm/prims/jvmtiRawMonitor.hpp + src/share/vm/runtime/basicLock.cpp + src/share/vm/runtime/basicLock.hpp ! src/share/vm/runtime/mutex.hpp + src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/objectMonitor.inline.hpp + src/share/vm/runtime/park.cpp + src/share/vm/runtime/park.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: a312a67b32ef Author: acorn Date: 2010-10-25 13:31 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a312a67b32ef Merge ! src/share/vm/includeDB_core Changeset: 60ce9dade348 Author: acorn Date: 2010-10-26 14:43 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/60ce9dade348 Merge Changeset: 6412b3805cd6 Author: kamg Date: 2010-10-26 14:08 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6412b3805cd6 6891959: HotSpot should not throw ClassFormatError if a class has a field with '>' and/or '<' in its name Summary: Class file parser needs to look for and disallow '[' in names. Reviewed-by: coleenp, never ! src/share/vm/classfile/classFileParser.cpp Changeset: ee0d26abaad3 Author: kamg Date: 2010-10-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ee0d26abaad3 Merge Changeset: 35e4e086d5f5 Author: tonyp Date: 2010-10-14 10:38 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/35e4e086d5f5 6990359: G1: don't push a stolen entry on the taskqueue, deal with it directly Summary: When an entry is stolen, don't push it on the task queue but process it directly. Reviewed-by: iveresov, ysr, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 9f4848ebbabd Author: tonyp Date: 2010-10-15 17:26 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9f4848ebbabd 6992189: G1: inconsistent base used in sparse rem set iterator Summary: The remembered set iterator for sparse tables incorrectly assumes that index 0 corresponds to the bottom of the heap, not address 0 as it is the case. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: a5c514e74487 Author: johnc Date: 2010-10-18 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a5c514e74487 6988458: G1: assert(mr.end() <= _cm->finger()) failed: otherwise the region shouldn't be on the stack Summary: The changes from 6941395 did not clear the CMTask::_aborted_region fields when concurrent marking aborted because of overflow. As a result, the next time around we could see a memory region whose start address was above the global finger and the assertion tripped. Moved the clearing of the aborted regions to ConcurrentMark::clear_marking_state, which is executed on all of the exit paths. Reviewed-by: tonyp, ysr, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 72a161e62cc4 Author: tonyp Date: 2010-10-16 17:12 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/72a161e62cc4 6991377: G1: race between concurrent refinement and humongous object allocation Summary: There is a race between the concurrent refinement threads and the humongous object allocation that can cause the concurrent refinement threads to corrupt the part of the BOT that it is being initialized by the humongous object allocation operation. The solution is to do the humongous object allocation in careful steps to ensure that the concurrent refinement threads always have a consistent view over the BOT, region contents, and top. The fix includes some very minor tidying up in sparsePRT. Reviewed-by: jcoomes, johnc, ysr ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: cd3ef3fd20dd Author: ysr Date: 2010-10-21 17:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cd3ef3fd20dd 6992998: CMSWaitDuration=0 causes hangs with +ExplicitGCInvokesConcurrent Summary: Closed a timing hole during which concurrent full gc requests can be missed. The hole can increase the latency of the response to a full gc request by up to the value of CMSWaitDuration. If CMSWaitDuration=0 is, as currently, interpreted as an unbounded wait, suitable in certain tuning scenarios, the application can potentially hang. Made two obscure tunables, including CMSWaitDuration, manageable. Reviewed-by: jcoomes, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp Changeset: a7214d79fcf1 Author: ysr Date: 2010-10-23 23:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a7214d79fcf1 6896603: CMS/GCH: collection_attempt_is_safe() ergo should use more recent data Summary: Deprecated HandlePromotionFailure, removing the ability to turn off that feature, did away with one epoch look-ahead when deciding if a scavenge is likely to fail, relying on current data. Reviewed-by: jmasa, johnc, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: c766bae6c14d Author: ysr Date: 2010-10-28 14:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c766bae6c14d 6995045: assert(!gch->incremental_collection_failed()) failed: Error, defNewGeneration.cpp:827 Summary: Sharpened an assert, introduced in 6896603, that intended to check that the incremental_collection_failed() predicate on the heap was being reset "soon enough". Reviewed-by: jmasa ! src/share/vm/memory/defNewGeneration.cpp Changeset: f5c8d6e5bfee Author: jcoomes Date: 2010-11-01 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f5c8d6e5bfee Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9de67bf4244d Author: iveresov Date: 2010-11-02 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9de67bf4244d 6996136: VM crash in src/share/vm/runtime/virtualspace.cpp:424 Summary: Turn CDS off if compressed oops is on Reviewed-by: ysr, kvn, jcoomes, phh ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 4ac698856c43 Author: trims Date: 2010-11-04 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4ac698856c43 Merge - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp Changeset: 698b7b727e12 Author: trims Date: 2010-11-10 20:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/698b7b727e12 Merge ! .hgtags - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp Changeset: 3ef7426b4dea Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3ef7426b4dea Added tag jdk7-b118 for changeset 698b7b727e12 ! .hgtags Changeset: 79401ff1d56d Author: lana Date: 2010-11-13 18:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/79401ff1d56d Merge - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp From lana.steuck at oracle.com Sun Nov 14 06:42:45 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 14 Nov 2010 06:42:45 +0000 Subject: hg: jdk7/tl/jaxp: 2 new changesets Message-ID: <20101114064245.14D4D479B0@hg.openjdk.java.net> Changeset: b2f6d9c4f12f Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/b2f6d9c4f12f Added tag jdk7-b117 for changeset 9ee4d96e8934 ! .hgtags Changeset: 9ee900f01c58 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/9ee900f01c58 Added tag jdk7-b118 for changeset b2f6d9c4f12f ! .hgtags From lana.steuck at oracle.com Sun Nov 14 06:42:50 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 14 Nov 2010 06:42:50 +0000 Subject: hg: jdk7/tl/jaxws: 2 new changesets Message-ID: <20101114064250.D7BE4479B1@hg.openjdk.java.net> Changeset: 19a2fab3f91a Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/19a2fab3f91a Added tag jdk7-b117 for changeset 1320fb3bb588 ! .hgtags Changeset: 41fa02b36637 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/41fa02b36637 Added tag jdk7-b118 for changeset 19a2fab3f91a ! .hgtags From lana.steuck at oracle.com Sun Nov 14 06:45:32 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 14 Nov 2010 06:45:32 +0000 Subject: hg: jdk7/tl/jdk: 38 new changesets Message-ID: <20101114065156.36245479B2@hg.openjdk.java.net> Changeset: d87c1c06bbf9 Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d87c1c06bbf9 Added tag jdk7-b117 for changeset 3e6726bbf80a ! .hgtags Changeset: 1bebd1f9445b Author: katakai Date: 2010-11-07 19:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1bebd1f9445b 4225362: localized DateFormatSymbols for fr_FR is wrong Reviewed-by: yhuang, peytoia ! 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 ! test/sun/text/resources/LocaleData Changeset: 0660c48dd705 Author: yhuang Date: 2010-11-07 23:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0660c48dd705 Merge Changeset: 565be51eb60e Author: cl Date: 2010-11-09 11:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/565be51eb60e Merge Changeset: 12b65e7ee3e4 Author: bae Date: 2010-10-22 16:57 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/12b65e7ee3e4 6663447: D3D: excessive surface data replacements Reviewed-by: prr, art ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 065e6c5a8027 Author: dlila Date: 2010-10-26 10:39 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/065e6c5a8027 6967434: Round joins/caps of scaled up lines have poor quality. Summary: eliminated flattening from the rendering engine. Reviewed-by: flar + src/share/classes/sun/java2d/pisces/Curve.java ! src/share/classes/sun/java2d/pisces/Dasher.java + src/share/classes/sun/java2d/pisces/Helpers.java - src/share/classes/sun/java2d/pisces/LineSink.java ! src/share/classes/sun/java2d/pisces/PiscesCache.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java + src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java Changeset: d9890d8a8159 Author: bae Date: 2010-10-29 11:49 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d9890d8a8159 6670881: Phantom lines appear when rendering polygons & ellipses with antialiasing OFF Reviewed-by: prr, bae ! src/share/native/sun/java2d/loops/ProcessPath.c Changeset: c63c38b956c7 Author: lana Date: 2010-11-02 12:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c63c38b956c7 Merge - src/share/classes/sun/java2d/pisces/LineSink.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 90e394405356 Author: dav Date: 2010-10-22 12:46 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/90e394405356 6659228: GridBagConstraints API typo - 'ComponentOrienation' (missing t) 6210739: Need spec clarification of Scrollbar set/getVisibleAmount() Reviewed-by: anthony ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/Scrollbar.java Changeset: 18ad61517761 Author: lana Date: 2010-10-28 15:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/18ad61517761 Merge Changeset: 2b466aaec7af Author: lana Date: 2010-11-02 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2b466aaec7af Merge Changeset: 4a29a9ff158c Author: okutsu Date: 2010-10-20 14:41 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a29a9ff158c 6991380: (cal) Calendar.cachedLocaleData should be transitioned from Hashtable to ConcurrentHashMap 6560965: [Fmt-Da] defaultCenturyStart In SimpleDateFormat should be protected 6560980: [Fmt-Da] DateFormatSymbols.cacheLookup doesn't update cache correctly. Reviewed-by: naoto, peytoia ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/TimeZone.java Changeset: 1f45c4c1f3a7 Author: amenkov Date: 2010-10-20 15:08 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f45c4c1f3a7 6867515: Reduce impact of D3D initializion on startup time 6891435: Improve D3D preloading 6946559: AWTToolKit thread crashes in JNU_GetEnv 6987967: D3D preloading thread should initialize COM Reviewed-by: igor, art, uta ! src/windows/bin/java_md.c ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.h ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: db2bc901c702 Author: alexp Date: 2010-10-20 19:37 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/db2bc901c702 6989617: Enable JComponent to control repaintings of its children Reviewed-by: rupashka ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/RepaintManager.java + test/javax/swing/JComponent/6989617/bug6989617.java Changeset: 64f599571511 Author: malenkov Date: 2010-10-21 20:41 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/64f599571511 4358979: javax.swing.border should have a DashedBorder Reviewed-by: flar, alexp ! src/share/classes/java/awt/BasicStroke.java ! src/share/classes/java/awt/GradientPaint.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/javax/swing/BorderFactory.java + src/share/classes/javax/swing/border/StrokeBorder.java + test/java/beans/XMLEncoder/java_awt_BasicStroke.java + test/java/beans/XMLEncoder/java_awt_GradientPaint.java + test/java/beans/XMLEncoder/java_awt_LinearGradientPaint.java + test/java/beans/XMLEncoder/java_awt_RadialGradientPaint.java + test/java/beans/XMLEncoder/java_awt_geom_AffineTransform.java + test/java/beans/XMLEncoder/javax_swing_border_StrokeBorder.java Changeset: 3e1415e9a52c Author: peterz Date: 2010-10-22 16:25 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3e1415e9a52c 6993140: protected constructor in javax.swing.plaf.synth.SynthTabbedPaneUI.SynthTabbedPaneUI is needed Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java Changeset: f52ad79e2826 Author: naoto Date: 2010-10-22 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f52ad79e2826 6993339: Bug4168625Test.java fails Reviewed-by: peytoia ! test/java/util/ResourceBundle/Bug4168625Test.java Changeset: a2c3278c377c Author: rupashka Date: 2010-10-25 18:25 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a2c3278c377c 6816582: WindowsFileChooserUI throws NullPointer when awt.useSystemAAFontSettings=false Reviewed-by: uta ! src/share/classes/java/awt/Toolkit.java Changeset: e650bbeab2f2 Author: rupashka Date: 2010-10-25 19:24 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e650bbeab2f2 6632810: javax.swing.plaf.basic.BasicScrollPaneUI.getBaseline(JComponent, int, int) doesn't throw NPE and IAE Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java + test/javax/swing/plaf/basic/BasicScrollPaneUI/Test6632810.java Changeset: eb466bafbc00 Author: rupashka Date: 2010-10-26 12:35 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eb466bafbc00 6735286: javax.swing.DefaultTableCellRender.getTableCellRendererComponent() doesn't allow passing null Tables Reviewed-by: alexp ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java + test/javax/swing/JTable/6735286/bug6735286.java Changeset: de89eec422c3 Author: rupashka Date: 2010-10-29 04:24 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de89eec422c3 6659894: JDialog instance returns unexpected GraphicsConfiguration Reviewed-by: alexp ! src/share/classes/javax/swing/JDialog.java Changeset: 30bc265fa0d0 Author: peytoia Date: 2010-11-02 15:08 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/30bc265fa0d0 6996686: (tz) Support tzdata2010o Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/zone.tab Changeset: e86aef08aa1f Author: rupashka Date: 2010-11-02 13:32 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e86aef08aa1f 6432566: Replace usage of StringBuffer with StringBuilder in Swing Reviewed-by: malenkov ! src/share/classes/javax/swing/DebugGraphics.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/TabSet.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/MinimalHTMLWriter.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/text/rtf/AbstractFilter.java Changeset: 12dc06e49f49 Author: amenkov Date: 2010-11-02 14:59 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/12dc06e49f49 6950553: Applet: IE process crash in OLE32.DLL when playing a sound Reviewed-by: poonam ! make/javax/sound/jsoundds/Makefile ! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_DirectSound.cpp Changeset: ff9d09604606 Author: amenkov Date: 2010-11-02 15:04 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ff9d09604606 Merge Changeset: e4d839f8dfee Author: naoto Date: 2010-11-02 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e4d839f8dfee 6989111: Incorrect default locale for New Zealand 6990452: Provide system properties for the user specified script 6992312: Currency becomes XXX if do not specify user.country.format Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java ! src/share/classes/sun/util/resources/LocaleNames.properties ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/java/lang/locale_str.h ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/sun/windows/awt_InputMethod.cpp ! test/java/util/Locale/data/deflocale.rhel5 ! test/java/util/Locale/data/deflocale.rhel5.fmtasdefault ! test/java/util/Locale/data/deflocale.sol10 ! test/java/util/Locale/data/deflocale.sol10.fmtasdefault ! test/java/util/Locale/data/deflocale.win7 ! test/java/util/Locale/data/deflocale.win7.fmtasdefault Changeset: ea5fd0550613 Author: lana Date: 2010-11-02 12:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea5fd0550613 Merge ! src/share/native/java/lang/System.c ! src/solaris/native/java/lang/java_props_md.c ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 45601fbddedf Author: lana Date: 2010-11-02 19:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/45601fbddedf Merge - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java ! src/windows/bin/java_md.c - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java Changeset: ddb39b2582b1 Author: naoto Date: 2010-11-05 20:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ddb39b2582b1 6997928: LocaleCategory test fails with b118 PIT Reviewed-by: sherman ! test/java/util/Locale/LocaleCategory.java ! test/java/util/Locale/LocaleCategory.sh Changeset: bb30977193b0 Author: lana Date: 2010-11-09 22:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bb30977193b0 Merge - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java Changeset: 48f0b94573c8 Author: jrose Date: 2010-09-08 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/48f0b94573c8 6964498: JSR 292 invokedynamic sites need local bootstrap methods Summary: Add JVM_CONSTANT_InvokeDynamic records to constant pool to determine per-instruction BSMs; add MethodHandleProvider. Reviewed-by: twisti + src/share/classes/java/dyn/BootstrapMethod.java ! src/share/classes/java/dyn/CallSite.java + src/share/classes/java/dyn/ConstantCallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java + src/share/classes/java/dyn/MethodHandleProvider.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! test/java/dyn/MethodHandlesTest.java Changeset: d30ca8bcad63 Author: jrose Date: 2010-09-08 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d30ca8bcad63 6980096: JSR 292 reflective lookup should throw checked exceptions Summary: Make NoAccessException be a checked exception. Also remove JavaMethodHandle. Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/JavaMethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/NoAccessException.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/Invokers.java + src/share/classes/sun/dyn/JavaMethodHandle.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/util/ValueConversions.java + test/java/dyn/JavaDocExamples.java ! test/java/dyn/MethodHandlesTest.java Changeset: 93f36769ecef Author: jrose Date: 2010-09-08 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93f36769ecef 6953246: JSR 292 should support SAM conversion Summary: Conversion function MethodHandles.asInstance; initial slow implementation based on Proxy. Reviewed-by: twisti ! src/share/classes/java/dyn/MethodHandles.java ! test/java/dyn/MethodHandlesTest.java Changeset: 4ed243e9e9d9 Author: jrose Date: 2010-09-14 01:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4ed243e9e9d9 6982752: dynamic languages need to decorate types with runtime information Summary: Add ClassValue Reviewed-by: twisti + src/share/classes/java/dyn/ClassValue.java + test/java/dyn/ClassValueTest.java Changeset: aec1afae879d Author: trims Date: 2010-11-04 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aec1afae879d Merge - make/common/Rules-SCCS.gmk - src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/NoAccessException.java - src/share/native/sun/java2d/cmm/lcms/cmscam97.c - src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c - src/share/native/sun/java2d/cmm/lcms/icc34.h - src/share/native/sun/java2d/cmm/lcms/lcms.h - src/solaris/classes/sun/net/spi/SdpProvider.java - src/solaris/native/sun/net/spi/SdpProvider.c - test/java/util/Locale/data/deflocale.exe - test/java/util/Locale/data/deflocale.jds3 - test/java/util/Locale/data/deflocale.rhel4 - test/java/util/Locale/data/deflocale.winvista - test/java/util/Locale/data/deflocale.winxp - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh - test/tools/launcher/VerifyExceptions.java Changeset: b357910aa04a Author: trims Date: 2010-11-10 20:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b357910aa04a Merge - src/share/classes/java/dyn/JavaMethodHandle.java Changeset: ecab7eefb8f2 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ecab7eefb8f2 Added tag jdk7-b118 for changeset b357910aa04a ! .hgtags Changeset: f70d0d0a84cd Author: lana Date: 2010-11-13 18:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f70d0d0a84cd Merge - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/sun/java2d/pisces/LineSink.java From lana.steuck at oracle.com Sun Nov 14 06:53:36 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 14 Nov 2010 06:53:36 +0000 Subject: hg: jdk7/tl/langtools: 5 new changesets Message-ID: <20101114065348.49FCF479B3@hg.openjdk.java.net> Changeset: 5bb96781fb58 Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5bb96781fb58 Added tag jdk7-b117 for changeset 2129a046f117 ! .hgtags Changeset: 534afdc92cdc Author: lana Date: 2010-11-02 19:41 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/534afdc92cdc Merge - src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java - src/share/classes/com/sun/source/tree/DisjointTypeTree.java - src/share/classes/com/sun/source/util/AbstractTypeProcessor.java - test/tools/javac/T6985181.java - test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java - test/tools/javac/treeannotests/AnnoTreeTests.java - test/tools/javac/typeAnnotations/6967002/T6967002.java - test/tools/javac/typeAnnotations/6967002/T6967002.out - test/tools/javac/typeAnnotations/InnerClass.java - test/tools/javac/typeAnnotations/MultipleTargets.java - test/tools/javac/typeAnnotations/TypeParameterTarget.java - test/tools/javac/typeAnnotations/TypeUseTarget.java - test/tools/javac/typeAnnotations/attribution/Scopes.java - test/tools/javac/typeAnnotations/classfile/DeadCode.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.out - test/tools/javac/typeAnnotations/failures/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/typeAnnotations/failures/IncompleteVararg.out - test/tools/javac/typeAnnotations/failures/IndexArray.java - test/tools/javac/typeAnnotations/failures/IndexArray.out - test/tools/javac/typeAnnotations/failures/LintCast.java - test/tools/javac/typeAnnotations/failures/LintCast.out - test/tools/javac/typeAnnotations/failures/OldArray.java - test/tools/javac/typeAnnotations/failures/Scopes.java - test/tools/javac/typeAnnotations/failures/Scopes.out - test/tools/javac/typeAnnotations/failures/StaticFields.java - test/tools/javac/typeAnnotations/failures/StaticFields.out - test/tools/javac/typeAnnotations/failures/StaticMethods.java - test/tools/javac/typeAnnotations/failures/StaticMethods.out - test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/target/Constructor.java - test/tools/javac/typeAnnotations/failures/target/Constructor.out - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out - test/tools/javac/typeAnnotations/failures/target/VoidMethod.java - test/tools/javac/typeAnnotations/failures/target/VoidMethod.out - test/tools/javac/typeAnnotations/newlocations/ClassExtends.java - test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java - test/tools/javac/typeAnnotations/newlocations/ClassParameters.java - test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/Expressions.java - test/tools/javac/typeAnnotations/newlocations/Fields.java - test/tools/javac/typeAnnotations/newlocations/LocalVariables.java - test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Parameters.java - test/tools/javac/typeAnnotations/newlocations/Receivers.java - test/tools/javac/typeAnnotations/newlocations/Throws.java - test/tools/javac/typeAnnotations/newlocations/TypeCasts.java - test/tools/javac/typeAnnotations/newlocations/TypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Wildcards.java - test/tools/javap/typeAnnotations/ArrayClassLiterals.java - test/tools/javap/typeAnnotations/ArrayClassLiterals2.java - test/tools/javap/typeAnnotations/ClassLiterals.java - test/tools/javap/typeAnnotations/JSR175Annotations.java - test/tools/javap/typeAnnotations/NewArray.java - test/tools/javap/typeAnnotations/Presence.java - test/tools/javap/typeAnnotations/PresenceInner.java - test/tools/javap/typeAnnotations/T6855990.java - test/tools/javap/typeAnnotations/Visibility.java Changeset: c491eec0acc7 Author: lana Date: 2010-11-09 22:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c491eec0acc7 Merge - src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java - src/share/classes/com/sun/source/tree/DisjointTypeTree.java - src/share/classes/com/sun/source/util/AbstractTypeProcessor.java - test/tools/javac/T6985181.java - test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java - test/tools/javac/treeannotests/AnnoTreeTests.java - test/tools/javac/typeAnnotations/6967002/T6967002.java - test/tools/javac/typeAnnotations/6967002/T6967002.out - test/tools/javac/typeAnnotations/InnerClass.java - test/tools/javac/typeAnnotations/MultipleTargets.java - test/tools/javac/typeAnnotations/TypeParameterTarget.java - test/tools/javac/typeAnnotations/TypeUseTarget.java - test/tools/javac/typeAnnotations/attribution/Scopes.java - test/tools/javac/typeAnnotations/classfile/DeadCode.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.out - test/tools/javac/typeAnnotations/failures/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/typeAnnotations/failures/IncompleteVararg.out - test/tools/javac/typeAnnotations/failures/IndexArray.java - test/tools/javac/typeAnnotations/failures/IndexArray.out - test/tools/javac/typeAnnotations/failures/LintCast.java - test/tools/javac/typeAnnotations/failures/LintCast.out - test/tools/javac/typeAnnotations/failures/OldArray.java - test/tools/javac/typeAnnotations/failures/Scopes.java - test/tools/javac/typeAnnotations/failures/Scopes.out - test/tools/javac/typeAnnotations/failures/StaticFields.java - test/tools/javac/typeAnnotations/failures/StaticFields.out - test/tools/javac/typeAnnotations/failures/StaticMethods.java - test/tools/javac/typeAnnotations/failures/StaticMethods.out - test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/target/Constructor.java - test/tools/javac/typeAnnotations/failures/target/Constructor.out - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out - test/tools/javac/typeAnnotations/failures/target/VoidMethod.java - test/tools/javac/typeAnnotations/failures/target/VoidMethod.out - test/tools/javac/typeAnnotations/newlocations/ClassExtends.java - test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java - test/tools/javac/typeAnnotations/newlocations/ClassParameters.java - test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/Expressions.java - test/tools/javac/typeAnnotations/newlocations/Fields.java - test/tools/javac/typeAnnotations/newlocations/LocalVariables.java - test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Parameters.java - test/tools/javac/typeAnnotations/newlocations/Receivers.java - test/tools/javac/typeAnnotations/newlocations/Throws.java - test/tools/javac/typeAnnotations/newlocations/TypeCasts.java - test/tools/javac/typeAnnotations/newlocations/TypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Wildcards.java - test/tools/javap/typeAnnotations/ArrayClassLiterals.java - test/tools/javap/typeAnnotations/ArrayClassLiterals2.java - test/tools/javap/typeAnnotations/ClassLiterals.java - test/tools/javap/typeAnnotations/JSR175Annotations.java - test/tools/javap/typeAnnotations/NewArray.java - test/tools/javap/typeAnnotations/Presence.java - test/tools/javap/typeAnnotations/PresenceInner.java - test/tools/javap/typeAnnotations/T6855990.java - test/tools/javap/typeAnnotations/Visibility.java Changeset: 814561077c44 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/814561077c44 Added tag jdk7-b118 for changeset c491eec0acc7 ! .hgtags Changeset: a7faadc252c8 Author: lana Date: 2010-11-13 19:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a7faadc252c8 Merge From joe.darcy at oracle.com Sun Nov 14 15:18:21 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sun, 14 Nov 2010 15:18:21 +0000 Subject: hg: jdk7/tl/langtools: 6991528: Support making Throwable.suppressedExceptions immutable Message-ID: <20101114151825.49B51479C5@hg.openjdk.java.net> Changeset: 4328728e0409 Author: darcy Date: 2010-11-14 07:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4328728e0409 6991528: Support making Throwable.suppressedExceptions immutable Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! test/tools/javac/TryWithResources/TwrSuppression.java ! test/tools/javac/TryWithResources/TwrTests.java From joe.darcy at oracle.com Sun Nov 14 15:23:29 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sun, 14 Nov 2010 15:23:29 +0000 Subject: hg: jdk7/tl/jdk: 6991528: Support making Throwable.suppressedExceptions immutable Message-ID: <20101114152348.F28BA479C6@hg.openjdk.java.net> Changeset: e1a1a2f5d7e1 Author: darcy Date: 2010-11-14 07:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1a1a2f5d7e1 6991528: Support making Throwable.suppressedExceptions immutable Reviewed-by: mchung, dholmes ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/lang/Throwable.java ! test/java/lang/Throwable/StackTraceSerialization.java ! test/java/lang/Throwable/SuppressedExceptions.java From forax at univ-mlv.fr Sun Nov 14 19:24:56 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 14 Nov 2010 20:24:56 +0100 Subject: hg: jdk7/tl/jdk: 6991528: Support making Throwable.suppressedExceptions immutable In-Reply-To: <20101114152348.F28BA479C6@hg.openjdk.java.net> References: <20101114152348.F28BA479C6@hg.openjdk.java.net> Message-ID: <4CE03788.6040109@univ-mlv.fr> Le 14/11/2010 16:23, joe.darcy at oracle.com a ?crit : > Changeset: e1a1a2f5d7e1 > Author: darcy > Date: 2010-11-14 07:22 -0800 > URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1a1a2f5d7e1 > > 6991528: Support making Throwable.suppressedExceptions immutable > Reviewed-by: mchung, dholmes > > ! src/share/classes/java/lang/StackTraceElement.java > ! src/share/classes/java/lang/Throwable.java > ! test/java/lang/Throwable/StackTraceSerialization.java > ! test/java/lang/Throwable/SuppressedExceptions.java > > Hi Joe, StackTraceElement.equals checks if methodName is null even if it can not be null by construction. Also the code can be a little more efficient if the lineNumber are checked before checking the declaring class. The code should be: return e.lineNumber == lineNumber && e.declaringClass.equals(declaringClass) && methodName.equals(e.methodName) && Objects.equals(fileName, e.fileName); R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Holmes at oracle.com Mon Nov 15 03:18:09 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 15 Nov 2010 13:18:09 +1000 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDDA0DF.6020608@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> <4CDCCC9E.3050204@oracle.com> <4CDDA0DF.6020608@oracle.COM> Message-ID: <4CE0A671.9020600@oracle.com> Hi Kumar, This appeases my concerns about the VM settings. Thanks, David Kumar Srinivasan said the following on 11/13/10 06:17: > Thanks for all the reviews!. > > Here are the fixes in this version: > http://cr.openjdk.java.net/~ksrini/6452854/webrev.01 > > 1. Fixed the representation of numbers and scaling using BigDecimal. > 2. Argument processing checks for -XshowSettings and -XshowSetting:opt > (added a test to catch the former, added some comments in java.c) > 3. Replaced String* with PrintStream.print*, it makes the logic easier > to read, so I decided to go with this. > 4. Removed extraneous path.separators. > 5. line.separator will be printed as ASCII symbols CR and LF > 6. If the helper cannot determine the value that line will not be > displayed. > 7. In the case of the Max memory not gotten from the launcher > (Estimated) is printed. > 8. Removed the option hints -X* and so on in the labels. > 9. Renamed Ergonomic Class -> Ergonomic Machine Class. > > Thanks > Kumar > > > > >> On 11/11/2010 16:42, Kumar Srinivasan wrote: >>>> line 176, 188, 190-191, 195, and other lines in printPrintLocales >>>> and printLocale methods: >>>> - the assignment to the buf and out variable to itself (returned >>>> from StringBuffer.append() method) is not necessary. >>> >>> >>> Yes fixed, I missed these. >> >> The "intention" of returning the StringBuffer itself for those >> append() methods is that >> you can then write the code like >> >> >> private static void printLocale(PrintStream ostream) { >> ostream.println(new StringBuilder("\n" + LOCALE_SETTINGS + "\n") >> .append(INDENT) >> .append("default locale: ") >> .append(Locale.getDefault().getDisplayLanguage()) >> .append(prettyPrintLocales()) >> .toString()); >> } >> >> >> One more nit is that you might want to do something special for >> >> line.separator = >> >> to make it "readable" >> >> -Sherman >> > From ptisnovs at redhat.com Mon Nov 15 12:10:55 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 15 Nov 2010 13:10:55 +0100 Subject: Please review correction of regression test Test6929067 Message-ID: <4CE1234F.4080100@redhat.com> Hi, can anybody please review correction of regression test runtime/6929067/Test6929067? I changed this test in a way that it now correctly works on x86_64 platform for example. Webrev is available at: http://cr.openjdk.java.net/~ptisnovs/JTreg_Test6929067/ Thank you in advance Pavel From Alan.Bateman at oracle.com Mon Nov 15 12:34:56 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Nov 2010 12:34:56 +0000 Subject: Please review correction of regression test Test6929067 In-Reply-To: <4CE1234F.4080100@redhat.com> References: <4CE1234F.4080100@redhat.com> Message-ID: <4CE128F0.3050900@oracle.com> Pavel Tisnovsky wrote: > Hi, > > can anybody please review correction of regression test > runtime/6929067/Test6929067? > > I changed this test in a way that it now correctly works on x86_64 > platform for example. > > Webrev is available at: > http://cr.openjdk.java.net/~ptisnovs/JTreg_Test6929067/ > > Thank you in advance > Pavel > Pavel - as this is a runtime test in the hotspot repo then it would be best to send this to hotspot-runtime-dev. Also, I think jdk7/hotspot-rt/hotspot would be a better repo to target as it complicates integration a bit if there are changesets for the hotspot repo pushed to the jdk7/tl forest. -Alan From ptisnovs at redhat.com Mon Nov 15 13:06:05 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 15 Nov 2010 14:06:05 +0100 Subject: Please review correction of regression test Test6929067 In-Reply-To: <4CE128F0.3050900@oracle.com> References: <4CE1234F.4080100@redhat.com> <4CE128F0.3050900@oracle.com> Message-ID: <4CE1303D.3020303@redhat.com> Alan Bateman wrote: > Pavel Tisnovsky wrote: >> Hi, >> >> can anybody please review correction of regression test >> runtime/6929067/Test6929067? >> >> I changed this test in a way that it now correctly works on x86_64 >> platform for example. >> >> Webrev is available at: >> http://cr.openjdk.java.net/~ptisnovs/JTreg_Test6929067/ >> >> Thank you in advance >> Pavel >> > Pavel - as this is a runtime test in the hotspot repo then it would be > best to send this to hotspot-runtime-dev. Also, I think > jdk7/hotspot-rt/hotspot would be a better repo to target as it > complicates integration a bit if there are changesets for the hotspot > repo pushed to the jdk7/tl forest. Hi Alan, thank you for info, I'll send mail with proper webrev to hotspot-runtime-dev. Pavel > > -Alan From alan.bateman at oracle.com Mon Nov 15 14:36:51 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 15 Nov 2010 14:36:51 +0000 Subject: hg: jdk7/tl/jdk: 6999915: TEST_BUG: test/java/nio/channels/AsynchronousSocketChannel/Leaky.java failed intermittently (win) Message-ID: <20101115143702.7CFD9479F5@hg.openjdk.java.net> Changeset: f88048284eb6 Author: alanb Date: 2010-11-15 14:34 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f88048284eb6 6999915: TEST_BUG: test/java/nio/channels/AsynchronousSocketChannel/Leaky.java failed intermittently (win) Reviewed-by: forax ! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java From maurizio.cimadamore at oracle.com Mon Nov 15 14:53:48 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 15 Nov 2010 14:53:48 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20101115145352.09EC7479F6@hg.openjdk.java.net> Changeset: a7ea58fa3e9a Author: mcimadamore Date: 2010-11-15 13:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a7ea58fa3e9a 6985719: Alike methods in interfaces (Inheritance and Overriding) Summary: javac should report error when interface inherits unrelated method with same erasure Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/6985719/T6985719a.java + test/tools/javac/generics/6985719/T6985719a.out + test/tools/javac/generics/6985719/T6985719b.java + test/tools/javac/generics/6985719/T6985719b.out + test/tools/javac/generics/6985719/T6985719c.java + test/tools/javac/generics/6985719/T6985719c.out + test/tools/javac/generics/6985719/T6985719d.java + test/tools/javac/generics/6985719/T6985719d.out + test/tools/javac/generics/6985719/T6985719e.java + test/tools/javac/generics/6985719/T6985719e.out + test/tools/javac/generics/6985719/T6985719f.java + test/tools/javac/generics/6985719/T6985719f.out + test/tools/javac/generics/6985719/T6985719g.java + test/tools/javac/generics/6985719/T6985719g.out + test/tools/javac/generics/6985719/T6985719h.java + test/tools/javac/generics/6985719/T6985719h.out Changeset: 1dd813a529cf Author: mcimadamore Date: 2010-11-15 14:41 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1dd813a529cf 6999635: Multicatch: crash while compiling simple code with a multicatch parameter Summary: missing erasure when computing stackmaps leads to assertion error Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java + test/tools/javac/multicatch/Pos08.java + test/tools/javac/multicatch/Pos08eff_final.java From chris.hegarty at oracle.com Mon Nov 15 15:11:49 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 15 Nov 2010 15:11:49 +0000 Subject: hg: jdk7/tl/jdk: 6993789: LinkedBlockingDeque iterator/descendingIterator loops and owns lock forever Message-ID: <20101115151200.664C8479F8@hg.openjdk.java.net> Changeset: bf284d2db008 Author: chegar Date: 2010-11-15 15:11 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf284d2db008 6993789: LinkedBlockingDeque iterator/descendingIterator loops and owns lock forever Reviewed-by: dl, dholmes ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java From xueming.shen at oracle.com Mon Nov 15 17:35:17 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 15 Nov 2010 17:35:17 +0000 Subject: hg: jdk7/tl/jdk: 6994145: (zipfs) README should be updated; ... Message-ID: <20101115173527.56C0147A01@hg.openjdk.java.net> Changeset: 0682c9357897 Author: sherman Date: 2010-11-15 09:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0682c9357897 6994145: (zipfs) README should be updated 6994161: (zipfs) newFileSystem method should FileSystemAlreadyExistsException 6994152: (zipfs) copyTo ignores COPY_ATTRIBUTES option Summary: zipfile update Reviewed-by: alanb ! make/mkdemo/nio/zipfs/Makefile ! src/share/demo/nio/zipfs/Demo.java ! src/share/demo/nio/zipfs/README.txt ! src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java ! src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java ! src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java ! src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java ! src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java ! src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java ! src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java ! src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java ! test/demo/zipfs/ZipFSTester.java From xueming.shen at oracle.com Mon Nov 15 17:50:38 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 15 Nov 2010 17:50:38 +0000 Subject: hg: jdk7/tl/jdk: 6544278: SecurityException not thrown for Indexed Jar file whose signature is corrupted Message-ID: <20101115175047.E44B647A02@hg.openjdk.java.net> Changeset: 23ccf9a8451f Author: sherman Date: 2010-11-15 09:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/23ccf9a8451f 6544278: SecurityException not thrown for Indexed Jar file whose signature is corrupted Summary: Added code to deal with the index case specially. Reviewed-by: mullan ! src/share/classes/java/util/jar/JarInputStream.java + test/java/util/jar/JarInputStream/BadSignedJar.jar + test/java/util/jar/JarInputStream/TestIndexedJarWithBadSignature.java From naoto.sato at oracle.com Mon Nov 15 19:07:15 2010 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 15 Nov 2010 11:07:15 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDDA0DF.6020608@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> <4CDCCC9E.3050204@oracle.com> <4CDDA0DF.6020608@oracle.COM> Message-ID: <4CE184E3.1040506@oracle.com> Hi Kumar, I just noticed this locale printing feature. In JDK7, we have provided the default locale for UIs (Locale.getDefault(LocaleCategory.DISPLAY)), and the one for formatting (Locale.getDefault(LocaleCategory.FORMAT)), so you may want to show them along with the original default locale. Naoto (11/12/10 12:17 PM), Kumar Srinivasan wrote: > Thanks for all the reviews!. > > Here are the fixes in this version: > http://cr.openjdk.java.net/~ksrini/6452854/webrev.01 > > 1. Fixed the representation of numbers and scaling using BigDecimal. > 2. Argument processing checks for -XshowSettings and -XshowSetting:opt > (added a test to catch the former, added some comments in java.c) > 3. Replaced String* with PrintStream.print*, it makes the logic easier > to read, so I decided to go with this. > 4. Removed extraneous path.separators. > 5. line.separator will be printed as ASCII symbols CR and LF > 6. If the helper cannot determine the value that line will not be > displayed. > 7. In the case of the Max memory not gotten from the launcher > (Estimated) is printed. > 8. Removed the option hints -X* and so on in the labels. > 9. Renamed Ergonomic Class -> Ergonomic Machine Class. > > Thanks > Kumar > > > > >> On 11/11/2010 16:42, Kumar Srinivasan wrote: >>>> line 176, 188, 190-191, 195, and other lines in printPrintLocales >>>> and printLocale methods: >>>> - the assignment to the buf and out variable to itself (returned >>>> from StringBuffer.append() method) is not necessary. >>> >>> >>> Yes fixed, I missed these. >> >> The "intention" of returning the StringBuffer itself for those >> append() methods is that >> you can then write the code like >> >> >> private static void printLocale(PrintStream ostream) { >> ostream.println(new StringBuilder("\n" + LOCALE_SETTINGS + "\n") >> .append(INDENT) >> .append("default locale: ") >> .append(Locale.getDefault().getDisplayLanguage()) >> .append(prettyPrintLocales()) >> .toString()); >> } >> >> >> One more nit is that you might want to do something special for >> >> line.separator = >> >> to make it "readable" >> >> -Sherman >> > From kumar.x.srinivasan at oracle.COM Mon Nov 15 19:56:27 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 15 Nov 2010 11:56:27 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CE184E3.1040506@oracle.com> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> <4CDCCC9E.3050204@oracle.com> <4CDDA0DF.6020608@oracle.COM> <4CE184E3.1040506@oracle.com> Message-ID: <4CE1906B.4010402@oracle.COM> Hi Naoto, If there is another round of changes required I will consider your suggestion otherwise I will fix it later as a bug fix. Thanks Kumar > Hi Kumar, > > I just noticed this locale printing feature. > > In JDK7, we have provided the default locale for UIs > (Locale.getDefault(LocaleCategory.DISPLAY)), and the one for > formatting (Locale.getDefault(LocaleCategory.FORMAT)), so you may want > to show them along with the original default locale. > > Naoto > > (11/12/10 12:17 PM), Kumar Srinivasan wrote: >> Thanks for all the reviews!. >> >> Here are the fixes in this version: >> http://cr.openjdk.java.net/~ksrini/6452854/webrev.01 >> >> 1. Fixed the representation of numbers and scaling using BigDecimal. >> 2. Argument processing checks for -XshowSettings and -XshowSetting:opt >> (added a test to catch the former, added some comments in java.c) >> 3. Replaced String* with PrintStream.print*, it makes the logic easier >> to read, so I decided to go with this. >> 4. Removed extraneous path.separators. >> 5. line.separator will be printed as ASCII symbols CR and LF >> 6. If the helper cannot determine the value that line will not be >> displayed. >> 7. In the case of the Max memory not gotten from the launcher >> (Estimated) is printed. >> 8. Removed the option hints -X* and so on in the labels. >> 9. Renamed Ergonomic Class -> Ergonomic Machine Class. >> >> Thanks >> Kumar >> >> >> >> >>> On 11/11/2010 16:42, Kumar Srinivasan wrote: >>>>> line 176, 188, 190-191, 195, and other lines in printPrintLocales >>>>> and printLocale methods: >>>>> - the assignment to the buf and out variable to itself (returned >>>>> from StringBuffer.append() method) is not necessary. >>>> >>>> >>>> Yes fixed, I missed these. >>> >>> The "intention" of returning the StringBuffer itself for those >>> append() methods is that >>> you can then write the code like >>> >>> >>> private static void printLocale(PrintStream ostream) { >>> ostream.println(new StringBuilder("\n" + LOCALE_SETTINGS + "\n") >>> .append(INDENT) >>> .append("default locale: ") >>> .append(Locale.getDefault().getDisplayLanguage()) >>> .append(prettyPrintLocales()) >>> .toString()); >>> } >>> >>> >>> One more nit is that you might want to do something special for >>> >>> line.separator = >>> >>> to make it "readable" >>> >>> -Sherman >>> >> > From kumar.x.srinivasan at oracle.com Tue Nov 16 01:24:17 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 15 Nov 2010 17:24:17 -0800 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: <4CDC3EBB.20500@oracle.com> References: <4CDC27E1.9000909@oracle.COM> <4CDC3EBB.20500@oracle.com> Message-ID: <4CE1DD41.2050406@oracle.COM> Hi John, et. al., This revision contains all fixes noted by Brian below and other comments from Alan. http://cr.openjdk.java.net/~ksrini/6990106/webrev.01/ Thanks Kumar > Mostly style issues, but at least one likely bug. > > In a few places, you've used @SuppressWarnings("unchecked"). While > this may well be unavoidable, it is worth factoring this out into the > smallest possible chunk. For BandStructure, you've applied it to the > whole class, and there's some big methods that use it too. You can > usually get it down to a small "makeArrayOfGenericFoo" method, since > this is the most common source of non-fixable unchecked warnings. > > Also using an interface like Constants to import symbols is an > antipattern and is better replaced with static imports. > > In ClassReader you've replaced use of new Integer() and friends with > Integer.valueOf(), but its better style to go all the way and just use > autoboxing. > > In Instruction the equals() method takes into account bc, w, length, > and bytes, but the hashCode() method also takes into account pc. This > may violate the "equal objects must have equal hashcodes" rule. > > Throughout you've changed loops from > for (Iterator i=...) > to > for (Iterator i=...) > but didn't go all the way and just use foreach loops. > > PropMap should extend TreeMap by composition, not extension. This > implementation is subject to the hazards outlined in the Effective > Java item "Prefer composition to extension." (For example you > override put() but not putAll(), but this idiom cannot be made to work > without tightly coupling it to the superclass implementation.) > > On 11/11/2010 12:29 PM, Kumar Srinivasan wrote: >> Hi, >> >> Appreciate a review of the pack200 cleanup work, in the following areas: >> >> 1. General generification of Collections. >> 2. fixed worthy findbugs items. >> 3. fixed worthy Netbeans nags. >> 4. Elimination of array/generics combination. >> >> The webrev is here: >> http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/ >> >> Thanks >> Kumar >> From Alan.Bateman at oracle.com Tue Nov 16 14:34:24 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Nov 2010 14:34:24 +0000 Subject: 6613829: (docs) Readable.read() ReadOnlyBufferException is not linked Message-ID: <4CE29670.5040905@oracle.com> I need a reviewer to a trivial drive-by fix to java.lang.Readable's javadoc. Thanks, Alan. diff --git a/src/share/classes/java/lang/Readable.java b/src/share/classes/java/lang/Readable.java --- a/src/share/classes/java/lang/Readable.java +++ b/src/share/classes/java/lang/Readable.java @@ -44,11 +44,11 @@ public interface Readable { * rewinding of the buffer is performed. * * @param cb the buffer to read characters into - * @return @return The number of char values added to the buffer, + * @return The number of {@code char} values added to the buffer, * or -1 if this source of characters is at its end * @throws IOException if an I/O error occurs * @throws NullPointerException if cb is null - * @throws ReadOnlyBufferException if cb is a read only buffer + * @throws java.nio.ReadOnlyBufferException if cb is a read only buffer */ public int read(java.nio.CharBuffer cb) throws IOException; From Lance.Andersen at oracle.com Tue Nov 16 14:58:13 2010 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 16 Nov 2010 09:58:13 -0500 Subject: 6613829: (docs) Readable.read() ReadOnlyBufferException is not linked In-Reply-To: <4CE29670.5040905@oracle.com> References: <4CE29670.5040905@oracle.com> Message-ID: <1940AFE9-16BD-42F8-A5D8-225C013BCB6B@oracle.com> Looks good to me Alan. Regards Lance On Nov 16, 2010, at 9:34 AM, Alan Bateman wrote: > I need a reviewer to a trivial drive-by fix to java.lang.Readable's javadoc. > > Thanks, > Alan. > > diff --git a/src/share/classes/java/lang/Readable.java b/src/share/classes/java/lang/Readable.java > --- a/src/share/classes/java/lang/Readable.java > +++ b/src/share/classes/java/lang/Readable.java > @@ -44,11 +44,11 @@ public interface Readable { > * rewinding of the buffer is performed. > * > * @param cb the buffer to read characters into > - * @return @return The number of char values added to the buffer, > + * @return The number of {@code char} values added to the buffer, > * or -1 if this source of characters is at its end > * @throws IOException if an I/O error occurs > * @throws NullPointerException if cb is null > - * @throws ReadOnlyBufferException if cb is a read only buffer > + * @throws java.nio.ReadOnlyBufferException if cb is a read only buffer > */ > public int read(java.nio.CharBuffer cb) throws IOException; Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at ORACLE.COM Tue Nov 16 14:58:08 2010 From: chris.hegarty at ORACLE.COM (Chris Hegarty) Date: Tue, 16 Nov 2010 14:58:08 +0000 Subject: 6613829: (docs) Readable.read() ReadOnlyBufferException is not linked In-Reply-To: <4CE29670.5040905@oracle.com> References: <4CE29670.5040905@oracle.com> Message-ID: <4CE29C00.9060204@oracle.com> Alan, Looks fine. -Chris. Alan Bateman wrote: > I need a reviewer to a trivial drive-by fix to java.lang.Readable's > javadoc. > > Thanks, > Alan. > > diff --git a/src/share/classes/java/lang/Readable.java > b/src/share/classes/java/lang/Readable.java > --- a/src/share/classes/java/lang/Readable.java > +++ b/src/share/classes/java/lang/Readable.java > @@ -44,11 +44,11 @@ public interface Readable { > * rewinding of the buffer is performed. > * > * @param cb the buffer to read characters into > - * @return @return The number of char values added to the > buffer, > + * @return The number of {@code char} values added to the buffer, > * or -1 if this source of characters is at its end > * @throws IOException if an I/O error occurs > * @throws NullPointerException if cb is null > - * @throws ReadOnlyBufferException if cb is a read only buffer > + * @throws java.nio.ReadOnlyBufferException if cb is a read only > buffer > */ > public int read(java.nio.CharBuffer cb) throws IOException; From alan.bateman at oracle.com Tue Nov 16 15:24:05 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 16 Nov 2010 15:24:05 +0000 Subject: hg: jdk7/tl/jdk: 6613829: (docs) Readable.read() ReadOnlyBufferException is not linked Message-ID: <20101116152415.A4EA047A33@hg.openjdk.java.net> Changeset: 9ec7802cc759 Author: alanb Date: 2010-11-16 15:23 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9ec7802cc759 6613829: (docs) Readable.read() ReadOnlyBufferException is not linked Reviewed-by: chegar, lancea ! src/share/classes/java/lang/Readable.java From rob.mckenna at oracle.com Mon Nov 15 18:49:56 2010 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Mon, 15 Nov 2010 18:49:56 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20101115184957.909FA47A05@hg.openjdk.java.net> Changeset: f642c9ec81a0 Author: robm Date: 2010-11-15 10:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/f642c9ec81a0 6277781: Serialization of Enums over IIOP is broke. Summary: Reviewed by Ken Cavanaugh Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: cff5a173ec1e Author: robm Date: 2010-11-15 10:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/cff5a173ec1e 6763340: memory leak in com.sun.corba.se.* classes 6873605: Missing finishedDispatch() call in ORBImpl causes test failures after 5u20 b04 Summary: Reviewed by Ken Cavanaugh Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/interceptors/ClientRequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PIHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PINoOpHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/RequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java ! src/share/classes/com/sun/corba/se/spi/protocol/PIHandler.java + src/share/classes/com/sun/corba/se/spi/protocol/RetryType.java From mike.duigou at oracle.com Tue Nov 16 19:30:50 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 16 Nov 2010 11:30:50 -0800 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: <4CE1DD41.2050406@oracle.COM> References: <4CDC27E1.9000909@oracle.COM> <4CDC3EBB.20500@oracle.com> <4CE1DD41.2050406@oracle.COM> Message-ID: Attribute.java/Instruction.java/Package.java.File : - Layout.equals(Object x) { return x instanceof Layout && equals((Layout)x); } should be : Layout.equals(Object x) { return (null != x) && (x.getClass() == Layout.class) && equals((Layout)x); } as sub-classes also using instanceof would have a non-reflexive equals(). ie. layout.equals(someSubClassOfLayout) != someSubclassOfLayout.equals(layout) - Layout.isEmpty() { return layout.isEmpty(); } - BandStructure.java/ClassReader.java/Coding.java/CodingChooser.java/PackageReader.java/PackageWriter.java : is there a reason to use concrete types (HashMap, ArrayList, HashSet) for fields and vars such as basicCodingIndexes, allKQBands? It seems not. - Code.java : Arrays.copyOf and/or copyOfRange could be used rather than separate allocation and System.arrayCopy. - Package.java.stripAttributeKind() : could be a switch. - Package.java.File : possibly static class and final (which would eliminate the complaint about File.equals()) ? - PropMap._listeners could be final (and probably a List rather than explicitly an ArrayList). - PropMap.java : convert newly added final to ARM? - FixedList.java : Anything saved by extending AbstractList rather than implementing List? On Nov 15 2010, at 17:24 , Kumar Srinivasan wrote: > Hi John, et. al., > > This revision contains all fixes noted by Brian below and other > comments from Alan. > > http://cr.openjdk.java.net/~ksrini/6990106/webrev.01/ > > Thanks > Kumar > >> Mostly style issues, but at least one likely bug. >> >> In a few places, you've used @SuppressWarnings("unchecked"). While this may well be unavoidable, it is worth factoring this out into the smallest possible chunk. For BandStructure, you've applied it to the whole class, and there's some big methods that use it too. You can usually get it down to a small "makeArrayOfGenericFoo" method, since this is the most common source of non-fixable unchecked warnings. >> >> Also using an interface like Constants to import symbols is an antipattern and is better replaced with static imports. >> >> In ClassReader you've replaced use of new Integer() and friends with Integer.valueOf(), but its better style to go all the way and just use autoboxing. >> >> In Instruction the equals() method takes into account bc, w, length, and bytes, but the hashCode() method also takes into account pc. This may violate the "equal objects must have equal hashcodes" rule. >> >> Throughout you've changed loops from >> for (Iterator i=...) >> to >> for (Iterator i=...) >> but didn't go all the way and just use foreach loops. >> >> PropMap should extend TreeMap by composition, not extension. This implementation is subject to the hazards outlined in the Effective Java item "Prefer composition to extension." (For example you override put() but not putAll(), but this idiom cannot be made to work without tightly coupling it to the superclass implementation.) >> >> On 11/11/2010 12:29 PM, Kumar Srinivasan wrote: >>> Hi, >>> >>> Appreciate a review of the pack200 cleanup work, in the following areas: >>> >>> 1. General generification of Collections. >>> 2. fixed worthy findbugs items. >>> 3. fixed worthy Netbeans nags. >>> 4. Elimination of array/generics combination. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/ >>> >>> Thanks >>> Kumar >>> > From valerie.peng at oracle.com Tue Nov 16 19:53:06 2010 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Tue, 16 Nov 2010 19:53:06 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20101116195335.1ACB947A3E@hg.openjdk.java.net> Changeset: 86ea594c1d10 Author: valeriep Date: 2010-11-15 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/86ea594c1d10 6848930: JSN security test jce/Global/Cipher/PKCS5Padding cannot thrown expected BadPaddingException Summary: Disabled CKM_DES_CBC_PAD, CKM_DES3_CBC_PAD, CKM_AES_CBC_PAD mechs by default and use our own internal padding impl. Reviewed-by: wetmore ! src/share/lib/security/sunpkcs11-solaris.cfg Changeset: cb10e1177801 Author: valeriep Date: 2010-11-15 14:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb10e1177801 6687725: Internal PKCS5Padding impl should throw IllegalBlockSizeException and not BadPaddingException Summary: Changed to throw IllegalBlockSizeException when the data length isn't multiples of block size Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java + test/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java Changeset: 8134c0b75da5 Author: valeriep Date: 2010-11-16 11:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8134c0b75da5 Merge From abhi.saha at oracle.com Tue Nov 16 22:39:49 2010 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Tue, 16 Nov 2010 22:39:49 +0000 Subject: hg: jdk7/tl/corba: 5 new changesets Message-ID: <20101116223952.9809147A46@hg.openjdk.java.net> Changeset: e0f7ed041196 Author: skoppar Date: 2010-10-07 00:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/e0f7ed041196 6714797: InitialContext.close does not close NIO socket connections Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/transport/CorbaConnectionCacheBase.java ! src/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java ! src/share/classes/com/sun/corba/se/pept/transport/ConnectionCache.java ! src/share/classes/com/sun/corba/se/spi/transport/CorbaConnection.java Changeset: 459c07278c3c Author: skoppar Date: 2010-10-07 00:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/459c07278c3c 6893109: memory leak in readObject() and writeObject() using idlj from jdk 1.6.0_14 Reviewed-by: asaha ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/Stub.java Changeset: 2d3622317730 Author: skoppar Date: 2010-10-07 00:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/2d3622317730 6896157: unsynchronized hashmap in com.sun.corba.se.impl.transport.SelectorImpl.createReaderThread Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java Changeset: 5f026ab0098c Author: skoppar Date: 2010-10-07 00:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/5f026ab0098c 6929137: java-corba: Locking too broad in com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java Changeset: 34af2070439b Author: skoppar Date: 2010-10-07 01:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/34af2070439b 6948223: Corba issue, fail to reload object Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/oa/poa/AOMEntry.java ! src/share/classes/com/sun/corba/se/impl/oa/poa/POAPolicyMediatorBase_R.java From mike.duigou at oracle.com Tue Nov 16 23:39:21 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 16 Nov 2010 15:39:21 -0800 Subject: 70000691 : (coll) (doc) ConcurrentLinkedQueue @link to ConcurrentModificationException Message-ID: I'll ask the same as Alan for a small doc review for ConcurrentLinkedQueue Thanks, Mike diff --git a/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java b/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java --- a/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java +++ b/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java @@ -65,8 +65,8 @@ *

Iterators are weakly consistent, returning elements * reflecting the state of the queue at some point at or since the * creation of the iterator. They do not throw {@link - * ConcurrentModificationException}, and may proceed concurrently with - * other operations. Elements contained in the queue since the creation + * java.util.ConcurrentModificationException}, and may proceed concurrently + * with other operations. Elements contained in the queue since the creation * of the iterator will be returned exactly once. * *

Beware that, unlike in most collections, the {@code size} method From forax at univ-mlv.fr Wed Nov 17 00:06:10 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 17 Nov 2010 01:06:10 +0100 Subject: 70000691 : (coll) (doc) ConcurrentLinkedQueue @link to ConcurrentModificationException In-Reply-To: References: Message-ID: <4CE31C72.3030804@univ-mlv.fr> Le 17/11/2010 00:39, Mike Duigou a ?crit : > I'll ask the same as Alan for a small doc review for ConcurrentLinkedQueue > > Thanks, > Mike > > diff --git a/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java b/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java > --- a/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java > +++ b/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java > @@ -65,8 +65,8 @@ > *

Iterators areweakly consistent, returning elements > * reflecting the state of the queue at some point at or since the > * creation of the iterator. They donot throw {@link > - * ConcurrentModificationException}, and may proceed concurrently with > - * other operations. Elements contained in the queue since the creation > + * java.util.ConcurrentModificationException}, and may proceed concurrently > + * with other operations. Elements contained in the queue since the creation > * of the iterator will be returned exactly once. > * > *

Beware that, unlike in most collections, the {@code size} method > > Looks good. R?mi From Alan.Bateman at oracle.com Wed Nov 17 09:00:44 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Nov 2010 09:00:44 +0000 Subject: 70000691 : (coll) (doc) ConcurrentLinkedQueue @link to ConcurrentModificationException In-Reply-To: References: Message-ID: <4CE399BC.9050202@oracle.com> Mike Duigou wrote: > I'll ask the same as Alan for a small doc review for ConcurrentLinkedQueue > > Thanks, > Mike > > diff --git a/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java b/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java > --- a/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java > +++ b/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java > @@ -65,8 +65,8 @@ > *

Iterators are weakly consistent, returning elements > * reflecting the state of the queue at some point at or since the > * creation of the iterator. They do not throw {@link > - * ConcurrentModificationException}, and may proceed concurrently with > - * other operations. Elements contained in the queue since the creation > + * java.util.ConcurrentModificationException}, and may proceed concurrently > + * with other operations. Elements contained in the queue since the creation > * of the iterator will be returned exactly once. > * > *

Beware that, unlike in most collections, the {@code size} method > > Looks good to me too. -Alan. From michael.x.mcmahon at oracle.com Wed Nov 17 14:33:59 2010 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 17 Nov 2010 14:33:59 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101117143436.AA09647A75@hg.openjdk.java.net> Changeset: f9dbb7d2e8a3 Author: michaelm Date: 2010-11-17 14:29 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f9dbb7d2e8a3 6725892: Http server stability issues Reviewed-by: chegar ! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java ! src/share/classes/com/sun/net/httpserver/HttpsParameters.java ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/httpserver/Event.java ! src/share/classes/sun/net/httpserver/ExchangeImpl.java ! src/share/classes/sun/net/httpserver/FixedLengthInputStream.java ! src/share/classes/sun/net/httpserver/HttpConnection.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/SSLStreams.java - src/share/classes/sun/net/httpserver/SelectorCache.java ! src/share/classes/sun/net/httpserver/ServerConfig.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! test/com/sun/net/httpserver/Test.java ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test13.java + test/com/sun/net/httpserver/bugs/6725892/Test.java ! test/com/sun/net/httpserver/bugs/B6401598.java Changeset: 664b35adabd2 Author: michaelm Date: 2010-11-17 14:32 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/664b35adabd2 Merge From john_platts at hotmail.com Wed Nov 17 16:01:31 2010 From: john_platts at hotmail.com (John Platts) Date: Wed, 17 Nov 2010 10:01:31 -0600 Subject: Bug in java.nio.StringCharBuffer.slice Message-ID: Here is the current implementation of slice in java.nio.StringCharBuffer (as found in OpenJDK 7): 44 public CharBuffer slice() { 45 return new StringCharBuffer(str, 46 -1, 47 0, 48 this.remaining(), 49 this.remaining(), 50 this.position()); 51 } Here is the implementation of slice used for heap-based byte buffers, which is found in java/nio/Heap-X-Buffer.java.template: 97 public $Type$Buffer slice() { 98 return new Heap$Type$Buffer$RW$(hb, 99 -1, 100 0, 101 this.remaining(), 102 this.remaining(), 103 this.position() + offset); 104 } It appears that the slice() method fails to return the correct region of the string for CharBuffer objects that wrap a string whenever offset is non-zero. Here is the corrected code, with the correction in red: 44 public CharBuffer slice() { 45 return new StringCharBuffer(str, 46 -1, 47 0, 48 this.remaining(), 49 this.remaining(), 50 offset + this.position()); 51 } Is this bug limited to OpenJDK 7, or is this bug found in OpenJDK 6, JDK 6, JDK 5, and JDK 1.4? This bug might be affecting code that uses CharBuffers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Nov 17 19:39:50 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Nov 2010 19:39:50 +0000 Subject: Bug in java.nio.StringCharBuffer.slice In-Reply-To: References: Message-ID: <4CE42F86.7050704@oracle.com> John Platts wrote: > Here is the current implementation of slice in > java.nio.StringCharBuffer (as found in OpenJDK 7): > 44 public CharBuffer slice() { > 45 return new StringCharBuffer(str, > 46 -1, > 47 0, > 48 this.remaining(), > 49 this.remaining(), > 50 this.position()); > 51 } > > Here is the implementation of slice used for heap-based byte buffers, > which is found in java/nio/Heap-X-Buffer.java.template: > 97 public $Type$Buffer slice() { > 98 return new Heap$Type$Buffer$RW$(hb, > 99 -1, > 100 0, > 101 this.remaining(), > 102 this.remaining(), > 103 this.position() + offset); > 104 } > > It appears that the slice() method fails to return the correct region > of the string for CharBuffer objects that wrap a string whenever > offset is non-zero. Here is the corrected code, with the correction in > red: > 44 public CharBuffer slice() { > 45 return new StringCharBuffer(str, > 46 -1, > 47 0, > 48 this.remaining(), > 49 this.remaining(), > 50 offset + this.position()); > 51 } > > Is this bug limited to OpenJDK 7, or is this bug found in OpenJDK 6, > JDK 6, JDK 5, and JDK 1.4? This bug might be affecting code that uses > CharBuffers. Thanks for the bug report. I've created a bug to track it: 7000913: (bf) CharBuffer.wrap, slice, position, slice leads to CharBuffer with incorrect offset I'm kinda surprised this hasn't been noticed before but it may be that it's rare to slice a buffer that itself was created by slicing a wrapped char sequence. It does highlight a hole in our tests so part of fixing this will adding further tests. So are you contributing the fix to this? I see a John Platts on the SCA list but I'm not sure if that is you. As regards versions, then it is likely to exist in all versions. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Nov 17 23:08:35 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 17 Nov 2010 23:08:35 +0000 Subject: hg: jdk7/tl/langtools: 7000973: isBogus needs to be called on the to-be-returned entry, not on the current entry Message-ID: <20101117230837.965D847A8D@hg.openjdk.java.net> Changeset: abaceae7c9f8 Author: jjg Date: 2010-11-17 15:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/abaceae7c9f8 7000973: isBogus needs to be called on the to-be-returned entry, not on the current entry Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/code/Scope.java From xueming.shen at oracle.com Wed Nov 17 23:10:52 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 17 Nov 2010 23:10:52 +0000 Subject: hg: jdk7/tl/jdk: 6615506: (fmt spec) Date/Time conversion table missing column for 'Z' Message-ID: <20101117231101.8EAC147A8E@hg.openjdk.java.net> Changeset: 59d10b97be7c Author: sherman Date: 2010-11-17 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59d10b97be7c 6615506: (fmt spec) Date/Time conversion table missing column for 'Z' Summary: added the column entry back in Reviewed-by: alanb ! src/share/classes/java/util/Formatter.java From xueming.shen at oracle.com Thu Nov 18 05:31:54 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 18 Nov 2010 05:31:54 +0000 Subject: hg: jdk7/tl/jdk: 6217210: RFE: Support for Cp833 in 1.4.2 Message-ID: <20101118053204.8684647AA2@hg.openjdk.java.net> Changeset: ce757906302f Author: sherman Date: 2010-11-17 21:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ce757906302f 6217210: RFE: Support for Cp833 in 1.4.2 Summary: Forward port the Cp833 charset Reviewed-by: poonam ! make/sun/nio/cs/FILES_java.gmk + make/tools/CharsetMapping/IBM833.c2b + make/tools/CharsetMapping/IBM833.map ! make/tools/CharsetMapping/extsbcs + src/share/classes/sun/io/ByteToCharCp833.java + src/share/classes/sun/io/CharToByteCp833.java ! src/share/classes/sun/io/CharacterEncoding.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! test/sun/nio/cs/CheckHistoricalNames.java From alan.bateman at oracle.com Thu Nov 18 21:27:51 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 18 Nov 2010 21:27:51 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101118212811.6366347ACD@hg.openjdk.java.net> Changeset: 2e0204644cf4 Author: alanb Date: 2010-11-18 19:16 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2e0204644cf4 7000913: (bf) CharBuffer.wrap, slice, position, slice leads to CharBuffer with incorrect offser Reviewed-by: forax ! src/share/classes/java/nio/StringCharBuffer.java ! test/java/nio/Buffer/StringCharBufferSliceTest.java Changeset: fbd3395f973b Author: alanb Date: 2010-11-18 19:17 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fbd3395f973b Merge - src/share/classes/sun/net/httpserver/SelectorCache.java From mandy.chung at oracle.com Thu Nov 18 21:43:23 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 18 Nov 2010 13:43:23 -0800 Subject: Code review request "6402006: FileInputStream.available() returns negative values when reading a large file" Message-ID: <4CE59DFB.9050909@oracle.com> 6402006 FileInputStream.available() returns negative values when reading a large file Webrev at: http://cr.openjdk.java.net/~mchung/6402006/webrev.00/ This fixes a bug in the windows implementation of io_util.c that ignores the high-order doubleword of the file size in computing the end of the file. Thus the available() method incorrectly returns only the low-order 32-bit for large files. Thanks Mandy From xueming.shen at oracle.com Thu Nov 18 22:03:11 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 18 Nov 2010 14:03:11 -0800 Subject: 6989471: compiler warnings building java/zip native code Message-ID: <4CE5A29F.8030302@oracle.com> Alan, Kelly, Would you please help review the patch that tries to address those compiler warning in zip area? http://cr.openjdk.java.net/~sherman/6989471/webrev I added some comments to document the fact that ZIP_Read/FindEntry/InflateFully can't deal with > 2**32 byte (the only user of these native method is the vm, I don't think they are trying to de-compress a > 4G entry in one invocation any time soon). We might find interesting to support > 2**32 entry for those methods, but obviously it is not the purpose of this bug. Same for the "dstLen" of the compress/uncompress methods, the original zlib interface has the limitation of 2**32. I only tried to remove the warning in this patch. I'm not dealing with the POSIX strdup warning. It appears Kumar has already address the warning in zcrc32.c. Thanks, Sherman -------------- next part -------------- An HTML attachment was scrubbed... URL: From kelly.ohair at oracle.com Thu Nov 18 22:28:31 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 18 Nov 2010 14:28:31 -0800 Subject: 6989471: compiler warnings building java/zip native code In-Reply-To: <4CE5A29F.8030302@oracle.com> References: <4CE5A29F.8030302@oracle.com> Message-ID: <89E17653-1F0F-45A4-8352-B7C96CDA9E86@oracle.com> Looks good to me. Thanks for doing this. -kto On Nov 18, 2010, at 2:03 PM, Xueming Shen wrote: > Alan, Kelly, > > Would you please help review the patch that tries to address those > compiler warning > in zip area? > > http://cr.openjdk.java.net/~sherman/6989471/webrev > > I added some comments to document the fact that ZIP_Read/FindEntry/ > InflateFully can't > deal with > 2**32 byte (the only user of these native method is the > vm, I don't think they > are trying to de-compress a > 4G entry in one invocation any time > soon). We might find > interesting to support > 2**32 entry for those methods, but > obviously it is not the purpose > of this bug. > > Same for the "dstLen" of the compress/uncompress methods, the > original zlib interface > has the limitation of 2**32. I only tried to remove the warning in > this patch. > > I'm not dealing with the POSIX strdup warning. > > It appears Kumar has already address the warning in zcrc32.c. > > Thanks, > Sherman -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Nov 18 22:34:02 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 18 Nov 2010 14:34:02 -0800 Subject: Code review request "6631046: BufferedInputStream.available() reports negative int on very large inputstream" Message-ID: <4CE5A9DA.80502@oracle.com> 6631046: BufferedInputStream.available() reports negative int on very large inputstream Webrev at: http://cr.openjdk.java.net/~mchung/6631046/webrev.00/ InputStream.available() returns an int. For streams larger than 2GB, the FileInputStream.available() implementation returns Integer.MAX_VALUE which is a reasonable choice. java.io.BufferedInputStream and java.io.PushbackInputStream maintain a buffer. The available() method in these 2 classes returns the sum of the number of bytes remaining to be read in the buffer and the result of calling the in.available(). If in.available() returns a large number, the result may overflow and a negative size will be returned. This fixes to handle the overflow case properly. Thanks Mandy From kumar.x.srinivasan at oracle.COM Thu Nov 18 22:58:11 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 18 Nov 2010 14:58:11 -0800 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: References: <4CDC27E1.9000909@oracle.COM> <4CDC3EBB.20500@oracle.com> <4CE1DD41.2050406@oracle.COM> Message-ID: <4CE5AF83.9040900@oracle.COM> Hi Mike, Thanks for the review, here is the new version: http://cr.openjdk.java.net/~ksrini/6990106/webrev.02/ > Attribute.java/Instruction.java/Package.java.File : > > - Layout.equals(Object x) { > return x instanceof Layout&& equals((Layout)x); > } > > should be : > > Layout.equals(Object x) { > return (null != x)&& (x.getClass() == Layout.class)&& equals((Layout)x); > } > > as sub-classes also using instanceof would have a non-reflexive equals(). ie. layout.equals(someSubClassOfLayout) != someSubclassOfLayout.equals(layout) Fixed. > - Layout.isEmpty() { > return layout.isEmpty(); > } Fixed > - BandStructure.java/ClassReader.java/Coding.java/CodingChooser.java/PackageReader.java/PackageWriter.java : is there a reason to use concrete types (HashMap, ArrayList, HashSet) for fields and vars such as basicCodingIndexes, allKQBands? It seems not. Fixed most of these, some of them need to be concrete. > - Code.java : Arrays.copyOf and/or copyOfRange could be used rather than separate allocation and System.arrayCopy. Fixed > - Package.java.stripAttributeKind() : could be a switch. Fixed > - Package.java.File : possibly static class and final (which would eliminate the complaint about File.equals()) ? This can be made final but not static, due to references. > - PropMap._listeners could be final (and probably a List rather than explicitly an ArrayList). Fixed. > - PropMap.java : convert newly added final to ARM? I will pass on it right now, there are other places too, which needs ARM'ing, but talking to Stuart Marks he seems to have the ARM'izing effort on his agenda. > - FixedList.java : Anything saved by extending AbstractList rather than implementing List? Done Thanks Kumar > On Nov 15 2010, at 17:24 , Kumar Srinivasan wrote: > >> Hi John, et. al., >> >> This revision contains all fixes noted by Brian below and other >> comments from Alan. >> >> http://cr.openjdk.java.net/~ksrini/6990106/webrev.01/ >> >> Thanks >> Kumar >> >>> Mostly style issues, but at least one likely bug. >>> >>> In a few places, you've used @SuppressWarnings("unchecked"). While this may well be unavoidable, it is worth factoring this out into the smallest possible chunk. For BandStructure, you've applied it to the whole class, and there's some big methods that use it too. You can usually get it down to a small "makeArrayOfGenericFoo" method, since this is the most common source of non-fixable unchecked warnings. >>> >>> Also using an interface like Constants to import symbols is an antipattern and is better replaced with static imports. >>> >>> In ClassReader you've replaced use of new Integer() and friends with Integer.valueOf(), but its better style to go all the way and just use autoboxing. >>> >>> In Instruction the equals() method takes into account bc, w, length, and bytes, but the hashCode() method also takes into account pc. This may violate the "equal objects must have equal hashcodes" rule. >>> >>> Throughout you've changed loops from >>> for (Iterator i=...) >>> to >>> for (Iterator i=...) >>> but didn't go all the way and just use foreach loops. >>> >>> PropMap should extend TreeMap by composition, not extension. This implementation is subject to the hazards outlined in the Effective Java item "Prefer composition to extension." (For example you override put() but not putAll(), but this idiom cannot be made to work without tightly coupling it to the superclass implementation.) >>> >>> On 11/11/2010 12:29 PM, Kumar Srinivasan wrote: >>>> Hi, >>>> >>>> Appreciate a review of the pack200 cleanup work, in the following areas: >>>> >>>> 1. General generification of Collections. >>>> 2. fixed worthy findbugs items. >>>> 3. fixed worthy Netbeans nags. >>>> 4. Elimination of array/generics combination. >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~ksrini/6990106/webrev.00/ >>>> >>>> Thanks >>>> Kumar >>>> From David.Holmes at oracle.com Thu Nov 18 23:06:36 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 19 Nov 2010 09:06:36 +1000 Subject: Code review request "6631046: BufferedInputStream.available() reports negative int on very large inputstream" In-Reply-To: <4CE5A9DA.80502@oracle.com> References: <4CE5A9DA.80502@oracle.com> Message-ID: <4CE5B17C.7030200@oracle.com> Hi Mandy, Looks good to me. David Mandy Chung said the following on 11/19/10 08:34: > 6631046: BufferedInputStream.available() reports negative int on very > large inputstream > > Webrev at: > http://cr.openjdk.java.net/~mchung/6631046/webrev.00/ > > InputStream.available() returns an int. For streams larger than 2GB, the > FileInputStream.available() implementation returns Integer.MAX_VALUE > which is a reasonable choice. > > java.io.BufferedInputStream and java.io.PushbackInputStream maintain a > buffer. The available() method in these 2 classes returns the sum of > the number of bytes remaining to be read in the buffer and the result of > calling the in.available(). If in.available() returns a large number, > the result may overflow and a negative size will be returned. This > fixes to handle the overflow case properly. > > Thanks > Mandy From mandy.chung at oracle.com Thu Nov 18 23:29:52 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 18 Nov 2010 15:29:52 -0800 Subject: Please review -XshowSettings a java launcher option. In-Reply-To: <4CDDA0DF.6020608@oracle.COM> References: <4CDC66A5.8000709@oracle.COM> <4CDC77BA.2010603@oracle.com> <4CDC8D87.7030709@oracle.COM> <4CDCCC9E.3050204@oracle.com> <4CDDA0DF.6020608@oracle.COM> Message-ID: <4CE5B6F0.4090605@oracle.com> Hi Kumar, I reviewed your latest webrev.02. Looks good to me. Thanks Mandy On 11/12/10 12:17, Kumar Srinivasan wrote: > Thanks for all the reviews!. > > Here are the fixes in this version: > http://cr.openjdk.java.net/~ksrini/6452854/webrev.01 > > 1. Fixed the representation of numbers and scaling using BigDecimal. > 2. Argument processing checks for -XshowSettings and -XshowSetting:opt > (added a test to catch the former, added some comments in java.c) > 3. Replaced String* with PrintStream.print*, it makes the logic easier > to read, so I decided to go with this. > 4. Removed extraneous path.separators. > 5. line.separator will be printed as ASCII symbols CR and LF > 6. If the helper cannot determine the value that line will not be > displayed. > 7. In the case of the Max memory not gotten from the launcher > (Estimated) is printed. > 8. Removed the option hints -X* and so on in the labels. > 9. Renamed Ergonomic Class -> Ergonomic Machine Class. > > Thanks > Kumar > > > > >> On 11/11/2010 16:42, Kumar Srinivasan wrote: >>>> line 176, 188, 190-191, 195, and other lines in printPrintLocales >>>> and printLocale methods: >>>> - the assignment to the buf and out variable to itself (returned >>>> from StringBuffer.append() method) is not necessary. >>> >>> >>> Yes fixed, I missed these. >> >> The "intention" of returning the StringBuffer itself for those >> append() methods is that >> you can then write the code like >> >> >> private static void printLocale(PrintStream ostream) { >> ostream.println(new StringBuilder("\n" + LOCALE_SETTINGS + "\n") >> .append(INDENT) >> .append("default locale: ") >> .append(Locale.getDefault().getDisplayLanguage()) >> .append(prettyPrintLocales()) >> .toString()); >> } >> >> >> One more nit is that you might want to do something special for >> >> line.separator = >> >> to make it "readable" >> >> -Sherman >> > From jonathan.gibbons at oracle.com Fri Nov 19 00:13:40 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 19 Nov 2010 00:13:40 +0000 Subject: hg: jdk7/tl/langtools: 6999438: remove support for exotic identifiers from JDK 7 Message-ID: <20101119001342.D26F447AD6@hg.openjdk.java.net> Changeset: 03177f49411d Author: jjg Date: 2010-11-18 16:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/03177f49411d 6999438: remove support for exotic identifiers from JDK 7 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/EmptyBytecodeIdent.java - test/tools/javac/diags/examples/IllegalBytecodeIdentChar.java - test/tools/javac/diags/examples/UnclosedBytecodeIdent.java - test/tools/javac/diags/examples/UnsupportedExoticID.java ! test/tools/javac/meth/InvokeDyn.java ! test/tools/javac/meth/InvokeDynTrans.java ! test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/quid/QuotedIdent.java - test/tools/javac/quid/QuotedIdent2.java + test/tools/javac/quid/T6999438.java + test/tools/javac/quid/T6999438.out From mike.duigou at oracle.com Fri Nov 19 00:42:25 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 18 Nov 2010 16:42:25 -0800 Subject: Code review request "6631046: BufferedInputStream.available() reports negative int on very large inputstream" In-Reply-To: <4CE5A9DA.80502@oracle.com> References: <4CE5A9DA.80502@oracle.com> Message-ID: Looks good to me. Mike On Nov 18 2010, at 14:34 , Mandy Chung wrote: > 6631046: BufferedInputStream.available() reports negative int on very large inputstream > > Webrev at: > http://cr.openjdk.java.net/~mchung/6631046/webrev.00/ > > InputStream.available() returns an int. For streams larger than 2GB, the FileInputStream.available() implementation returns Integer.MAX_VALUE which is a reasonable choice. > > java.io.BufferedInputStream and java.io.PushbackInputStream maintain a buffer. The available() method in these 2 classes returns the sum of the number of bytes remaining to be read in the buffer and the result of calling the in.available(). If in.available() returns a large number, the result may overflow and a negative size will be returned. This fixes to handle the overflow case properly. > > Thanks > Mandy From mike.duigou at oracle.com Fri Nov 19 00:55:42 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 18 Nov 2010 16:55:42 -0800 Subject: Code review request "6402006: FileInputStream.available() returns negative values when reading a large file" In-Reply-To: <4CE59DFB.9050909@oracle.com> References: <4CE59DFB.9050909@oracle.com> Message-ID: <64CF203E-7B57-4216-BA53-CEB97D30E59C@oracle.com> Would it be possible to call GetFileSizeEx() (or add a call to GetLastError()) MSDN: > Note that if the return value is INVALID_FILE_SIZE (0xffffffff), an application must call GetLastError to determine whether the function has succeeded or failed. The reason the function may appear to fail when it has not is that lpFileSizeHigh could be non-NULL or the file size could be 0xffffffff. In this case, GetLastError will return NO_ERROR (0) upon success. Because of this behavior, it is recommended that you use GetFileSizeEx instead. There is a similar problem for for SetFilePosition(): MSDN: > Note Because INVALID_SET_FILE_POINTER is a valid value for the low-order DWORD of the new file pointer, you must check both the return value of the function and the error code returned by GetLastError to determine whether or not an error has occurred. If an error has occurred, the return value of SetFilePointer is INVALID_SET_FILE_POINTER and GetLastError returns a value other than NO_ERROR. For a code example that demonstrates how to check for failure, see the Remarks section in this topic. Mike On Nov 18 2010, at 13:43 , Mandy Chung wrote: > 6402006 FileInputStream.available() returns negative values when reading a large file > > Webrev at: > http://cr.openjdk.java.net/~mchung/6402006/webrev.00/ > > This fixes a bug in the windows implementation of io_util.c that ignores the high-order doubleword of the file size in computing the end of the file. Thus the available() method incorrectly returns only the low-order 32-bit for large files. > > Thanks > Mandy From mike.duigou at oracle.com Fri Nov 19 01:39:23 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 18 Nov 2010 17:39:23 -0800 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: <4CE5AF83.9040900@oracle.COM> References: <4CDC27E1.9000909@oracle.COM> <4CDC3EBB.20500@oracle.com> <4CE1DD41.2050406@oracle.COM> <4CE5AF83.9040900@oracle.COM> Message-ID: <59D6EF00-6342-4898-ACB9-52DC4185C0DB@oracle.com> A few more I nits I noticed. BandStructure : allKQBands could be final. ClassReader : string switch opportunities in readAttributes() FixedArrayList : Seems to be unchanged since last webrev. Was nothing saved by extending AbstractList? ConstantPool : equals() only works as long as all sub-classes have different tag values. (see sameTagAs() which uses instanceof rather than getClass()). Using getClass() likely makes tag comparison unnecessary. Package : another InnerClass.equals() using instanceof PackerImpl : several uses of XXX.size() > 0 which could be !XXX.isEmpty() which is generally preferred as size() is not O(1) for some collections where isEmpty() is O(1). PropMap : could _listeners and theMap be private? Since initialization of theMap doesn't depend upon any constructor params why not construct it at declaration? Mike On Nov 18 2010, at 14:58 , Kumar Srinivasan wrote: > Hi Mike, > > Thanks for the review, here is the new version: > http://cr.openjdk.java.net/~ksrini/6990106/webrev.02/ > From xueming.shen at oracle.com Fri Nov 19 07:32:52 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 18 Nov 2010 23:32:52 -0800 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length Message-ID: <4CE62824.5080701@oracle.com> Alan, It might not be a real "regression" if only consider the supported platforms (and yes, the malloc manpageI can found does clearly indicate NULL is for error). However I prefer to add some checks to make sure it behaves the same (compared to before the #6728376 change went it), even on the "weird OS" that Mario has. Anyway, a 0-length really malloc should not trigger a OOME. http://cr.openjdk.java.net/~sherman/6858865/webrev The webrev for #6728376 is at http://cr.openjdk.java.net/~sherman/6728376/webrev Thanks, -Sherman From xueming.shen at oracle.com Fri Nov 19 07:55:30 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 18 Nov 2010 23:55:30 -0800 Subject: Code review request 6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3 Message-ID: <4CE62D72.30406@oracle.com> Alan, Last time when Martin and I discussed this issue we agreed that the submitter is right about this. (The "charset" is a mapping between "a sequence of bytes" and a "sequence of sisteen-bit Unicode characters, so the character discussed here should be a utf-16 character...) http://cr.openjdk.java.net/~sherman/6957230/webrev Thanks, -Sherman From Alan.Bateman at oracle.com Fri Nov 19 09:16:30 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2010 09:16:30 +0000 Subject: Code review request 6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3 In-Reply-To: <4CE62D72.30406@oracle.com> References: <4CE62D72.30406@oracle.com> Message-ID: <4CE6406E.40804@oracle.com> Xueming Shen wrote: > Alan, > > Last time when Martin and I discussed this issue we agreed that the > submitter is right > about this. (The "charset" is a mapping between "a sequence of bytes" > and a "sequence > of sisteen-bit Unicode characters, so the character discussed here > should be a utf-16 > character...) > > http://cr.openjdk.java.net/~sherman/6957230/webrev > > Thanks, > -Sherman I'll go along with this too, so thumbs up from me. -Alan. From Alan.Bateman at oracle.com Fri Nov 19 09:16:24 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2010 09:16:24 +0000 Subject: Code review request "6631046: BufferedInputStream.available() reports negative int on very large inputstream" In-Reply-To: <4CE5A9DA.80502@oracle.com> References: <4CE5A9DA.80502@oracle.com> Message-ID: <4CE64068.5070903@oracle.com> Mandy Chung wrote: > 6631046: BufferedInputStream.available() reports negative int on very > large inputstream > > Webrev at: > http://cr.openjdk.java.net/~mchung/6631046/webrev.00/ > > InputStream.available() returns an int. For streams larger than 2GB, > the FileInputStream.available() implementation returns > Integer.MAX_VALUE which is a reasonable choice. > > java.io.BufferedInputStream and java.io.PushbackInputStream maintain a > buffer. The available() method in these 2 classes returns the sum of > the number of bytes remaining to be read in the buffer and the result > of calling the in.available(). If in.available() returns a large > number, the result may overflow and a negative size will be returned. > This fixes to handle the overflow case properly. > > Thanks > Mandy Looks good to me too - thanks for taking this one. -Alan. From Alan.Bateman at oracle.com Fri Nov 19 09:31:21 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2010 09:31:21 +0000 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CE62824.5080701@oracle.com> References: <4CE62824.5080701@oracle.com> Message-ID: <4CE643E9.2060509@oracle.com> Xueming Shen wrote: > Alan, > > It might not be a real "regression" if only consider the supported > platforms > (and yes, the malloc manpageI can found does clearly indicate NULL is > for error). > However I prefer to add some checks to make sure it behaves the same > (compared to before the #6728376 change went it), even on the "weird OS" > that Mario has. Anyway, a 0-length really malloc should not trigger a > OOME. > > http://cr.openjdk.java.net/~sherman/6858865/webrev > > The webrev for #6728376 is at > http://cr.openjdk.java.net/~sherman/6728376/webrev > > Thanks, > -Sherman > > I think this one has come up before [1]. Looking at it now, I wonder if it would be simpe for inflate to just return 0 if the input buffer or the max number of uncompressed bytes is 0. That is, just don't attempt the mallocs for these cases. -Alan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-July/002028.html From Alan.Bateman at oracle.com Fri Nov 19 09:38:03 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2010 09:38:03 +0000 Subject: 6989471: compiler warnings building java/zip native code In-Reply-To: <4CE5A29F.8030302@oracle.com> References: <4CE5A29F.8030302@oracle.com> Message-ID: <4CE6457B.3040207@oracle.com> Xueming Shen wrote: > Alan, Kelly, > > Would you please help review the patch that tries to address those > compiler warning > in zip area? > > http://cr.openjdk.java.net/~sherman/6989471/webrev > > > I added some comments to document the fact that > ZIP_Read/FindEntry/InflateFully can't > deal with > 2**32 byte (the only user of these native method is the > vm, I don't think they > are trying to de-compress a > 4G entry in one invocation any time > soon). We might find > interesting to support > 2**32 entry for those methods, but obviously > it is not the purpose > of this bug. > > Same for the "dstLen" of the compress/uncompress methods, the original > zlib interface > has the limitation of 2**32. I only tried to remove the warning in > this patch. > > I'm not dealing with the POSIX strdup warning. > > It appears Kumar has already address the warning in zcrc32.c. > > Thanks, > Sherman In zip_util.c there is a comment that reads "reading A entry". Is that a typo that should be "reading an entry". Also looks like an indent problem at L1377. Otherwise looks fine to me. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Nov 19 10:11:18 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2010 10:11:18 +0000 Subject: Code review request "6402006: FileInputStream.available() returns negative values when reading a large file" In-Reply-To: <64CF203E-7B57-4216-BA53-CEB97D30E59C@oracle.com> References: <4CE59DFB.9050909@oracle.com> <64CF203E-7B57-4216-BA53-CEB97D30E59C@oracle.com> Message-ID: <4CE64D46.7010808@oracle.com> Mike Duigou wrote: > Would it be possible to call GetFileSizeEx() (or add a call to GetLastError()) > > MSDN: > >> Note that if the return value is INVALID_FILE_SIZE (0xffffffff), an application must call GetLastError to determine whether the function has succeeded or failed. The reason the function may appear to fail when it has not is that lpFileSizeHigh could be non-NULL or the file size could be 0xffffffff. In this case, GetLastError will return NO_ERROR (0) upon success. Because of this behavior, it is recommended that you use GetFileSizeEx instead. >> > > There is a similar problem for for SetFilePosition(): > > MSDN: > >> Note Because INVALID_SET_FILE_POINTER is a valid value for the low-order DWORD of the new file pointer, you must check both the return value of the function and the error code returned by GetLastError to determine whether or not an error has occurred. If an error has occurred, the return value of SetFilePointer is INVALID_SET_FILE_POINTER and GetLastError returns a value other than NO_ERROR. For a code example that demonstrates how to check for failure, see the Remarks section in this topic. >> > > Mike > I agree with Mike's suggestion to use GetFileSizeEx. Also, well spotted that the SetFilePointer usage is missing a check to GetLastError. I quickly checked the other usages of this clunky API and they seem to check the error. Do you plan to include a regression test for this? I know it's not nice for tests to be create multi-GB files but this is one that we should have caught a long time ago. If we create it as a sparse file then the test should be relatively quick. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Fri Nov 19 10:44:33 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 19 Nov 2010 10:44:33 +0000 Subject: hg: jdk7/tl/jdk: 6712185: java/util/concurrent/Executors/AutoShutdown.java fails on slow or busy systems Message-ID: <20101119104522.67D5847AFB@hg.openjdk.java.net> Changeset: d5489d652f6f Author: dl Date: 2010-11-19 10:43 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d5489d652f6f 6712185: java/util/concurrent/Executors/AutoShutdown.java fails on slow or busy systems Reviewed-by: chegar, alanb ! test/ProblemList.txt ! test/java/util/concurrent/Executors/AutoShutdown.java From michael.x.mcmahon at oracle.com Fri Nov 19 13:35:38 2010 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Fri, 19 Nov 2010 13:35:38 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101119133558.83B9C47B02@hg.openjdk.java.net> Changeset: 3092c842b0ea Author: michaelm Date: 2010-11-19 13:30 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3092c842b0ea 7001301: com/sun/net/httpserver/bugs/6725892/Test.java failing Reviewed-by: alanb ! test/com/sun/net/httpserver/bugs/6725892/Test.java Changeset: 892c54251ac8 Author: michaelm Date: 2010-11-19 13:35 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/892c54251ac8 Merge From mandy.chung at oracle.com Fri Nov 19 15:46:07 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 19 Nov 2010 07:46:07 -0800 Subject: Code review request "6402006: FileInputStream.available() returns negative values when reading a large file" In-Reply-To: <4CE64D46.7010808@oracle.com> References: <4CE59DFB.9050909@oracle.com> <64CF203E-7B57-4216-BA53-CEB97D30E59C@oracle.com> <4CE64D46.7010808@oracle.com> Message-ID: <4CE69BBF.1060308@oracle.com> On 11/19/10 2:11 AM, Alan Bateman wrote: > I agree with Mike's suggestion to use GetFileSizeEx. Also, well > spotted that the SetFilePointer usage is missing a check to > GetLastError. I quickly checked the other usages of this clunky API > and they seem to check the error. > I'll send out a new webrev. > Do you plan to include a regression test for this? I know it's not > nice for tests to be create multi-GB files but this is one that we > should have caught a long time ago. If we create it as a sparse file > then the test should be relatively quick. I have a regression test but didn't plan to include in the changeset. I'll modify it to create a sparse file as you suggest and include it in the webrev. Thanks Mandy From john_platts at hotmail.com Fri Nov 19 15:49:43 2010 From: john_platts at hotmail.com (John Platts) Date: Fri, 19 Nov 2010 09:49:43 -0600 Subject: Improved Java Collection APIs Message-ID: Here are improvements that I really want to see to Java Collection APIs: - Addition of an equality comparator interface. - An wrapper that wraps a java.util.Comparator as a equality comparator. - Map and set classes that allow an equality comparator to be used instead of the equals() method or identity comparisons - New map and set interfaces that behave like the existing java.util.Map and java.util.Set interfaces. Unlike the contract of the java.util.Map and java.util.Set interfaces, the contract of the new map and set interfaces will not require that o1 be considered to be equal to o2 when o1 != o2 and o1.equals(o2) are both true. The new map and set interfaces will still require that o1 be considered equal to o2 whenever o1 == o2 is true. - New collection interfaces which define versions of search and removal operations that take an additional equality comparator argument. This enables search and removal operations to use an equality comparator to determine equality instead of relying on the equals method, an identity comparison, or the java.util.Comparator.compare method. - Additional concurrent collection classes. Some of these classes will require synchronized modification, while supporting thread-safe unsynchronized access and concurrent iteration. - Support for collections synchronized on a read-write lock. - Addition of methods that iterates through the collection and invokes a callback. This is useful in cases where the callback object can be pre-allocated, since iteration using a java.util.Iterator object usually requires an iterator to be allocated each time an iteration takes place. From xueming.shen at oracle.com Fri Nov 19 16:08:13 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 19 Nov 2010 08:08:13 -0800 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CE643E9.2060509@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> Message-ID: <4CE6A0ED.20307@oracle.com> On 11/19/2010 01:31, Alan Bateman wrote: > Xueming Shen wrote: >> Alan, >> >> It might not be a real "regression" if only consider the supported >> platforms >> (and yes, the malloc manpageI can found does clearly indicate NULL is >> for error). >> However I prefer to add some checks to make sure it behaves the same >> (compared to before the #6728376 change went it), even on the "weird OS" >> that Mario has. Anyway, a 0-length really malloc should not trigger a >> OOME. >> >> http://cr.openjdk.java.net/~sherman/6858865/webrev >> >> The webrev for #6728376 is at >> http://cr.openjdk.java.net/~sherman/6728376/webrev >> >> Thanks, >> -Sherman >> >> > I think this one has come up before [1]. Looking at it now, I wonder > if it would be simpe for inflate to just return 0 if the input buffer > or the max number of uncompressed bytes is 0. That is, just don't > attempt the mallocs for these cases. > > -Alan > > > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-July/002028.html We can probably do that for Inflater.c (and probably better do that at java level before we even "come down" here), but thing gets a little complicated for Deflater. One of the paths of the deflateBytes is to deal with parameter(s) change, so if malloc does not fail for 0-length request (true on all supported platforms), the deflateBytes goes down to zlib's deflateParams() and if there is nothing left to flush, "this" invocation can successfully re-set the param(s) and return 0. The reason why I decided to go with the "safe and simple" solution last night, the proposed webrev at least should behave the exactly the same as it was before. -Sherman From Ulf.Zibis at gmx.de Fri Nov 19 17:00:15 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 19 Nov 2010 18:00:15 +0100 Subject: Code review request 6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3 In-Reply-To: <4CE62D72.30406@oracle.com> References: <4CE62D72.30406@oracle.com> Message-ID: <4CE6AD1F.5090407@gmx.de> IMO, you consequently should additionally correct the javadoc according the evaluation of bug 6957230. -Ulf Am 19.11.2010 08:55, schrieb Xueming Shen: > Alan, > > Last time when Martin and I discussed this issue we agreed that the submitter is right > about this. (The "charset" is a mapping between "a sequence of bytes" and a "sequence > of sisteen-bit Unicode characters, so the character discussed here should be a utf-16 > character...) > > http://cr.openjdk.java.net/~sherman/6957230/webrev > > Thanks, > -Sherman > From xueming.shen at oracle.com Fri Nov 19 17:25:58 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 19 Nov 2010 09:25:58 -0800 Subject: 6989471: compiler warnings building java/zip native code In-Reply-To: <4CE6457B.3040207@oracle.com> References: <4CE5A29F.8030302@oracle.com> <4CE6457B.3040207@oracle.com> Message-ID: <4CE6B326.2070509@oracle.com> Thanks Alan! webrev has been updated accordingly to fix the typo. -Sherman On 11/19/2010 01:38, Alan Bateman wrote: > Xueming Shen wrote: >> Alan, Kelly, >> >> Would you please help review the patch that tries to address those >> compiler warning >> in zip area? >> >> http://cr.openjdk.java.net/~sherman/6989471/webrev >> >> >> I added some comments to document the fact that >> ZIP_Read/FindEntry/InflateFully can't >> deal with > 2**32 byte (the only user of these native method is the >> vm, I don't think they >> are trying to de-compress a > 4G entry in one invocation any time >> soon). We might find >> interesting to support > 2**32 entry for those methods, but obviously >> it is not the purpose >> of this bug. >> >> Same for the "dstLen" of the compress/uncompress methods, the >> original zlib interface >> has the limitation of 2**32. I only tried to remove the warning in >> this patch. >> >> I'm not dealing with the POSIX strdup warning. >> >> It appears Kumar has already address the warning in zcrc32.c. >> >> Thanks, >> Sherman > In zip_util.c there is a comment that reads "reading A entry". Is that > a typo that should be "reading an entry". Also looks like an indent > problem at L1377. > > Otherwise looks fine to me. > > -Alan. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Nov 19 17:38:55 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 19 Nov 2010 18:38:55 +0100 Subject: Improved Java Collection APIs In-Reply-To: References: Message-ID: <4CE6B62F.60609@univ-mlv.fr> Le 19/11/2010 16:49, John Platts a ?crit : > Here are improvements that I really want to see to Java Collection APIs: > [...] > - Addition of methods that iterates through the collection and invokes a callback. This is useful in cases where the callback object can be pre-allocated, since iteration using a java.util.Iterator object usually requires an iterator to be allocated each time an iteration takes place. > This one is on the task list of the lambda JSR, the callback will be expressed as a lambda. R?mi From Alan.Bateman at oracle.com Fri Nov 19 17:40:32 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2010 17:40:32 +0000 Subject: 6989471: compiler warnings building java/zip native code In-Reply-To: <4CE6B326.2070509@oracle.com> References: <4CE5A29F.8030302@oracle.com> <4CE6457B.3040207@oracle.com> <4CE6B326.2070509@oracle.com> Message-ID: <4CE6B690.30403@oracle.com> Xueming Shen wrote: > Thanks Alan! > > webrev has been updated accordingly to fix the typo. > > -Sherman Looks fine to me except the indentation at L1385 where it looks like you need to insert two additional spaces. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Nov 19 17:55:58 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2010 17:55:58 +0000 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CE6A0ED.20307@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> <4CE6A0ED.20307@oracle.com> Message-ID: <4CE6BA2E.90209@oracle.com> Xueming Shen wrote: > : > We can probably do that for Inflater.c (and probably better do that at > java level before > we even "come down" here), but thing gets a little complicated for > Deflater. One of the > paths of the deflateBytes is to deal with parameter(s) change, so if > malloc does not > fail for 0-length request (true on all supported platforms), the > deflateBytes goes down > to zlib's deflateParams() and if there is nothing left to flush, > "this" invocation can successfully > re-set the param(s) and return 0. The reason why I decided to go with > the "safe and simple" > solution last night, the proposed webrev at least should behave the > exactly the same as it > was before. > > -Sherman > I think it would be a bit cleaner for inflater. For deflater would it cleaner to just skip the mallocs when the lengths are 0 (for the deflateParams path). -Alan. From mandy.chung at oracle.com Fri Nov 19 18:00:40 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 19 Nov 2010 18:00:40 +0000 Subject: hg: jdk7/tl/jdk: 6631046: BufferedInputStream.available() reports negative int on very large inputstream Message-ID: <20101119180050.2CA7947B0D@hg.openjdk.java.net> Changeset: f30e1e1a4d90 Author: mchung Date: 2010-11-19 10:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f30e1e1a4d90 6631046: BufferedInputStream.available() reports negative int on very large inputstream Reviewed-by: dholmes, alanb, mduigou ! src/share/classes/java/io/BufferedInputStream.java ! src/share/classes/java/io/PushbackInputStream.java From kumar.x.srinivasan at oracle.com Fri Nov 19 19:10:35 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 19 Nov 2010 11:10:35 -0800 Subject: Please review java.util.jar.pack.* cleanup/refactoring/generificaiton In-Reply-To: <59D6EF00-6342-4898-ACB9-52DC4185C0DB@oracle.com> References: <4CDC27E1.9000909@oracle.COM> <4CDC3EBB.20500@oracle.com> <4CE1DD41.2050406@oracle.COM> <4CE5AF83.9040900@oracle.COM> <59D6EF00-6342-4898-ACB9-52DC4185C0DB@oracle.com> Message-ID: <4CE6CBAB.3050509@oracle.COM> Mike, Here is the new revision: http://cr.openjdk.java.net/~ksrini/6990106/webrev.03/ I nailed all the items per your suggestions. > A few more I nits I noticed. > > BandStructure : allKQBands could be final. > > ClassReader : string switch opportunities in readAttributes() > > FixedArrayList : Seems to be unchanged since last webrev. Was nothing saved by extending AbstractList? Initially I was extending AbstractList and later changed it to implement List. And no I did not see any change. Thanks Kumar > ConstantPool : equals() only works as long as all sub-classes have different tag values. (see sameTagAs() which uses instanceof rather than getClass()). Using getClass() likely makes tag comparison unnecessary. > > Package : another InnerClass.equals() using instanceof > > PackerImpl : several uses of XXX.size()> 0 which could be !XXX.isEmpty() which is generally preferred as size() is not O(1) for some collections where isEmpty() is O(1). > > PropMap : could _listeners and theMap be private? Since initialization of theMap doesn't depend upon any constructor params why not construct it at declaration? > > Mike > > On Nov 18 2010, at 14:58 , Kumar Srinivasan wrote: > >> Hi Mike, >> >> Thanks for the review, here is the new version: >> http://cr.openjdk.java.net/~ksrini/6990106/webrev.02/ >> From xueming.shen at oracle.com Fri Nov 19 19:18:55 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 19 Nov 2010 11:18:55 -0800 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CE6BA2E.90209@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> <4CE6A0ED.20307@oracle.com> <4CE6BA2E.90209@oracle.com> Message-ID: <4CE6CD9F.9070209@oracle.com> On 11/19/2010 09:55 AM, Alan Bateman wrote: > Xueming Shen wrote: >> : >> We can probably do that for Inflater.c (and probably better do that >> at java level before >> we even "come down" here), but thing gets a little complicated for >> Deflater. One of the >> paths of the deflateBytes is to deal with parameter(s) change, so if >> malloc does not >> fail for 0-length request (true on all supported platforms), the >> deflateBytes goes down >> to zlib's deflateParams() and if there is nothing left to flush, >> "this" invocation can successfully >> re-set the param(s) and return 0. The reason why I decided to go with >> the "safe and simple" >> solution last night, the proposed webrev at least should behave the >> exactly the same as it >> was before. >> >> -Sherman >> > I think it would be a bit cleaner for inflater. For deflater would it > cleaner to just skip the mallocs when the lengths are 0 (for the > deflateParams path). I might not explain it clear enough. For Deflater.c we want to at least keep the "malloc" path for if ((*env)->GetBooleanField(env, this, setParamsID)) { .... } so it will continue go down to deflateParams() to reset the params, with a valid non-NULL ptr on most platforms, even for 0-length buf, this is what it was before #6728376 and what it is now, We don't what to have another "regression" (change the params, invoke the deflate() with 0-length buffer, but now it returns 0 with change the setting, I have to invoke it again with...) here. And with the "len != 0" check, it will be no behavior change as well for that weird OS. For other 2 paths (the Inflater.c and the (*env)->GetBooleanField(env, this, setParamsID) == false path, I believe/think/guess it should be safe to bypath the zlib by checking len/in_len and returning 0 if any of them is zero. But this is again a "change", probably:-) harmless giving my understand/reading of zlib code and the existing regression tests. So the "bit cleaner" webrev is http://cr.openjdk.java.net/~sherman/6858865/webrev/ But it deal with the 0-length issue "differently" at different places. This is why I proposed last night the "safe" and "simple: change. Anyway, I'm fine with the "bit-cleaner" approach, so if you're OK with it, throw it in:-) The "old" webrev is at http://cr.openjdk.java.net/~sherman/6858865/webrev.00/ -Sherman From xueming.shen at oracle.com Fri Nov 19 20:58:22 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 19 Nov 2010 20:58:22 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101119205841.4ADC347B1A@hg.openjdk.java.net> Changeset: d9e4556acd4a Author: sherman Date: 2010-11-19 12:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d9e4556acd4a 6989471: compiler warnings building java/zip native code Summary: remvoed the warning Reviewed-by: ohair, alanb ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zlib-1.2.3/compress.c ! src/share/native/java/util/zip/zlib-1.2.3/uncompr.c Changeset: b44704ce8a08 Author: sherman Date: 2010-11-19 12:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b44704ce8a08 6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3 Summary: changged utf-8's CharsetEncoder.maxBytesPerChar to 3 Reviewed-by: alanb ! src/share/classes/sun/nio/cs/UTF_8.java From Alan.Bateman at oracle.com Fri Nov 19 21:33:02 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2010 21:33:02 +0000 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CE6CD9F.9070209@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> <4CE6A0ED.20307@oracle.com> <4CE6BA2E.90209@oracle.com> <4CE6CD9F.9070209@oracle.com> Message-ID: <4CE6ED0E.4020605@oracle.com> Xueming Shen wrote: > : > > I might not explain it clear enough. For Deflater.c we want to at > least keep the "malloc" > path for > > if ((*env)->GetBooleanField(env, this, setParamsID)) { > .... > } > > so it will continue go down to deflateParams() to reset the params, with > a valid non-NULL ptr on most platforms, even for 0-length buf, this is > what it was before #6728376 and what it is now, We don't what to have > another "regression" (change the params, invoke the deflate() with > 0-length > buffer, but now it returns 0 with change the setting, I have to invoke it > again with...) here. And with the "len != 0" check, it will be no > behavior > change as well for that weird OS. > > For other 2 paths (the Inflater.c and the > (*env)->GetBooleanField(env, this, setParamsID) == false > path, I believe/think/guess it should be safe to bypath the zlib by > checking len/in_len and returning 0 if any of them is zero. But this is > again a "change", probably:-) harmless giving my understand/reading of > zlib code and the existing regression tests. > > So the "bit cleaner" webrev is > http://cr.openjdk.java.net/~sherman/6858865/webrev/ > > But it deal with the 0-length issue "differently" at different places. > This is why I proposed last night the "safe" and "simple: change. > > Anyway, I'm fine with the "bit-cleaner" approach, so if you're OK with > it, throw it in:-) > > The "old" webrev is at > http://cr.openjdk.java.net/~sherman/6858865/webrev.00/ > > -Sherman > The updated webrev looks better, but for the deflateParam path then maybe you could do something like this: if (this_len == 0) { in_buf = NULL; } else { in_buf = (jbyte*) malloc(this_len); if (in_buf == NULL) { JNU_ThrowOutOfMemoryError(env, 0); return 0; } } and same thing for out_buf. Would that be a bit cleaner? -Alan From xueming.shen at oracle.com Fri Nov 19 21:51:22 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 19 Nov 2010 13:51:22 -0800 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CE6ED0E.4020605@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> <4CE6A0ED.20307@oracle.com> <4CE6BA2E.90209@oracle.com> <4CE6CD9F.9070209@oracle.com> <4CE6ED0E.4020605@oracle.com> Message-ID: <4CE6F15A.7040209@oracle.com> On 11/19/2010 01:33 PM, Alan Bateman wrote: > Xueming Shen wrote: >> : >> >> I might not explain it clear enough. For Deflater.c we want to at >> least keep the "malloc" >> path for >> >> if ((*env)->GetBooleanField(env, this, setParamsID)) { >> .... >> } >> >> so it will continue go down to deflateParams() to reset the params, with >> a valid non-NULL ptr on most platforms, even for 0-length buf, this is >> what it was before #6728376 and what it is now, We don't what to have >> another "regression" (change the params, invoke the deflate() with >> 0-length >> buffer, but now it returns 0 with change the setting, I have to >> invoke it >> again with...) here. And with the "len != 0" check, it will be no >> behavior >> change as well for that weird OS. >> >> For other 2 paths (the Inflater.c and the >> (*env)->GetBooleanField(env, this, setParamsID) == false >> path, I believe/think/guess it should be safe to bypath the zlib by >> checking len/in_len and returning 0 if any of them is zero. But this is >> again a "change", probably:-) harmless giving my understand/reading of >> zlib code and the existing regression tests. >> >> So the "bit cleaner" webrev is >> http://cr.openjdk.java.net/~sherman/6858865/webrev/ >> >> But it deal with the 0-length issue "differently" at different places. >> This is why I proposed last night the "safe" and "simple: change. >> >> Anyway, I'm fine with the "bit-cleaner" approach, so if you're OK with >> it, throw it in:-) >> >> The "old" webrev is at >> http://cr.openjdk.java.net/~sherman/6858865/webrev.00/ >> >> -Sherman >> > The updated webrev looks better, but for the deflateParam path then > maybe you could do something like this: > > if (this_len == 0) { > in_buf = NULL; > } else { > in_buf = (jbyte*) malloc(this_len); > if (in_buf == NULL) { > JNU_ThrowOutOfMemoryError(env, 0); > return 0; > } > } > > and same thing for out_buf. > > Would that be a bit cleaner? Why do you want to feed the zlib with a null buffer? :-) The zlib#deflate() does some null checks at the beginning as showed below. I probably can do something tricky to make it work, but for me I don't see the benefit of taking the risk. If it works don't break it:-) -Sherman int ZEXPORT deflate (strm, flush) z_streamp strm; int flush; { int old_flush; /* value of flush param for previous deflate call */ deflate_state *s; if (strm == Z_NULL || strm->state == Z_NULL || flush > Z_FINISH || flush < 0) { return Z_STREAM_ERROR; } s = strm->state; if (strm->next_out == Z_NULL || (strm->next_in == Z_NULL && strm->avail_in != 0) || (s->status == FINISH_STATE && flush != Z_FINISH)) { ERR_RETURN(strm, Z_STREAM_ERROR); } if (strm->avail_out == 0) ERR_RETURN(strm, Z_BUF_ERROR); .... > > -Alan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Nov 19 21:51:51 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2010 21:51:51 +0000 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CE6F15A.7040209@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> <4CE6A0ED.20307@oracle.com> <4CE6BA2E.90209@oracle.com> <4CE6CD9F.9070209@oracle.com> <4CE6ED0E.4020605@oracle.com> <4CE6F15A.7040209@oracle.com> Message-ID: <4CE6F177.909@oracle.com> Xueming Shen wrote: > : > Why do you want to feed the zlib with a null buffer? :-) So are you saying that if the length is 0 that it still looks at the buffer? If so, then I'm okay with the last webrev. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From xueming.shen at oracle.com Fri Nov 19 22:03:47 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 19 Nov 2010 14:03:47 -0800 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CE6F177.909@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> <4CE6A0ED.20307@oracle.com> <4CE6BA2E.90209@oracle.com> <4CE6CD9F.9070209@oracle.com> <4CE6ED0E.4020605@oracle.com> <4CE6F15A.7040209@oracle.com> <4CE6F177.909@oracle.com> Message-ID: <4CE6F443.1080908@oracle.com> On 11/19/2010 01:51 PM, Alan Bateman wrote: > Xueming Shen wrote: >> : >> Why do you want to feed the zlib with a null buffer? :-) > So are you saying that if the length is 0 that it still looks at the > buffer? If so, then I'm okay with the last webrev. > zlib does buffer null check before anything else, just like we do null check/throw NPE first then check the offset and length. -Sherman -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Fri Nov 19 22:19:48 2010 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 19 Nov 2010 22:19:48 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101119222007.E112F47B1E@hg.openjdk.java.net> Changeset: ff619988afac Author: lancea Date: 2010-11-19 17:15 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ff619988afac 7000752: Duplicate entry in RowSetResourceBundles.properties Reviewed-by: alanb ! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Changeset: bf407ff3e97b Author: lancea Date: 2010-11-19 17:18 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf407ff3e97b 7001669: Typo in javadocs for SQLPermission Reviewed-by: alanb ! src/share/classes/java/sql/SQLPermission.java From gnu_andrew at member.fsf.org Fri Nov 19 22:27:01 2010 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Fri, 19 Nov 2010 22:27:01 +0000 Subject: Improved Java Collection APIs In-Reply-To: References: Message-ID: On 19 November 2010 15:49, John Platts wrote: > > Here are improvements that I really want to see to Java Collection APIs: > - Addition of an equality comparator interface. > - An wrapper that wraps a java.util.Comparator as a equality comparator. > - Map and set classes that allow an equality comparator to be used instead of the equals() method or identity comparisons > - New map and set interfaces that behave like the existing java.util.Map and java.util.Set interfaces. Unlike the contract of the java.util.Map and java.util.Set interfaces, the contract of the new map and set interfaces will not require that o1 be considered to be equal to o2 when o1 != o2 and o1.equals(o2) are both true. The new map and set interfaces will still require that o1 be considered equal to o2 whenever o1 == o2 is true. > - New collection interfaces which define versions of search and removal operations that take an additional equality comparator argument. This enables search and removal operations to use an equality comparator to determine equality instead of relying on the equals method, an identity comparison, or the java.util.Comparator.compare method. > - Additional concurrent collection classes. Some of these classes will require synchronized modification, while supporting thread-safe unsynchronized access and concurrent iteration. > - Support for collections synchronized on a read-write lock. > - Addition of methods that iterates through the collection and invokes a callback. This is useful in cases where the callback object can be pre-allocated, since iteration using a java.util.Iterator object usually requires an iterator to be allocated each time an iteration takes place. > Feel free to post patches to add these features. Then they can be reviewed and maybe added to the JDK. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA? 7927 142C 2591 94EF D9D8 From David.Holmes at oracle.com Fri Nov 19 22:39:14 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 20 Nov 2010 08:39:14 +1000 Subject: Improved Java Collection APIs In-Reply-To: References: Message-ID: <4CE6FC92.305@oracle.com> John Platts said the following on 11/20/10 01:49: > Here are improvements that I really want to see to Java Collection APIs: > - Additional concurrent collection classes. Some of these classes > will require synchronized modification, while supporting thread-safe > unsynchronized access and concurrent iteration. That's a somewhat vague request. If you have specific ideas/suggestions here feel free to raise them on the concurrency-interest at cs.oswego.edu mailing list where Doug Lea and the JSR-166 EG will see them (along with a large chunk of the community interested in concurrent collections). > - Support for collections synchronized on a read-write lock. Again can you be more specific? Read-write locks sound theoretically useful for some collection operations but the devil is in the details. Unlike synchronized collections you can't necessarily just use a wrapper. David Holmes From xueming.shen at oracle.com Fri Nov 19 23:18:35 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 19 Nov 2010 15:18:35 -0800 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CE6F443.1080908@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> <4CE6A0ED.20307@oracle.com> <4CE6BA2E.90209@oracle.com> <4CE6CD9F.9070209@oracle.com> <4CE6ED0E.4020605@oracle.com> <4CE6F15A.7040209@oracle.com> <4CE6F177.909@oracle.com> <4CE6F443.1080908@oracle.com> Message-ID: <4CE705CB.8050304@oracle.com> Alan, After staring those simple, 11 lines of change for minutes, I believe we should simply go back with the original approach at http://cr.openjdk.java.net/~sherman/6858865/webrev.00 The change in http://cr.openjdk.java.net/~sherman/6858865/webrev.00 obviously is problematic, especially in case like in_len == 0 but out_len != 0 (no more, or no more new input, but with a valid output buffer), it's definitely possible the inflater/deflater might have more bites to (and should) output in this scenario, it's a bug to return 0 here. Sure it's possible to go further like if (in_len == 0) return 0; .... if (len == 0) ... But given the purpose of this fix is to solve that particular "regression" (which actually does not cause any regression for "mainstream" platforms), I prefer not take the risk of causing another real regression/behavior change here, especially we got burned couple times here in the past when tried to do better. Agree? -Sherman On 11/19/2010 02:03 PM, Xueming Shen wrote: > On 11/19/2010 01:51 PM, Alan Bateman wrote: >> Xueming Shen wrote: >>> : >>> Why do you want to feed the zlib with a null buffer? :-) >> So are you saying that if the length is 0 that it still looks at the >> buffer? If so, then I'm okay with the last webrev. >> > > zlib does buffer null check before anything else, just like we do null > check/throw NPE first then > check the offset and length. > > -Sherman -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Sat Nov 20 01:14:20 2010 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Sat, 20 Nov 2010 01:14:20 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101120011457.CA36B47B26@hg.openjdk.java.net> Changeset: 6deeca9378c0 Author: valeriep Date: 2010-11-19 16:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6deeca9378c0 6203816: Can not run test/java/security/Security/ClassLoaderDeadlock.sh from the command line Summary: Fixed the script to not delete the provider sub-directory Reviewed-by: weijun ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh Changeset: 784f2f094051 Author: valeriep Date: 2010-11-19 17:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/784f2f094051 6720456: New 4150 may have larger blowfish keysizes Summary: Changed to use TBD value instead of FAIL Reviewed-by: weijun ! test/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java From xuelei.fan at oracle.com Sat Nov 20 15:01:28 2010 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sat, 20 Nov 2010 15:01:28 +0000 Subject: hg: jdk7/tl/jdk: 6903584: Legal notice repair: Three files under jdk/src/share/classes/sun/security/ssl/ Message-ID: <20101120150150.8F17647B47@hg.openjdk.java.net> Changeset: b66c09b7ce85 Author: xuelei Date: 2010-11-20 07:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b66c09b7ce85 6903584: Legal notice repair: Three files under jdk/src/share/classes/sun/security/ssl/ Reviewed-by: weijun ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/Krb5Proxy.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java From weijun.wang at oracle.com Mon Nov 22 01:44:51 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 22 Nov 2010 01:44:51 +0000 Subject: hg: jdk7/tl/jdk: 6979329: CCacheInputStream fails to read ticket cache files from Kerberos 1.8.1 Message-ID: <20101122014516.5FFBB47B8E@hg.openjdk.java.net> Changeset: c1734c00a8ba Author: weijun Date: 2010-11-22 09:43 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c1734c00a8ba 6979329: CCacheInputStream fails to read ticket cache files from Kerberos 1.8.1 Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java + test/sun/security/krb5/UnknownCCEntry.java From Alan.Bateman at oracle.com Mon Nov 22 13:52:44 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Nov 2010 13:52:44 +0000 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization Message-ID: <4CEA75AC.9000803@oracle.com> This is a patch to default deserialization so that it uses volatile-write when setting final fields: http://cr.openjdk.java.net/~alanb/6647361/webrev/ Thanks, Alan. From Alan.Bateman at oracle.com Mon Nov 22 13:52:21 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Nov 2010 13:52:21 +0000 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CE705CB.8050304@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> <4CE6A0ED.20307@oracle.com> <4CE6BA2E.90209@oracle.com> <4CE6CD9F.9070209@oracle.com> <4CE6ED0E.4020605@oracle.com> <4CE6F15A.7040209@oracle.com> <4CE6F177.909@oracle.com> <4CE6F443.1080908@oracle.com> <4CE705CB.8050304@oracle.com> Message-ID: <4CEA7595.1020502@oracle.com> Xueming Shen wrote: > Alan, > > After staring those simple, 11 lines of change for minutes, I believe > we should simply > go back with the original approach at > > http://cr.openjdk.java.net/~sherman/6858865/webrev.00 > > The change in > http://cr.openjdk.java.net/~sherman/6858865/webrev.00 > > obviously is problematic, especially in case like in_len == 0 but > out_len != 0 (no more, > or no more new input, but with a valid output buffer), it's definitely > possible the > inflater/deflater might have more bites to (and should) output in this > scenario, it's a > bug to return 0 here. > > Sure it's possible to go further like > > if (in_len == 0) > return 0; > .... > > if (len == 0) > ... > > But given the purpose of this fix is to solve that particular > "regression" (which actually > does not cause any regression for "mainstream" platforms), I prefer > not take the risk > of causing another real regression/behavior change here, especially we > got burned > couple times here in the past when tried to do better. > > Agree? > > -Sherman I understand the concern but I don't think that patch-1 is risky. That is, for Inflater, I can't see any side effects to simply returning 0 if either length is 0. Same thing for Deflater when not in the code path that calls deflateParams. For the deflateParams cases then the changes in the latest patch is fine with me. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Nov 22 14:35:36 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 22 Nov 2010 15:35:36 +0100 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization In-Reply-To: <4CEA75AC.9000803@oracle.com> References: <4CEA75AC.9000803@oracle.com> Message-ID: <4CEA7FB8.2030401@univ-mlv.fr> Le 22/11/2010 14:52, Alan Bateman a ?crit : > > This is a patch to default deserialization so that it uses > volatile-write when setting final fields: > http://cr.openjdk.java.net/~alanb/6647361/webrev/ > > Thanks, > Alan. > I wonder if we can't use putOrdered instead of putVolatile. In that case Field.set() should be changed too because it uses putVolatile. Alan, in your patch the write key is get twice, once in setPrimFieldValues and once in setPrimFieldValue (resp setFinalPrimFieldValue). I think you shoud add the write key as parameter of these methods. R?mi From brian.goetz at oracle.com Mon Nov 22 14:39:26 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 22 Nov 2010 09:39:26 -0500 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization In-Reply-To: <4CEA75AC.9000803@oracle.com> References: <4CEA75AC.9000803@oracle.com> Message-ID: <4CEA809E.2020805@oracle.com> The performance impact of this might be severe when deserializing object graphs with lots of final fields (and we recommend using final fields wherever possible.) And, I'm a little unclear on the approach here. If the goal is to provide a happens-before edge between deserializing an object graph and reading a final field in that object graph, I don't see how this does it, since the reads of those field will be nonvolatile reads. So this seems like it has a big performance cost and doesn't fully solve the problem. Can you outline the strategy here? On 11/22/2010 8:52 AM, Alan Bateman wrote: > > This is a patch to default deserialization so that it uses volatile-write when > setting final fields: > http://cr.openjdk.java.net/~alanb/6647361/webrev/ > > Thanks, > Alan. > > > From david.lloyd at redhat.com Mon Nov 22 15:01:52 2010 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 22 Nov 2010 09:01:52 -0600 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization In-Reply-To: <4CEA75AC.9000803@oracle.com> References: <4CEA75AC.9000803@oracle.com> Message-ID: <4CEA85E0.7010400@redhat.com> On 11/22/2010 07:52 AM, Alan Bateman wrote: > > This is a patch to default deserialization so that it uses > volatile-write when setting final fields: > http://cr.openjdk.java.net/~alanb/6647361/webrev/ Please don't go farther down the path of "only JDK/proprietary classes can properly deserialize". Bad enough that proper implementation of the spec requires using sun.reflect.ReflectionFactory. Requiring Unsafe too would just be irritating. How about putting this stuff on a public (if privileged) API *first*? -- - DML From dl at cs.oswego.edu Mon Nov 22 15:10:02 2010 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 22 Nov 2010 10:10:02 -0500 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization In-Reply-To: <4CEA7FB8.2030401@univ-mlv.fr> References: <4CEA75AC.9000803@oracle.com> <4CEA7FB8.2030401@univ-mlv.fr> Message-ID: <4CEA87CA.5090108@cs.oswego.edu> On 11/22/10 09:35, R?mi Forax wrote: >> This is a patch to default deserialization so that it uses volatile-write when >> setting final fields: >> http://cr.openjdk.java.net/~alanb/6647361/webrev/ >> > > I wonder if we can't use putOrdered instead of putVolatile. > In that case Field.set() should be changed too because it uses putVolatile. > Yes this will suffice. For some discussion about emulating final, see the draft (NOT JDK7 (maybe 8)) Fences API (http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html) In fact if this API existed you could just use it (modulo some JVM/platform-dependent tearing issues for long/double). In the mean time, putOrdered suffices. But note that putOrdered exists only for int, long, and volatile. For the others you could just resort to the volatile form. The cost savings of using these lighter fences are platform dependent. On some Intel i7s, it might be less than 10 cycles. On most processors, it is on the order of 30. On older P4s (and PowerPC) it can be over 100. -Doug From brian.goetz at oracle.com Mon Nov 22 15:29:18 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 22 Nov 2010 10:29:18 -0500 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization In-Reply-To: <4CEA87CA.5090108@cs.oswego.edu> References: <4CEA75AC.9000803@oracle.com> <4CEA7FB8.2030401@univ-mlv.fr> <4CEA87CA.5090108@cs.oswego.edu> Message-ID: <4CEA8C4E.7020802@oracle.com> Is it possible to coalesce the fences so that we don't incur them on every field write? On 11/22/2010 10:10 AM, Doug Lea wrote: > On 11/22/10 09:35, R?mi Forax wrote: >>> This is a patch to default deserialization so that it uses volatile-write when >>> setting final fields: >>> http://cr.openjdk.java.net/~alanb/6647361/webrev/ >>> >> >> I wonder if we can't use putOrdered instead of putVolatile. >> In that case Field.set() should be changed too because it uses putVolatile. >> > > Yes this will suffice. For some discussion about emulating > final, see the draft (NOT JDK7 (maybe 8)) Fences API > (http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html) > > In fact if this API existed you could just use it (modulo > some JVM/platform-dependent tearing issues for long/double). > In the mean time, putOrdered suffices. But note that > putOrdered exists only for int, long, and volatile. > For the others you could just resort to the volatile form. > > The cost savings of using these lighter fences are > platform dependent. On some Intel i7s, it might be > less than 10 cycles. On most processors, it is on the > order of 30. On older P4s (and PowerPC) it can be over 100. > > -Doug > From Alan.Bateman at oracle.com Mon Nov 22 15:41:25 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Nov 2010 15:41:25 +0000 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization In-Reply-To: <4CEA8C4E.7020802@oracle.com> References: <4CEA75AC.9000803@oracle.com> <4CEA7FB8.2030401@univ-mlv.fr> <4CEA87CA.5090108@cs.oswego.edu> <4CEA8C4E.7020802@oracle.com> Message-ID: <4CEA8F25.4060500@oracle.com> Brian Goetz wrote: > Is it possible to coalesce the fences so that we don't incur them on > every field write? I've also been concerned about performance. As I understand it, but maybe I have it wrong, is that the JLS [1] doesn't allow this when changing final fields after an object is constructed. -Alan. [1] http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.5.3 From dl at cs.oswego.edu Mon Nov 22 15:49:35 2010 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 22 Nov 2010 10:49:35 -0500 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization In-Reply-To: <4CEA8F25.4060500@oracle.com> References: <4CEA75AC.9000803@oracle.com> <4CEA7FB8.2030401@univ-mlv.fr> <4CEA87CA.5090108@cs.oswego.edu> <4CEA8C4E.7020802@oracle.com> <4CEA8F25.4060500@oracle.com> Message-ID: <4CEA910F.7050009@cs.oswego.edu> On 11/22/10 10:41, Alan Bateman wrote: > Brian Goetz wrote: >> Is it possible to coalesce the fences so that we don't incur them on every >> field write? > I've also been concerned about performance. As I understand it, but maybe I have > it wrong, is that the JLS [1] doesn't allow this when changing final fields > after an object is constructed. > In the case of volatile writes, hotspot already does some safe (short-horizon) coalescing at instruction generation time. In the case of store fences (i.e., putOrdered), it doesn't, but it wouldn't help on most platforms anyway. -Doug From michael.x.mcmahon at oracle.com Mon Nov 22 16:11:50 2010 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 22 Nov 2010 16:11:50 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101122161219.CCF4447BAD@hg.openjdk.java.net> Changeset: 4bb2a0229796 Author: michaelm Date: 2010-11-22 16:09 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4bb2a0229796 6984182: Setting SO_RCVBUF/SO_SNDBUF to larger than tcp_max_buf fails on Solaris 11 if kernel params changed Reviewed-by: alanb, chegar ! src/solaris/native/java/net/net_util_md.c Changeset: 4b93d39eb352 Author: michaelm Date: 2010-11-22 16:11 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4b93d39eb352 Merge From sean.mullan at oracle.com Mon Nov 22 16:27:46 2010 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 22 Nov 2010 16:27:46 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20101122162816.6FBC747BAE@hg.openjdk.java.net> Changeset: 951db417fc3c Author: mullan Date: 2010-11-22 10:16 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/951db417fc3c 6995424: Eliminate dependency to a deprecated API com.sun.security.auth.PolicyFile Reviewed-by: mchung ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java Changeset: 83d08a3e4e04 Author: mullan Date: 2010-11-22 10:18 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/83d08a3e4e04 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 8aa383f37420 Author: mullan Date: 2010-11-22 11:27 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8aa383f37420 Merge From xueming.shen at oracle.com Mon Nov 22 20:04:08 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 22 Nov 2010 12:04:08 -0800 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CEA7595.1020502@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> <4CE6A0ED.20307@oracle.com> <4CE6BA2E.90209@oracle.com> <4CE6CD9F.9070209@oracle.com> <4CE6ED0E.4020605@oracle.com> <4CE6F15A.7040209@oracle.com> <4CE6F177.909@oracle.com> <4CE6F443.1080908@oracle.com> <4CE705CB.8050304@oracle.com> <4CEA7595.1020502@oracle.com> Message-ID: <4CEACCB8.3050808@oracle.com> On 11/22/2010 05:52, Alan Bateman wrote: > Xueming Shen wrote: >> Alan, >> >> After staring those simple, 11 lines of change for minutes, I believe >> we should simply >> go back with the original approach at >> >> http://cr.openjdk.java.net/~sherman/6858865/webrev.00 >> >> The change in >> http://cr.openjdk.java.net/~sherman/6858865/webrev.00 >> >> obviously is problematic, especially in case like in_len == 0 but >> out_len != 0 (no more, >> or no more new input, but with a valid output buffer), it's >> definitely possible the >> inflater/deflater might have more bites to (and should) output in >> this scenario, it's a >> bug to return 0 here. >> >> Sure it's possible to go further like >> >> if (in_len == 0) >> return 0; >> .... >> >> if (len == 0) >> ... >> >> But given the purpose of this fix is to solve that particular >> "regression" (which actually >> does not cause any regression for "mainstream" platforms), I prefer >> not take the risk >> of causing another real regression/behavior change here, especially >> we got burned >> couple times here in the past when tried to do better. >> >> Agree? >> >> -Sherman > I understand the concern but I don't think that patch-1 is risky. That > is, for Inflater, I can't see any side effects to simply returning 0 > if either length is 0. Same thing for Deflater when not in the code > path that calls deflateParams. For the deflateParams cases then the > changes in the latest patch is fine with me. > > We can not simply return 0 if the "out" buffer length is NOT 0 even when "in" buffer length is 0. The de/inflater might have something to push/flush out even there is no more input. Consider the buffer in last invocation of de/inflating is not big enough, de/infalte() gets invoked the second time without any new data (and the data for the last invocation has been consumed by the zlib de/inflate). The patch-1 (the second one) is simply wrong. It is probably OK to return 0 if the output buffer is 0, I said "probably" is because I would need to read all those zlib code again to make sure there is no any internal status change (for example in case like the "in" buffer is NOT zero but the "out" buffer is 0, consider the de/inflater might try to consume more data even the output buffer is zero) or even if there is an internal status change it would not have any negative impact. This is why I'm saying it is probably not worth the effect. -Sherman -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Nov 22 21:59:56 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Nov 2010 21:59:56 +0000 Subject: Code review request 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length In-Reply-To: <4CEACCB8.3050808@oracle.com> References: <4CE62824.5080701@oracle.com> <4CE643E9.2060509@oracle.com> <4CE6A0ED.20307@oracle.com> <4CE6BA2E.90209@oracle.com> <4CE6CD9F.9070209@oracle.com> <4CE6ED0E.4020605@oracle.com> <4CE6F15A.7040209@oracle.com> <4CE6F177.909@oracle.com> <4CE6F443.1080908@oracle.com> <4CE705CB.8050304@oracle.com> <4CEA7595.1020502@oracle.com> <4CEACCB8.3050808@oracle.com> Message-ID: <4CEAE7DC.2020208@oracle.com> Xueming Shen wrote: > : > > We can not simply return 0 if the "out" buffer length is NOT 0 even > when "in" buffer length is 0. The de/inflater might > have something to push/flush out even there is no more input. Consider > the buffer in last invocation of de/inflating is > not big enough, de/infalte() gets invoked the second time without any > new data (and the data for the last invocation > has been consumed by the zlib de/inflate). The patch-1 (the second > one) is simply wrong. > > It is probably OK to return 0 if the output buffer is 0, I said > "probably" is because I would need to read all those > zlib code again to make sure there is no any internal status change > (for example in case like the "in" buffer is NOT > zero but the "out" buffer is 0, consider the de/inflater might try to > consume more data even the output buffer is > zero) or even if there is an internal status change it would not have > any negative impact. This is why I'm saying > it is probably not worth the effect. > > > -Sherman The inflate/deflater state is a good point, in which case you are right to be cautious as it's easy to get burned in the zip code. If your replace the "Some weird system" comment with something to say that OOME is only thrown then the length is not zero then the changes in webrev.00 are okay with me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Holmes at oracle.com Mon Nov 22 22:30:40 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 23 Nov 2010 08:30:40 +1000 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization In-Reply-To: <4CEA910F.7050009@cs.oswego.edu> References: <4CEA75AC.9000803@oracle.com> <4CEA7FB8.2030401@univ-mlv.fr> <4CEA87CA.5090108@cs.oswego.edu> <4CEA8C4E.7020802@oracle.com> <4CEA8F25.4060500@oracle.com> <4CEA910F.7050009@cs.oswego.edu> Message-ID: <4CEAEF10.3050004@oracle.com> Doug Lea said the following on 11/23/10 01:49: > On 11/22/10 10:41, Alan Bateman wrote: >> Brian Goetz wrote: >>> Is it possible to coalesce the fences so that we don't incur them on >>> every >>> field write? >> I've also been concerned about performance. As I understand it, but >> maybe I have >> it wrong, is that the JLS [1] doesn't allow this when changing final >> fields >> after an object is constructed. >> > > In the case of volatile writes, hotspot already does > some safe (short-horizon) coalescing at instruction generation > time. In the case of store fences (i.e., putOrdered), it doesn't, > but it wouldn't help on most platforms anyway. I don't think coalescing is going to occur here as the different writes will be too far apart unless there is some very aggressive loop unrolling. Brian: this was intended to be a small patch to close a hole in deserialization where we do not strictly comply with the JMM. It should have been done years ago but slipped through the cracks. Our expert advice (Hi Doug!) at the time was that using a volatile-write ala Unsafe.put*Volatile was the way to go here - though perhaps there was a misunderstanding between Doug and the original RE. Alan was going to defer this but I convinced him it was a simple enough change to just go and do it. If it is proving to be contentious then we'll just let it drop as it is not worth spending significant time on this - and my apologies to Alan for wasting his time. Cheers, David From xueming.shen at oracle.com Tue Nov 23 00:02:20 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 23 Nov 2010 00:02:20 +0000 Subject: hg: jdk7/tl/jdk: 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length Message-ID: <20101123000240.2EBF347BC2@hg.openjdk.java.net> Changeset: 0049b9a85e74 Author: sherman Date: 2010-11-22 16:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0049b9a85e74 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length Summary: don't throw OOME when in or out buffer size is 0 length Reviewed-by: alanb ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c From xueming.shen at oracle.com Tue Nov 23 00:10:10 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 23 Nov 2010 00:10:10 +0000 Subject: hg: jdk7/tl/jdk: 7001434: charset name for Cp833 should be x-IBM833. Message-ID: <20101123001020.CECCD47BC4@hg.openjdk.java.net> Changeset: 7fac77daa9be Author: sherman Date: 2010-11-22 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fac77daa9be 7001434: charset name for Cp833 should be x-IBM833. Summary: changed the name to x-IBM833 in extsbcs Reviewed-by: alanb ! make/tools/CharsetMapping/extsbcs From maurizio.cimadamore at oracle.com Tue Nov 23 11:09:31 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 23 Nov 2010 11:09:31 +0000 Subject: hg: jdk7/tl/langtools: 6995200: JDK 7 compiler crashes when type-variable is inferred from expected primitive type Message-ID: <20101123110935.5B27A47BDC@hg.openjdk.java.net> Changeset: 2536dedd897e Author: mcimadamore Date: 2010-11-23 11:08 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2536dedd897e 6995200: JDK 7 compiler crashes when type-variable is inferred from expected primitive type Summary: 15.12.2.8 should use boxing when expected type in assignment context is a primitive type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/generics/inference/6638712/T6638712a.java + test/tools/javac/generics/inference/6995200/T6995200.java From kelly.ohair at oracle.com Tue Nov 23 20:20:35 2010 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 23 Nov 2010 20:20:35 +0000 Subject: hg: jdk7/tl/jaxp: 7002248: Update urls for jaxp and jaxws source downloads Message-ID: <20101123202035.43E2C47C03@hg.openjdk.java.net> Changeset: d1cb3e473c32 Author: ohair Date: 2010-11-23 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/d1cb3e473c32 7002248: Update urls for jaxp and jaxws source downloads Reviewed-by: darcy ! jaxp.properties From kelly.ohair at oracle.com Tue Nov 23 20:21:20 2010 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 23 Nov 2010 20:21:20 +0000 Subject: hg: jdk7/tl/jaxws: 7002248: Update urls for jaxp and jaxws source downloads Message-ID: <20101123202120.C21CA47C04@hg.openjdk.java.net> Changeset: f258bef45f3b Author: ohair Date: 2010-11-23 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/f258bef45f3b 7002248: Update urls for jaxp and jaxws source downloads Reviewed-by: darcy ! jaxws.properties From jonathan.gibbons at oracle.com Tue Nov 23 21:32:56 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 23 Nov 2010 21:32:56 +0000 Subject: hg: jdk7/tl/langtools: 6942366: javadoc no longer inherits doc from sourcepath Message-ID: <20101123213258.4090D47C09@hg.openjdk.java.net> Changeset: 285896f2227a Author: jjg Date: 2010-11-23 13:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/285896f2227a 6942366: javadoc no longer inherits doc from sourcepath Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java + test/tools/javadoc/6942366/T6942366.java + test/tools/javadoc/6942366/Test.java + test/tools/javadoc/6942366/p/Base.java From jonathan.gibbons at oracle.com Tue Nov 23 23:29:02 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 23 Nov 2010 23:29:02 +0000 Subject: hg: jdk7/tl/langtools: 7002346: javap test relies on location of scratch directory Message-ID: <20101123232905.1D30D47C0D@hg.openjdk.java.net> Changeset: 79d0c48d361e Author: jjg Date: 2010-11-23 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/79d0c48d361e 7002346: javap test relies on location of scratch directory Reviewed-by: ksrini ! test/tools/javap/T6729471.java From weijun.wang at oracle.com Tue Nov 23 23:44:32 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 23 Nov 2010 23:44:32 +0000 Subject: hg: jdk7/tl/jdk: 7002036: ktab return code changes on a error case Message-ID: <20101123234443.3370147C10@hg.openjdk.java.net> Changeset: de402590e18f Author: weijun Date: 2010-11-24 07:43 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de402590e18f 7002036: ktab return code changes on a error case Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java + test/sun/security/krb5/tools/ktarg.sh From kumar.x.srinivasan at oracle.com Wed Nov 24 00:52:52 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 24 Nov 2010 00:52:52 +0000 Subject: hg: jdk7/tl/jdk: 6452854: Provide a flag to print the java configuration Message-ID: <20101124005311.D1FD747C19@hg.openjdk.java.net> Changeset: 32f3094b2c73 Author: ksrini Date: 2010-11-23 16:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/32f3094b2c73 6452854: Provide a flag to print the java configuration Reviewed-by: darcy, mchung, sherman, dholmes, mduigou ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties + test/tools/launcher/Settings.java From alan.bateman at oracle.com Wed Nov 24 10:02:15 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 24 Nov 2010 10:02:15 +0000 Subject: hg: jdk7/tl/jdk: 6878369: (ch) AsynchronousSocketChannel read/write methods that specify timeouts should not throw IAE Message-ID: <20101124100239.5E92647C32@hg.openjdk.java.net> Changeset: 4d9e09600175 Author: alanb Date: 2010-11-24 09:51 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4d9e09600175 6878369: (ch) AsynchronousSocketChannel read/write methods that specify timeouts should not throw IAE Reviewed-by: forax ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java From adamrabung at gmail.com Wed Nov 24 18:57:11 2010 From: adamrabung at gmail.com (Adam Rabung) Date: Wed, 24 Nov 2010 13:57:11 -0500 Subject: Lambda-related changes to collection api Message-ID: Hi, I would like to learn more about how the collection library will change when lambdas are introduced in JDK 8. Specifically: 1. What methods are being considered? (ie, map, filter) 2. For a map-like method that can produce a collection of a different type, what will the return type be? Will arrayList.map(str => str.length) return an ArrayList, or an Iterable? Any info/links would be much appreciated. I'm sorry if this is the wrong forum. Thanks, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Holmes at oracle.com Wed Nov 24 23:29:09 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 25 Nov 2010 09:29:09 +1000 Subject: Lambda-related changes to collection api In-Reply-To: References: Message-ID: <4CED9FC5.5080408@oracle.com> Hi Adam, Adam Rabung said the following on 11/25/10 04:57: > I would like to learn more about how the collection library will change > when lambdas are introduced in JDK 8. Specifically: > 1. What methods are being considered? (ie, map, filter) > 2. For a map-like method that can produce a collection of a different > type, what will the return type be? Will arrayList.map(str => > str.length) return an ArrayList, or an Iterable? > > Any info/links would be much appreciated. I'm sorry if this is the > wrong forum. The best forum is unclear right at this point. At the moment JSR-335 has just been proposed, to add closures, and it hopes to include enhancements to core APIs such as collections. http://www.jcp.org/en/jsr/detail?id=335 Exactly what form that will take will be discussed by the expert group and I would expect they will establish some kind of forum for public discussion and comments. So hold that thought. David Holmes From Ulf.Zibis at gmx.de Thu Nov 25 12:44:10 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 25 Nov 2010 13:44:10 +0100 Subject: Code review request 6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3 In-Reply-To: <4CE6AD1F.5090407@gmx.de> References: <4CE62D72.30406@oracle.com> <4CE6AD1F.5090407@gmx.de> Message-ID: <4CEE5A1A.7060406@gmx.de> No answer ? :-( -Ulf Am 19.11.2010 18:00, schrieb Ulf Zibis: > IMO, you consequently should additionally correct the javadoc according the evaluation of bug > 6957230. > > -Ulf > > > Am 19.11.2010 08:55, schrieb Xueming Shen: >> Alan, >> >> Last time when Martin and I discussed this issue we agreed that the submitter is right >> about this. (The "charset" is a mapping between "a sequence of bytes" and a "sequence >> of sisteen-bit Unicode characters, so the character discussed here should be a utf-16 >> character...) >> >> http://cr.openjdk.java.net/~sherman/6957230/webrev >> >> Thanks, >> -Sherman >> > From assembling.signals at yandex.ru Thu Nov 25 20:58:32 2010 From: assembling.signals at yandex.ru (assembling signals) Date: Thu, 25 Nov 2010 21:58:32 +0100 Subject: Are ANY additions/improvements to the collections API considered for JDK7? Message-ID: <78171290718712@web95.yandex.ru> Hello community! I read several times (in mailing lists, forums, blogs, ...) about several small requests (proposed over and over again) for specific ideas for the collections API. Examples: * adding certain new collection classes / interfaces (such as some multi-key-maps, multi-equal-value-sets, multi-you-name-it-what, ... ); * adding more functions to utility classes; * merging parts from certain advanced collections APIs, even the possibility of merging parts from Google Collections API (or how is it called) were considered (however I don't remember, whether those were official statements). Most requests are either ignored or rejected with comments, such as: * "use this and that external API"; * "use this and that little workaround, it's not that complex"; * "this it too specific to be included"; * [request or comment ignored] (as happens often on mailing lists) I want to remind everyone that there is a great psychological difference between a) having an ecosystem which doesn't provide lot functionality, BUT can be extended easily (by using external APIs or writing own mini-solutions); b) having an ecosystem which offers most frequently used functionality out-of-the-box. Option b) is more complex on the development and maintainability side, but much more welcomed by end users. Examples: * a webbrowser is considered to be better when it doesn't have to be extended using 100 addons to be usable (see: Firefox's ability to print to PDF, read news feeds, ...) * an IDE is considered to be better when it offers (let's say) version control for common versioning systems (such as Netbeans DOES and Eclipse DOESN'T) With that in mind, will be any additions/improvements to the collections API considered for JDK7? Will this mail be ignored? ;) Best regards, Ivan G Shevchenko From David.Holmes at oracle.com Fri Nov 26 00:38:12 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 26 Nov 2010 10:38:12 +1000 Subject: Are ANY additions/improvements to the collections API considered for JDK7? In-Reply-To: <78171290718712@web95.yandex.ru> References: <78171290718712@web95.yandex.ru> Message-ID: <4CEF0174.3000803@oracle.com> Skipping to the final questions :) assembling signals said the following on 11/26/10 06:58: > With that in mind, will be any additions/improvements to the > collections API considered for JDK7? There are already a number of additions and changes for collections in the OpenJDK 7 codebase. Most of these are in the concurrent collections area - and there are not a huge number of them. More are likely for JDK 8 due to the proposed integration of closures (see JSR-335 http://www.jcp.org/en/jsr/detail?id=335 ) The ongoing philosophy with Collections has been that every API change has to "carry its own weight": http://download.oracle.com/javase/6/docs/technotes/guides/collections/overview.html "The main design goal was to produce an API that was reasonably small, both in size, and, more importantly, in "conceptual weight." " > I want to remind everyone that there is a great psychological > difference between > a) having an ecosystem which doesn't provide lot functionality, BUT > can be extended easily (by using external APIs or writing own > mini-solutions); > b) having an ecosystem which offers most frequently used functionality > out-of-the-box. If every suggestion for a new collection API were implemented in the JDK it would be a very bloated and difficult to maintain set of classes. It would also be harder to use effectively as people would struggle to understand exactly which "tool" was right for their job. Different people have different needs and requests for things have to reach "critical mass" to be accepted in general - for example a lot of the concurrent collections work comes from the discussion on Doug Lea's concurrency-interest mailing list. While it is nice in theory to have every possible tool in the toolbox just in case, you don't want the toolbox to be so large as to need a semi-trailer to lug it around, and a GPS locator to find things in it. Nor so complex that you can't work out which tool is best for the job at hand. > Will this mail be ignored? ;) Time will tell :) Cheers, David Holmes ------------ assembling signals said the following on 11/26/10 06:58: > Hello community! > > I read several times (in mailing lists, forums, blogs, ...) about several small requests > (proposed over and over again) for specific ideas for the collections API. > > Examples: > * adding certain new collection classes / interfaces > (such as some multi-key-maps, multi-equal-value-sets, multi-you-name-it-what, ... ); > * adding more functions to utility classes; > * merging parts from certain advanced collections APIs, > even the possibility of merging parts from Google Collections API (or how is it called) > were considered (however I don't remember, whether those were official statements). > > Most requests are either ignored or rejected with comments, such as: > * "use this and that external API"; > * "use this and that little workaround, it's not that complex"; > * "this it too specific to be included"; > * [request or comment ignored] (as happens often on mailing lists) > > I want to remind everyone that there is a great psychological difference between > a) having an ecosystem which doesn't provide lot functionality, BUT can be extended easily > (by using external APIs or writing own mini-solutions); > b) having an ecosystem which offers most frequently used functionality out-of-the-box. > > Option b) is more complex on the development and maintainability side, but much more > welcomed by end users. Examples: > * a webbrowser is considered to be better when it doesn't have to be extended using 100 addons > to be usable (see: Firefox's ability to print to PDF, read news feeds, ...) > * an IDE is considered to be better when it offers (let's say) version control for common versioning > systems (such as Netbeans DOES and Eclipse DOESN'T) > > With that in mind, will be any additions/improvements to the collections API considered for JDK7? > Will this mail be ignored? ;) > > Best regards, > Ivan G Shevchenko From i30817 at gmail.com Fri Nov 26 09:12:34 2010 From: i30817 at gmail.com (Paulo Levi) Date: Fri, 26 Nov 2010 09:12:34 +0000 Subject: Are ANY additions/improvements to the collections API considered for JDK7? Message-ID: The one i'd like is a lazy Map.putIfAbsent Seems logical. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.x.srinivasan at oracle.com Sat Nov 27 15:48:30 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 27 Nov 2010 15:48:30 +0000 Subject: hg: jdk7/tl/jdk: 7002986: (pack200) intermittent failures compiling pack200 Message-ID: <20101127154854.C8A3047DB8@hg.openjdk.java.net> Changeset: 6a8d669d963a Author: ksrini Date: 2010-11-27 07:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6a8d669d963a 7002986: (pack200) intermittent failures compiling pack200 Reviewed-by: jjg ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/CodingMethod.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PopulationCoding.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java From brian.goetz at oracle.com Mon Nov 29 04:33:33 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 28 Nov 2010 23:33:33 -0500 Subject: Lambda-related changes to collection api In-Reply-To: References: Message-ID: <4CF32D1D.3090603@oracle.com> We're in the process of spinning up this effort. We have no answer for you now other than "there will be some", but as we progress you'll see details showing up in one or more of: this list, lambda-dev, concurrency-interest. On 11/24/2010 1:57 PM, Adam Rabung wrote: > Hi, > I would like to learn more about how the collection library will change when > lambdas are introduced in JDK 8. Specifically: > 1. What methods are being considered? (ie, map, filter) > 2. For a map-like method that can produce a collection of a different type, > what will the return type be? Will arrayList.map(str => str.length) return an > ArrayList, or an Iterable? > > Any info/links would be much appreciated. I'm sorry if this is the wrong forum. > > Thanks, > Adam From Alan.Bateman at oracle.com Mon Nov 29 11:25:15 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Nov 2010 11:25:15 +0000 Subject: 6709457: (fc) lock/tryLock() throws IOException "Access is denied" when file opened for append [win] Message-ID: <4CF38D9B.4010209@oracle.com> This is an awkward regression that Martin and I previously discussed on this list [1]. To re-cap: When the redirection API for sub-processes was added early in jdk7, FileOutputStream was changed on Windows so that opening a file in append mode results in the write-at-end to be atomic. It achieves this by opening the file with FILE_APPEND_DATA and not FILE_WRITE_DATA access. Unfortunately this change came with side effects, the main one being that it breaks the file locking facility for files opened for append. We also observed that files opened for append cannot be truncated, potentially an issue for code that wants to truncate a log file for example. The changes here are along the lines that we discussed. First, the opening of files for append is changed back to using GENERIC_WRITE mode. Secondly, writing is changed so that it does a write-at-end. This is probably the way it should have been done originally. For the redirection API, the Windows implementation is changed so that it opens the output file in FILE_APPEND_DATA mode. This gives us the semantics that we want as we have no control as to how the sub-process will write to its output or error streams. One thing to point out is that I have deliberately kept the code as simple as possible. That is, I have not duplicated the code for long file handling and all the other odd cases that Windows entails. The rational is that we could could easily just eliminate this and have it use the new file system API to open the file (as supporting platform specific options there is easy). However, there are modularity concerns with creating that dependency and it might be better to see how that plays out first. We can create a low priority bug as a reminder of this odd cases. That's mostly it except for some additional tests for these scenarios. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/6709457/webrev/ Thanks, -Alan. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-June/000468.html From jonathan.gibbons at oracle.com Mon Nov 29 18:11:04 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 29 Nov 2010 18:11:04 +0000 Subject: hg: jdk7/tl/langtools: 7003006: add option to list directory in deterministic order Message-ID: <20101129181106.9B96A47EF4@hg.openjdk.java.net> Changeset: d44d6d8493ad Author: jjg Date: 2010-11-29 10:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d44d6d8493ad 7003006: add option to list directory in deterministic order Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java From mike.duigou at oracle.com Mon Nov 29 18:47:57 2010 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 29 Nov 2010 18:47:57 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101129184816.B690B47EFA@hg.openjdk.java.net> Changeset: 58fa22ee49f9 Author: mduigou Date: 2010-11-29 10:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/58fa22ee49f9 6998016: Incorrect ifdef nesting in sane-gcc-compiler rule 6998014: Use /etc/lsb-release, when available, to detect linux variant and version Reviewed-by: dholmes, ohair ! make/common/shared/Defs-linux.gmk ! make/common/shared/Sanity.gmk Changeset: d05cb7c442b2 Author: mduigou Date: 2010-11-29 10:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d05cb7c442b2 Merge From jonathan.gibbons at oracle.com Mon Nov 29 22:16:10 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 29 Nov 2010 22:16:10 +0000 Subject: hg: jdk7/tl/langtools: 6900037: javac should warn if earlier -source is used and bootclasspath not set Message-ID: <20101129221612.E937547F19@hg.openjdk.java.net> Changeset: c44234f680da Author: jjg Date: 2010-11-29 14:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c44234f680da 6900037: javac should warn if earlier -source is used and bootclasspath not set Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! test/tools/javac/6341866/T6341866.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java + test/tools/javac/T6900037.java + test/tools/javac/T6900037.out ! test/tools/javac/TryWithResources/PlainTry.java ! test/tools/javac/annotations/neg/Dep.java ! test/tools/javac/diags/examples/AnnotationsNotSupported.java ! test/tools/javac/diags/examples/AssertAsIdentifier.java ! test/tools/javac/diags/examples/DiamondNotSupported.java ! test/tools/javac/diags/examples/EnumAsIdentifier.java ! test/tools/javac/diags/examples/EnumsNotSupported.java ! test/tools/javac/diags/examples/Expected2.java ! test/tools/javac/diags/examples/ForeachNotSupported.java ! test/tools/javac/diags/examples/GenericsNotSupported.java ! test/tools/javac/diags/examples/MulticatchNotSupported.java ! test/tools/javac/diags/examples/NeitherConditionalSubtype.java + test/tools/javac/diags/examples/SourceNoBootclasspath.java ! test/tools/javac/diags/examples/StaticImportNotSupported.java ! test/tools/javac/diags/examples/StringSwitchNotSupported.java ! test/tools/javac/diags/examples/TryResourceNotSupported.java ! test/tools/javac/diags/examples/TryWithoutCatchOrFinally.java ! test/tools/javac/diags/examples/UnsupportedBinaryLiteral.java ! test/tools/javac/diags/examples/UnsupportedFpLit.java ! test/tools/javac/diags/examples/UnsupportedUnderscoreLiteral.java ! test/tools/javac/diags/examples/VarargsNotSupported.java ! test/tools/javac/enum/6384542/T6384542.java ! test/tools/javac/enum/6384542/T6384542a.java ! test/tools/javac/literals/BadBinaryLiterals.java ! test/tools/javac/literals/BadUnderscoreLiterals.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/varargs/warning/Warn1.java From David.Holmes at oracle.com Tue Nov 30 09:39:30 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 30 Nov 2010 19:39:30 +1000 Subject: hg: jdk7/tl/langtools: 6900037: javac should warn if earlier -source is used and bootclasspath not set In-Reply-To: <20101129221612.E937547F19@hg.openjdk.java.net> References: <20101129221612.E937547F19@hg.openjdk.java.net> Message-ID: <4CF4C652.7030403@oracle.com> Jon, This change: --- a/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java Sun Oct 03 19:40:15 2010 +0100 +++ b/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java Mon Nov 29 14:15:36 2010 -0800 @@ -170,6 +170,11 @@ public class JavacPathFileManager extend } return getClassLoader(lb.toArray(new URL[lb.size()])); + } + + @Override + public boolean isDefaultBootClassPath() { + return searchPaths.isDefaultBootClassPath(); } causes a build failure: /java/embedded/ws/j2se-baseline/1.7.0/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:177: isDefaultBootClassPath() is not public in Paths; cannot be accessed from outside package [javac] return searchPaths.isDefaultBootClassPath(); [javac] ^ [javac] 1 error because it's a package-private method: --- a/src/share/classes/com/sun/tools/javac/file/Paths.java Mon Jul 26 14:25:56 2010 -0700 +++ b/src/share/classes/com/sun/tools/javac/file/Paths.java Mon Nov 29 14:15:36 2010 -0800 @@ -114,6 +114,11 @@ public class Paths { ... + + boolean isDefaultBootClassPath() { + lazy(); + return isDefaultBootClassPath; } David ----- jonathan.gibbons at oracle.com said the following on 11/30/10 08:16: > Changeset: c44234f680da > Author: jjg > Date: 2010-11-29 14:15 -0800 > URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c44234f680da > > 6900037: javac should warn if earlier -source is used and bootclasspath not set > Reviewed-by: darcy > > ! src/share/classes/com/sun/tools/javac/code/Lint.java > ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java > ! src/share/classes/com/sun/tools/javac/file/Paths.java > ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java > ! src/share/classes/com/sun/tools/javac/main/Main.java > ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java > ! src/share/classes/com/sun/tools/javac/resources/compiler.properties > ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java > ! test/tools/javac/6341866/T6341866.java > ! test/tools/javac/ClassFileModifiers/MemberModifiers.java > + test/tools/javac/T6900037.java > + test/tools/javac/T6900037.out > ! test/tools/javac/TryWithResources/PlainTry.java > ! test/tools/javac/annotations/neg/Dep.java > ! test/tools/javac/diags/examples/AnnotationsNotSupported.java > ! test/tools/javac/diags/examples/AssertAsIdentifier.java > ! test/tools/javac/diags/examples/DiamondNotSupported.java > ! test/tools/javac/diags/examples/EnumAsIdentifier.java > ! test/tools/javac/diags/examples/EnumsNotSupported.java > ! test/tools/javac/diags/examples/Expected2.java > ! test/tools/javac/diags/examples/ForeachNotSupported.java > ! test/tools/javac/diags/examples/GenericsNotSupported.java > ! test/tools/javac/diags/examples/MulticatchNotSupported.java > ! test/tools/javac/diags/examples/NeitherConditionalSubtype.java > + test/tools/javac/diags/examples/SourceNoBootclasspath.java > ! test/tools/javac/diags/examples/StaticImportNotSupported.java > ! test/tools/javac/diags/examples/StringSwitchNotSupported.java > ! test/tools/javac/diags/examples/TryResourceNotSupported.java > ! test/tools/javac/diags/examples/TryWithoutCatchOrFinally.java > ! test/tools/javac/diags/examples/UnsupportedBinaryLiteral.java > ! test/tools/javac/diags/examples/UnsupportedFpLit.java > ! test/tools/javac/diags/examples/UnsupportedUnderscoreLiteral.java > ! test/tools/javac/diags/examples/VarargsNotSupported.java > ! test/tools/javac/enum/6384542/T6384542.java > ! test/tools/javac/enum/6384542/T6384542a.java > ! test/tools/javac/literals/BadBinaryLiterals.java > ! test/tools/javac/literals/BadUnderscoreLiterals.java > ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java > ! test/tools/javac/varargs/warning/Warn1.java > From jonathan.gibbons at oracle.com Tue Nov 30 17:39:40 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 30 Nov 2010 17:39:40 +0000 Subject: hg: jdk7/tl/langtools: 7003477: Paths.isDefaultBootClassPath needs to be public Message-ID: <20101130173942.4721847F94@hg.openjdk.java.net> Changeset: bcbc86cc5b31 Author: jjg Date: 2010-11-30 09:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bcbc86cc5b31 7003477: Paths.isDefaultBootClassPath needs to be public Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/Paths.java From mike.duigou at oracle.com Tue Nov 30 21:55:22 2010 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 30 Nov 2010 21:55:22 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101130215541.7B4FD47FAF@hg.openjdk.java.net> Changeset: 714eb2807ed8 Author: mduigou Date: 2010-11-30 13:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/714eb2807ed8 7003544: backout of openjdk changeset 58fa22ee49f9 Reviewed-by: ohair ! make/common/shared/Defs-linux.gmk ! make/common/shared/Sanity.gmk Changeset: b9745d2b6595 Author: mduigou Date: 2010-11-30 13:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b9745d2b6595 Merge From vikram.aroskar at sun.com Tue Nov 30 07:49:31 2010 From: vikram.aroskar at sun.com (vikram.aroskar at sun.com) Date: Tue, 30 Nov 2010 07:49:31 +0000 Subject: hg: jdk7/tl/corba: 6382377: incorrect Exception is given to interceptor; ... Message-ID: <20101130074932.25FD147F60@hg.openjdk.java.net> Changeset: ff0f02a67881 Author: vikram Date: 2010-11-29 22:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/ff0f02a67881 6382377: incorrect Exception is given to interceptor 6828768: RMI-IIOP EJB clients do not fail over due to defect in JDK 1.6.0_12 Summary: Also reviewed by ken.cavanaugh at oracle.com Reviewed-by: skoppar ! src/share/classes/com/sun/corba/se/impl/encoding/BufferManagerWriteStream.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java