From michael.mcmahon at sun.com Thu Oct 1 03:27:45 2009 From: michael.mcmahon at sun.com (michael.mcmahon at sun.com) Date: Thu, 01 Oct 2009 10:27:45 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20091001102823.8CDE6416F4@hg.openjdk.java.net> Changeset: dd724911c90a Author: michaelm Date: 2009-09-29 10:00 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd724911c90a 6886108: Test case B4933582 binding to fixed port number Reviewed-by: chegar ! test/java/net/Authenticator/B4933582.java ! test/sun/net/www/httptest/HttpTransaction.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java Changeset: 896cbd9c91f4 Author: michaelm Date: 2009-10-01 11:25 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/896cbd9c91f4 Merge From pravin at zensoftech.co.in Thu Oct 1 06:14:54 2009 From: pravin at zensoftech.co.in (Pravin Jain) Date: Thu, 1 Oct 2009 18:44:54 +0530 Subject: Increaed support for Unicode in Java API Message-ID: Hello all, Currently, the JDK API has a very limited support for the Unicode properties. Mostly what is available is from the Character class's methods like isDigit, getNumericValue, getCategory, etc. These properties are supported by building the CharacterData classes from the UnicodeData.txt files. There are around 89 properties mentioned in the Unicode database. The UCD contains information about all the properties. I wish to start working to build support for these properties, starting with giving priority to Normative properties. I have already built a class from the information available from the UCD.html file to contain the meta-information related to the various Properties. I feel we could start by creating a separate package may be something like java.lang.unicode which would have the required classes for supporting information about the unicode properties. I have also tested a code which could generate enums for the Properties having values of Enumeration type as mentioned in the UCD.html. Any one may please let me know as to how I can start contributing for this. Thanks and regards. Pravin Jain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091001/7232fbe7/attachment.html From Ulf.Zibis at gmx.de Thu Oct 1 06:37:21 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 01 Oct 2009 15:37:21 +0200 Subject: Increaed support for Unicode in Java API In-Reply-To: References: Message-ID: <4AC4B091.2020705@gmx.de> I would suggest to start a new project under java.net for this. If it would become widely used and accepted, there is maybe a way to integrate it in JDK. For package I suggest something like java.util.text.unicode. -Ulf Am 01.10.2009 15:14, Pravin Jain schrieb: > Hello all, > Currently, the JDK API has a very limited support for the Unicode > properties. > Mostly what is available is from the Character class's methods like > isDigit, > getNumericValue, getCategory, etc. > These properties are supported by building the CharacterData classes > from the UnicodeData.txt files. There are around 89 properties > mentioned in the Unicode database. The UCD contains > information about all the properties. > I wish to start working to build support for these properties, > starting with giving priority to Normative properties. > I have already built a class from the information available from the > UCD.html file to contain > the meta-information related to the various Properties. > I feel we could start by creating a separate package may be something > like java.lang.unicode > which would have the required classes for supporting information about > the unicode properties. > I have also tested a code which could generate enums for the > Properties having values of Enumeration type as mentioned in the UCD.html. > Any one may please let me know as to how I can start contributing for > this. > Thanks and regards. > Pravin Jain > From Ulf.Zibis at gmx.de Thu Oct 1 06:41:28 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 01 Oct 2009 15:41:28 +0200 Subject: Increaed support for Unicode in Java API In-Reply-To: References: Message-ID: <4AC4B188.8070305@gmx.de> ... did you rekognize the icu4j project? http://icu-project.org/download/4.2.html#ICU4J -Ulf Am 01.10.2009 15:14, Pravin Jain schrieb: > Hello all, > Currently, the JDK API has a very limited support for the Unicode > properties. > Mostly what is available is from the Character class's methods like > isDigit, > getNumericValue, getCategory, etc. > These properties are supported by building the CharacterData classes > from the UnicodeData.txt files. There are around 89 properties > mentioned in the Unicode database. The UCD contains > information about all the properties. > I wish to start working to build support for these properties, > starting with giving priority to Normative properties. > I have already built a class from the information available from the > UCD.html file to contain > the meta-information related to the various Properties. > I feel we could start by creating a separate package may be something > like java.lang.unicode > which would have the required classes for supporting information about > the unicode properties. > I have also tested a code which could generate enums for the > Properties having values of Enumeration type as mentioned in the UCD.html. > Any one may please let me know as to how I can start contributing for > this. > Thanks and regards. > Pravin Jain > From Joe.Darcy at Sun.COM Thu Oct 1 21:23:55 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 01 Oct 2009 21:23:55 -0700 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AB989B7.5030101@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> Message-ID: <4AC5805B.3090902@sun.com> Joe Darcy wrote: > Joe Darcy wrote: >> Stephen Colebourne wrote: >>> Joe Darcy wrote: >>>> What other utility methods would have broad enough use and >>>> applicability to go into a common java.util class? >>> >>> Joe, >>> You've asked for a call for ideas, but not given any indication of >>> process. Are you going to evaluate everything that comes in and pick >>> the best a la Coin? Or allow anyone to send in patches? >> >> Those options are not mutually exclusive; patches are welcome subject >> to the usual terms and conditions. >> >>> Who decides what is in and what is out? >> >> This is a little side project of mine and I wanted to get some >> feedback before preparing a formal change for review, possibly >> including patches from others. >> >> -Joe > > I'm getting caught up after the JVM Languages Summit and will post > some java.util.Objects code for review in the near future. > > -Joe Below is a patch implementing the methods I think should go into java.util.Objects as a first cut: * null safe two-argument equals method * null safe hashCode(Object) returning 0 for null * null safe toString(Object), returning "null" for a null argument * null tolerating compare method; tests if both arguments are == and if not calls compare The need for the last of these in Objects isn't quite as clear. Var-arg-ifying some of the existing methods in Arrays, (hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), is probably worthwhile but can be done separately. I wouldn't oppose a toDebugString(Object) method going into the platform somewhere, but I don't think it necessarily belongs in Objects. Further below is the code for an annotation processor which finds candidate equals methods to be replaced with Objects.equals. It found over half a dozen good candidates in the jdk repository. To run the annotation processor, first compile the class and then run it with javac similar to this: javac -proc:only -processor EqualsFinder -processorpath sources -Joe --- old/make/java/java/FILES_java.gmk 2009-10-01 21:04:12.000000000 -0700 +++ new/make/java/java/FILES_java.gmk 2009-10-01 21:04:12.000000000 -0700 @@ -258,6 +258,7 @@ java/util/ServiceConfigurationError.java \ java/util/Timer.java \ java/util/TimerTask.java \ + java/util/Objects.java \ java/util/UUID.java \ java/util/concurrent/AbstractExecutorService.java \ java/util/concurrent/ArrayBlockingQueue.java \ --- /dev/null 2009-08-12 17:12:33.000000000 -0700 +++ new/src/share/classes/java/util/Objects.java 2009-10-01 21:04:13.000000000 -0700 @@ -0,0 +1,96 @@ +/* + * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Sun designates this + * particular file as subject to the "Classpath" exception as provided + * by Sun in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, + * CA 95054 USA or visit www.sun.com if you need additional information or + * have any questions. + */ + +package java.util; + +/** + * This class consists of {@code static} utility methods for operating + * on objects. + */ +public class Objects { + private Objects() { + throw new AssertionError("No java.util.Objects instances for you!"); + } + + /** + * Returns {@code true} if the arguments are equal to each other + * and {@code false} otherwise. + * Consequently, if both arguments are {@code null} {@code true} + * is returned and if exactly one argument is {@code null} {@code + * false} is returned. Otherwise, equality is determined by using + * the {@link Object#equals equals} method of the first + * argument. + * + * @return {@code true} if the arguments are equal to each other + * and {@code false} otherwise + * @see Object#equals(Object) + * @since 1.7 + */ + public static boolean equals(Object a, Object b) { + return (a == b) || (a != null && a.equals(b)); + } + + /** + * Returns the hash code of a non-{@code null} argument and 0 for + * a {@code null} argument. + * + * @return the hash code of a non-{@code null} argument and 0 for + * a {@code null} argument + * @see Object#hashCode + * @since 1.7 + */ + public static int hashCode(Object o) { + return o != null ? o.hashCode() : 0; + } + + /** + * Returns the result of calling {@code toString} for a non-{@code + * null} argument and {@code "null"} for a {@code null} argument. + * + * @return the result of calling {@code toString} for a non-{@code + * null} argument and {@code "null"} for a {@code null} argument + * @see Object#toString + * @since 1.7 + */ + public static String toString(Object o) { + return (o != null) ? o.toString() : "null" ; + } + + /** + * Returns 0 if the arguments are identical and {@code + * c.compare(a, b)} otherwise. + * Consequently, if both arguments are {@code null} 0 + * is returned. + * + * @return 0 if the arguments are identical and {@code + * c.compare(a, b)} otherwise. + * @see Comparable + * @see Comparator + * @since 1.7 + */ + public static int compare(T a, T b, Comparator c) { + return (a == b) ? 0 : c.compare(a, b); + } +} --- /dev/null 2009-08-12 17:12:33.000000000 -0700 +++ new/test/java/util/Objects/BasicObjectsTest.java 2009-10-01 21:04:14.000000000 -0700 @@ -0,0 +1,110 @@ +/* + * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, + * CA 95054 USA or visit www.sun.com if you need additional information or + * have any questions. + */ + + +/* + * @test + * @bug 6797535 + * @summary Basic tests for methods in java.util.Objects + * @author Joseph D. Darcy + */ + +import java.util.*; + +public class BasicObjectsTest { + public static void main(String... args) { + int errors = 0; + errors += testEquals(); + errors += testHashCode(); + errors += testToString(); + errors += testCompare(); + if (errors > 0 ) + throw new RuntimeException(); + } + + private static int testEquals() { + int errors = 0; + Object[] values = {null, "42", 42}; + + for(int i = 0; i < values.length; i++) + for(int j = 0; j < values.length; j++) { + boolean expected = (i == j); + Object a = values[i]; + Object b = values[j]; + boolean result = Objects.equals(a, b); + if (result != expected) { + errors++; + System.err.printf("When equating %s to %s, got %b intead of %b%n.", + a, b, result, expected); + } + } + return errors; + } + + private static int testHashCode() { + int errors = 0; + errors += (Objects.hashCode(null) == 0 ) ? 0 : 1; + String s = "42"; + errors += (Objects.hashCode(s) == s.hashCode() ) ? 0 : 1; + return errors; + } + + private static int testToString() { + int errors = 0; + errors += ("null".equals(Objects.toString(null)) ) ? 0 : 1; + String s = "Some string"; + errors += (s.equals(Objects.toString(s)) ) ? 0 : 1; + return errors; + } + + private static int testCompare() { + int errors = 0; + String[] values = {"e. e. cummings", "zzz"}; + String[] VALUES = {"E. E. Cummings", "ZZZ"}; + + errors += compareTest(null, null, 0); + + for(int i = 0; i < values.length; i++) { + String a = values[i]; + errors += compareTest(a, a, 0); + for(int j = 0; j < VALUES.length; j++) { + int expected = Integer.compare(i, j); + String b = VALUES[j]; + errors += compareTest(a, b, expected); + } + } + return errors; + } + + private static int compareTest(String a, String b, int expected) { + int errors = 0; + int result = Objects.compare(a, b, String.CASE_INSENSITIVE_ORDER); + if (Integer.signum(result) != Integer.signum(expected)) { + errors++; + System.err.printf("When comaping %s to %s, got %d intead of %d%n.", + a, b, result, expected); + + } + return errors; + } +} /* * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * - Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * - Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * - Neither the name of Sun Microsystems nor the names of its * contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ import java.util.Set; import java.util.EnumSet; import javax.annotation.processing.*; import javax.lang.model.SourceVersion; import javax.lang.model.element.*; import javax.lang.model.type.*; import javax.lang.model.util.*; import static javax.lang.model.SourceVersion.*; import static javax.lang.model.element.Modifier.*; import static javax.lang.model.element.ElementKind.*; import static javax.lang.model.type.TypeKind.*; import static javax.lang.model.util.ElementFilter.*; import static javax.tools.Diagnostic.Kind.*; @SupportedAnnotationTypes("*") // Process (check) everything @SupportedSourceVersion(SourceVersion.RELEASE_6) public class EqualsFinder extends AbstractProcessor { private EqualsFinder0 equalsFinder; public EqualsFinder() {super();} @Override public boolean process(Set annotations, RoundEnvironment roundEnv) { if (!roundEnv.processingOver()) { for (Element element : roundEnv.getRootElements() ) equalsFinder.find(element); } return false; // Allow other processors to examine files too. } @Override public void init(ProcessingEnvironment processingEnv) { super.init(processingEnv); equalsFinder = new EqualsFinder0(processingEnv); } private static class EqualsFinder0 { private final Messager messager; private final Elements eltUtils; EqualsScanner equalsScanner = new EqualsScanner(); EqualsFinder0(ProcessingEnvironment processsingEnv) { this.messager = processsingEnv.getMessager(); this.eltUtils = processsingEnv.getElementUtils(); } public void find(Element e) { equalsScanner.scan(e); } /** * Visitor to implement name checks. */ private class EqualsScanner extends ElementScanner6 { /** * Check the name of an executable (method, constructor, * etc.) and its type parameters. */ @Override public Void visitExecutable(ExecutableElement e, Void p) { // Check the name of the executable if (e.getKind() == METHOD) { Name name = e.getSimpleName(); if (name.contentEquals("equals") && e.getModifiers().contains(Modifier.STATIC) && e.getParameters().size() == 2) { messager.printMessage(NOTE, "Possible Objects.equals replacement.", e); eltUtils.printElements(new java.io.OutputStreamWriter(System.out) , e); } } return null; } } } } From weijun.wang at sun.com Fri Oct 2 03:54:24 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Fri, 02 Oct 2009 10:54:24 +0000 Subject: hg: jdk7/tl/jdk: 4 new changesets Message-ID: <20091002105543.1DD344188C@hg.openjdk.java.net> Changeset: 527ad9cbc9cf Author: weijun Date: 2009-10-02 18:44 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/527ad9cbc9cf 6324292: keytool -help is unhelpful Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/keytool/newhelp.sh Changeset: 56bad48e2810 Author: weijun Date: 2009-10-02 18:47 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/56bad48e2810 6862679: ESC: AD Authentication with user with umlauts fails Reviewed-by: valeriep, mullan ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/ETypeInfo.java ! src/share/classes/sun/security/krb5/internal/ETypeInfo2.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/crypto/Des.java + src/share/classes/sun/security/krb5/internal/util/KerberosString.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java + test/sun/security/krb5/RFC396xTest.java Changeset: a2d24418be6c Author: weijun Date: 2009-10-02 18:49 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a2d24418be6c 6874472: display address lists for tickets in klist tool Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java Changeset: a6046f6e720e Author: weijun Date: 2009-10-02 18:49 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a6046f6e720e 6868579: RFE: jarsigner to support reading password from environment variable Reviewed-by: xuelei, wetmore ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/jarsigner/passtype.sh From Ulf.Zibis at gmx.de Fri Oct 2 04:31:10 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 02 Oct 2009 13:31:10 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AC5805B.3090902@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> <4AC5805B.3090902@sun.com> Message-ID: <4AC5E47E.3010406@gmx.de> Am 02.10.2009 06:23, Joe Darcy schrieb: > > I wouldn't oppose a toDebugString(Object) method going into the > platform somewhere, but I don't think it necessarily belongs in Objects. I suggest new class java.util.Debug to contain this and many other thinkable helper methods useful for developers. > > Further below is the code for an annotation processor which finds > candidate equals methods to be replaced with Objects.equals. It found > over half a dozen good candidates in the jdk repository. To run the > annotation processor, first compile the class and then run it with > javac similar to this: > > javac -proc:only -processor EqualsFinder -processorpath processor> sources > That's very cool. -Ulf From michael.mcmahon at sun.com Fri Oct 2 06:02:10 2009 From: michael.mcmahon at sun.com (michael.mcmahon at sun.com) Date: Fri, 02 Oct 2009 13:02:10 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20091002130249.1920A418AE@hg.openjdk.java.net> Changeset: f0fdc4dd97d5 Author: michaelm Date: 2009-10-02 13:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f0fdc4dd97d5 6870935: DIGEST proxy authentication fails to connect to URLs with no trailing slash Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/NTLMAuthentication.java + test/java/net/Authenticator/B6870935.java Changeset: e782a9564eae Author: michaelm Date: 2009-10-02 13:59 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e782a9564eae Merge From jason_mehrens at hotmail.com Fri Oct 2 07:41:28 2009 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 2 Oct 2009 09:41:28 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AC5805B.3090902@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> Message-ID: Joe, > * null safe toString(Object), returning "null" for a null argument Doesn't String.valueOf do the same thing? http://java.sun.com/javase/6/docs/api/java/lang/String.html#valueOf(java.lang.Object) What about a toIdentityString(Object) instead? Some of the nice properties of an identity string is that it is safe to call from multiple threads even on objects that are not thread safe (JComponent), won't deadlock if toString is synchronized (observed in logging), and won't build run away strings (nCopies(Integer.MAX_VALUE, "lookout").toString()). Jason _________________________________________________________________ Hotmail? has ever-growing storage! Don?t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091002/0aee6a94/attachment.html From schulz at e-spirit.de Fri Oct 2 01:31:38 2009 From: schulz at e-spirit.de (Schulz, Stefan) Date: Fri, 2 Oct 2009 10:31:38 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AC5805B.3090902@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org><4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> <4AC5805B.3090902@sun.com> Message-ID: <7D2077BFF677D2429DDDEE095D9A48AC1375AA4B@osiris2.e-spirit.de> > Joe Darcy wrote: > * null safe two-argument equals method > > + public static boolean equals(Object a, Object b) { > + return (a == b) || (a != null && a.equals(b)); > + } While I agree this being helpful, as I earlier stated, it would be nice to have a (additional?) method that takes arrays into account as well, as equals() only does an identity check on arrays. In the current situation, one has to check for arrays before using either equals() or Arrays.deepEquals(), which makes Object.equals() pointless as identity and null-check are already done. Thanks, Stefan From tim.bell at sun.com Fri Oct 2 08:53:10 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 02 Oct 2009 15:53:10 +0000 Subject: hg: jdk7/tl/jdk: 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails Message-ID: <20091002155331.1EB39418DD@hg.openjdk.java.net> Changeset: 9fcca0aae3da Author: tbell Date: 2009-10-02 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9fcca0aae3da 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails Reviewed-by: dcubed ! test/com/sun/jdi/ShellScaffold.sh From Joe.Darcy at Sun.COM Fri Oct 2 10:49:36 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 02 Oct 2009 10:49:36 -0700 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> Message-ID: <4AC63D30.90700@sun.com> Jason Mehrens wrote: > Joe, > > > * null safe toString(Object), returning "null" for a null argument > > Doesn't String.valueOf do the same thing? > http://java.sun.com/javase/6/docs/api/java/lang/String.html#valueOf(java.lang.Object > ) Indeed it does! I'll replace the implementation with a call to String.valueOf and update the javadoc accordingly. Thanks for spotting this. > > What about a toIdentityString(Object) instead? Some of the nice > properties of an identity string is that it is safe to By toIdentityString, do you mean the String that would be returned by toString if toString is not overridden? -Joe > call from multiple threads even on objects that are not thread safe > (JComponent), won't deadlock if toString is synchronized (observed in > logging), and won't build run away strings (nCopies(Integer.MAX_VALUE, > "lookout").toString()). > > Jason > > ------------------------------------------------------------------------ > Hotmail? has ever-growing storage! Don?t worry about storage limits. > Check it out. > From jason_mehrens at hotmail.com Fri Oct 2 11:26:08 2009 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 2 Oct 2009 13:26:08 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AC63D30.90700@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> Message-ID: > By toIdentityString, do you mean the String that would be returned by > toString if toString is not overridden? > > -Joe Yep. As in: return o != null ? o.getClass().getName() +'@'+ Integer.toHexString(System.identityHashCode(o)) : "null"; I suppose the name should be identityToString to match System.identityHashCode??? Jason _________________________________________________________________ Insert movie times and more without leaving Hotmail?. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091002/660c24e7/attachment.html From Joe.Darcy at Sun.COM Fri Oct 2 13:26:09 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Fri, 02 Oct 2009 13:26:09 -0700 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> Message-ID: <4AC661E1.7010304@sun.com> Jason Mehrens wrote: > > By toIdentityString, do you mean the String that would be returned by > > toString if toString is not overridden? > > > > -Joe > > Yep. As in: > > return o != null ? o.getClass().getName() +'@' + > Integer.toHexString(System.identityHashCode(o)) : "null"; > > I suppose the name should be identityToString to match > System.identityHashCode??? > > Jason I think a better name would be "defaultToString" since it is the default toString from Object. However, I haven't ever heard anyone else request easier access to the default toString before so I'm not convinced this should go into Objects. -Joe From jason_mehrens at hotmail.com Fri Oct 2 15:14:35 2009 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 2 Oct 2009 17:14:35 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AC661E1.7010304@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> Message-ID: > I think a better name would be "defaultToString" since it is the default > toString from Object. However, I haven't ever heard anyone else request > easier access to the default toString before so I'm not convinced this > should go into Objects. > > -Joe One use case is implementing toString for identity maps and collections. The current IdentityHashMap is immune to poison objects except for its toString implementation. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6579224 Another point of confusion is that the toString does not match what is going on in equals. Take the following code: public static void main(String[] args) { Map dis = new IdentityHashMap(one()); Map dat = new IdentityHashMap(one()); System.out.println(dis.equals(dat)); System.out.println(dis.toString().equals(dat.toString())); } private static Map one() { Integer kv = new Integer(256); return Collections.singletonMap(kv, kv); } It prints false and then true. If defaultToString was used on the key/value pairs it would print false and then false making it clear why the two maps are not equal. Something to consider if a new reference map or identity map is added to the JDK (jsr166/extra166y). Jason _________________________________________________________________ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/171222984/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091002/f2736bba/attachment.html From pbenedict at apache.org Sat Oct 3 21:43:58 2009 From: pbenedict at apache.org (Paul Benedict) Date: Sat, 3 Oct 2009 23:43:58 -0500 Subject: JSR-292: Why not java.lang.dyn? Message-ID: I've always found it a bit perplexing that java.lang was never chosen for the parent package of the Dynamic API. Why is that? Dynamic types are now "part of the language" as proven by spec itself and exotic identifiers. Will this be reconsidered? Paul From Mandy.Chung at Sun.COM Sat Oct 3 23:03:51 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Sat, 03 Oct 2009 23:03:51 -0700 Subject: Review request for 6612680 (Remove classloader dependency on jkernel) Message-ID: <4AC83AC7.60402@sun.com> Alan, Karen, Can you review the fix for: 6612680: Remove classloader dependency on jkernel Webrev at: http://cr.openjdk.java.net/~mchung/6612680/ java.lang.ClassLoader and sun.misc.Launcher have explicit dependencies on the jkernel code. While the performance impact of this is minimal (the calls basically amount to nops when the JRE is complete), it's still undesirable. To eliminate the static dependency on jkernel, this adds a boot classloader hook interface that is invoked in the ClassLoader findClass, getSystemResource, and other methods. The hook is null by default. The jkernel VM will call the static DownloadManager.setBootClassLoaderHook() method and only the jkernel environment will have a non-null boot class loader hook. Since jkernel is a separate build including the bundles and VM, as we discussed, the jkernel VM is a reasonable place to inject the DownloadManager as the boot class loader hook. I'm hoping to make TL b74 which is code freeze by 10 pm PT Monday. Thanks Mandy From Christian.Thalinger at Sun.COM Sun Oct 4 02:39:14 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 04 Oct 2009 11:39:14 +0200 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: References: Message-ID: <1254649154.1535.13.camel@macbook> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote: > I've always found it a bit perplexing that java.lang was never chosen > for the parent package of the Dynamic API. Why is that? Dynamic types > are now "part of the language" as proven by spec itself and exotic > identifiers. Will this be reconsidered? [I'm forwarding this question to mlvm-dev.] I think John Rose or another member of the EG should have an answer to this. -- Christian From forax at univ-mlv.fr Sun Oct 4 04:34:18 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 04 Oct 2009 13:34:18 +0200 Subject: Review request for 6612680 (Remove classloader dependency on jkernel) In-Reply-To: <4AC83AC7.60402@sun.com> References: <4AC83AC7.60402@sun.com> Message-ID: <4AC8883A.5030409@univ-mlv.fr> Le 04/10/2009 08:03, Mandy Chung a ?crit : > Alan, Karen, > > Can you review the fix for: > 6612680: Remove classloader dependency on jkernel > > Webrev at: > http://cr.openjdk.java.net/~mchung/6612680/ > > java.lang.ClassLoader and sun.misc.Launcher have explicit dependencies > on the jkernel code. While the performance impact of this is minimal > (the calls basically amount to nops when the JRE is complete), it's > still undesirable. > > To eliminate the static dependency on jkernel, this adds a boot > classloader hook interface that is invoked in the ClassLoader > findClass, getSystemResource, and other methods. The hook is null by > default. The jkernel VM will call the static > DownloadManager.setBootClassLoaderHook() method and only the jkernel > environment will have a non-null boot class loader hook. Since > jkernel is a separate build including the bundles and VM, as we > discussed, the jkernel VM is a reasonable place to inject the > DownloadManager as the boot class loader hook. > > I'm hoping to make TL b74 which is code freeze by 10 pm PT Monday. > > Thanks > Mandy > A small comment, it seems that DownloadManager.instance is never read. cheers, R?mi From forax at univ-mlv.fr Sun Oct 4 04:40:56 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 04 Oct 2009 13:40:56 +0200 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: <1254649154.1535.13.camel@macbook> References: <1254649154.1535.13.camel@macbook> Message-ID: <4AC889C8.5070208@univ-mlv.fr> Le 04/10/2009 11:39, Christian Thalinger a ?crit : > On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote: > >> I've always found it a bit perplexing that java.lang was never chosen >> for the parent package of the Dynamic API. Why is that? Dynamic types >> are now "part of the language" as proven by spec itself and exotic >> identifiers. Will this be reconsidered? >> > [I'm forwarding this question to mlvm-dev.] > > I think John Rose or another member of the EG should have an answer to > this. > > -- Christian > > java.lang => Java the language (not the platform) Exotic identifiers and MethodHandle.invoke calling rules in Java (the language) are not part of the JSR292 spec. JSR 292 => method handle API for any (dynamic?) language So why java.dyn API should be a 'part' of java.lang ? R?mi From pbenedict at apache.org Sun Oct 4 10:11:25 2009 From: pbenedict at apache.org (Paul Benedict) Date: Sun, 4 Oct 2009 12:11:25 -0500 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: <4AC889C8.5070208@univ-mlv.fr> References: <1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr> Message-ID: I thought the language was being modified to make Dynamic<> exempt from type-checking rules. The way I look at it, grammar is the underpinnings of language. To "read the grammar" is analogous to "compiling the source" -- both are about making sense of tokens. With the introduction of Dynamic<>, I have to amend my understanding of the grammar to no longer perform type-checking rules. Hence, this is a language issue. Did I misunderstand? Paul On Sun, Oct 4, 2009 at 6:40 AM, R?mi Forax wrote: > Le 04/10/2009 11:39, Christian Thalinger a ?crit : >> >> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote: >> >>> >>> I've always found it a bit perplexing that java.lang was never chosen >>> for the parent package of the Dynamic API. Why is that? Dynamic types >>> are now "part of the language" as proven by spec itself and exotic >>> identifiers. Will this be reconsidered? >>> >> >> [I'm forwarding this question to mlvm-dev.] >> >> I think John Rose or another member of the EG should have an answer to >> this. >> >> -- Christian >> >> > > java.lang => Java the language (not the platform) > > Exotic identifiers and MethodHandle.invoke calling rules in Java (the > language) > are not part of the JSR292 spec. > JSR 292 => method handle API for any (dynamic?) language > > So why java.dyn API should be a 'part' of java.lang ? > > R?mi > From forax at univ-mlv.fr Sun Oct 4 11:48:28 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 04 Oct 2009 20:48:28 +0200 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: References: <1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr> Message-ID: <4AC8EDFC.6060801@univ-mlv.fr> Le 04/10/2009 19:11, Paul Benedict a ?crit : > I thought the language was being modified to make Dynamic<> exempt > from type-checking rules. In fact, this is InvokeDynamic.invoke() and MethodHandle.invoke() that allow you to escape the type-checking rules. > The way I look at it, grammar is the > underpinnings of language. To "read the grammar" is analogous to > "compiling the source" -- both are about making sense of tokens. I think you forget 'infer the semantics' somewhere. > With > the introduction of Dynamic<>, I have to amend my understanding of the > grammar to no longer perform type-checking rules. Hence, this is a > language issue. > > Did I misunderstand? > > Paul > There is two specifications : One is about bringing invokedynamic to the VM, the JSR292 spec. This spec doesn't require any change to the JLS, only change to the JVMS. The other spec is how to allow Java (the language) to use the invokedynamic/method handle stuff. Clearly this requires changes of the JLS. see http://wikis.sun.com/display/mlvm/ProjectCoinProposal R?mi From pbenedict at apache.org Sun Oct 4 17:27:58 2009 From: pbenedict at apache.org (Paul Benedict) Date: Sun, 4 Oct 2009 19:27:58 -0500 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: <7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com> References: <1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr> <7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com> Message-ID: Stepan, That is a very good observation. I wonder what others have to say about it? As you pointed out, there are other java.lang.* sub-packages that have no impact on the Java language. I am in agreement that java.dyn is closer to the language than not -- hence I think java.lang.dyn is natural. Paul On Sun, Oct 4, 2009 at 6:34 PM, Stepan Koltsov wrote: > On Sun, Oct 4, 2009 at 15:40, R?mi Forax wrote: >> Le 04/10/2009 11:39, Christian Thalinger a ?crit : >>> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote: >>> >>>> I've always found it a bit perplexing that java.lang was never chosen >>>> for the parent package of the Dynamic API. Why is that? Dynamic types >>>> are now "part of the language" as proven by spec itself and exotic >>>> identifiers. Will this be reconsidered? >>>> >>> [I'm forwarding this question to mlvm-dev.] >>> >>> I think John Rose or another member of the EG should have an answer to >>> this. >>> >>> -- Christian >>> >>> >> >> java.lang => Java the language (not the platform) >> >> Exotic identifiers and MethodHandle.invoke calling rules in Java (the >> language) >> are not part of the JSR292 spec. >> JSR 292 => method handle API for any (dynamic?) language >> >> So why java.dyn API should be a 'part' of java.lang ? > > java.lang.reflect also deals with JVM objects, not Java language. But > it still java.lang.reflect, not java.reflect. > > java.lang.Class is also closer to JVM then to the java language. > > java.lang has lots of JVM stuff. > > I also think, that package name should be java.lang.dyc, although it > is not absolutely correct. > > "java" root package has lots of libraries (java.io, java.sql), and > these libraries should not be mixed with JVM interface. > > If you think java.lang.dyn is inappropriate, then java.vm.dyn is > better, because next JVM interface (what ever it will be) can be > placed into java.vm package too and won't be lost among all java.* > stuff. > > S. > From yozh at mx1.ru Sun Oct 4 16:34:31 2009 From: yozh at mx1.ru (Stepan Koltsov) Date: Mon, 5 Oct 2009 03:34:31 +0400 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: <4AC889C8.5070208@univ-mlv.fr> References: <1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr> Message-ID: <7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com> On Sun, Oct 4, 2009 at 15:40, R?mi Forax wrote: > Le 04/10/2009 11:39, Christian Thalinger a ?crit : >> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote: >> >>> I've always found it a bit perplexing that java.lang was never chosen >>> for the parent package of the Dynamic API. Why is that? Dynamic types >>> are now "part of the language" as proven by spec itself and exotic >>> identifiers. Will this be reconsidered? >>> >> [I'm forwarding this question to mlvm-dev.] >> >> I think John Rose or another member of the EG should have an answer to >> this. >> >> -- Christian >> >> > > java.lang => Java the language (not the platform) > > Exotic identifiers and MethodHandle.invoke calling rules in Java (the > language) > are not part of the JSR292 spec. > JSR 292 => method handle API for any (dynamic?) language > > So why java.dyn API should be a 'part' of java.lang ? java.lang.reflect also deals with JVM objects, not Java language. But it still java.lang.reflect, not java.reflect. java.lang.Class is also closer to JVM then to the java language. java.lang has lots of JVM stuff. I also think, that package name should be java.lang.dyc, although it is not absolutely correct. "java" root package has lots of libraries (java.io, java.sql), and these libraries should not be mixed with JVM interface. If you think java.lang.dyn is inappropriate, then java.vm.dyn is better, because next JVM interface (what ever it will be) can be placed into java.vm package too and won't be lost among all java.* stuff. S. From pravin at zensoftech.co.in Mon Oct 5 01:37:45 2009 From: pravin at zensoftech.co.in (Pravin Jain) Date: Mon, 5 Oct 2009 14:07:45 +0530 Subject: 6609441 : Ch] Enumerated types for general category and directionality in Character class Message-ID: Hello All, I would like to work on this RFE. This change is quite simple and gives greater value to the Character class. The change can be done without breaking any existing code by adding the following enums in the Character class. /** * An enum for all the GeneralCategory values. The ordinal values for these enums are compatible with the * corresponding byte values as returned by the getType method. * @since 1.7 */ public enum GeneralCategory { /** * General category "Cn" in the Unicode specification. * @since 1.7 */ UNASSIGNED("Cn"),// = 0; /** * General category "Lu" in the Unicode specification. * @since 1.7 */ UPPERCASE_LETTER("Lu"),// = 1; /** * General category "Ll" in the Unicode specification. * @since 1.7 */ LOWERCASE_LETTER("Ll"),// = 2; /** * General category "Lt" in the Unicode specification. * @since 1.7 */ TITLECASE_LETTER("Lt"),// = 3; /** * General category "Lm" in the Unicode specification. * @since 1.7 */ MODIFIER_LETTER("Lm"),// = 4; /** * General category "Lo" in the Unicode specification. * @since 1.7 */ OTHER_LETTER("Lo"),// = 5; /** * General category "Mn" in the Unicode specification. * @since 1.7 */ NON_SPACING_MARK("Mn"),// = 6; /** * General category "Me" in the Unicode specification. * @since 1.7 */ ENCLOSING_MARK("Me"),// = 7; /** * General category "Mc" in the Unicode specification. * @since 1.7 */ COMBINING_SPACING_MARK("Mc"),// = 8; /** * General category "Nd" in the Unicode specification. * @since 1.7 */ DECIMAL_DIGIT_NUMBER("Nd"),// = 9; /** * General category "Nl" in the Unicode specification. * @since 1.7 */ LETTER_NUMBER("Nl"),// = 10; /** * General category "No" in the Unicode specification. * @since 1.7 */ OTHER_NUMBER("No"),// = 11; /** * General category "Zs" in the Unicode specification. * @since 1.7 */ SPACE_SEPARATOR("Zs"),// = 12; /** * General category "Zl" in the Unicode specification. * @since 1.7 */ LINE_SEPARATOR("Zl"),// = 13; /** * General category "Zp" in the Unicode specification. * @since 1.7 */ PARAGRAPH_SEPARATOR("Zp"),// = 14; /** * General category "Cc" in the Unicode specification. * @since 1.7 */ CONTROL("Cc"),// = 15; /** * General category "Cf" in the Unicode specification. * @since 1.7 */ FORMAT("Cf"),// = 16; /** * Filler * @since 1.7 */ UNKNOWN(null),// = 17; /** * General category "Co" in the Unicode specification. * @since 1.7 */ PRIVATE_USE("Co"),// = 18; /** * General category "Cs" in the Unicode specification. * @since 1.7 */ SURROGATE("Cs"),// = 19; /** * General category "Pd" in the Unicode specification. * @since 1.7 */ DASH_PUNCTUATION("Pd"),// = 20; /** * General category "Ps" in the Unicode specification. * @since 1.7 */ START_PUNCTUATION("Ps"),// = 21; /** * General category "Pe" in the Unicode specification. * @since 1.7 */ END_PUNCTUATION("Pe"),// = 22; /** * General category "Pc" in the Unicode specification. * @since 1.7 */ CONNECTOR_PUNCTUATION("Pc"),// = 23; /** * General category "Po" in the Unicode specification. * @since 1.7 */ OTHER_PUNCTUATION("Po"),// = 24; /** * General category "Sm" in the Unicode specification. * @since 1.7 */ MATH_SYMBOL("Sm"),// = 25; /** * General category "Sc" in the Unicode specification. * @since 1.7 */ CURRENCY_SYMBOL("Sc"),// = 26; /** * General category "Sk" in the Unicode specification. * @since 1.7 */ MODIFIER_SYMBOL("Sk"),// = 27; /** * General category "So" in the Unicode specification. * @since 1.7 */ OTHER_SYMBOL("So"),// = 28; /** * General category "Pi" in the Unicode specification. * @since 1.7 */ INITIAL_QUOTE_PUNCTUATION("Pi"),// = 29; /** * General category "Pf" in the Unicode specification. * @since 1.7 */ FINAL_QUOTE_PUNCTUATION("Pf"),// = 30; ; /** * The abbreviated name of the general category as available from the UCD. * */ private String abbreviatedName; /** * The constructor requires the abbreviated name as parameter * @param abbrName - abreviated Name for the general category * */ private GeneralCategory(String abbrName) { this.abbreviatedName = abbrName; } /** * This method returns the abbreviated name for the general category represented by this instance. * @return - abbreviated name for the general category. */ public String getAbbreviatedName() { return abbreviatedName; } } /** * An enum for all the Directionality values. The ordinal values for these enums are compatible with the * corresponding byte values as returned by the getDirectionality method. */ public enum Directionality { /** * Strong bidirectional character type "L" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_LEFT_TO_RIGHT("L"),// = 0; /** * Strong bidirectional character type "R" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_RIGHT_TO_LEFT("R"),// = 1; /** * Strong bidirectional character type "AL" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_RIGHT_TO_LEFT_ARABIC("AL"),// = 2; /** * Weak bidirectional character type "EN" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_EUROPEAN_NUMBER("EN"),// = 3; /** * Weak bidirectional character type "ES" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_EUROPEAN_NUMBER_SEPARATOR("ES"),// = 4; /** * Weak bidirectional character type "ET" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_EUROPEAN_NUMBER_TERMINATOR("ET"),// = 5; /** * Weak bidirectional character type "AN" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_ARABIC_NUMBER("AN"),// = 6; /** * Weak bidirectional character type "CS" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_COMMON_NUMBER_SEPARATOR("CS"),// = 7; /** * Weak bidirectional character type "NSM" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_NONSPACING_MARK("NSM"),// = 8; /** * Weak bidirectional character type "BN" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_BOUNDARY_NEUTRAL("BN"),// = 9; /** * Neutral bidirectional character type "B" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_PARAGRAPH_SEPARATOR("B"),// = 10; /** * Neutral bidirectional character type "S" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_SEGMENT_SEPARATOR("S"),// = 11; /** * Neutral bidirectional character type "WS" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_WHITESPACE("WS"),// = 12; /** * Neutral bidirectional character type "ON" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_OTHER_NEUTRALS("ON"),// = 13; /** * Strong bidirectional character type "LRE" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_LEFT_TO_RIGHT_EMBEDDING("LRE"),// = 14; /** * Strong bidirectional character type "LRO" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_LEFT_TO_RIGHT_OVERRIDE("LRO"),// = 15; /** * Strong bidirectional character type "RLE" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_RIGHT_TO_LEFT_EMBEDDING("RLE"),// = 16; /** * Strong bidirectional character type "RLO" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_RIGHT_TO_LEFT_OVERRIDE("RLO"),// = 17; /** * Weak bidirectional character type "PDF" in the Unicode specification. * @since 1.4 */ DIRECTIONALITY_POP_DIRECTIONAL_FORMAT("PDF"),// = 18; ; /** * The abbreviated name of the general category as available from the UCD. * */ private String abbreviatedName; /** * The constructor requires the abbreviated name as parameter * @param abbrName - abreviated Name for the directionality * */ private Directionality(String abbrName) { this.abbreviatedName = abbrName; } /** * This method returns the abbreviated name for the directionality represented by this instance. * @return - abbreviated name for the directionality. */ public String getAbbreviatedName() { return abbreviatedName; } } Also the following methods can be added /** * * @ returns - The general category for the unicode code point */ public static GeneralCategory getGeneralCategory(int codePoint) { return GeneralCategory.values()[getType(codePoint)]; } /** * * @ returns - The directionality for the unicode code point */ public static Directionality getDirectionalityOf(int codePoint) { return Directionality.values()[getDirectionality(codePoint)]; } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091005/32c1a4aa/attachment-0001.html From i30817 at gmail.com Mon Oct 5 06:49:34 2009 From: i30817 at gmail.com (Paulo Levi) Date: Mon, 5 Oct 2009 14:49:34 +0100 Subject: New methods in jdk7 Message-ID: <212322090910050649x2c696a47v83346908cc0ce564@mail.gmail.com> Since i heard you were looking for suggestions, i think i might have a useful one that i think is impossible nowadays without native code. public void restart(); At first i thought it could be simulated just by calling the main class again in a shutdown hook, but i don't think all the static state is destroyed then. ProcessBuilder shenanigans wouldn't work, because when the parent jvm dies the child must too right? From Alan.Bateman at Sun.COM Mon Oct 5 07:24:41 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 05 Oct 2009 15:24:41 +0100 Subject: Review request for 6612680 (Remove classloader dependency on jkernel) In-Reply-To: <4AC83AC7.60402@sun.com> References: <4AC83AC7.60402@sun.com> Message-ID: <4ACA01A9.6000707@sun.com> Mandy Chung wrote: > Alan, Karen, > > Can you review the fix for: > 6612680: Remove classloader dependency on jkernel > > Webrev at: > http://cr.openjdk.java.net/~mchung/6612680/ > > java.lang.ClassLoader and sun.misc.Launcher have explicit dependencies > on the jkernel code. While the performance impact of this is minimal > (the calls basically amount to nops when the JRE is complete), it's > still undesirable. > > To eliminate the static dependency on jkernel, this adds a boot > classloader hook interface that is invoked in the ClassLoader > findClass, getSystemResource, and other methods. The hook is null by > default. The jkernel VM will call the static > DownloadManager.setBootClassLoaderHook() method and only the jkernel > environment will have a non-null boot class loader hook. Since > jkernel is a separate build including the bundles and VM, as we > discussed, the jkernel VM is a reasonable place to inject the > DownloadManager as the boot class loader hook. > > I'm hoping to make TL b74 which is code freeze by 10 pm PT Monday. Good to see this dependency going away. A couple of comments: - In thread.cpp, do you need to check if klass is NULL (sun.jkernel.DownloadManager not present). - In thread.cpp, you set the hook after the system classes have been initialized. Do I have this right? (looks like you double check in setHook). You might want to check with the deployment folks to make sure that they understand the implications of this - for example it might have change the contents of the core bundle. - Do these changes mean we can remove sun.misc.VM.isBootedKernelVM? - Is the removal of CLASSDESTDIR from make/sun/jkernel/Makefile related or just clean-up (as it doesn't seem to be used)? Minor nit but you've add a blank line at line 46. - ZipEntry: the idea that a class loader hook overrides the zip file time is a bit strange. I see you have a few FIXME comments in the code to revisit but maybe for this push it might be neater to just have BootClassLoaderHook define a isCurrentThreadPrefetching or some such method that returns a boolean to indicate if the current thread is fetching and if so, set it to some pre-defined value (I don't know if there is any significance to the value of KERNEL_STATIC_MODTIME). - In ICC_Profile would it be neater to do: BootClassLoaderHook hook = BootClassLoaderHook.getHook(); if (hook != null) hook.prefetchFile(...) - Minor nit but you've added a few blank lines to DownloadManager. - I agree with R?mi comment that DownloadManager.instance doesn't seem to be needed. - In BootClassLoaderHook's class description they may be a typo - I think you meant to say "into the bootstrap class loader". Also, I assume you meant to say "In other JDK builds ...". Otherwise, I think this is okay. I'll do another pass on it today as I know you want to get this over the finish line by tonight. -Alan. From alan.bateman at sun.com Mon Oct 5 08:48:16 2009 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Mon, 05 Oct 2009 15:48:16 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20091005154935.32CCA41D84@hg.openjdk.java.net> Changeset: 97f17e6d0560 Author: alanb Date: 2009-10-04 15:42 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/97f17e6d0560 6884800: (file) Path.newInputStream does not usefully implement available() Reviewed-by: martin, chegar ! src/share/classes/sun/nio/ch/ChannelInputStream.java ! test/java/nio/channels/Channels/Basic.java Changeset: a4f31836660a Author: alanb Date: 2009-10-05 16:45 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a4f31836660a 6854954: Eliminate static dependency on java.awt.AWTPermission Reviewed-by: mullan, mchung, anthony ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/MouseInfo.java ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/javax/swing/JPopupMenu.java + src/share/classes/sun/awt/AWTPermissionFactory.java ! src/share/classes/sun/security/provider/PolicyFile.java + src/share/classes/sun/security/util/PermissionFactory.java ! src/share/classes/sun/security/util/SecurityConstants.java From benjamin.john.evans at googlemail.com Mon Oct 5 11:01:57 2009 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Mon, 5 Oct 2009 19:01:57 +0100 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: References: <1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr> <7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com> Message-ID: <38a53eb30910051101n1cd69750r99455ec8dfc5a6b9@mail.gmail.com> I think this is somewhat of a red herring. After all, there are many classes which live in java.lang which are fundamental to the operation of the platform, and which any language which lived on top of the VM would have an intimate relationship with (eg Object, Class, String, etc). If we are moving to a point of view in which the Java language is not central to the platform, but rather first among equals (by removing all direct dependencies of the JVM spec on the JLS, etc), then in an ideal world these classes would live in java.core or java.platform or something. That would of course break the whole world, so is clearly not going to happen. The best we can do is not make the situation worse for future amendments, by not placing additional classes which are not specific to the Java language into java.lang. I am puzzled, however, by your assertion that dynamic invocation is closer to the language than 'not', ie closer to the language than the platform. Non-Java languages have been making use (and shipping support for, in some cases) of dynamic invocation for quite a few months now. The experience of those language's implementors has been integral to the development process of this feature. The Java language has been playing catch-up throughout. It's fantastic that it's in the JLS now and I look forward to seeing some first-class implementations of it, but this feature really wasn't crafted with Java as the pre-eminent use case. Ben On Mon, Oct 5, 2009 at 1:27 AM, Paul Benedict wrote: > Stepan, > > That is a very good observation. I wonder what others have to say > about it? As you pointed out, there are other java.lang.* sub-packages > that have no impact on the Java language. > > I am in agreement that java.dyn is closer to the language than not -- > hence I think java.lang.dyn is natural. > > Paul > > On Sun, Oct 4, 2009 at 6:34 PM, Stepan Koltsov wrote: > > On Sun, Oct 4, 2009 at 15:40, R?mi Forax wrote: > >> Le 04/10/2009 11:39, Christian Thalinger a ?crit : > >>> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote: > >>> > >>>> I've always found it a bit perplexing that java.lang was never chosen > >>>> for the parent package of the Dynamic API. Why is that? Dynamic types > >>>> are now "part of the language" as proven by spec itself and exotic > >>>> identifiers. Will this be reconsidered? > >>>> > >>> [I'm forwarding this question to mlvm-dev.] > >>> > >>> I think John Rose or another member of the EG should have an answer to > >>> this. > >>> > >>> -- Christian > >>> > >>> > >> > >> java.lang => Java the language (not the platform) > >> > >> Exotic identifiers and MethodHandle.invoke calling rules in Java (the > >> language) > >> are not part of the JSR292 spec. > >> JSR 292 => method handle API for any (dynamic?) language > >> > >> So why java.dyn API should be a 'part' of java.lang ? > > > > java.lang.reflect also deals with JVM objects, not Java language. But > > it still java.lang.reflect, not java.reflect. > > > > java.lang.Class is also closer to JVM then to the java language. > > > > java.lang has lots of JVM stuff. > > > > I also think, that package name should be java.lang.dyc, although it > > is not absolutely correct. > > > > "java" root package has lots of libraries (java.io, java.sql), and > > these libraries should not be mixed with JVM interface. > > > > If you think java.lang.dyn is inappropriate, then java.vm.dyn is > > better, because next JVM interface (what ever it will be) can be > > placed into java.vm package too and won't be lost among all java.* > > stuff. > > > > S. > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091005/7632eb8f/attachment.html From quintin at last.za.net Mon Oct 5 14:10:35 2009 From: quintin at last.za.net (Quintin Beukes) Date: Mon, 5 Oct 2009 23:10:35 +0200 Subject: New Methods/Features in JDK7 Message-ID: <1f3854d50910051410i341732aftd2d452c44537d6f8@mail.gmail.com> Hey, Are there any current listings of new language features/broad API changes so far in OpenJDK7. I understand they might not be permanent, and could change in a wink, though I'm curious to see what could possibly be in the next Java. Quintin Beukes From Joe.Darcy at Sun.COM Mon Oct 5 15:12:38 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 05 Oct 2009 15:12:38 -0700 Subject: New Methods/Features in JDK7 In-Reply-To: <1f3854d50910051410i341732aftd2d452c44537d6f8@mail.gmail.com> References: <1f3854d50910051410i341732aftd2d452c44537d6f8@mail.gmail.com> Message-ID: <4ACA6F56.3000408@sun.com> Quintin Beukes wrote: > Hey, > > Are there any current listings of new language features/broad API > changes so far in OpenJDK7. I understand they might not be permanent, > and could change in a wink, though I'm curious to see what could > possibly be in the next Java. > > Quintin Beukes > http://openjdk.java.net/projects/jdk7/features/ -Joe From martinrb at google.com Mon Oct 5 15:14:11 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 5 Oct 2009 15:14:11 -0700 Subject: New methods in jdk7 In-Reply-To: <212322090910050649x2c696a47v83346908cc0ce564@mail.gmail.com> References: <212322090910050649x2c696a47v83346908cc0ce564@mail.gmail.com> Message-ID: <1ccfd1c10910051514y27117fb9ic61e8d2786636c0f@mail.gmail.com> On Mon, Oct 5, 2009 at 06:49, Paulo Levi wrote: > ProcessBuilder shenanigans wouldn't work, because when the parent jvm > dies the child must too right? There's no reason why the child should not be able to outlive the parent. The child will get end of file on the pipes connected to the parent, but the new ProcessBuilder I/O redirection API in jdk7 evades that as well. Martin From martinrb at google.com Mon Oct 5 15:16:56 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 5 Oct 2009 15:16:56 -0700 Subject: New Methods/Features in JDK7 In-Reply-To: <1f3854d50910051410i341732aftd2d452c44537d6f8@mail.gmail.com> References: <1f3854d50910051410i341732aftd2d452c44537d6f8@mail.gmail.com> Message-ID: <1ccfd1c10910051516x5555b909yb4cc234c9aa258bc@mail.gmail.com> Unofficial: http://tech.puredanger.com/java7 On Mon, Oct 5, 2009 at 14:10, Quintin Beukes wrote: > Hey, > > Are there any current listings of new language features/broad API > changes so far in OpenJDK7. I understand they might not be permanent, > and could change in a wink, though I'm curious to see what could > possibly be in the next Java. > > Quintin Beukes > From vincent.ryan at sun.com Mon Oct 5 15:41:35 2009 From: vincent.ryan at sun.com (vincent.ryan at sun.com) Date: Mon, 05 Oct 2009 22:41:35 +0000 Subject: hg: jdk7/tl/jdk: 6885204: JSSE should not require Kerberos to be present Message-ID: <20091005224206.008D641DF9@hg.openjdk.java.net> Changeset: 54118c8e0ebe Author: vinnie Date: 2009-10-05 23:42 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/54118c8e0ebe 6885204: JSSE should not require Kerberos to be present Reviewed-by: wetmore, alanb ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/JsseJce.java From Mandy.Chung at Sun.COM Mon Oct 5 16:39:20 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Mon, 05 Oct 2009 16:39:20 -0700 Subject: Review request for 6612680 (Remove classloader dependency on jkernel) In-Reply-To: <4ACA01A9.6000707@sun.com> References: <4AC83AC7.60402@sun.com> <4ACA01A9.6000707@sun.com> Message-ID: <4ACA83A8.7040000@sun.com> Alan, R?mi, Thanks for the review. The revised webrev is at: http://cr.openjdk.java.net/~mchung/6612680/jdk-webrev.01/ http://cr.openjdk.java.net/~mchung/6612680/hotspot-webrev.01/ Alan Bateman wrote: > Good to see this dependency going away. A couple of comments: > > - In thread.cpp, do you need to check if klass is NULL > (sun.jkernel.DownloadManager not present). > Yes, we need that so that jkernel VM can run with other JDKs with no DownloadManager. Thanks for catching it. > - In thread.cpp, you set the hook after the system classes have been > initialized. Do I have this right? (looks like you double check in > setHook). You might want to check with the deployment folks to make > sure that they understand the implications of this - for example it > might have change the contents of the core bundle. Yes. I set the hook after the system classes have been initialized. I added the check in the setHook() method to catch if a new hook would be added in the future before the system is initialized. > > - Do these changes mean we can remove sun.misc.VM.isBootedKernelVM? > I clean that up. We no longer need this method that was put as a workaround. > - Is the removal of CLASSDESTDIR from make/sun/jkernel/Makefile > related or just clean-up (as it doesn't seem to be used)? Minor nit > but you've add a blank line at line 46. This is to fix the jdk and deploy build failure when we eliminate the dependency to jkernel. If the sun.jkernel.* classes were built in the tmp directory, javah fail to find the sun.jkernel.* classes to generate the .h files. Usually we only set CLASSDESTDIR to TEMPDIR when we want to package classes in a different jar file. This is not the case for sun.jkernel.* since they are included in rt.jar and that's a bug. I guess why it worked in the past is because sun.jkernel.* get compiled when compiling the system classes that reference DownloadManager and the sun.jkernel.* classes were put in the usual class destination directory. > > - ZipEntry: the idea that a class loader hook overrides the zip file > time is a bit strange. I see you have a few FIXME comments in the code > to revisit but maybe for this push it might be neater to just have > BootClassLoaderHook define a isCurrentThreadPrefetching or some such > method that returns a boolean to indicate if the current thread is > fetching and if so, set it to some pre-defined value (I don't know if > there is any significance to the value of KERNEL_STATIC_MODTIME). > > - In ICC_Profile would it be neater to do: > BootClassLoaderHook hook = BootClassLoaderHook.getHook(); > if (hook != null) > hook.prefetchFile(...) > > - Minor nit but you've added a few blank lines to DownloadManager. > > - I agree with R?mi comment that DownloadManager.instance doesn't seem > to be needed. > > - In BootClassLoaderHook's class description they may be a typo - I > think you meant to say "into the bootstrap class loader". Also, I > assume you meant to say "In other JDK builds ...". > > Otherwise, I think this is okay. I'll do another pass on it today as I > know you want to get this over the finish line by tonight. > I clean up the code per your suggestion and ready to push the fix. Mandy > -Alan. > > > > > > > > > > > > From Joe.Darcy at Sun.COM Mon Oct 5 16:43:17 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 05 Oct 2009 16:43:17 -0700 Subject: Core review request for 5062288 "(reflect) Core reflection uses raw types when it could be using wildcards" Message-ID: <4ACA8495.6080105@sun.com> Hello. Please review my changes to address: 5062288 "(reflect) Core reflection uses raw types when it could be using wildcards" http://cr.openjdk.java.net/~darcy/5062288.0/ This changeset removes most of the raw types warnings in core reflection, java.lang.Class and java.lang.reflect.*. I did not attempt to remove uses of raw types from ClassLoader and I did not attempt to make serious changes to Proxy. This changeset does not affect "exported public" API signatures, only local variables and less than public exported method signatures and fields. Thanks, -Joe From mandy.chung at sun.com Mon Oct 5 18:21:39 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Tue, 06 Oct 2009 01:21:39 +0000 Subject: hg: jdk7/tl/jdk: 6612680: Remove classloader dependency on jkernel Message-ID: <20091006012159.4618941E24@hg.openjdk.java.net> Changeset: c499401bc138 Author: mchung Date: 2009-10-05 18:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c499401bc138 6612680: Remove classloader dependency on jkernel Summary: Add a new sun.misc.BootClassLoaderHook that DownloadManager will implement Reviewed-by: alanb, forax, igor ! make/sun/jkernel/Makefile ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/sun/jkernel/DownloadManager.java + src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/VM.java ! src/share/native/sun/misc/VM.c From Alan.Bateman at Sun.COM Tue Oct 6 01:46:41 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 06 Oct 2009 09:46:41 +0100 Subject: Core review request for 5062288 "(reflect) Core reflection uses raw types when it could be using wildcards" In-Reply-To: <4ACA8495.6080105@sun.com> References: <4ACA8495.6080105@sun.com> Message-ID: <4ACB03F1.5010706@sun.com> Joseph D. Darcy wrote: > Hello. > > Please review my changes to address: > > 5062288 "(reflect) Core reflection uses raw types when it could be > using wildcards" > http://cr.openjdk.java.net/~darcy/5062288.0/ > > This changeset removes most of the raw types warnings in core > reflection, java.lang.Class and java.lang.reflect.*. I did not > attempt to remove uses of raw types from ClassLoader and I did not > attempt to make serious changes to Proxy. This changeset does not > affect "exported public" API signatures, only local variables and less > than public exported method signatures and fields. > > Thanks, > > -Joe I took a pass over this and the changes looks good to me. -Alan. From Alan.Bateman at Sun.COM Tue Oct 6 01:56:54 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 06 Oct 2009 09:56:54 +0100 Subject: Review request for 6612680 (Remove classloader dependency on jkernel) In-Reply-To: <4ACA83A8.7040000@sun.com> References: <4AC83AC7.60402@sun.com> <4ACA01A9.6000707@sun.com> <4ACA83A8.7040000@sun.com> Message-ID: <4ACB0656.6050704@sun.com> Mandy Chung wrote: > Alan, R?mi, > > Thanks for the review. The revised webrev is at: > http://cr.openjdk.java.net/~mchung/6612680/jdk-webrev.01/ > http://cr.openjdk.java.net/~mchung/6612680/hotspot-webrev.01/ The changes you pushed to jdk7/tl/jdk look fine - thanks for doing the clean-ups (and for the explanation for the make/sun/jkernel/Makefile change). One other thing I forgot to mention is that System.initializeSystemClasses can be restored - as I recall, that was hacked to workaround issues encountered with the download manager running before the system classes were completely initialized. Minor comment on thread.cpp is that it might be neater if set_jkernel_boot_classloader_hook were: if (k != NULL) { JavaValue result(T_VOID); JavaCalls::call_static( ... ); } Otherwise, good job! -Alan. From Ulf.Zibis at gmx.de Tue Oct 6 02:48:05 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 06 Oct 2009 11:48:05 +0200 Subject: Core review request for 5062288 "(reflect) Core reflection uses raw types when it could be using wildcards" In-Reply-To: <4ACA8495.6080105@sun.com> References: <4ACA8495.6080105@sun.com> Message-ID: <4ACB1255.70600@gmx.de> Please note http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850338 in this context. -Ulf Am 06.10.2009 01:43, Joseph D. Darcy schrieb: > Hello. > > Please review my changes to address: > > 5062288 "(reflect) Core reflection uses raw types when it could be > using wildcards" > http://cr.openjdk.java.net/~darcy/5062288.0/ > > This changeset removes most of the raw types warnings in core > reflection, java.lang.Class and java.lang.reflect.*. I did not > attempt to remove uses of raw types from ClassLoader and I did not > attempt to make serious changes to Proxy. This changeset does not > affect "exported public" API signatures, only local variables and less > than public exported method signatures and fields. > > Thanks, > > -Joe > > From alexdmiller at yahoo.com Tue Oct 6 07:20:51 2009 From: alexdmiller at yahoo.com (Alex Miller) Date: Tue, 6 Oct 2009 07:20:51 -0700 (PDT) Subject: New Methods/Features in JDK7 In-Reply-To: References: Message-ID: <865116.50553.qm@web32201.mail.mud.yahoo.com> Martin points at my page below, which does indeed have a lot of stuff on it, although I must admit I have not been updating it for the last 3-6 months as the actual feature list has solidified. At the moment I'm focusing on putting together the Strange Loop conference (http://thestrangeloop.com - only a few spots left!) but after that, I will get it whipped back into shape. I am still maintaining an ongoing Java 7 link blog at http://java7.tumblr.com and will ultimately feed those links back into the page. Alex On Mon, Oct 5, 2009 at 15:16, Martin Buchholz wrote: > Unofficial: http://tech.puredanger.com/java7 > > On Mon, Oct 5, 2009 at 14:10, Quintin Beukes wrote: > > Hey, > > > > Are there any current listings of new language features/broad API > > changes so far in OpenJDK7. I understand they might not be permanent, > > and could change in a wink, though I'm curious to see what could > > possibly be in the next Java. > > > > Quintin Beukes > > From i30817 at gmail.com Tue Oct 6 09:40:14 2009 From: i30817 at gmail.com (Paulo Levi) Date: Tue, 6 Oct 2009 17:40:14 +0100 Subject: New methods in jdk7 In-Reply-To: <1ccfd1c10910051514y27117fb9ic61e8d2786636c0f@mail.gmail.com> References: <212322090910050649x2c696a47v83346908cc0ce564@mail.gmail.com> <1ccfd1c10910051514y27117fb9ic61e8d2786636c0f@mail.gmail.com> Message-ID: <212322090910060940q20d5de32v7b3778e97eaebfc8@mail.gmail.com> I thought there was the danger of deadlocks if the std.out and std.err wasn't drained? In fact my implementation of "fork" is like this, mostly because i read that otherwise deadlocks happened.: /** * This method creates a new process that will run a new jvm * on the main of the given class, with the selected arguments. * It already flushes the output and inputstream of the forked jvm * into the current jvm. * The forked jvm uses the same java.exe and classpath as the current * one. * @param javaClass class with main method * @param args jvm properties. * @return Process, the jvm process, already started */ public static Process forkJava(Class klass, String... args) throws IOException, InterruptedException { String javaExe = System.getProperty("java.home") + File.separator + "bin" + File.separator + "java"; String classpath = System.getProperty("java.class.path"); List l = new ArrayList(4 + args.length); l.add(javaExe); l.add("-cp"); l.add(classpath); l.addAll(Arrays.asList(args)); l.add(klass.getCanonicalName()); ProcessBuilder pb = new ProcessBuilder(l); pb.redirectErrorStream(true); final Process p = pb.start(); new Thread(new ProcessStreamConsumer(p), "ProcessBuilderInputStreamConsumer").start(); return p; } To be clear, you're saying that if i call this, and allow the parent to be killed (by throwing a Error for instance), the child process lives still? (I believe i can't call System.exit(1) without all jvm dying right?) From joe.darcy at sun.com Tue Oct 6 13:33:58 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Tue, 06 Oct 2009 20:33:58 +0000 Subject: hg: jdk7/tl/jdk: 5062288: (reflect) Core reflection uses raw types when it could be using wildcards Message-ID: <20091006203419.73C5041F63@hg.openjdk.java.net> Changeset: 572791538be5 Author: darcy Date: 2009-10-06 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/572791538be5 5062288: (reflect) Core reflection uses raw types when it could be using wildcards Reviewed-by: alanb ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/sun/reflect/LangReflectAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/annotation/AnnotationType.java From Ulf.Zibis at gmx.de Tue Oct 6 15:09:15 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 07 Oct 2009 00:09:15 +0200 Subject: Request for review: Race conditions in java.nio.charset.Charset Message-ID: <4ACBC00B.9060602@gmx.de> I.) Internal charset cache will be corrupted in theoretical race conditions: Startpoint: cache1 --> Charset1 cache2 --> Charset2 Scenario 1: - Thread1 asks for Charset2 via Charset.forName("Charset2"). - If Thread1 is interrupted after code line: cache2 = cache1 in method lookup2(String charsetName) we have: cache1 --> Charset1 cache2 --> Charset1 > If now thread2 asks for Charset2, it can't find it in cache, so it invokes an expensive lookup via registered providers. Scenario 2: - Thread1 asks for Charset2. - Thread1 is interupted before cache2 = cache1; - If now thread2 asks for Charset2 we have after completing lookup2(): cache1 --> Charset2 cache2 --> Charset1 - Now thread1 resumes; after completing lookup2() we have: cache1 --> Charset2 cache2 --> Charset2 > In the end we can see, that Charset1 is lost in cache. II.) Endless loop, if VM's default charset (called by Charset.defaultCharset()) needs to load mapping data via Class.getResourceAsStream(): - Invoking Class.getResourceAsStream(), again calls for Charset.defaultCharset(), so we are in endless loop. Note: The error condition, described in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795536 is fixed since Bug ID 6797688, but the endless loop, getting the default charset, remains. See my patches here: https://bugs.openjdk.java.net/show_bug.cgi?id=100107 -Ulf From mandy.chung at sun.com Tue Oct 6 15:20:24 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Tue, 06 Oct 2009 22:20:24 +0000 Subject: hg: jdk7/tl/jdk: 6888802: sun.misc.BootClassLoaderHook.getBootstrapPaths stack overflow Message-ID: <20091006222045.BD81141F80@hg.openjdk.java.net> Changeset: 1b81fc851b20 Author: mchung Date: 2009-10-06 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1b81fc851b20 6888802: sun.misc.BootClassLoaderHook.getBootstrapPaths stack overflow Summary: Fixed sun.misc.BootClassLoaderHook.getBootstrapPaths calls hook.getAdditionalBootstrapPaths Reviewed-by: alanb, tbell ! src/share/classes/sun/misc/BootClassLoaderHook.java + test/sun/misc/BootClassLoaderHook/TestHook.java From Joe.Darcy at Sun.COM Tue Oct 6 15:50:34 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 06 Oct 2009 15:50:34 -0700 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AC5805B.3090902@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> <4AC5805B.3090902@sun.com> Message-ID: <4ACBC9BA.6010703@sun.com> Joe Darcy wrote: > Joe Darcy wrote: >> Joe Darcy wrote: >>> Stephen Colebourne wrote: >>>> Joe Darcy wrote: >>>>> What other utility methods would have broad enough use and >>>>> applicability to go into a common java.util class? >>>> >>>> Joe, >>>> You've asked for a call for ideas, but not given any indication of >>>> process. Are you going to evaluate everything that comes in and >>>> pick the best a la Coin? Or allow anyone to send in patches? >>> >>> Those options are not mutually exclusive; patches are welcome >>> subject to the usual terms and conditions. >>> >>>> Who decides what is in and what is out? >>> >>> This is a little side project of mine and I wanted to get some >>> feedback before preparing a formal change for review, possibly >>> including patches from others. >>> >>> -Joe >> >> I'm getting caught up after the JVM Languages Summit and will post >> some java.util.Objects code for review in the near future. >> >> -Joe > > Below is a patch implementing the methods I think should go into > java.util.Objects as a first cut: > > * null safe two-argument equals method > * null safe hashCode(Object) returning 0 for null > * null safe toString(Object), returning "null" for a null argument > * null tolerating compare method; tests if both arguments are == and > if not calls compare > > The need for the last of these in Objects isn't quite as clear. > > Var-arg-ifying some of the existing methods in Arrays, > (hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), > is probably worthwhile but can be done separately. > > I wouldn't oppose a toDebugString(Object) method going into the > platform somewhere, but I don't think it necessarily belongs in Objects. > > Further below is the code for an annotation processor which finds > candidate equals methods to be replaced with Objects.equals. It found > over half a dozen good candidates in the jdk repository. To run the > annotation processor, first compile the class and then run it with > javac similar to this: > > javac -proc:only -processor EqualsFinder -processorpath processor> sources > > -Joe > Updated patch of java.util.Objects with some spec clarifications suggested by Alan Bateman and the use of and reference to String.valueOf(Object) observed by Jason Mehrens. -Joe --- /dev/null 2009-08-12 17:12:33.000000000 -0700 +++ new/src/share/classes/java/util/Objects.java 2009-10-06 15:47:16.000000000 -0700 @@ -0,0 +1,100 @@ +/* + * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Sun designates this + * particular file as subject to the "Classpath" exception as provided + * by Sun in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, + * CA 95054 USA or visit www.sun.com if you need additional information or + * have any questions. + */ + +package java.util; + +/** + * This class consists of {@code static} utility methods for operating + * on objects. + * + * @since 1.7 + */ +public class Objects { + private Objects() { + throw new AssertionError("No java.util.Objects instances for you!"); + } + + /** + * Returns {@code true} if the arguments are equal to each other + * and {@code false} otherwise. + * Consequently, if both arguments are {@code null}, {@code true} + * is returned and if exactly one argument is {@code null}, {@code + * false} is returned. Otherwise, equality is determined by using + * the {@link Object#equals equals} method of the first + * argument. + * + * @return {@code true} if the arguments are equal to each other + * and {@code false} otherwise + * @see Object#equals(Object) + */ + public static boolean equals(Object a, Object b) { + return (a == b) || (a != null && a.equals(b)); + } + + /** + * Returns the hash code of a non-{@code null} argument and 0 for + * a {@code null} argument. + * + * @return the hash code of a non-{@code null} argument and 0 for + * a {@code null} argument + * @see Object#hashCode + */ + public static int hashCode(Object o) { + return o != null ? o.hashCode() : 0; + } + + /** + * Returns the result of calling {@code toString} for a non-{@code + * null} argument and {@code "null"} for a {@code null} argument. + * + * @return the result of calling {@code toString} for a non-{@code + * null} argument and {@code "null"} for a {@code null} argument + * @see Object#toString + * @see String#valueOf(Object) + */ + public static String toString(Object o) { + String.valueOf(o); + } + + /** + * Returns 0 if the arguments are identical and {@code + * c.compare(a, b)} otherwise. + * Consequently, if both arguments are {@code null} 0 + * is returned. + * + *

Note that if one of the argument is {@code null}, a {@code + * NullPointerException} may or may not be thrown depending on + * what ordering policy, if any, the {@link Comparator Comparator} + * chooses to have for {@code null} values. + * + * @return 0 if the arguments are identical and {@code + * c.compare(a, b)} otherwise. + * @see Comparable + * @see Comparator + */ + public static int compare(T a, T b, Comparator c) { + return (a == b) ? 0 : c.compare(a, b); + } +} From David.Holmes at Sun.COM Tue Oct 6 16:07:33 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 07 Oct 2009 09:07:33 +1000 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACBC9BA.6010703@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> <4AC5805B.3090902@sun.com> <4ACBC9BA.6010703@sun.com> Message-ID: <4ACBCDB5.4020803@sun.com> Hi Joe, I thought the point that Jason Mehrens was making was that this: + public static String toString(Object o) { + String.valueOf(o); + } is actually pointless. Why introduce such redundancy when people can just use String.valueOf directly ? This doesn't provide any benefit. PS. It should be "return String.valueOf(o);" of course. David Holmes Joe Darcy said the following on 10/07/09 08:50: > Joe Darcy wrote: >> Joe Darcy wrote: >>> Joe Darcy wrote: >>>> Stephen Colebourne wrote: >>>>> Joe Darcy wrote: >>>>>> What other utility methods would have broad enough use and >>>>>> applicability to go into a common java.util class? >>>>> >>>>> Joe, >>>>> You've asked for a call for ideas, but not given any indication of >>>>> process. Are you going to evaluate everything that comes in and >>>>> pick the best a la Coin? Or allow anyone to send in patches? >>>> >>>> Those options are not mutually exclusive; patches are welcome >>>> subject to the usual terms and conditions. >>>> >>>>> Who decides what is in and what is out? >>>> >>>> This is a little side project of mine and I wanted to get some >>>> feedback before preparing a formal change for review, possibly >>>> including patches from others. >>>> >>>> -Joe >>> >>> I'm getting caught up after the JVM Languages Summit and will post >>> some java.util.Objects code for review in the near future. >>> >>> -Joe >> >> Below is a patch implementing the methods I think should go into >> java.util.Objects as a first cut: >> >> * null safe two-argument equals method >> * null safe hashCode(Object) returning 0 for null >> * null safe toString(Object), returning "null" for a null argument >> * null tolerating compare method; tests if both arguments are == and >> if not calls compare >> >> The need for the last of these in Objects isn't quite as clear. >> >> Var-arg-ifying some of the existing methods in Arrays, >> (hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), >> is probably worthwhile but can be done separately. >> >> I wouldn't oppose a toDebugString(Object) method going into the >> platform somewhere, but I don't think it necessarily belongs in Objects. >> >> Further below is the code for an annotation processor which finds >> candidate equals methods to be replaced with Objects.equals. It found >> over half a dozen good candidates in the jdk repository. To run the >> annotation processor, first compile the class and then run it with >> javac similar to this: >> >> javac -proc:only -processor EqualsFinder -processorpath > processor> sources >> >> -Joe >> > > Updated patch of java.util.Objects with some spec clarifications > suggested by Alan Bateman and the use of and reference to > String.valueOf(Object) observed by Jason Mehrens. > > -Joe > > > --- /dev/null 2009-08-12 17:12:33.000000000 -0700 > +++ new/src/share/classes/java/util/Objects.java 2009-10-06 > 15:47:16.000000000 -0700 > @@ -0,0 +1,100 @@ > +/* > + * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. Sun designates this > + * particular file as subject to the "Classpath" exception as provided > + * by Sun in the LICENSE file that accompanied this code. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa > Clara, > + * CA 95054 USA or visit www.sun.com if you need additional information or > + * have any questions. > + */ > + > +package java.util; > + > +/** > + * This class consists of {@code static} utility methods for operating > + * on objects. > + * > + * @since 1.7 > + */ > +public class Objects { > + private Objects() { > + throw new AssertionError("No java.util.Objects instances for > you!"); > + } > + > + /** > + * Returns {@code true} if the arguments are equal to each other > + * and {@code false} otherwise. > + * Consequently, if both arguments are {@code null}, {@code true} > + * is returned and if exactly one argument is {@code null}, {@code > + * false} is returned. Otherwise, equality is determined by using > + * the {@link Object#equals equals} method of the first > + * argument. > + * > + * @return {@code true} if the arguments are equal to each other > + * and {@code false} otherwise > + * @see Object#equals(Object) > + */ > + public static boolean equals(Object a, Object b) { > + return (a == b) || (a != null && a.equals(b)); > + } > + > + /** > + * Returns the hash code of a non-{@code null} argument and 0 for > + * a {@code null} argument. > + * > + * @return the hash code of a non-{@code null} argument and 0 for > + * a {@code null} argument > + * @see Object#hashCode > + */ > + public static int hashCode(Object o) { > + return o != null ? o.hashCode() : 0; > + } > + > + /** > + * Returns the result of calling {@code toString} for a non-{@code > + * null} argument and {@code "null"} for a {@code null} argument. > + * > + * @return the result of calling {@code toString} for a non-{@code > + * null} argument and {@code "null"} for a {@code null} argument > + * @see Object#toString > + * @see String#valueOf(Object) > + */ > + public static String toString(Object o) { > + String.valueOf(o); > + } > + > + /** > + * Returns 0 if the arguments are identical and {@code > + * c.compare(a, b)} otherwise. > + * Consequently, if both arguments are {@code null} 0 > + * is returned. > + * > + *

Note that if one of the argument is {@code null}, a {@code > + * NullPointerException} may or may not be thrown depending on > + * what ordering policy, if any, the {@link Comparator Comparator} > + * chooses to have for {@code null} values. > + * > + * @return 0 if the arguments are identical and {@code > + * c.compare(a, b)} otherwise. > + * @see Comparable > + * @see Comparator > + */ > + public static int compare(T a, T b, Comparator c) { > + return (a == b) ? 0 : c.compare(a, b); > + } > +} From marquits at marquits.com Tue Oct 6 16:11:25 2009 From: marquits at marquits.com (quitos) Date: Tue, 6 Oct 2009 23:11:25 +0000 (UTC) Subject: Replacement of Quicksort in java.util.Arrays with new =?utf-8?b?RHVhbC1QaXZvdAlRdWlja3NvcnQ=?= References: <4AAA27EA.8090902@Sun.COM> Message-ID: I suppose if the array is small enough, it is better to use simple Quicksort. And the larger the array, the more sense it makes to use more pivots, because the calculation cost of comparing against many pivots becomes more affordable than iterating for a larger subset. So you think the optimal number of pivots to use could be directly linked to the size of the array you're trying to sort? From Joe.Darcy at Sun.COM Tue Oct 6 16:43:53 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 06 Oct 2009 16:43:53 -0700 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACBCDB5.4020803@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> <4AC5805B.3090902@sun.com> <4ACBC9BA.6010703@sun.com> <4ACBCDB5.4020803@sun.com> Message-ID: <4ACBD639.9000305@sun.com> David Holmes - Sun Microsystems wrote: > Hi Joe, > > I thought the point that Jason Mehrens was making was that this: > > + public static String toString(Object o) { > + String.valueOf(o); hat Jason Mehrens was making was that this: > > + public static String toString(Object o) { > + String.valueOf(o); > + } > > is actually pointless. Why introduce > + } > > is actually pointless. Why introduce such redundancy when people can > just use String.valueOf directly ? Because, IMO, String.valueOf is obscure and hard to find and from its name it is not clear it does null-safe toString on the argument. For example, I didn't know about String.valueOf. It is much clearer what Objects.toString is intended to do. > This doesn't provide any benefit. I think having the new method be commonly called would be a benefit :-) I don't think having a one-line forwarding method in Objects is that harmful. > > PS. It should be "return String.valueOf(o);" of course. Fixed. Thanks, -Joe > > David Holmes > > Joe Darcy said the following on 10/07/09 08:50: >> Joe Darcy wrote: >>> Joe Darcy wrote: >>>> Joe Darcy wrote: >>>>> Stephen Colebourne wrote: >>>>>> Joe Darcy wrote: >>>>>>> What other utility methods would have broad enough use and >>>>>>> applicability to go into a common java.util class? >>>>>> >>>>>> Joe, >>>>>> You've asked for a call for ideas, but not given any indication >>>>>> of process. Are you going to evaluate everything that comes in >>>>>> and pick the best a la Coin? Or allow anyone to send in patches? >>>>> >>>>> Those options are not mutually exclusive; patches are welcome >>>>> subject to the usual terms and conditions. >>>>> >>>>>> Who decides what is in and what is out? >>>>> >>>>> This is a little side project of mine and I wanted to get some >>>>> feedback before preparing a formal change for review, possibly >>>>> including patches from others. >>>>> >>>>> -Joe >>>> >>>> I'm getting caught up after the JVM Languages Summit and will post >>>> some java.util.Objects code for review in the near future. >>>> >>>> -Joe >>> >>> Below is a patch implementing the methods I think should go into >>> java.util.Objects as a first cut: >>> >>> * null safe two-argument equals method >>> * null safe hashCode(Object) returning 0 for null >>> * null safe toString(Object), returning "null" for a null argument >>> * null tolerating compare method; tests if both arguments are == and >>> if not calls compare >>> >>> The need for the last of these in Objects isn't quite as clear. >>> >>> Var-arg-ifying some of the existing methods in Arrays, >>> (hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), >>> is probably worthwhile but can be done separately. >>> >>> I wouldn't oppose a toDebugString(Object) method going into the >>> platform somewhere, but I don't think it necessarily belongs in >>> Objects. >>> >>> Further below is the code for an annotation processor which finds >>> candidate equals methods to be replaced with Objects.equals. It >>> found over half a dozen good candidates in the jdk repository. To >>> run the annotation processor, first compile the class and then run >>> it with javac similar to this: >>> >>> javac -proc:only -processor EqualsFinder -processorpath >> processor> sources >>> >>> -Joe >>> >> >> Updated patch of java.util.Objects with some spec clarifications >> suggested by Alan Bateman and the use of and reference to >> String.valueOf(Object) observed by Jason Mehrens. >> >> -Joe >> >> >> --- /dev/null 2009-08-12 17:12:33.000000000 -0700 >> +++ new/src/share/classes/java/util/Objects.java 2009-10-06 >> 15:47:16.000000000 -0700 >> @@ -0,0 +1,100 @@ >> +/* >> + * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. >> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> + * >> + * This code is free software; you can redistribute it and/or modify it >> + * under the terms of the GNU General Public License version 2 only, as >> + * published by the Free Software Foundation. Sun designates this >> + * particular file as subject to the "Classpath" exception as provided >> + * by Sun in the LICENSE file that accompanied this code. >> + * >> + * This code is distributed in the hope that it will be useful, but >> WITHOUT >> + * ANY WARRANTY; without even the implied warranty of >> MERCHANTABILITY or >> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >> License >> + * version 2 for more details (a copy is included in the LICENSE >> file that >> + * accompanied this code). >> + * >> + * You should have received a copy of the GNU General Public License >> version >> + * 2 along with this work; if not, write to the Free Software >> Foundation, >> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> + * >> + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa >> Clara, >> + * CA 95054 USA or visit www.sun.com if you need additional >> information or >> + * have any questions. >> + */ >> + >> +package java.util; >> + >> +/** >> + * This class consists of {@code static} utility methods for operating >> + * on objects. >> + * >> + * @since 1.7 >> + */ >> +public class Objects { >> + private Objects() { >> + throw new AssertionError("No java.util.Objects instances for >> you!"); >> + } >> + >> + /** >> + * Returns {@code true} if the arguments are equal to each other >> + * and {@code false} otherwise. >> + * Consequently, if both arguments are {@code null}, {@code true} >> + * is returned and if exactly one argument is {@code null}, {@code >> + * false} is returned. Otherwise, equality is determined by using >> + * the {@link Object#equals equals} method of the first >> + * argument. >> + * >> + * @return {@code true} if the arguments are equal to each other >> + * and {@code false} otherwise >> + * @see Object#equals(Object) >> + */ >> + public static boolean equals(Object a, Object b) { >> + return (a == b) || (a != null && a.equals(b)); >> + } >> + >> + /** >> + * Returns the hash code of a non-{@code null} argument and 0 for >> + * a {@code null} argument. >> + * >> + * @return the hash code of a non-{@code null} argument and 0 for >> + * a {@code null} argument >> + * @see Object#hashCode >> + */ >> + public static int hashCode(Object o) { >> + return o != null ? o.hashCode() : 0; >> + } >> + >> + /** >> + * Returns the result of calling {@code toString} for a non-{@code >> + * null} argument and {@code "null"} for a {@code null} argument. >> + * >> + * @return the result of calling {@code toString} for a non-{@code >> + * null} argument and {@code "null"} for a {@code null} argument >> + * @see Object#toString >> + * @see String#valueOf(Object) >> + */ >> + public static String toString(Object o) { >> + String.valueOf(o); >> + } >> + >> + /** >> + * Returns 0 if the arguments are identical and {@code >> + * c.compare(a, b)} otherwise. >> + * Consequently, if both arguments are {@code null} 0 >> + * is returned. >> + * >> + *

Note that if one of the argument is {@code null}, a {@code >> + * NullPointerException} may or may not be thrown depending on >> + * what ordering policy, if any, the {@link Comparator Comparator} >> + * chooses to have for {@code null} values. >> + * >> + * @return 0 if the arguments are identical and {@code >> + * c.compare(a, b)} otherwise. >> + * @see Comparable >> + * @see Comparator >> + */ >> + public static int compare(T a, T b, Comparator c) { >> + return (a == b) ? 0 : c.compare(a, b); >> + } >> +} From david.lloyd at redhat.com Tue Oct 6 16:49:23 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 06 Oct 2009 18:49:23 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACBD639.9000305@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> <4AC5805B.3090902@sun.com> <4ACBC9BA.6010703@sun.com> <4ACBCDB5.4020803@sun.com> <4ACBD639.9000305@sun.com> Message-ID: <4ACBD783.4030406@redhat.com> On 10/06/2009 06:43 PM, Joe Darcy wrote: > David Holmes - Sun Microsystems wrote: >> Hi Joe, >> >> I thought the point that Jason Mehrens was making was that this: >> >> + public static String toString(Object o) { >> + String.valueOf(o); hat Jason Mehrens was making was that this: >> >> + public static String toString(Object o) { >> + String.valueOf(o); >> + } >> >> is actually pointless. Why introduce >> + } >> >> is actually pointless. Why introduce such redundancy when people can >> just use String.valueOf directly ? > > Because, IMO, String.valueOf is obscure and hard to find and from its > name it is not clear it does null-safe toString on the argument. For > example, I didn't know about String.valueOf. It is much clearer what > Objects.toString is intended to do. I for one never thought of it as obscure. Isn't this one of the static methods one must know before taking the SCJP exam? I'm sure it was one of the first methods I learned, back in the day. >> This doesn't provide any benefit. > > I think having the new method be commonly called would be a benefit :-) > > I don't think having a one-line forwarding method in Objects is that > harmful. Redundancy can be harmful in fact. Now you've got two ways to do the exact same thing; it just makes it a little harder for people to develop and adhere to coding standards, to give one example. - DML From i30817 at gmail.com Tue Oct 6 19:17:26 2009 From: i30817 at gmail.com (Paulo Levi) Date: Wed, 7 Oct 2009 03:17:26 +0100 Subject: Adding methods to logger in jdk 7 Message-ID: <212322090910061917j160312a1k7e4691116192f962@mail.gmail.com> Logger has the utility method severe, warning etc so you can use the various log levels without using the longer log method... I'd like some more overloadings, for adding a throwable, besides a string for those methods. Logger.getLogger(getClass().getName()).severe(string, throwable); From David.Holmes at Sun.COM Tue Oct 6 20:14:18 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 07 Oct 2009 13:14:18 +1000 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACBD639.9000305@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> <4AC5805B.3090902@sun.com> <4ACBC9BA.6010703@sun.com> <4ACBCDB5.4020803@sun.com> <4ACBD639.9000305@sun.com> Message-ID: <4ACC078A.6030008@sun.com> Joe, Joe Darcy said the following on 10/07/09 09:43: > David Holmes - Sun Microsystems wrote: >> I thought the point that Jason Mehrens was making was that this: >> >> + public static String toString(Object o) { >> + String.valueOf(o); hat Jason Mehrens was making was that this: >> >> + public static String toString(Object o) { >> + String.valueOf(o); >> + } >> >> is actually pointless. Why introduce >> + } >> >> is actually pointless. Why introduce such redundancy when people can >> just use String.valueOf directly ? > > Because, IMO, String.valueOf is obscure and hard to find and from its > name it is not clear it does null-safe toString on the argument. For > example, I didn't know about String.valueOf. It is much clearer what > Objects.toString is intended to do. It is no more obscure or hard to find than any method one is unaware of. But if you look at any of a number of introductory Java texts - such as The Java Programming Language for example - you will find that valueOf is given good coverage along with the other members of the String class. Further, as David Lloyd points out, there is a strong convention that Type.valueOf(x) converts x to Type - so the Java programmer should be quite familiar with this concept. I agree the null behaviour is not evident from the name, but nor is it evident from the name toString either - in both cases you must initially check the specification of the method to know what it does. >> This doesn't provide any benefit. > > I think having the new method be commonly called would be a benefit :-) No more so than having String.valueOf commonly called. > I don't think having a one-line forwarding method in Objects is that > harmful. It is redundant and adds no value. It creates potential confusion because people will wonder why on earth you have two methods that do the exact same thing. (And it's a PITA for authors because it is yet another additional API they have to mention. ;-) ) Just my opinion of course. David ----- >> >> PS. It should be "return String.valueOf(o);" of course. > > Fixed. > > Thanks, > > -Joe > >> >> David Holmes >> >> Joe Darcy said the following on 10/07/09 08:50: >>> Joe Darcy wrote: >>>> Joe Darcy wrote: >>>>> Joe Darcy wrote: >>>>>> Stephen Colebourne wrote: >>>>>>> Joe Darcy wrote: >>>>>>>> What other utility methods would have broad enough use and >>>>>>>> applicability to go into a common java.util class? >>>>>>> >>>>>>> Joe, >>>>>>> You've asked for a call for ideas, but not given any indication >>>>>>> of process. Are you going to evaluate everything that comes in >>>>>>> and pick the best a la Coin? Or allow anyone to send in patches? >>>>>> >>>>>> Those options are not mutually exclusive; patches are welcome >>>>>> subject to the usual terms and conditions. >>>>>> >>>>>>> Who decides what is in and what is out? >>>>>> >>>>>> This is a little side project of mine and I wanted to get some >>>>>> feedback before preparing a formal change for review, possibly >>>>>> including patches from others. >>>>>> >>>>>> -Joe >>>>> >>>>> I'm getting caught up after the JVM Languages Summit and will post >>>>> some java.util.Objects code for review in the near future. >>>>> >>>>> -Joe >>>> >>>> Below is a patch implementing the methods I think should go into >>>> java.util.Objects as a first cut: >>>> >>>> * null safe two-argument equals method >>>> * null safe hashCode(Object) returning 0 for null >>>> * null safe toString(Object), returning "null" for a null argument >>>> * null tolerating compare method; tests if both arguments are == and >>>> if not calls compare >>>> >>>> The need for the last of these in Objects isn't quite as clear. >>>> >>>> Var-arg-ifying some of the existing methods in Arrays, >>>> (hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), >>>> is probably worthwhile but can be done separately. >>>> >>>> I wouldn't oppose a toDebugString(Object) method going into the >>>> platform somewhere, but I don't think it necessarily belongs in >>>> Objects. >>>> >>>> Further below is the code for an annotation processor which finds >>>> candidate equals methods to be replaced with Objects.equals. It >>>> found over half a dozen good candidates in the jdk repository. To >>>> run the annotation processor, first compile the class and then run >>>> it with javac similar to this: >>>> >>>> javac -proc:only -processor EqualsFinder -processorpath >>> processor> sources >>>> >>>> -Joe >>>> >>> >>> Updated patch of java.util.Objects with some spec clarifications >>> suggested by Alan Bateman and the use of and reference to >>> String.valueOf(Object) observed by Jason Mehrens. >>> >>> -Joe >>> >>> >>> --- /dev/null 2009-08-12 17:12:33.000000000 -0700 >>> +++ new/src/share/classes/java/util/Objects.java 2009-10-06 >>> 15:47:16.000000000 -0700 >>> @@ -0,0 +1,100 @@ >>> +/* >>> + * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. >>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> + * >>> + * This code is free software; you can redistribute it and/or modify it >>> + * under the terms of the GNU General Public License version 2 only, as >>> + * published by the Free Software Foundation. Sun designates this >>> + * particular file as subject to the "Classpath" exception as provided >>> + * by Sun in the LICENSE file that accompanied this code. >>> + * >>> + * This code is distributed in the hope that it will be useful, but >>> WITHOUT >>> + * ANY WARRANTY; without even the implied warranty of >>> MERCHANTABILITY or >>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>> License >>> + * version 2 for more details (a copy is included in the LICENSE >>> file that >>> + * accompanied this code). >>> + * >>> + * You should have received a copy of the GNU General Public License >>> version >>> + * 2 along with this work; if not, write to the Free Software >>> Foundation, >>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>> + * >>> + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa >>> Clara, >>> + * CA 95054 USA or visit www.sun.com if you need additional >>> information or >>> + * have any questions. >>> + */ >>> + >>> +package java.util; >>> + >>> +/** >>> + * This class consists of {@code static} utility methods for operating >>> + * on objects. >>> + * >>> + * @since 1.7 >>> + */ >>> +public class Objects { >>> + private Objects() { >>> + throw new AssertionError("No java.util.Objects instances for >>> you!"); >>> + } >>> + >>> + /** >>> + * Returns {@code true} if the arguments are equal to each other >>> + * and {@code false} otherwise. >>> + * Consequently, if both arguments are {@code null}, {@code true} >>> + * is returned and if exactly one argument is {@code null}, {@code >>> + * false} is returned. Otherwise, equality is determined by using >>> + * the {@link Object#equals equals} method of the first >>> + * argument. >>> + * >>> + * @return {@code true} if the arguments are equal to each other >>> + * and {@code false} otherwise >>> + * @see Object#equals(Object) >>> + */ >>> + public static boolean equals(Object a, Object b) { >>> + return (a == b) || (a != null && a.equals(b)); >>> + } >>> + >>> + /** >>> + * Returns the hash code of a non-{@code null} argument and 0 for >>> + * a {@code null} argument. >>> + * >>> + * @return the hash code of a non-{@code null} argument and 0 for >>> + * a {@code null} argument >>> + * @see Object#hashCode >>> + */ >>> + public static int hashCode(Object o) { >>> + return o != null ? o.hashCode() : 0; >>> + } >>> + >>> + /** >>> + * Returns the result of calling {@code toString} for a non-{@code >>> + * null} argument and {@code "null"} for a {@code null} argument. >>> + * >>> + * @return the result of calling {@code toString} for a non-{@code >>> + * null} argument and {@code "null"} for a {@code null} argument >>> + * @see Object#toString >>> + * @see String#valueOf(Object) >>> + */ >>> + public static String toString(Object o) { >>> + String.valueOf(o); >>> + } >>> + >>> + /** >>> + * Returns 0 if the arguments are identical and {@code >>> + * c.compare(a, b)} otherwise. >>> + * Consequently, if both arguments are {@code null} 0 >>> + * is returned. >>> + * >>> + *

Note that if one of the argument is {@code null}, a {@code >>> + * NullPointerException} may or may not be thrown depending on >>> + * what ordering policy, if any, the {@link Comparator Comparator} >>> + * chooses to have for {@code null} values. >>> + * >>> + * @return 0 if the arguments are identical and {@code >>> + * c.compare(a, b)} otherwise. >>> + * @see Comparable >>> + * @see Comparator >>> + */ >>> + public static int compare(T a, T b, Comparator c) { >>> + return (a == b) ? 0 : c.compare(a, b); >>> + } >>> +} > From martinrb at google.com Tue Oct 6 21:33:21 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 6 Oct 2009 21:33:21 -0700 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACC078A.6030008@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> <4AC5805B.3090902@sun.com> <4ACBC9BA.6010703@sun.com> <4ACBCDB5.4020803@sun.com> <4ACBD639.9000305@sun.com> <4ACC078A.6030008@sun.com> Message-ID: <1ccfd1c10910062133i50435c6ci6639deae585c3789@mail.gmail.com> I also vote against Objects.toString(). Foo.valueOf might not be the best name, (I'll resist the urge to suggest a better one) but it is an entrenched convention, and so cannot be considered a wart to be fixed. Martin On Tue, Oct 6, 2009 at 20:14, David Holmes - Sun Microsystems wrote: > Joe, > > Joe Darcy said the following on 10/07/09 09:43: >> >> David Holmes - Sun Microsystems wrote: >>> >>> I thought the point that Jason Mehrens was making was that this: >>> >>> + ? ?public static String toString(Object o) { >>> + ? ? ? ?String.valueOf(o); hat Jason Mehrens was making was that this: >>> >>> + ? ?public static String toString(Object o) { >>> + ? ? ? ?String.valueOf(o); >>> + ? ?} >>> >>> is actually pointless. Why introduce >>> + ? ?} >>> >>> is actually pointless. Why introduce such redundancy when people can just >>> use String.valueOf directly ? >> >> Because, IMO, String.valueOf is obscure and hard to find and from its name >> it is not clear it does null-safe toString on the argument. ?For example, I >> didn't know about String.valueOf. ?It is much clearer what Objects.toString >> is intended to do. > > It is no more obscure or hard to find than any method one is unaware of. But > if you look at any of a number of introductory Java texts - such as The Java > Programming Language for example - you will find that valueOf is given good > coverage along with the other members of the String class. Further, as David > Lloyd points out, there is a strong convention that Type.valueOf(x) converts > x to Type - so the Java programmer should be quite familiar with this > concept. > > I agree the null behaviour is not evident from the name, but nor is it > evident from the name toString either - in both cases you must initially > check the specification of the method to know what it does. > >>> This doesn't provide any benefit. >> >> I think having the new method be commonly called would be a benefit :-) > > No more so than having String.valueOf commonly called. > >> I don't think having a one-line forwarding method in Objects is that >> harmful. > > It is redundant and adds no value. It creates potential confusion because > people will wonder why on earth you have two methods that do the exact same > thing. (And it's a PITA for authors because it is yet another additional API > they have to mention. ;-) ) > > Just my opinion of course. > > David > ----- >>> >>> PS. It should be "return String.valueOf(o);" of course. >> >> Fixed. >> >> Thanks, >> >> -Joe >> >>> >>> David Holmes >>> >>> Joe Darcy said the following on 10/07/09 08:50: >>>> >>>> Joe Darcy wrote: >>>>> >>>>> Joe Darcy wrote: >>>>>> >>>>>> Joe Darcy wrote: >>>>>>> >>>>>>> Stephen Colebourne wrote: >>>>>>>> >>>>>>>> Joe Darcy wrote: >>>>>>>>> >>>>>>>>> What other utility methods would have broad enough use and >>>>>>>>> applicability to go into a common java.util class? >>>>>>>> >>>>>>>> Joe, >>>>>>>> You've asked for a call for ideas, but not given any indication of >>>>>>>> process. Are you going to evaluate everything that comes in and pick the >>>>>>>> best a la Coin? Or allow anyone to send in patches? >>>>>>> >>>>>>> Those options are not mutually exclusive; patches are welcome subject >>>>>>> to the usual terms and conditions. >>>>>>> >>>>>>>> Who decides what is in and what is out? >>>>>>> >>>>>>> This is a little side project of mine and I wanted to get some >>>>>>> feedback before preparing a formal change for review, possibly including >>>>>>> patches from others. >>>>>>> >>>>>>> -Joe >>>>>> >>>>>> I'm getting caught up after the JVM Languages Summit and will post >>>>>> some java.util.Objects code for review in the near future. >>>>>> >>>>>> -Joe >>>>> >>>>> Below is a patch implementing the methods I think should go into >>>>> java.util.Objects as a first cut: >>>>> >>>>> * null safe two-argument equals method >>>>> * null safe hashCode(Object) returning 0 for null >>>>> * null safe toString(Object), returning "null" for a null argument >>>>> * null tolerating compare method; tests if both arguments are == and if >>>>> not calls compare >>>>> >>>>> The need for the last of these in Objects isn't quite as clear. >>>>> >>>>> Var-arg-ifying some of the existing methods in Arrays, >>>>> (hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), is >>>>> probably worthwhile but can be done separately. >>>>> >>>>> I wouldn't oppose a toDebugString(Object) method going into the >>>>> platform somewhere, but I don't think it necessarily belongs in Objects. >>>>> >>>>> Further below is the code for an annotation processor which finds >>>>> candidate equals methods to be replaced with Objects.equals. ?It found over >>>>> half a dozen good candidates in the jdk repository. ?To run the annotation >>>>> processor, first compile the class and then run it with javac similar to >>>>> this: >>>>> >>>>> javac -proc:only -processor EqualsFinder -processorpath >>>> processor> sources >>>>> >>>>> -Joe >>>>> >>>> >>>> Updated patch of java.util.Objects with some spec clarifications >>>> suggested by Alan Bateman and the use of and reference to >>>> String.valueOf(Object) observed by Jason Mehrens. >>>> >>>> -Joe >>>> >>>> >>>> --- /dev/null ? ?2009-08-12 17:12:33.000000000 -0700 >>>> +++ new/src/share/classes/java/util/Objects.java ? ?2009-10-06 >>>> 15:47:16.000000000 -0700 >>>> @@ -0,0 +1,100 @@ >>>> +/* >>>> + * Copyright 2009 Sun Microsystems, Inc. ?All Rights Reserved. >>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> + * >>>> + * This code is free software; you can redistribute it and/or modify it >>>> + * under the terms of the GNU General Public License version 2 only, as >>>> + * published by the Free Software Foundation. ?Sun designates this >>>> + * particular file as subject to the "Classpath" exception as provided >>>> + * by Sun in the LICENSE file that accompanied this code. >>>> + * >>>> + * This code is distributed in the hope that it will be useful, but >>>> WITHOUT >>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY >>>> or >>>> + * FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU General Public >>>> License >>>> + * version 2 for more details (a copy is included in the LICENSE file >>>> that >>>> + * accompanied this code). >>>> + * >>>> + * You should have received a copy of the GNU General Public License >>>> version >>>> + * 2 along with this work; if not, write to the Free Software >>>> Foundation, >>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>> + * >>>> + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa >>>> Clara, >>>> + * CA 95054 USA or visit www.sun.com if you need additional information >>>> or >>>> + * have any questions. >>>> + */ >>>> + >>>> +package java.util; >>>> + >>>> +/** >>>> + * This class consists of {@code static} utility methods for operating >>>> + * on objects. >>>> + * >>>> + * @since 1.7 >>>> + */ >>>> +public class Objects { >>>> + ? ?private Objects() { >>>> + ? ? ? ?throw new AssertionError("No java.util.Objects instances for >>>> you!"); >>>> + ? ?} >>>> + >>>> + ? ?/** >>>> + ? ? * Returns {@code true} if the arguments are equal to each other >>>> + ? ? * and {@code false} otherwise. >>>> + ? ? * Consequently, if both arguments are {@code null}, {@code true} >>>> + ? ? * is returned and if exactly one argument is {@code null}, {@code >>>> + ? ? * false} is returned. ?Otherwise, equality is determined by using >>>> + ? ? * the {@link Object#equals equals} method of the first >>>> + ? ? * argument. >>>> + ? ? * >>>> + ? ? * @return {@code true} if the arguments are equal to each other >>>> + ? ? * and {@code false} otherwise >>>> + ? ? * @see Object#equals(Object) >>>> + ? ? */ >>>> + ? ?public static boolean equals(Object a, Object b) { >>>> + ? ? ? ?return (a == b) || (a != null && a.equals(b)); >>>> + ? ?} >>>> + >>>> + ? ?/** >>>> + ? ? * Returns the hash code of a non-{@code null} argument and 0 for >>>> + ? ? * a {@code null} argument. >>>> + ? ? * >>>> + ? ? * @return the hash code of a non-{@code null} argument and 0 for >>>> + ? ? * a {@code null} argument >>>> + ? ? * @see Object#hashCode >>>> + ? ? */ >>>> + ? ?public static int hashCode(Object o) { >>>> + ? ? ? ?return o != null ? o.hashCode() : 0; >>>> + ? ?} >>>> + >>>> + ? ?/** >>>> + ? ? * Returns the result of calling {@code toString} for a non-{@code >>>> + ? ? * null} argument and {@code "null"} for a {@code null} argument. >>>> + ? ? * >>>> + ? ? * @return the result of calling {@code toString} for a non-{@code >>>> + ? ? * null} argument and {@code "null"} for a {@code null} argument >>>> + ? ? * @see Object#toString >>>> + ? ? * @see String#valueOf(Object) >>>> + ? ? */ >>>> + ? ?public static String toString(Object o) { >>>> + ? ? ? ?String.valueOf(o); >>>> + ? ?} >>>> + >>>> + ? ?/** >>>> + ? ? * Returns 0 if the arguments are identical and {@code >>>> + ? ? * c.compare(a, b)} otherwise. >>>> + ? ? * Consequently, if both arguments are {@code null} 0 >>>> + ? ? * is returned. >>>> + ? ? * >>>> + ? ? *

Note that if one of the argument is {@code null}, a {@code >>>> + ? ? * NullPointerException} may or may not be thrown depending on >>>> + ? ? * what ordering policy, if any, the {@link Comparator Comparator} >>>> + ? ? * chooses to have for {@code null} values. >>>> + ? ? * >>>> + ? ? * @return 0 if the arguments are identical and {@code >>>> + ? ? * c.compare(a, b)} otherwise. >>>> + ? ? * @see Comparable >>>> + ? ? * @see Comparator >>>> + ? ? */ >>>> + ? ?public static int compare(T a, T b, Comparator c) { >>>> + ? ? ? ?return (a == b) ? 0 : ?c.compare(a, b); >>>> + ? ?} >>>> +} >> > From pbenedict at apache.org Tue Oct 6 21:44:26 2009 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Oct 2009 23:44:26 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? Message-ID: If you want Objects.toString() to provide value, consider mimicking the functionality from Apache Commons: http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html My biggest complaint about String.valueOf(Object) is that it will actually return "null" for null objects. I can't stand that. If I have no data, I don't want any printable data back. While my preference might be too narrow for the JDK, the second overloaded version of ObjectUtils#toString(String, String) seems like a winner to me. Allow a default String to be provided when it is null: public static String toString(Object o, String defaultStr) { return (o != null) ? : String.valueOf(o) : defaultStr; } Paul From David.Holmes at Sun.COM Tue Oct 6 21:56:35 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 07 Oct 2009 14:56:35 +1000 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: References: Message-ID: <4ACC1F83.4090304@sun.com> Paul, Paul Benedict said the following on 10/07/09 14:44: > If you want Objects.toString() to provide value, consider mimicking > the functionality from Apache Commons: > > http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html > > My biggest complaint about String.valueOf(Object) is that it will > actually return "null" for null objects. I can't stand that. If I have > no data, I don't want any printable data back. While my preference > might be too narrow for the JDK, the second overloaded version of > ObjectUtils#toString(String, String) seems like a winner to me. Allow > a default String to be provided when it is null: I can see this might be useful ... > public static String toString(Object o, String defaultStr) { > return (o != null) ? : String.valueOf(o) : defaultStr; > } but the implementation would just need to be: return o != null ? o.toString() : defaultStr; Cheers, David > > Paul From pbenedict at apache.org Tue Oct 6 22:52:49 2009 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 7 Oct 2009 00:52:49 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACC1F83.4090304@sun.com> References: <4ACC1F83.4090304@sun.com> Message-ID: Thanks Dave. You are exactly right. That implementation is better. On Tue, Oct 6, 2009 at 11:56 PM, David Holmes - Sun Microsystems wrote: > Paul, > > Paul Benedict said the following on 10/07/09 14:44: >> >> If you want Objects.toString() to provide value, consider mimicking >> the functionality from Apache Commons: >> >> >> http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html >> >> My biggest complaint about String.valueOf(Object) is that it will >> actually return "null" for null objects. I can't stand that. If I have >> no data, I don't want any printable data back. While my preference >> might be too narrow for the JDK, the second overloaded version of >> ObjectUtils#toString(String, String) seems like a winner to me. Allow >> a default String to be provided when it is null: > > I can see this might be useful ... > >> public static String toString(Object o, String defaultStr) { >> ? ?return (o != null) ? String.valueOf(o) : defaultStr; >> } > > but the implementation would just need to be: > > ? ? ?return o != null ? o.toString() : defaultStr; > > Cheers, > David From martinrb at google.com Tue Oct 6 23:55:46 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 6 Oct 2009 23:55:46 -0700 Subject: New methods in jdk7 In-Reply-To: <212322090910060940q20d5de32v7b3778e97eaebfc8@mail.gmail.com> References: <212322090910050649x2c696a47v83346908cc0ce564@mail.gmail.com> <1ccfd1c10910051514y27117fb9ic61e8d2786636c0f@mail.gmail.com> <212322090910060940q20d5de32v7b3778e97eaebfc8@mail.gmail.com> Message-ID: <1ccfd1c10910062355w1defe30ew153ec61b5ba933c2@mail.gmail.com> On Tue, Oct 6, 2009 at 09:40, Paulo Levi wrote: > I thought there was the danger of deadlocks if the std.out and std.err > wasn't drained? Well, yes, there is a danger of deadlocks, but this can be avoided by: - having separate threads read stdout and stderr - closing the various streams in the parent (but might cause child to exit) - using redirectErrorStream - using new redirection facilities in jdk7 http://download.java.net/jdk7/docs/api/java/lang/ProcessBuilder.html > To be clear, you're saying that if i call this, and allow the parent > to be killed (by throwing a Error for instance), the child process > lives still? (I believe i can't call System.exit(1) without all jvm > dying right?) Why not try it? System.exit should only cause one jdk to exit directly. Martin From keith.mcguigan at sun.com Wed Oct 7 00:03:57 2009 From: keith.mcguigan at sun.com (keith.mcguigan at sun.com) Date: Wed, 07 Oct 2009 07:03:57 +0000 Subject: hg: jdk7/tl/jdk: 6885916: Memory leak in inferencing verifier (libverify.so) Message-ID: <20091007070416.D9D0A412B3@hg.openjdk.java.net> Changeset: f69b40e43bff Author: kamg Date: 2009-10-06 22:01 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f69b40e43bff 6885916: Memory leak in inferencing verifier (libverify.so) Summary: Use the memory management already present to track allocated memory Reviewed-by: coleenp, acorn ! src/share/native/common/check_code.c From scolebourne at joda.org Wed Oct 7 01:10:19 2009 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 07 Oct 2009 09:10:19 +0100 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: References: Message-ID: <4ACC4CEB.8080209@joda.org> Paul Benedict wrote: > If you want Objects.toString() to provide value, consider mimicking > the functionality from Apache Commons: > > http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html > > My biggest complaint about String.valueOf(Object) is that it will > actually return "null" for null objects. I can't stand that. If I have > no data, I don't want any printable data back. While my preference > might be too narrow for the JDK, the second overloaded version of > ObjectUtils#toString(String, String) seems like a winner to me. Allow > a default String to be provided when it is null: > > public static String toString(Object o, String defaultStr) { > return (o != null) ? : String.valueOf(o) : defaultStr; > } I agree that this variant should be on Objects. To me, that strongly implies that the variant without the second argument should also be there (and yes, I'd prefer it to return "" instead of "null" for null). BTW, I don't accept the argument that one and only one way to do something is part of the JDK. In key places there are multiple options. NIO Path vs File and Calendar vs Date are examples. (Most code is written using IDEs these days, so having a predictable place to start from for autocomplete is important. Hence having equals/hashCode/compare but not toString would be very unintuitive to the Objects API). Stephen From David.Holmes at Sun.COM Wed Oct 7 01:51:40 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 07 Oct 2009 18:51:40 +1000 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACC4CEB.8080209@joda.org> References: <4ACC4CEB.8080209@joda.org> Message-ID: <4ACC569C.4020007@sun.com> Stephen Colebourne said the following on 10/07/09 18:10: > BTW, I don't accept the argument that one and only one way to do > something is part of the JDK. While the JDK is far from a model example of providing "one way" to do something, that doesn't mean we should gratuitously add superfluous and redundant functionality. Type.valueOf is an established pattern for converting types. The JDK is already severely bloated - new APIs should pay their own way. David From Ulf.Zibis at gmx.de Wed Oct 7 03:44:19 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 07 Oct 2009 12:44:19 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACBD639.9000305@sun.com> References: <4AA812D0.309@sun.com> <4AA9936B.5000006@joda.org> <4AAADC6B.7070807@sun.com> <4AB989B7.5030101@sun.com> <4AC5805B.3090902@sun.com> <4ACBC9BA.6010703@sun.com> <4ACBCDB5.4020803@sun.com> <4ACBD639.9000305@sun.com> Message-ID: <4ACC7103.4090207@gmx.de> Am 07.10.2009 01:43, Joe Darcy schrieb: > > I don't think having a one-line forwarding method in Objects is that > harmful. > On the other hand Character.MAX_SUPPLEMENTARY_CODE_POINT was rejected for JDK footprint reason. -Ulf From forax at univ-mlv.fr Wed Oct 7 05:37:58 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 07 Oct 2009 14:37:58 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACC4CEB.8080209@joda.org> References: <4ACC4CEB.8080209@joda.org> Message-ID: <4ACC8BA6.10008@univ-mlv.fr> Stephen Colebourne a ?crit : > Paul Benedict wrote: >> If you want Objects.toString() to provide value, consider mimicking >> the functionality from Apache Commons: >> >> http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html >> >> >> My biggest complaint about String.valueOf(Object) is that it will >> actually return "null" for null objects. I can't stand that. If I have >> no data, I don't want any printable data back. While my preference >> might be too narrow for the JDK, the second overloaded version of >> ObjectUtils#toString(String, String) seems like a winner to me. Allow >> a default String to be provided when it is null: >> >> public static String toString(Object o, String defaultStr) { >> return (o != null) ? : String.valueOf(o) : defaultStr; >> } > Hi Stephen, [...] > In key places there are multiple options. NIO Path vs File and > Calendar vs Date are examples. As you know, Path (resp. Calendar) is just an attempt to correct the mess introduced by File (resp. Date). So yes, there is duplication but this duplication is done to correct a wrong design. > (Most code is written using IDEs these days, so having a predictable > place to start from for autocomplete is important. Hence having > equals/hashCode/compare but not toString would be very unintuitive to > the Objects API). > > Stephen R?mi From jason_mehrens at hotmail.com Wed Oct 7 09:17:20 2009 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 7 Oct 2009 11:17:20 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACC8BA6.10008@univ-mlv.fr> References: <4ACC4CEB.8080209@joda.org> <4ACC8BA6.10008@univ-mlv.fr> Message-ID: > Hi Stephen, > > [...] > > In key places there are multiple options. NIO Path vs File and > > Calendar vs Date are examples. > > As you know, Path (resp. Calendar) is just an attempt to correct the > mess introduced by File (resp. Date). > So yes, there is duplication but this duplication is done to correct a > wrong design. > > > (Most code is written using IDEs these days, so having a predictable > > place to start from for autocomplete is important. Hence having > > equals/hashCode/compare but not toString would be very unintuitive to > > the Objects API). > > > > Stephen > R?mi The 2 toString variants from ObjectUtils are very handy to have for displaying values for UIs. Perhaps those should be added to Objects to correct a wrong design (limited use) of returning "null" for null and would least provide new behavior. Seems like the way to go unless these are going to cause more harm (confusion) than good. Jason _________________________________________________________________ Hotmail: Trusted email with Microsoft?s powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141664/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091007/02be0b62/attachment.html From christopher.hegarty at sun.com Wed Oct 7 09:24:02 2009 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Wed, 07 Oct 2009 16:24:02 +0000 Subject: hg: jdk7/tl/jdk: 6887364: SetOutgoingIf.java fails if run on multihomed machine without PIv6 on all interfaces Message-ID: <20091007162439.885B3413F5@hg.openjdk.java.net> Changeset: f864c15f6779 Author: chegar Date: 2009-10-07 17:23 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f864c15f6779 6887364: SetOutgoingIf.java fails if run on multihomed machine without PIv6 on all interfaces Reviewed-by: alanb ! test/java/net/MulticastSocket/SetOutgoingIf.java From Joe.Darcy at Sun.COM Wed Oct 7 10:25:48 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 07 Oct 2009 10:25:48 -0700 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACC569C.4020007@sun.com> References: <4ACC4CEB.8080209@joda.org> <4ACC569C.4020007@sun.com> Message-ID: <4ACCCF1C.20401@sun.com> David Holmes - Sun Microsystems wrote: > Stephen Colebourne said the following on 10/07/09 18:10: >> BTW, I don't accept the argument that one and only one way to do >> something is part of the JDK. > > While the JDK is far from a model example of providing "one way" to do > something, that doesn't mean we should gratuitously add superfluous > and redundant functionality. The JDK has a long history of providing convenience methods. For example, we have PrintStream.format and PrintStream.printf which are just two names for the same functionality. > Type.valueOf is an established pattern for converting types. > > The JDK is already severely bloated - new APIs should pay their own way. Getting rid of more than half a dozen implementations of equals(Object, Object) should just in the JDK should more than pay the for the entire Objects class ;-) -Joe From pbenedict at apache.org Wed Oct 7 10:50:48 2009 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 7 Oct 2009 12:50:48 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: References: Message-ID: Joe, Here are a few more resources that you may want to investigate for java.util.Objects: * http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Objects.html * http://static.springsource.org/spring/docs/3.0.0.M4/javadoc-api/org/springframework/util/ObjectUtils.html * http://commons.apache.org/lang/api-release/org/apache/commons/lang/ObjectUtils.html * http://hc.apache.org/httpcomponents-core/httpcore/apidocs/org/apache/http/util/LangUtils.html Paul From Xueming.Shen at Sun.COM Wed Oct 7 10:56:17 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Wed, 07 Oct 2009 10:56:17 -0700 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACBC00B.9060602@gmx.de> References: <4ACBC00B.9060602@gmx.de> Message-ID: <4ACCD641.5080809@sun.com> Ulf, Though I did not write the cache code my reading suggests the existing cache impl tries to avoid the relatively "expensive" synchronization for most use scenarios, your approach however hits the synchronization for each/every lookup invocation. So you should at least consider to put the sync block in a separate lookup2. But personally I doubt we really care this "race condition", it's a cache, a cache miss is not a disaster, in fact in most cases, since the charset has been in the cache already, it should be in the providers' "cache" as well, especially for the bundled standard & extended charset provider, the lookup actually is 1 or 2 O(1) hashmap lookup (yes, an additional name canonicalization and the "expensive" sync). So maybe we can do something like b = cache1; cache1 = a; cache2 = b; to make the situation a little better, or maybe worse:-) sherman sherman Ulf Zibis wrote: > I.) Internal charset cache will be corrupted in theoretical race > conditions: > > Startpoint: > cache1 --> Charset1 > cache2 --> Charset2 > > Scenario 1: > - Thread1 asks for Charset2 via Charset.forName("Charset2"). > - If Thread1 is interrupted after code line: cache2 = cache1 > in method lookup2(String charsetName) we have: > cache1 --> Charset1 > cache2 --> Charset1 >> If now thread2 asks for Charset2, it can't find it in cache, so it >> invokes > an expensive lookup via registered providers. > > Scenario 2: > - Thread1 asks for Charset2. > - Thread1 is interupted before cache2 = cache1; > - If now thread2 asks for Charset2 we have after completing lookup2(): > cache1 --> Charset2 > cache2 --> Charset1 > - Now thread1 resumes; after completing lookup2() we have: > cache1 --> Charset2 > cache2 --> Charset2 >> In the end we can see, that Charset1 is lost in cache. > > > II.) Endless loop, if VM's default charset (called by > Charset.defaultCharset()) > needs to load mapping data via Class.getResourceAsStream(): > > - Invoking Class.getResourceAsStream(), again calls for > Charset.defaultCharset(), > so we are in endless loop. > > Note: The error condition, described in > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795536 > is fixed since Bug ID 6797688, but the endless loop, getting the > default charset, remains. > > > See my patches here: https://bugs.openjdk.java.net/show_bug.cgi?id=100107 > > > -Ulf > > > From Ulf.Zibis at gmx.de Wed Oct 7 12:55:03 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 07 Oct 2009 21:55:03 +0200 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACCD641.5080809@sun.com> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> Message-ID: <4ACCF217.6000303@gmx.de> Sherman, thanks for your review ... Am 07.10.2009 19:56, Xueming Shen schrieb: > Though I did not write the cache code my reading suggests the existing > cache > impl tries to avoid the relatively "expensive" synchronization for > most use scenarios, > your approach however hits the synchronization for each/every lookup > invocation. > So you should at least consider to put the sync block in a separate > lookup2. Agreed: (But why separate lookup2? I suspect that Charset.forName() would occur in excessive loops, so hotspot potentially cold inline it.) private static Charset lookup(String charsetName) { if (charsetName == null) throw new IllegalArgumentException("Null charset name"); CacheItem ci = cache[0]; if (ci != null && charsetName.equals(ci.name)) return ci.charset; synchronized (Charset.class) { int pos; for (pos=1; ; pos++) { ... } } Is synchronization more expensive, than instantiating new Object[] each time + 2 castings (to String + to Charset)? > > But personally I doubt we really care this "race condition", it's a > cache, a cache miss > is not a disaster, OK, but why didn't you you reject Bug Id 6881442 with the same argumentation. ... and missing the class's name in Class.name could only happen once, in contrast to "my" race condition, which theoretically could happen every time. > in fact in most cases, since the charset has been in the cache > already, it should be in the providers' "cache" as well, especially > for the bundled > standard & extended charset provider, the lookup actually is 1 or 2 > O(1) hashmap > lookup ... it's 2 hashmap lookup, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850361 + 2 hashmap lookup for extended charset + 2n cost if in supplemental provider > (yes, an additional name canonicalization and the "expensive" sync). + check extendedProviderProbed + synchronize latter + resolve SoftReference (in fail: + hashmap lookup for class name + reflective instantiation + caching) > > So maybe we can do something like > > b = cache1; > cache1 = a; > cache2 = b; Hm, if content of cache1 was updated to content, which is hold in a by other thread, saving cache1in b doesn't help. (Maybe I didn't understand your trick.) > > to make the situation a little better, or maybe worse:-) > And what do you think about breaking the endless loop, while getting the default charset, and what about avoiding to cache wrong default charset? -Ulf From Joe.Darcy at Sun.COM Wed Oct 7 13:27:58 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 07 Oct 2009 13:27:58 -0700 Subject: Code review request: bugs 6480728 and 6655735 in the wrapper classes Message-ID: <4ACCF9CE.1060706@sun.com> Hello. Please review these simple cleanup fixes in the wrapper classes: 6480728: Byte.valueOf(byte) returns a cached value but Byte.valueOf(String) 6655735: Integer.toString() and String.valueOf(int) contain slow delegations The fix for the first bug is for the valueOf(String) and decode methods in Byte and Short to return objects after going through the cache. This behavior is already present in Integer and Long. The second fix changes method calls in various wrapper classes and in String to go to the Foo -> String method most directly implementing the desired conversion Patch is below; webrev at http://cr.openjdk.java.net/~darcy/6480728.0/ -Joe --- old/src/share/classes/java/lang/Byte.java 2009-10-07 12:18:04.000000000 -0700 +++ new/src/share/classes/java/lang/Byte.java 2009-10-07 12:18:03.000000000 -0700 @@ -201,7 +201,7 @@ */ public static Byte valueOf(String s, int radix) throws NumberFormatException { - return new Byte(parseByte(s, radix)); + return valueOf(parseByte(s, radix)); } /** @@ -277,7 +277,7 @@ if (i < MIN_VALUE || i > MAX_VALUE) throw new NumberFormatException( "Value " + i + " out of range from input " + nm); - return (byte)i; + return valueOf((byte)i); } /** @@ -374,7 +374,7 @@ * base 10. */ public String toString() { - return String.valueOf((int)value); + return Integer.toString((int)value); } /** --- old/src/share/classes/java/lang/Double.java 2009-10-07 12:18:04.000000000 -0700 +++ new/src/share/classes/java/lang/Double.java 2009-10-07 12:18:04.000000000 -0700 @@ -629,7 +629,7 @@ * @see java.lang.Double#toString(double) */ public String toString() { - return String.valueOf(value); + return toString(value); } /** --- old/src/share/classes/java/lang/Float.java 2009-10-07 12:18:05.000000000 -0700 +++ new/src/share/classes/java/lang/Float.java 2009-10-07 12:18:05.000000000 -0700 @@ -551,7 +551,7 @@ * @see java.lang.Float#toString(float) */ public String toString() { - return String.valueOf(value); + return Float.toString(value); } /** --- old/src/share/classes/java/lang/Integer.java 2009-10-07 12:18:06.000000000 -0700 +++ new/src/share/classes/java/lang/Integer.java 2009-10-07 12:18:06.000000000 -0700 @@ -746,7 +746,7 @@ * base 10. */ public String toString() { - return String.valueOf(value); + return toString(value); } /** --- old/src/share/classes/java/lang/Long.java 2009-10-07 12:18:07.000000000 -0700 +++ new/src/share/classes/java/lang/Long.java 2009-10-07 12:18:07.000000000 -0700 @@ -761,7 +761,7 @@ * base 10. */ public String toString() { - return String.valueOf(value); + return toString(value); } /** --- old/src/share/classes/java/lang/Short.java 2009-10-07 12:18:08.000000000 -0700 +++ new/src/share/classes/java/lang/Short.java 2009-10-07 12:18:07.000000000 -0700 @@ -170,7 +170,7 @@ */ public static Short valueOf(String s, int radix) throws NumberFormatException { - return new Short(parseShort(s, radix)); + return valueOf(parseShort(s, radix)); } /** @@ -282,7 +282,7 @@ if (i < MIN_VALUE || i > MAX_VALUE) throw new NumberFormatException( "Value " + i + " out of range from input " + nm); - return (short)i; + return valueOf((short)i); } /** @@ -379,7 +379,7 @@ * base 10. */ public String toString() { - return String.valueOf((int)value); + return Integer.toString((int)value); } /** --- old/src/share/classes/java/lang/String.java 2009-10-07 12:18:08.000000000 -0700 +++ new/src/share/classes/java/lang/String.java 2009-10-07 12:18:08.000000000 -0700 @@ -2995,7 +2995,7 @@ * @see java.lang.Integer#toString(int, int) */ public static String valueOf(int i) { - return Integer.toString(i, 10); + return Integer.toString(i); } /** @@ -3009,7 +3009,7 @@ * @see java.lang.Long#toString(long) */ public static String valueOf(long l) { - return Long.toString(l, 10); + return Long.toString(l); } /** From tim.bell at sun.com Wed Oct 7 13:54:33 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Wed, 07 Oct 2009 20:54:33 +0000 Subject: hg: jdk7/tl/jdk: 6888888: new javah throws NullPointerException when building in jdk/make/java/nio Message-ID: <20091007205501.6F3D241440@hg.openjdk.java.net> Changeset: 777714bd992a Author: tbell Date: 2009-10-07 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/777714bd992a 6888888: new javah throws NullPointerException when building in jdk/make/java/nio Summary: Use the bootstrap javah during the build until bug-ID 6889255 is fixed Reviewed-by: jjg ! make/common/shared/Defs-java.gmk From Lance.Andersen at Sun.COM Wed Oct 7 13:58:59 2009 From: Lance.Andersen at Sun.COM (Lance J. Andersen) Date: Wed, 07 Oct 2009 16:58:59 -0400 Subject: Code review request: bugs 6480728 and 6655735 in the wrapper classes In-Reply-To: <4ACCF9CE.1060706@sun.com> References: <4ACCF9CE.1060706@sun.com> Message-ID: <4ACD0113.4020705@sun.com> Joe, These look ok to me -lance Joseph D. Darcy wrote: > Hello. > > Please review these simple cleanup fixes in the wrapper classes: > > 6480728: Byte.valueOf(byte) returns a cached value but > Byte.valueOf(String) > 6655735: Integer.toString() and String.valueOf(int) contain slow > delegations > > The fix for the first bug is for the valueOf(String) and decode > methods in Byte and Short to return objects after going through the > cache. This behavior is already present in Integer and Long. > > The second fix changes method calls in various wrapper classes and in > String to go to the Foo -> String method most directly implementing > the desired conversion > > Patch is below; webrev at > http://cr.openjdk.java.net/~darcy/6480728.0/ > > -Joe > > --- old/src/share/classes/java/lang/Byte.java 2009-10-07 > 12:18:04.000000000 -0700 > +++ new/src/share/classes/java/lang/Byte.java 2009-10-07 > 12:18:03.000000000 -0700 > @@ -201,7 +201,7 @@ > */ > public static Byte valueOf(String s, int radix) > throws NumberFormatException { > - return new Byte(parseByte(s, radix)); > + return valueOf(parseByte(s, radix)); > } > > /** > @@ -277,7 +277,7 @@ > if (i < MIN_VALUE || i > MAX_VALUE) > throw new NumberFormatException( > "Value " + i + " out of range from input " + nm); > - return (byte)i; > + return valueOf((byte)i); > } > > /** > @@ -374,7 +374,7 @@ > * base 10. > */ > public String toString() { > - return String.valueOf((int)value); > + return Integer.toString((int)value); > } > > /** > --- old/src/share/classes/java/lang/Double.java 2009-10-07 > 12:18:04.000000000 -0700 > +++ new/src/share/classes/java/lang/Double.java 2009-10-07 > 12:18:04.000000000 -0700 > @@ -629,7 +629,7 @@ > * @see java.lang.Double#toString(double) > */ > public String toString() { > - return String.valueOf(value); > + return toString(value); > } > > /** > --- old/src/share/classes/java/lang/Float.java 2009-10-07 > 12:18:05.000000000 -0700 > +++ new/src/share/classes/java/lang/Float.java 2009-10-07 > 12:18:05.000000000 -0700 > @@ -551,7 +551,7 @@ > * @see java.lang.Float#toString(float) > */ > public String toString() { > - return String.valueOf(value); > + return Float.toString(value); > } > > /** > --- old/src/share/classes/java/lang/Integer.java 2009-10-07 > 12:18:06.000000000 -0700 > +++ new/src/share/classes/java/lang/Integer.java 2009-10-07 > 12:18:06.000000000 -0700 > @@ -746,7 +746,7 @@ > * base 10. > */ > public String toString() { > - return String.valueOf(value); > + return toString(value); > } > > /** > --- old/src/share/classes/java/lang/Long.java 2009-10-07 > 12:18:07.000000000 -0700 > +++ new/src/share/classes/java/lang/Long.java 2009-10-07 > 12:18:07.000000000 -0700 > @@ -761,7 +761,7 @@ > * base 10. > */ > public String toString() { > - return String.valueOf(value); > + return toString(value); > } > > /** > --- old/src/share/classes/java/lang/Short.java 2009-10-07 > 12:18:08.000000000 -0700 > +++ new/src/share/classes/java/lang/Short.java 2009-10-07 > 12:18:07.000000000 -0700 > @@ -170,7 +170,7 @@ > */ > public static Short valueOf(String s, int radix) > throws NumberFormatException { > - return new Short(parseShort(s, radix)); > + return valueOf(parseShort(s, radix)); > } > > /** > @@ -282,7 +282,7 @@ > if (i < MIN_VALUE || i > MAX_VALUE) > throw new NumberFormatException( > "Value " + i + " out of range from input " + nm); > - return (short)i; > + return valueOf((short)i); > } > > /** > @@ -379,7 +379,7 @@ > * base 10. > */ > public String toString() { > - return String.valueOf((int)value); > + return Integer.toString((int)value); > } > > /** > --- old/src/share/classes/java/lang/String.java 2009-10-07 > 12:18:08.000000000 -0700 > +++ new/src/share/classes/java/lang/String.java 2009-10-07 > 12:18:08.000000000 -0700 > @@ -2995,7 +2995,7 @@ > * @see java.lang.Integer#toString(int, int) > */ > public static String valueOf(int i) { > - return Integer.toString(i, 10); > + return Integer.toString(i); > } > > /** > @@ -3009,7 +3009,7 @@ > * @see java.lang.Long#toString(long) > */ > public static String valueOf(long l) { > - return Long.toString(l, 10); > + return Long.toString(l); > } > > /** > From Xueming.Shen at Sun.COM Wed Oct 7 14:01:42 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Wed, 07 Oct 2009 14:01:42 -0700 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACCF217.6000303@gmx.de> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> Message-ID: <4ACD01B6.5030607@sun.com> Ulf Zibis wrote: > Sherman, thanks for your review ... > > Am 07.10.2009 19:56, Xueming Shen schrieb: >> Though I did not write the cache code my reading suggests the >> existing cache >> impl tries to avoid the relatively "expensive" synchronization for >> most use scenarios, >> your approach however hits the synchronization for each/every lookup >> invocation. >> So you should at least consider to put the sync block in a separate >> lookup2. > > Agreed: > (But why separate lookup2? I suspect that Charset.forName() would > occur in excessive loops, so hotspot potentially cold inline it.) Maybe I meant to say "to put the sync in a separate block" > > Is synchronization more expensive, than instantiating new Object[] > each time + 2 castings (to String + to Charset)? > The difference is fast cpu + a good gc probably can make "instantiating new Object[] each time + 2 castings" trivial, but a synchronization only allows one thread run into the code block and keeps anyone else outside waiting till the first done. >> >> But personally I doubt we really care this "race condition", it's a >> cache, a cache miss >> is not a disaster, > > OK, but why didn't you you reject Bug Id 6881442 with the same > argumentation. > ... and missing the class's name in Class.name could only happen once, > in contrast to "my" race condition, which theoretically could happen > every time. The difference is that race condition may cause a wrong result, In this case the result is still correct though it might come out at a relatively slow speed should the race condition occur. sherman From joe.darcy at sun.com Wed Oct 7 14:06:23 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Wed, 07 Oct 2009 21:06:23 +0000 Subject: hg: jdk7/tl/jdk: 6480728: Byte.valueOf(byte) returns a cached value but Byte.valueOf(String); ... Message-ID: <20091007210649.2EAC641446@hg.openjdk.java.net> Changeset: e7ad502130ba Author: darcy Date: 2009-10-07 14:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e7ad502130ba 6480728: Byte.valueOf(byte) returns a cached value but Byte.valueOf(String) 6655735: Integer.toString() and String.valueOf(int) contain slow delegations Reviewed-by: lancea ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java From martinrb at google.com Wed Oct 7 15:01:59 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Oct 2009 15:01:59 -0700 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACD01B6.5030607@sun.com> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> Message-ID: <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> IIRC correctly, I am the author of the hacky 2-element charset cache. Certainly improvements can be made, but it's hard to balance memory usage vs. the cost and complexity of writing a good cache. I agree with Sherman that a race in the cache itself is not a bug (or at best, a performance bug). I don't think it's worth a point fix here unless an actual wrong result can be demonstrated. I do think a more sophisticated charset cache would be good, but hard to get right. Martin On Wed, Oct 7, 2009 at 14:01, Xueming Shen wrote: > Ulf Zibis wrote: >> >> Sherman, thanks for your review ... >> >> Am 07.10.2009 19:56, Xueming Shen schrieb: >>> >>> Though I did not write the cache code my reading suggests the existing >>> cache >>> impl tries to avoid the relatively "expensive" synchronization for most >>> use scenarios, >>> your approach however hits the synchronization for each/every lookup >>> invocation. >>> So you should at least consider to put the sync block in a separate >>> lookup2. >> >> Agreed: >> (But why separate lookup2? I suspect that Charset.forName() would occur in >> excessive loops, so hotspot potentially cold inline it.) > > Maybe I meant to say "to put the sync in a separate block" > >> >> Is synchronization more expensive, than instantiating new Object[] each >> time + 2 castings (to String + to Charset)? >> > > The difference is fast cpu + a good gc probably can make "instantiating new > Object[] each time + 2 castings" trivial, > but a synchronization only allows one thread run into the code block and > keeps anyone else outside waiting till the > first done. > >>> >>> But personally I doubt we really care this "race condition", it's a >>> cache, a cache miss >>> is not a disaster, >> >> OK, but why didn't you you reject Bug Id 6881442 with the same >> argumentation. >> ... and missing the class's name in Class.name could only happen once, in >> contrast to "my" race condition, which theoretically could happen every >> time. > > The difference is that race condition may cause a wrong result, In this case > the result is still correct though it > might come out at a relatively slow speed should the race condition occur. > > > sherman > From Ulf.Zibis at gmx.de Wed Oct 7 15:58:41 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 08 Oct 2009 00:58:41 +0200 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> Message-ID: <4ACD1D21.4000805@gmx.de> Martin, thank for your review. Am 08.10.2009 00:01, Martin Buchholz schrieb: > IIRC correctly, I am the author of the hacky 2-element charset cache. > Certainly improvements can be made, but it's hard to balance > memory usage vs. the cost and complexity of writing a good cache. > I guess, the memory usage of 2-element class CharsetItem is equivalent to 2-element Object[]. > I agree with Sherman that a race in the cache itself is not a bug > (or at best, a performance bug). > For my better understanding: Can you explain me the real bug in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442. In my understanding, loading the "name" field twice is too only a performance bug. Please correct me! > I don't think it's worth a point fix here unless an actual wrong result > can be demonstrated. I do think a more sophisticated charset cache > would be good, but hard to get right. > The other point is the size of the cache, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795535. I have logged the usage of the Charset.lookup() method from a simple test which has only called ISO-8859-1 and IBM037 . As you can see, UTF-8 and cp1252 (default encoding on German Windows) is frequently requested from the VM, so IMO size 2 is too restrictive (note the different aliases UTF-8, utf-8 and UTF8): UTF-8 utf-8 UTF-8 Cp1252 UTF-8 UTF-8 UTF-8 UTF-8 UTF-8 UTF-8 UTF8 UTF8 Cp1252 Cp1252 Cp1252 Cp1252 Cp1252 Cp1252 Cp1252 Cp1252 Cp1252 Cp1252 Cp1252 Cp1252 UTF-8 IBM037 UTF-8 UTF-8 utf-8 ISO-8859-1 UTF-8 -Ulf From martinrb at google.com Wed Oct 7 21:31:19 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Oct 2009 21:31:19 -0700 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACD1D21.4000805@gmx.de> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> <4ACD1D21.4000805@gmx.de> Message-ID: <1ccfd1c10910072131o3be89ee0lb00537ed39cc1665@mail.gmail.com> On Wed, Oct 7, 2009 at 15:58, Ulf Zibis wrote: > For my better understanding: > Can you explain me the real bug in > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442. > In my understanding, loading the "name" field twice is too only a > performance bug. Please correct me! Take a look at the discussion on 6881442 in the core-libs-dev archives. It *is* a performance improvement, but it's not a very big one (at least on x86) and that is not its primary purpose. Martin From David.Holmes at Sun.COM Wed Oct 7 21:35:40 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 08 Oct 2009 14:35:40 +1000 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACD1D21.4000805@gmx.de> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> <4ACD1D21.4000805@gmx.de> Message-ID: <4ACD6C1C.5020506@sun.com> Ulf, Ulf Zibis said the following on 10/08/09 08:58: > For my better understanding: > Can you explain me the real bug in > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442. > In my understanding, loading the "name" field twice is too only a > performance bug. Please correct me! Class.getName() could in theory return null and this is not allowed, hence this was a functional correctness issue. There are a few benevolent data-races in the JDK libs. I haven't looked at the Charset code so can't comment on whether or not it is benevolent. David Holmes >> I don't think it's worth a point fix here unless an actual wrong result >> can be demonstrated. I do think a more sophisticated charset cache >> would be good, but hard to get right. >> > > The other point is the size of the cache, see > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795535. > I have logged the usage of the Charset.lookup() method from a simple > test which has only called ISO-8859-1 and IBM037 . As you can see, UTF-8 > and cp1252 (default encoding on German Windows) is frequently requested > from the VM, so IMO size 2 is too restrictive (note the different > aliases UTF-8, utf-8 and UTF8): > UTF-8 > utf-8 > UTF-8 > Cp1252 > UTF-8 > UTF-8 > UTF-8 > UTF-8 > UTF-8 > UTF-8 > UTF8 > UTF8 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > UTF-8 > IBM037 > UTF-8 > UTF-8 > utf-8 > ISO-8859-1 > UTF-8 > > > -Ulf > > From martinrb at google.com Wed Oct 7 21:40:39 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Oct 2009 21:40:39 -0700 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACD1D21.4000805@gmx.de> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> <4ACD1D21.4000805@gmx.de> Message-ID: <1ccfd1c10910072140j737d99a3ha2a6324b81db1fdd@mail.gmail.com> If you can show that a simple test program that appears to access only 2 charsets in fact causes accesses to 3 or 4, that is a serious problem with the 2-element cache. People at Google are working on better caches, but I don't think they are quite ready today. Perhaps, instead of a small charset cache, we could cache all the charsets, but for the large charsets like GB18030, we could, inside the charset implementation, cache the large data tables using a soft reference, and recompute as needed. Then most of the static memory used by an unused charset could be reclaimed. In general, high quality caching is hard, much harder than it looks. Martin On Wed, Oct 7, 2009 at 15:58, Ulf Zibis wrote: >> I don't think it's worth a point fix here unless an actual wrong result >> can be demonstrated. ?I do think a more sophisticated charset cache >> would be good, but hard to get right. >> > > The other point is the size of the cache, see > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795535. > I have logged the usage of the Charset.lookup() method from a simple test > which has only called ISO-8859-1 and IBM037 . As you can see, UTF-8 and > cp1252 (default encoding on German Windows) is frequently requested from the > VM, so IMO size 2 is too restrictive (note the different aliases UTF-8, > utf-8 and UTF8): > UTF-8 > utf-8 > UTF-8 > Cp1252 > UTF-8 > UTF-8 > UTF-8 > UTF-8 > UTF-8 > UTF-8 > UTF8 > UTF8 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > Cp1252 > UTF-8 > IBM037 > UTF-8 > UTF-8 > utf-8 > ISO-8859-1 > UTF-8 > > > -Ulf > > > From David.Holmes at Sun.COM Thu Oct 8 03:59:54 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 08 Oct 2009 20:59:54 +1000 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACDB9E5.6090202@gmx.de> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> <4ACD1D21.4000805@gmx.de> <4ACD6C1C.5020506@sun.com> <4ACDB9E5.6090202@gmx.de> Message-ID: <4ACDC62A.4020608@sun.com> Hi Ulf, Ulf Zibis said the following on 10/08/09 20:07: > Am 08.10.2009 06:35, David Holmes - Sun Microsystems schrieb: >> Ulf Zibis said the following on 10/08/09 08:58: >>> For my better understanding: >>> Can you explain me the real bug in >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442. >>> In my understanding, loading the "name" field twice is too only a >>> performance bug. Please correct me! >> >> Class.getName() could in theory return null and this is not allowed, >> hence this was a functional correctness issue. > > Hm, my problem is, I can't see any condition, how Class.getName() could > return null, except native method getName0() would return null. > But if native getName0() could return null, I can't see how the new code > would prevent method Class.getName() from returning null. It's a memory model issue. The code is like this: public String getName() { if (name == null) name = getName0(); return name; } but in theory, accoridng to the JMM experts, it could act as if it does this: public String getName() { String tmp1 = name; // sees null String tmp2 = name; // sees non-null if (tmp2 == null) tmp1 = name = getName0(); return tmp1; } imagine the temporaries are registers. David From Ulf.Zibis at gmx.de Thu Oct 8 03:07:33 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 08 Oct 2009 12:07:33 +0200 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACD6C1C.5020506@sun.com> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> <4ACD1D21.4000805@gmx.de> <4ACD6C1C.5020506@sun.com> Message-ID: <4ACDB9E5.6090202@gmx.de> Am 08.10.2009 06:35, David Holmes - Sun Microsystems schrieb: > Ulf, > > Ulf Zibis said the following on 10/08/09 08:58: >> For my better understanding: >> Can you explain me the real bug in >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442. >> In my understanding, loading the "name" field twice is too only a >> performance bug. Please correct me! > > Class.getName() could in theory return null and this is not allowed, > hence this was a functional correctness issue. Hm, my problem is, I can't see any condition, how Class.getName() could return null, except native method getName0() would return null. But if native getName0() could return null, I can't see how the new code would prevent method Class.getName() from returning null. -Ulf From Ulf.Zibis at gmx.de Thu Oct 8 04:58:55 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 08 Oct 2009 13:58:55 +0200 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACDC62A.4020608@sun.com> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> <4ACD1D21.4000805@gmx.de> <4ACD6C1C.5020506@sun.com> <4ACDB9E5.6090202@gmx.de> <4ACDC62A.4020608@sun.com> Message-ID: <4ACDD3FF.7060106@gmx.de> Am 08.10.2009 12:59, David Holmes - Sun Microsystems schrieb: > Hi Ulf, > > It's a memory model issue. The code is like this: > > public String getName() { > if (name == null) > name = getName0(); > return name; > } > > but in theory, accoridng to the JMM experts, it could act as if it > does this: > > public String getName() { > String tmp1 = name; // sees null > String tmp2 = name; // sees non-null > if (tmp2 == null) > tmp1 = name = getName0(); > return tmp1; > } > > imagine the temporaries are registers. Oops, java programming is not simple as it looks like. Can you give me a link, where I can read more about that subject / JMM? David, thanks for your explicit explanation. -Ulf From scolebourne at joda.org Thu Oct 8 03:47:49 2009 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 8 Oct 2009 11:47:49 +0100 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] Message-ID: <4b4f45e00910080347h9ae22c3m1b50ef30f834c301@mail.gmail.com> A number of us are proposing that Objects.toString(obj) should return "" when the object is null. I'm strongly in favour of this, and it removes any discussion of duplicated API (as it does something different and more useful). In favour/against +1/-1 ? Stephen 2009/10/7 Joseph D. Darcy : > David Holmes - Sun Microsystems wrote: >> >> Stephen Colebourne said the following on 10/07/09 18:10: >>> >>> BTW, I don't accept the argument that one and only one way to do >>> something is part of the JDK. >> >> While the JDK is far from a model example of providing "one way" to do >> something, that doesn't mean we should gratuitously add superfluous and >> redundant functionality. > > The JDK has a long history of providing convenience methods. ?For example, > we have PrintStream.format and PrintStream.printf which are just two names > for the same functionality. > >> Type.valueOf is an established pattern for converting types. >> >> The JDK is already severely bloated - new APIs should pay their own way. > > Getting rid of more than half a dozen implementations of equals(Object, > Object) should just in the JDK should more than pay the for the entire > Objects class ;-) > > -Joe > > From Ulf.Zibis at gmx.de Thu Oct 8 09:36:54 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 08 Oct 2009 18:36:54 +0200 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: <4b4f45e00910080347h9ae22c3m1b50ef30f834c301@mail.gmail.com> References: <4b4f45e00910080347h9ae22c3m1b50ef30f834c301@mail.gmail.com> Message-ID: <4ACE1526.1000800@gmx.de> +1 or drop Objects.toString(obj) completely. -Ulf Am 08.10.2009 12:47, Stephen Colebourne schrieb: > A number of us are proposing that Objects.toString(obj) should return > "" when the object is null. I'm strongly in favour of this, and it > removes any discussion of duplicated API (as it does something > different and more useful). > > In favour/against +1/-1 ? > > Stephen > > 2009/10/7 Joseph D. Darcy : > >> David Holmes - Sun Microsystems wrote: >> >>> Stephen Colebourne said the following on 10/07/09 18:10: >>> >>>> BTW, I don't accept the argument that one and only one way to do >>>> something is part of the JDK. >>>> >>> While the JDK is far from a model example of providing "one way" to do >>> something, that doesn't mean we should gratuitously add superfluous and >>> redundant functionality. >>> >> The JDK has a long history of providing convenience methods. For example, >> we have PrintStream.format and PrintStream.printf which are just two names >> for the same functionality. >> >> >>> Type.valueOf is an established pattern for converting types. >>> >>> The JDK is already severely bloated - new APIs should pay their own way. >>> >> Getting rid of more than half a dozen implementations of equals(Object, >> Object) should just in the JDK should more than pay the for the entire >> Objects class ;-) >> >> -Joe >> >> >> > > > From pbenedict at apache.org Thu Oct 8 10:04:35 2009 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 8 Oct 2009 12:04:35 -0500 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] Message-ID: +1 for me. +1 also for having the overloaded version that can accept a fallback string. Paul From jason_mehrens at hotmail.com Thu Oct 8 10:10:09 2009 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 8 Oct 2009 12:10:09 -0500 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: <4b4f45e00910080347h9ae22c3m1b50ef30f834c301@mail.gmail.com> References: <4b4f45e00910080347h9ae22c3m1b50ef30f834c301@mail.gmail.com> Message-ID: +1, return empty string for the one arg and add the two arg variant. The j.u.Properties.getProperty(String, String) could use it first. Just curious, what does project jigsaw think of j.u.Objects? Jason > Date: Thu, 8 Oct 2009 11:47:49 +0100 > Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] > From: scolebourne at joda.org > To: core-libs-dev at openjdk.java.net > > A number of us are proposing that Objects.toString(obj) should return > "" when the object is null. I'm strongly in favour of this, and it > removes any discussion of duplicated API (as it does something > different and more useful). > > In favour/against +1/-1 ? > > Stephen _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/171222986/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091008/bde8ae07/attachment.html From Joe.Darcy at Sun.COM Thu Oct 8 10:51:50 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 08 Oct 2009 10:51:50 -0700 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: References: <4b4f45e00910080347h9ae22c3m1b50ef30f834c301@mail.gmail.com> Message-ID: <4ACE26B6.7040709@sun.com> Jason Mehrens wrote: > +1, return empty string for the one arg and add the two arg > variant. The j.u.Properties.getProperty(String, String) could use it > first. Just curious, what does project jigsaw think of j.u.Objects? I'm preparing the first round of java.util.Objects with the single-argument static toString method return "null" for null for final review. I'll send out a few follow-up emails, including one for additional toStrings methods. I'm sympathetic to the two-argument toString method with a default. Project Jigsaw is about modularity so I don't see what connection there is between Jigsaw and j.u.Objects. -Joe > > Jason > > > > Date: Thu, 8 Oct 2009 11:47:49 +0100 > > Subject: Objects.toString [Re: What methods should go into a > java.util.Objects class in JDK 7?] > > From: scolebourne at joda.org > > To: core-libs-dev at openjdk.java.net > > > > A number of us are proposing that Objects.toString(obj) should return > > "" when the object is null. I'm strongly in favour of this, and it > > removes any discussion of duplicated API (as it does something > > different and more useful). > > > > In favour/against +1/-1 ? > > > > Stephen > > > > ------------------------------------------------------------------------ > Hotmail: Powerful Free email with security by Microsoft. Get it now. > From Joe.Darcy at Sun.COM Thu Oct 8 11:10:01 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 08 Oct 2009 11:10:01 -0700 Subject: First round of java.util.Objects for code review (bug 6797535) Message-ID: <4ACE2AF9.4070104@sun.com> Hello. Please code review the first-round of java.util.Objects; the patch is below: http://cr.openjdk.java.net/~darcy/6797535.0/ -Joe --- old/make/java/java/FILES_java.gmk 2009-10-08 11:04:03.000000000 -0700 +++ new/make/java/java/FILES_java.gmk 2009-10-08 11:04:02.000000000 -0700 @@ -258,6 +258,7 @@ java/util/ServiceConfigurationError.java \ java/util/Timer.java \ java/util/TimerTask.java \ + java/util/Objects.java \ java/util/UUID.java \ java/util/concurrent/AbstractExecutorService.java \ java/util/concurrent/ArrayBlockingQueue.java \ --- /dev/null 2009-07-06 20:02:10.000000000 -0700 +++ new/src/share/classes/java/util/Objects.java 2009-10-08 11:04:03.000000000 -0700 @@ -0,0 +1,102 @@ +/* + * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Sun designates this + * particular file as subject to the "Classpath" exception as provided + * by Sun in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, + * CA 95054 USA or visit www.sun.com if you need additional information or + * have any questions. + */ + +package java.util; + +/** + * This class consists of {@code static} utility methods for operating + * on objects. These utilities include {@code null}-safe or {@code + * null}-tolerant methods for computing the hash code of an object, + * returning a string for an object, and comparing two objects. + * + * @since 1.7 + */ +public class Objects { + private Objects() { + throw new AssertionError("No java.util.Objects instances for you!"); + } + + /** + * Returns {@code true} if the arguments are equal to each other + * and {@code false} otherwise. + * Consequently, if both arguments are {@code null}, {@code true} + * is returned and if exactly one argument is {@code null}, {@code + * false} is returned. Otherwise, equality is determined by using + * the {@link Object#equals equals} method of the first + * argument. + * + * @return {@code true} if the arguments are equal to each other + * and {@code false} otherwise + * @see Object#equals(Object) + */ + public static boolean equals(Object a, Object b) { + return (a == b) || (a != null && a.equals(b)); + } + + /** + * Returns the hash code of a non-{@code null} argument and 0 for + * a {@code null} argument. + * + * @return the hash code of a non-{@code null} argument and 0 for + * a {@code null} argument + * @see Object#hashCode + */ + public static int hashCode(Object o) { + return o != null ? o.hashCode() : 0; + } + + /** + * Returns the result of calling {@code toString} for a non-{@code + * null} argument and {@code "null"} for a {@code null} argument. + * + * @return the result of calling {@code toString} for a non-{@code + * null} argument and {@code "null"} for a {@code null} argument + * @see Object#toString + * @see String#valueOf(Object) + */ + public static String toString(Object o) { + return String.valueOf(o); + } + + /** + * Returns 0 if the arguments are identical and {@code + * c.compare(a, b)} otherwise. + * Consequently, if both arguments are {@code null} 0 + * is returned. + * + *

Note that if one of the arguments is {@code null}, a {@code + * NullPointerException} may or may not be thrown depending on + * what ordering policy, if any, the {@link Comparator Comparator} + * chooses to have for {@code null} values. + * + * @return 0 if the arguments are identical and {@code + * c.compare(a, b)} otherwise. + * @see Comparable + * @see Comparator + */ + public static int compare(T a, T b, Comparator c) { + return (a == b) ? 0 : c.compare(a, b); + } +} --- /dev/null 2009-07-06 20:02:10.000000000 -0700 +++ new/test/java/util/Objects/BasicObjectsTest.java 2009-10-08 11:04:04.000000000 -0700 @@ -0,0 +1,105 @@ +/* + * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, + * CA 95054 USA or visit www.sun.com if you need additional information or + * have any questions. + */ + +/* + * @test + * @bug 6797535 + * @summary Basic tests for methods in java.util.Objects + * @author Joseph D. Darcy + */ + +import java.util.*; + +public class BasicObjectsTest { + public static void main(String... args) { + int errors = 0; + errors += testEquals(); + errors += testHashCode(); + errors += testToString(); + errors += testCompare(); + if (errors > 0 ) + throw new RuntimeException(); + } + + private static int testEquals() { + int errors = 0; + Object[] values = {null, "42", 42}; + for(int i = 0; i < values.length; i++) + for(int j = 0; j < values.length; j++) { + boolean expected = (i == j); + Object a = values[i]; + Object b = values[j]; + boolean result = Objects.equals(a, b); + if (result != expected) { + errors++; + System.err.printf("When equating %s to %s, got %b intead of %b%n.", + a, b, result, expected); + } + } + return errors; + } + + private static int testHashCode() { + int errors = 0; + errors += (Objects.hashCode(null) == 0 ) ? 0 : 1; + String s = "42"; + errors += (Objects.hashCode(s) == s.hashCode() ) ? 0 : 1; + return errors; + } + + private static int testToString() { + int errors = 0; + errors += ("null".equals(Objects.toString(null)) ) ? 0 : 1; + String s = "Some string"; + errors += (s.equals(Objects.toString(s)) ) ? 0 : 1; + return errors; + } + + private static int testCompare() { + int errors = 0; + String[] values = {"e. e. cummings", "zzz"}; + String[] VALUES = {"E. E. Cummings", "ZZZ"}; + errors += compareTest(null, null, 0); + for(int i = 0; i < values.length; i++) { + String a = values[i]; + errors += compareTest(a, a, 0); + for(int j = 0; j < VALUES.length; j++) { + int expected = Integer.compare(i, j); + String b = VALUES[j]; + errors += compareTest(a, b, expected); + } + } + return errors; + } + + private static int compareTest(String a, String b, int expected) { + int errors = 0; + int result = Objects.compare(a, b, String.CASE_INSENSITIVE_ORDER); + if (Integer.signum(result) != Integer.signum(expected)) { + errors++; + System.err.printf("When comaping %s to %s, got %d intead of %d%n.", + a, b, result, expected); + } + return errors; + } +} From pbenedict at apache.org Thu Oct 8 11:11:01 2009 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 8 Oct 2009 13:11:01 -0500 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] Message-ID: Joe, > I'm preparing the first round of java.util.Objects with the > single-argument static toString method return "null" for null for final > review. Why would you choose to return "null" for any null object? Everyone who has opined did disagree with replicating String.valueOf() behavior. I don't see how this behavior is appropriate for all objects: no data in should be no data (or at least empty data) going out. Paul From Joe.Darcy at Sun.COM Thu Oct 8 11:14:18 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 08 Oct 2009 11:14:18 -0700 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: References: Message-ID: <4ACE2BFA.9060205@sun.com> Paul Benedict wrote: > Joe, > > >> I'm preparing the first round of java.util.Objects with the >> single-argument static toString method return "null" for null for final >> review. >> > > Why would you choose to return "null" for any null object? Because that is how the platform has always treated null in string concatenation. > Everyone > who has opined did disagree with replicating String.valueOf() > behavior. The people who disagreed with the replication disagreed with the replication. Others disagreed with the behavior. -Joe From pbenedict at apache.org Thu Oct 8 11:21:59 2009 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 8 Oct 2009 13:21:59 -0500 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: <4ACE2BFA.9060205@sun.com> References: <4ACE2BFA.9060205@sun.com> Message-ID: >> Why would you choose to return "null" for any null object? > > Because that is how the platform has always treated null in string > concatenation. If you were defining new operations for String, StringBuilder, or StringBuffer, I would agree with your choice. Since you are now defining a global utility method for all objects, I think having "null" being the de-facto string representation of null is simply taking it too far. Paul From Joe.Darcy at Sun.COM Thu Oct 8 11:30:29 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 08 Oct 2009 11:30:29 -0700 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: References: <4ACE2BFA.9060205@sun.com> Message-ID: <4ACE2FC5.7070702@sun.com> Paul Benedict wrote: >>> Why would you choose to return "null" for any null object? >>> >> Because that is how the platform has always treated null in string >> concatenation. >> > > If you were defining new operations for String, StringBuilder, or > StringBuffer, I would agree with your choice. Since you are now > defining a global utility method for all objects, I think having > "null" being the de-facto string representation of null is simply > taking it too far. > System.out.println("" + referenceOfAnyType); will print "null" if referenceOfAnyType is null. This is what the platform has done since the beginning. -Joe From Joe.Darcy at Sun.COM Thu Oct 8 11:34:32 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 08 Oct 2009 11:34:32 -0700 Subject: j.ul.Objects follow-up: methods for var-argification? Message-ID: <4ACE30B8.8070302@sun.com> Hello. In the discussion about java.util.Objects, a few existing JDK methods were mentioned for possible var-argification: java.util.Arrays.hashCode(Object[] a) java.util.Arrays.deepHashCode(Object[] a) java.util.Arrays.toString(Object[] a) Also of possible general interest are some methods on String (bug 6762452 API change proposal: Enhance String constructor for varargs) java.lang.String.copyValueOf(char[] data) java.lang.String.valueOf(char[] data) java.lang.String(char[] value) Var-argification is fully binary compatible and is generally source compatible, although new conversions are allowed of course and overloadings may change. -Joe From Joe.Darcy at Sun.COM Thu Oct 8 12:12:11 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 08 Oct 2009 12:12:11 -0700 Subject: j.u.Objects follow-up: variations on Object -> String methods Message-ID: <4ACE398B.50400@sun.com> Hello. During the vigorous discussion of what Objects.toString(Object) should be defined to do, a number of alternatives were suggested: public static toString(Object a, String default) // return default if (a == null) else a.toString() public static toDefaultString(Object a) // return the string Object.toString returns if not overriden, what about null? public static toDebugString(Object a) // reflectively return an informative representation of the argument I can accept the utility of toString(Object a, String default) and will include it in the next round of j.u.Objects updates. The functionality of toDefaultString is included in Apache commons under the name of "identityToString," returning null for a null argument. From a quick Google code search, this methods doesn't seem to be widely called and I'm not yet convinced it's worthwhile to add this method to Objects. I think I could be convinced that a reflection-based toDebugString was useful enough to include in the platform. However, someone would have to contribute the specification and a robust implementation. -Joe From jason_mehrens at hotmail.com Thu Oct 8 13:13:57 2009 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 8 Oct 2009 15:13:57 -0500 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: <4ACE26B6.7040709@sun.com> References: <4b4f45e00910080347h9ae22c3m1b50ef30f834c301@mail.gmail.com> <4ACE26B6.7040709@sun.com> Message-ID: Joe, I'll volunteer some "find usage" stats from the code base I work on for a living: 565 ObjectUtils.toString(Object) calls. 487 String.valueOf(Object) calls. Hopefully others can contribute their "find usage" stats. It seems to me that both behaviors are useful. Jason > Date: Thu, 8 Oct 2009 10:51:50 -0700 > From: Joe.Darcy at Sun.COM > Subject: Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] > To: jason_mehrens at hotmail.com > CC: core-libs-dev at openjdk.java.net > I'm preparing the first round of java.util.Objects with the > single-argument static toString method return "null" for null for final > review. I'll send out a few follow-up emails, including one for > additional toStrings methods. I'm sympathetic to the two-argument > toString method with a default. > -Joe _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/171222986/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091008/6bd06255/attachment.html From jjb at google.com Thu Oct 8 14:56:13 2009 From: jjb at google.com (Joshua Bloch) Date: Thu, 8 Oct 2009 14:56:13 -0700 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <4ACE2AF9.4070104@sun.com> References: <4ACE2AF9.4070104@sun.com> Message-ID: <17b2302a0910081456n3379569dnf031b18a1d949e43@mail.gmail.com> Joe, Hi. I think it's great that you're doing this. A few comments: > +public class Objects { > + private Objects() { > + throw new AssertionError("No java.util.Objects instances for > you!"); > + } > Cute! > + > + /** > + * Returns {@code true} if the arguments are equal to each other > + * and {@code false} otherwise. > + * Consequently, if both arguments are {@code null}, {@code true} > + * is returned and if exactly one argument is {@code null}, {@code > + * false} is returned. Otherwise, equality is determined by using > + * the {@link Object#equals equals} method of the first > + * argument. > + * > + * @return {@code true} if the arguments are equal to each other > + * and {@code false} otherwise > + * @see Object#equals(Object) > + */ > + public static boolean equals(Object a, Object b) { > + return (a == b) || (a != null && a.equals(b)); > + } > Very useful! We've needed this one ( equals(Object a, Object b) ) for years. + > + /** > + * Returns the hash code of a non-{@code null} argument and 0 for > + * a {@code null} argument. > + * > + * @return the hash code of a non-{@code null} argument and 0 for > + * a {@code null} argument > + * @see Object#hashCode > + */ > + public static int hashCode(Object o) { > + return o != null ? o.hashCode() : 0; > + } > Again, very useful. Along these lines, I would add this method too: /** * Generates a hash code for a sequence of input values. The hash code is * generated as if all the input values were placed into an array, and that * array were hashed by calling {@link Arrays#hashCode(Object[])}. *

*

This method is useful for implementing {@link Object#hashCode()} on * objects containing multiple fields. For example, if an object that has * three fields, {@code x}, {@code y}, and {@code z}, one could write: * 

     * @Override public int hashCode() {
     *     return Objects.hashCode(x, y, z);
     * }
     *
* Warning: When a single object reference is supplied, the returned * value does not equal the hash code of that object reference. This * value can be computed by calling {@link #hashCode(Object)}. */ public static int hash(Object... components) { return Arrays.hashCode(components); } People still don't know how to hash objects with multiple fields; this little method makes it much easier. > + > + /** > + * Returns the result of calling {@code toString} for a non-{@code > + * null} argument and {@code "null"} for a {@code null} argument. > + * > + * @return the result of calling {@code toString} for a non-{@code > + * null} argument and {@code "null"} for a {@code null} argument > + * @see Object#toString > + * @see String#valueOf(Object) > + */ > + public static String toString(Object o) { > + return String.valueOf(o); > + } I would definitely *not* add this method (Objects.toString). It brings nothing to the table that isn't already there. People know and use String.valueOf. Let's not muddy the waters by adding another choice. > + > + /** > + * Returns 0 if the arguments are identical and {@code > + * c.compare(a, b)} otherwise. > + * Consequently, if both arguments are {@code null} 0 > + * is returned. > + * > + *

Note that if one of the arguments is {@code null}, a {@code > + * NullPointerException} may or may not be thrown depending on > + * what ordering policy, if any, the {@link Comparator Comparator} > + * chooses to have for {@code null} values. > + * > + * @return 0 if the arguments are identical and {@code > + * c.compare(a, b)} otherwise. > + * @see Comparable > + * @see Comparator > + */ > + public static int compare(T a, T b, Comparator c) { > + return (a == b) ? 0 : c.compare(a, b); > + } > +} I don't think you should add this method ( compare(T a, T b, Comparator c)). Its utility is unclear, and it doesn't have the power-to-weight ratio of the other methods in this class. I strongly suggest that you do add these two methods: /** * Checks that the specified object reference is not {@code null}. This * method is designed primarily for doing parameter validation in methods * and constructors, as demonstrated below: * 

     * public Foo(Bar bar) {
     *     this.bar = Objects.nonNull(bar);
     * }
     *
* * @param obj the object reference to check for nullity * @return {@code obj} if not {@code null} * @throws NullPointerException if {@code obj} is {@code null} */ public static T nonNull(T obj) { if (obj == null) throw new NullPointerException(); return obj; } /** * Checks that the specified object reference is not {@code null} and * throws a customized {@Link NullPointerException} if it is. This method * is designed primarily for doing parameter validation in methods and * constructors with multiple parameters, as demonstrated below: * 
     * public Foo(Bar bar, Baz baz) {
     *     this.bar = Objects.nonNull(bar, "bar must not be null");
     *     this.baz = Objects.nonNull(baz, "baz must not be null");
     * }
     *
* * @param obj the object reference to check for nullity * @param message detail message to be used in the event that a {@code * NullPointerException} is thrown * @return {@code obj} if not {@code null} * @throws NullPointerException if {@code obj} is {@code null} */ public static T nonNull(T obj, String message) { if (obj == null) throw new NullPointerException(message); return obj; } They do a great job reducing the verbiage in validity-checking of arguments that must not be null. Regards, Josh Bloch and Bob Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091008/4b1809d0/attachment.html From David.Holmes at Sun.COM Thu Oct 8 16:03:26 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 09 Oct 2009 09:03:26 +1000 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACDD3FF.7060106@gmx.de> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> <4ACD1D21.4000805@gmx.de> <4ACD6C1C.5020506@sun.com> <4ACDB9E5.6090202@gmx.de> <4ACDC62A.4020608@sun.com> <4ACDD3FF.7060106@gmx.de> Message-ID: <4ACE6FBE.5060500@sun.com> Ulf Zibis said the following on 10/08/09 21:58: > Am 08.10.2009 12:59, David Holmes - Sun Microsystems schrieb: >> It's a memory model issue. The code is like this: >> >> public String getName() { >> if (name == null) >> name = getName0(); >> return name; >> } >> >> but in theory, accoridng to the JMM experts, it could act as if it >> does this: >> >> public String getName() { >> String tmp1 = name; // sees null >> String tmp2 = name; // sees non-null >> if (tmp2 == null) >> tmp1 = name = getName0(); >> return tmp1; >> } >> >> imagine the temporaries are registers. > > Oops, java programming is not simple as it looks like. Can you give me a > link, where I can read more about that subject / JMM? > David, thanks for your explicit explanation. The JMM is mostly defined in Chapter 17 of the Java Language Specification Third Edition, but it has little pieces scattered in other places in the spec (eg treatment of final fields). For more gory details than you would want to know check out this site: http://www.cs.umd.edu/~pugh/java/memoryModel/ For the record I disagree with this particular case as I think returning null would violate program order. But the fix is benign so not worth arguing over. And the argument is too difficult to make. :) And as this is getting very OT that's enough of that :) Cheers, David From neugens at limasoftware.net Thu Oct 8 14:15:19 2009 From: neugens at limasoftware.net (Mario Torre) Date: Thu, 08 Oct 2009 23:15:19 +0200 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <4ACE2AF9.4070104@sun.com> References: <4ACE2AF9.4070104@sun.com> Message-ID: <4ACE5667.70705@limasoftware.net> Il 08/10/2009 20:10, Joseph D. Darcy ha scritto: Hi Joseph! Of course, it's nitpicking but: > + System.err.printf("When equating %s to %s, got %b intead of %b%n.", > + a, b, result, expected); has a typo in there :) There are others similar, copy and paste errors I suppose. Cheers, Mario From Joe.Darcy at Sun.COM Thu Oct 8 12:59:37 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 08 Oct 2009 12:59:37 -0700 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? Message-ID: <4ACE44A9.8060506@sun.com> Another piece of functionality requested in the j.u.Objects thread was a deepEquals(Object a, Object b.) method that "did the right thing" if the arguments happened to dynamically be arrays. I've been thinking a bit how this might be implemented. The array-ness of a and b would need to be determined, after any up-front null-checks boolean aIsArray = a.getClass().isArray(); boolean bIsArray = b.getClass().isArray(); followed various case-analyses. if (aIsArray && bIsArray) { Class aComponentType = a.getClass().getComponentType(); Class bComponentType = b.getClass().getComponentType(); if (aComponentType == bComponentType) { // long case analysis to cast and call Arrays.deepEquals if ComponentType is a reference type // or the matching Arrays.equals(primitiveComponent[], primitiveComponent[]) method if // aComponentType.isPrimitive(). } else return false; } else return a.equals(b); Certainly a bit messy internally. What are scenarios where this method would be used? -Joe From pbenedict at apache.org Thu Oct 8 13:20:52 2009 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 8 Oct 2009 15:20:52 -0500 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: <4ACE2FC5.7070702@sun.com> References: <4ACE2BFA.9060205@sun.com> <4ACE2FC5.7070702@sun.com> Message-ID: Joe, I understand your point, and that's why I countered with my String and StringBuilder points. Those two classes are used underneath the covers for inline concatenation, but, again, java.util.Objects has grander intentions than string concatenation. This class is for all objects, and however String/StringBuilder work with nulls is totally irrelevant to how this class should behave. You are taking one use from one class and making it the utility behavior for any object. Paul On Thu, Oct 8, 2009 at 1:30 PM, Joseph D. Darcy wrote: > Paul Benedict wrote: >>>> >>>> Why would you choose to return "null" for any null object? >>>> >>> >>> Because that is how the platform has always treated null in string >>> concatenation. >>> >> >> If you were defining new operations for String, StringBuilder, or >> StringBuffer, I would agree with your choice. Since you are now >> defining a global utility method for all objects, I think having >> "null" being the de-facto string representation of null is simply >> taking it too far. >> > > System.out.println("" + referenceOfAnyType); > > will print "null" if referenceOfAnyType is null. > > This is what the platform has done since the beginning. > > -Joe > > From David.Holmes at Sun.COM Thu Oct 8 16:53:36 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 09 Oct 2009 09:53:36 +1000 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: <4ACE2FC5.7070702@sun.com> References: <4ACE2BFA.9060205@sun.com> <4ACE2FC5.7070702@sun.com> Message-ID: <4ACE7B80.3020401@sun.com> Joe, Joseph D. Darcy said the following on 10/09/09 04:30: > System.out.println("" + referenceOfAnyType); > > will print "null" if referenceOfAnyType is null. > > This is what the platform has done since the beginning. Yes because String concatenation can not tolerate null values appearing, so it is defined to replace null with "null" (or replace a null from o.toString() with "null"). And I suspect that "null" was chosen over "" because it is then obvious when an unexpected null was encountered. But Objects.toString(o) is not concerned with string concatenation so doesn't have to mimic that behaviour. Personally I'd only put in the two-arg variant because: a) a one-arg that simply forwards to String.valueOf is redundant as already discussed b) a one-arg that hardwires the response to null (whether that be to return null or "null") will simply force the programmer to either switch to a different API or else add their own null handling logic - which defeats the purpose of putting in these utility/convenience methods. So to me: String toString(Object o, String useIfNull) is the only method that provides true utility in this case. David From Joe.Darcy at Sun.COM Thu Oct 8 18:21:52 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 08 Oct 2009 18:21:52 -0700 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <17b2302a0910081456n3379569dnf031b18a1d949e43@mail.gmail.com> References: <4ACE2AF9.4070104@sun.com> <17b2302a0910081456n3379569dnf031b18a1d949e43@mail.gmail.com> Message-ID: <4ACE9030.3030801@sun.com> Hello. Joshua Bloch wrote: > Joe, > > Hi. I think it's great that you're doing this. A few comments: > > > +public class Objects { > + private Objects() { > + throw new AssertionError("No java.util.Objects instances > for you!"); > + } > > Cute! > > > + > + /** > + * Returns {@code true} if the arguments are equal to each other > + * and {@code false} otherwise. > + * Consequently, if both arguments are {@code null}, {@code true} > + * is returned and if exactly one argument is {@code null}, > {@code > + * false} is returned. Otherwise, equality is determined by > using > + * the {@link Object#equals equals} method of the first > + * argument. > + * > + * @return {@code true} if the arguments are equal to each other > + * and {@code false} otherwise > + * @see Object#equals(Object) > + */ > + public static boolean equals(Object a, Object b) { > + return (a == b) || (a != null && a.equals(b)); > + } > > Very useful! We've needed this one ( equals(Object a, Object b) ) > for years. Indeed. > > + > + /** > + * Returns the hash code of a non-{@code null} argument and 0 for > + * a {@code null} argument. > + * > + * @return the hash code of a non-{@code null} argument and 0 for > + * a {@code null} argument > + * @see Object#hashCode > + */ > + public static int hashCode(Object o) { > + return o != null ? o.hashCode() : 0; > + } > > > Again, very useful. Along these lines, I would add this method too: > > /** > * Generates a hash code for a sequence of input values. The hash > code is > * generated as if all the input values were placed into an array, > and that > * array were hashed by calling {@link Arrays#hashCode(Object[])}. > *

> *

This method is useful for implementing {@link > Object#hashCode()} on > * objects containing multiple fields. For example, if an object > that has > * three fields, {@code x}, {@code y}, and {@code z}, one could > write: > * 

>      * @Override public int hashCode() {
>      *     return Objects.hashCode(x, y, z);
>      * }
>      *
> * Warning: When a single object reference is supplied, the > returned > * value does not equal the hash code of that object > reference. This > * value can be computed by calling {@link #hashCode(Object)}. > */ > public static int hash(Object... components) { > return Arrays.hashCode(components); > } > > People still don't know how to hash objects with multiple fields; this > little method makes it much easier. Hmm. I split up a number of the follow-up ideas into separate email threads on core-libs-deve; one of those was whether or not some of the existing methods in Arrays should be var-argified. What about introducing a java.util.Hash (Hasher?) class with * hash methods for double and long implementing the Long and Double hash code algorithms, etc. * the hash convenience method above > > > + > + /** > + * Returns the result of calling {@code toString} for a > non-{@code > + * null} argument and {@code "null"} for a {@code null} argument. > + * > + * @return the result of calling {@code toString} for a > non-{@code > + * null} argument and {@code "null"} for a {@code null} argument > + * @see Object#toString > + * @see String#valueOf(Object) > + */ > + public static String toString(Object o) { > + return String.valueOf(o); > + } > > I would definitely /not/ add this method (Objects.toString). It > brings nothing to the table that isn't already there. People know and > use String.valueOf. Let's not muddy the waters by adding another choice. So noted. > > > + > + /** > + * Returns 0 if the arguments are identical and {@code > + * c.compare(a, b)} otherwise. > + * Consequently, if both arguments are {@code null} 0 > + * is returned. > + * > + *

Note that if one of the arguments is {@code null}, a {@code > + * NullPointerException} may or may not be thrown depending on > + * what ordering policy, if any, the {@link Comparator > Comparator} > + * chooses to have for {@code null} values. > + * > + * @return 0 if the arguments are identical and {@code > + * c.compare(a, b)} otherwise. > + * @see Comparable > + * @see Comparator > + */ > + public static int compare(T a, T b, Comparator > c) { > + return (a == b) ? 0 : c.compare(a, b); > + } > +} > > I don't think you should add this method ( compare(T a, T b, > Comparator c)). Its utility is unclear, and it doesn't > have the power-to-weight ratio of the other methods in this class. Yeah, I included this with "Item 12: Consider implementing Comparable" from EJv2 in mind. > > I strongly suggest that you do add these two methods: > > /** > * Checks that the specified object reference is not {@code null}. > This > * method is designed primarily for doing parameter validation in > methods > * and constructors, as demonstrated below: > * 

>      * public Foo(Bar bar) {
>      *     this.bar = Objects.nonNull(bar);
>      * }
>      *
> * > * @param obj the object reference to check for nullity > * @return {@code obj} if not {@code null} > * @throws NullPointerException if {@code obj} is {@code null} > */ > public static T nonNull(T obj) { > if (obj == null) > throw new NullPointerException(); > return obj; > } > > /** > * Checks that the specified object reference is not {@code null} and > * throws a customized {@Link NullPointerException} if it is. This > method > * is designed primarily for doing parameter validation in methods and > * constructors with multiple parameters, as demonstrated below: > * 
>      * public Foo(Bar bar, Baz baz) {
>      *     this.bar = Objects.nonNull(bar, "bar must not be null");
>      *     this.baz = Objects.nonNull(baz, "baz must not be null");
>      * }
>      *
> * > * @param obj the object reference to check for nullity > * @param message detail message to be used in the event that a {@code > * NullPointerException} is thrown > * @return {@code obj} if not {@code null} > * @throws NullPointerException if {@code obj} is {@code null} > */ > public static T nonNull(T obj, String message) { > if (obj == null) > throw new NullPointerException(message); > return obj; > } > > They do a great job reducing the verbiage in validity-checking of > arguments that must not be null. I've filed bug 6889858 "Add nonNull methods to java.util.Objects" for these last two methods. If you want to finish off the engineering need for a changeset, some light tests, etc., I'll file the Sun-internal paperwork for these. Once the Mercurial repos are feeling healthy again, I'm going to push the four-method version of j.u.Objects (equals(Object, Object), hashCode(Object), toString(Object), compare(T, T)) into JDK 7 TL. Afterward I expect discussions of refinements, changes, and additions to j.u.Objects to continue on the mailing list. -Joe From Joe.Darcy at Sun.COM Thu Oct 8 18:22:22 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 08 Oct 2009 18:22:22 -0700 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <4ACE5667.70705@limasoftware.net> References: <4ACE2AF9.4070104@sun.com> <4ACE5667.70705@limasoftware.net> Message-ID: <4ACE904E.3020301@sun.com> Mario Torre wrote: > Il 08/10/2009 20:10, Joseph D. Darcy ha scritto: > > Hi Joseph! > > Of course, it's nitpicking but: > > > + System.err.printf("When equating %s to %s, got %b intead of %b%n.", > > + a, b, result, expected); > > has a typo in there :) > > There are others similar, copy and paste errors I suppose. > Will be fixed. Thanks for catching these, -Joe From develop4lasu at gmail.com Thu Oct 8 23:58:56 2009 From: develop4lasu at gmail.com (=?UTF-8?Q?Marek_Kozie=C5=82?=) Date: Fri, 9 Oct 2009 08:58:56 +0200 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <4ACE2AF9.4070104@sun.com> References: <4ACE2AF9.4070104@sun.com> Message-ID: <28bca0ff0910082358m7aef2399m5fa436c858b27f28@mail.gmail.com> 2009/10/8 Joseph D. Darcy : > Hello. > > Please code review the first-round of java.util.Objects; the patch is below: > http://cr.openjdk.java.net/~darcy/6797535.0/ > > -Joe > > --- old/make/java/java/FILES_java.gmk ? 2009-10-08 11:04:03.000000000 -0700 > +++ new/make/java/java/FILES_java.gmk ? 2009-10-08 11:04:02.000000000 -0700 > @@ -258,6 +258,7 @@ > ? ?java/util/ServiceConfigurationError.java \ > ? ?java/util/Timer.java \ > ? ?java/util/TimerTask.java \ > + ? ?java/util/Objects.java \ > ? ?java/util/UUID.java \ > ? ?java/util/concurrent/AbstractExecutorService.java \ > ? ?java/util/concurrent/ArrayBlockingQueue.java \ > --- /dev/null ? 2009-07-06 20:02:10.000000000 -0700 > +++ new/src/share/classes/java/util/Objects.java ? ? ? ?2009-10-08 > 11:04:03.000000000 -0700 > @@ -0,0 +1,102 @@ > +/* > + * Copyright 2009 Sun Microsystems, Inc. ?All Rights Reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. ?Sun designates this > + * particular file as subject to the "Classpath" exception as provided > + * by Sun in the LICENSE file that accompanied this code. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, > + * CA 95054 USA or visit www.sun.com if you need additional information or > + * have any questions. > + */ > + > +package java.util; > + > +/** > + * This class consists of {@code static} utility methods for operating > + * on objects. ?These utilities include {@code null}-safe or {@code > + * null}-tolerant methods for computing the hash code of an object, > + * returning a string for an object, and comparing two objects. > + * > + * @since 1.7 > + */ > +public class Objects { > + ? ?private Objects() { > + ? ? ? ?throw new AssertionError("No java.util.Objects instances for > you!"); > + ? ?} > + > + ? ?/** > + ? ? * Returns {@code true} if the arguments are equal to each other > + ? ? * and {@code false} otherwise. > + ? ? * Consequently, if both arguments are {@code null}, {@code true} > + ? ? * is returned and if exactly one argument is {@code null}, {@code > + ? ? * false} is returned. ?Otherwise, equality is determined by using > + ? ? * the {@link Object#equals equals} method of the first > + ? ? * argument. > + ? ? * > + ? ? * @return {@code true} if the arguments are equal to each other > + ? ? * and {@code false} otherwise > + ? ? * @see Object#equals(Object) > + ? ? */ > + ? ?public static boolean equals(Object a, Object b) { > + ? ? ? ?return (a == b) || (a != null && a.equals(b)); > + ? ?} Hello, I would suggest other implementation of equals method: public static boolean equals(Object a, Object b) { if (a == null) return (b == null ? true : b.equals(null)); if (b == null) return a.equals(null); return a.equals(b); } This one could cover case when null is considered as object in object equals method, while in not time implementation result might depend from arguments order: class Boo { public String data; @Override public boolean equals(Object obj) { if (obj == null) return (data == null);// ... } } -- Regards. Lasu aka Marek Kozie? http://lasu2string.blogspot.com/ From Ulf.Zibis at gmx.de Fri Oct 9 01:16:06 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 09 Oct 2009 10:16:06 +0200 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: <4ACE7B80.3020401@sun.com> References: <4ACE2BFA.9060205@sun.com> <4ACE2FC5.7070702@sun.com> <4ACE7B80.3020401@sun.com> Message-ID: <4ACEF146.8060403@gmx.de> Am 09.10.2009 01:53, David Holmes - Sun Microsystems schrieb: > So to me: String toString(Object o, String useIfNull) is the only > method that provides true utility in this case. > I can follow this argumentation. +1 -Ulf From Ulf.Zibis at gmx.de Fri Oct 9 01:33:40 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 09 Oct 2009 10:33:40 +0200 Subject: j.ul.Objects follow-up: methods for var-argification? In-Reply-To: <4ACE30B8.8070302@sun.com> References: <4ACE30B8.8070302@sun.com> Message-ID: <4ACEF564.8000407@gmx.de> Am 08.10.2009 20:34, Joseph D. Darcy schrieb: > Hello. > > In the discussion about java.util.Objects, a few existing JDK methods > were mentioned for possible var-argification: > > java.util.Arrays.hashCode(Object[] a) > java.util.Arrays.deepHashCode(Object[] a) > java.util.Arrays.toString(Object[] a) > > Also of possible general interest are some methods on String (bug > 6762452 API change proposal: Enhance String constructor for varargs) > > java.lang.String.copyValueOf(char[] data) > java.lang.String.valueOf(char[] data) > java.lang.String(char[] value) > > Var-argification is fully binary compatible and is generally source > compatible, although new conversions are allowed of course and > overloadings may change. > As String is final, there are no changed overloadings. As the Arrays methods are static, there are too no changed overloadings. OK, correct me, if I'm wrong. -Ulf From Ulf.Zibis at gmx.de Fri Oct 9 01:42:04 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 09 Oct 2009 10:42:04 +0200 Subject: j.u.Objects follow-up: variations on Object -> String methods In-Reply-To: <4ACE398B.50400@sun.com> References: <4ACE398B.50400@sun.com> Message-ID: <4ACEF75C.4020406@gmx.de> Am 08.10.2009 21:12, Joseph D. Darcy schrieb: > > I think I could be convinced that a reflection-based toDebugString was > useful enough to include in the platform. However, someone would have > to contribute the specification and a robust implementation. I more tend to prefer a separate class, called java.util.Debug. You could start a survey like for project coin, to collect ideas, what helper methods users want for debugging purposes. -Ulf From Eamonn.McManus at Sun.COM Fri Oct 9 01:56:55 2009 From: Eamonn.McManus at Sun.COM (Eamonn McManus) Date: Fri, 09 Oct 2009 10:56:55 +0200 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <28bca0ff0910082358m7aef2399m5fa436c858b27f28@mail.gmail.com> References: <4ACE2AF9.4070104@sun.com> <28bca0ff0910082358m7aef2399m5fa436c858b27f28@mail.gmail.com> Message-ID: <4ACEFAD7.5060108@sun.com> Hi, Marek Kozie? wrote: >> + public static boolean equals(Object a, Object b) { >> + return (a == b) || (a != null && a.equals(b)); >> + } > > Hello, > I would suggest other implementation of equals method: > > public static boolean equals(Object a, Object b) { > if (a == null) return (b == null ? true : b.equals(null)); > if (b == null) return a.equals(null); > return a.equals(b); > } > > This one could cover case when null is considered as object in object > equals method [...] An equals implementation that can return true when its argument is null violates its contract since it is not symmetric. In fact, the spec of Object.equals specifically says that the method must return false when the argument is null. Regards, ?amonn McManus ? JMX Spec Lead ? http://weblogs.java.net/blog/emcmanus Marek Kozie? wrote: > 2009/10/8 Joseph D. Darcy : >> Hello. >> >> Please code review the first-round of java.util.Objects; the patch is below: >> http://cr.openjdk.java.net/~darcy/6797535.0/ >> >> -Joe >> >> --- old/make/java/java/FILES_java.gmk 2009-10-08 11:04:03.000000000 -0700 >> +++ new/make/java/java/FILES_java.gmk 2009-10-08 11:04:02.000000000 -0700 >> @@ -258,6 +258,7 @@ >> java/util/ServiceConfigurationError.java \ >> java/util/Timer.java \ >> java/util/TimerTask.java \ >> + java/util/Objects.java \ >> java/util/UUID.java \ >> java/util/concurrent/AbstractExecutorService.java \ >> java/util/concurrent/ArrayBlockingQueue.java \ >> --- /dev/null 2009-07-06 20:02:10.000000000 -0700 >> +++ new/src/share/classes/java/util/Objects.java 2009-10-08 >> 11:04:03.000000000 -0700 >> @@ -0,0 +1,102 @@ >> +/* >> + * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. >> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> + * >> + * This code is free software; you can redistribute it and/or modify it >> + * under the terms of the GNU General Public License version 2 only, as >> + * published by the Free Software Foundation. Sun designates this >> + * particular file as subject to the "Classpath" exception as provided >> + * by Sun in the LICENSE file that accompanied this code. >> + * >> + * This code is distributed in the hope that it will be useful, but WITHOUT >> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> + * version 2 for more details (a copy is included in the LICENSE file that >> + * accompanied this code). >> + * >> + * You should have received a copy of the GNU General Public License >> version >> + * 2 along with this work; if not, write to the Free Software Foundation, >> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> + * >> + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, >> + * CA 95054 USA or visit www.sun.com if you need additional information or >> + * have any questions. >> + */ >> + >> +package java.util; >> + >> +/** >> + * This class consists of {@code static} utility methods for operating >> + * on objects. These utilities include {@code null}-safe or {@code >> + * null}-tolerant methods for computing the hash code of an object, >> + * returning a string for an object, and comparing two objects. >> + * >> + * @since 1.7 >> + */ >> +public class Objects { >> + private Objects() { >> + throw new AssertionError("No java.util.Objects instances for >> you!"); >> + } >> + >> + /** >> + * Returns {@code true} if the arguments are equal to each other >> + * and {@code false} otherwise. >> + * Consequently, if both arguments are {@code null}, {@code true} >> + * is returned and if exactly one argument is {@code null}, {@code >> + * false} is returned. Otherwise, equality is determined by using >> + * the {@link Object#equals equals} method of the first >> + * argument. >> + * >> + * @return {@code true} if the arguments are equal to each other >> + * and {@code false} otherwise >> + * @see Object#equals(Object) >> + */ >> + public static boolean equals(Object a, Object b) { >> + return (a == b) || (a != null && a.equals(b)); >> + } > > Hello, > I would suggest other implementation of equals method: > > public static boolean equals(Object a, Object b) { > if (a == null) return (b == null ? true : b.equals(null)); > if (b == null) return a.equals(null); > return a.equals(b); > } > > This one could cover case when null is considered as object in object > equals method, while in not time implementation result might depend > from arguments order: > > class Boo { > public String data; > > @Override > public boolean equals(Object obj) { > if (obj == null) return (data == null);// > ... > } > } > > From Eamonn.McManus at Sun.COM Fri Oct 9 02:15:48 2009 From: Eamonn.McManus at Sun.COM (Eamonn McManus) Date: Fri, 09 Oct 2009 11:15:48 +0200 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: <4ACE7B80.3020401@sun.com> References: <4ACE2BFA.9060205@sun.com> <4ACE2FC5.7070702@sun.com> <4ACE7B80.3020401@sun.com> Message-ID: <4ACEFF44.4070806@sun.com> David Holmes - Sun Microsystems wrote: > So to me: String toString(Object o, String useIfNull) is the only method > that provides true utility in this case. I agree with that, and would just suggest to the person specifying the method to add a @see String#valueOf(Object). I find that the behaviour of that method is usually exactly what I want when the argument is null (and I find the idea of representing null by an empty string aberrant, but there you go), so for people like me but who might not have noticed String.valueOf this will save them from peppering Objects.toString(x, "null") throughout their programs. ?amonn McManus ? JMX Spec Lead ? http://weblogs.java.net/blog/emcmanus David Holmes - Sun Microsystems wrote: > Joe, > > Joseph D. Darcy said the following on 10/09/09 04:30: >> System.out.println("" + referenceOfAnyType); >> >> will print "null" if referenceOfAnyType is null. >> >> This is what the platform has done since the beginning. > > Yes because String concatenation can not tolerate null values appearing, > so it is defined to replace null with "null" (or replace a null from > o.toString() with "null"). And I suspect that "null" was chosen over "" > because it is then obvious when an unexpected null was encountered. > > But Objects.toString(o) is not concerned with string concatenation so > doesn't have to mimic that behaviour. > > Personally I'd only put in the two-arg variant because: > > a) a one-arg that simply forwards to String.valueOf is redundant as > already discussed > > b) a one-arg that hardwires the response to null (whether that be to > return null or "null") will simply force the programmer to either switch > to a different API or else add their own null handling logic - which > defeats the purpose of putting in these utility/convenience methods. > > So to me: String toString(Object o, String useIfNull) is the only method > that provides true utility in this case. > > David From Eamonn.McManus at Sun.COM Fri Oct 9 02:30:33 2009 From: Eamonn.McManus at Sun.COM (Eamonn McManus) Date: Fri, 09 Oct 2009 11:30:33 +0200 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? In-Reply-To: <4ACE44A9.8060506@sun.com> References: <4ACE44A9.8060506@sun.com> Message-ID: <4ACF02B9.8070708@sun.com> Joseph D. Darcy wrote: > What are scenarios where this method would be used? I use a similar method fairly often in unit tests. JUnit's assertEquals doesn't do the right thing if its arguments happen to be arrays, so I use the following simple if inefficient implementation: static void deepEquals(Object x, Object y) { return Arrays.deepEquals(new Object[] {x}, new Object[] {y}); } What that shows of course is that the messy logic you mention is already present in Arrays.deepEquals so you could factor it out. Regards, ?amonn McManus ? JMX Spec Lead ? http://weblogs.java.net/blog/emcmanus Joseph D. Darcy wrote: > Another piece of functionality requested in the j.u.Objects thread was a > deepEquals(Object a, Object b.) method that "did the right thing" if the > arguments happened to dynamically be arrays. > > I've been thinking a bit how this might be implemented. > > The array-ness of a and b would need to be determined, after any > up-front null-checks > > boolean aIsArray = a.getClass().isArray(); > boolean bIsArray = b.getClass().isArray(); > > followed various case-analyses. > > if (aIsArray && bIsArray) { > Class aComponentType = a.getClass().getComponentType(); > Class bComponentType = b.getClass().getComponentType(); > if (aComponentType == bComponentType) { > // long case analysis to cast and call Arrays.deepEquals if > ComponentType is a reference type > // or the matching Arrays.equals(primitiveComponent[], > primitiveComponent[]) method if > // aComponentType.isPrimitive(). > } else > return false; > } else > return a.equals(b); > > Certainly a bit messy internally. > > What are scenarios where this method would be used? > > -Joe From Ulf.Zibis at gmx.de Fri Oct 9 02:30:13 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 09 Oct 2009 11:30:13 +0200 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <4ACEFAD7.5060108@sun.com> References: <4ACE2AF9.4070104@sun.com> <28bca0ff0910082358m7aef2399m5fa436c858b27f28@mail.gmail.com> <4ACEFAD7.5060108@sun.com> Message-ID: <4ACF02A5.1020000@gmx.de> Am 09.10.2009 10:56, Eamonn McManus schrieb: > Hi, > > Marek Kozie? wrote: > >> + public static boolean equals(Object a, Object b) { > >> + return (a == b) || (a != null && a.equals(b)); > >> + } > > > > Hello, > > I would suggest other implementation of equals method: > > > > public static boolean equals(Object a, Object b) { > > if (a == null) return (b == null ? true : b.equals(null)); > > if (b == null) return a.equals(null); > > return a.equals(b); > > } > > > > This one could cover case when null is considered as object in object > > equals method [...] > > An equals implementation that can return true when its argument is > null violates its contract since > it is not symmetric. In fact, the spec of Object.equals specifically > says that the method must > return false when the argument is null. > The spec, you mention, refers to the instance method equals(), but here we are talking about static helpers. But anyway, I don't understand the point of Marek's implementation. -Ulf From Ulf.Zibis at gmx.de Fri Oct 9 02:33:37 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 09 Oct 2009 11:33:37 +0200 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? In-Reply-To: <4ACF02B9.8070708@sun.com> References: <4ACE44A9.8060506@sun.com> <4ACF02B9.8070708@sun.com> Message-ID: <4ACF0371.8090407@gmx.de> Am 09.10.2009 11:30, Eamonn McManus schrieb: > Joseph D. Darcy wrote: > > What are scenarios where this method would be used? > > I use a similar method fairly often in unit tests. JUnit's > assertEquals doesn't > do the right thing if its arguments happen to be arrays, so I use the > following > simple if inefficient implementation: Don't you know about assertArrayEquals() in JUnit ? It's in version 4.5. -Ulf From Eamonn.McManus at Sun.COM Fri Oct 9 02:36:20 2009 From: Eamonn.McManus at Sun.COM (Eamonn McManus) Date: Fri, 09 Oct 2009 11:36:20 +0200 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <4ACF02A5.1020000@gmx.de> References: <4ACE2AF9.4070104@sun.com> <28bca0ff0910082358m7aef2399m5fa436c858b27f28@mail.gmail.com> <4ACEFAD7.5060108@sun.com> <4ACF02A5.1020000@gmx.de> Message-ID: <4ACF0414.70500@sun.com> > The spec, you mention, refers to the instance method equals(), but here > we are talking about static helpers. The difference between Marek's suggestion and Joe's is what happens when the equals(Object) method of a or b returns true for a null argument, and that is what I was saying violates the spec. ?amonn McManus ? JMX Spec Lead ? http://weblogs.java.net/blog/emcmanus Ulf Zibis wrote: > Am 09.10.2009 10:56, Eamonn McManus schrieb: >> Hi, >> >> Marek Kozie? wrote: >> >> + public static boolean equals(Object a, Object b) { >> >> + return (a == b) || (a != null && a.equals(b)); >> >> + } >> > >> > Hello, >> > I would suggest other implementation of equals method: >> > >> > public static boolean equals(Object a, Object b) { >> > if (a == null) return (b == null ? true : b.equals(null)); >> > if (b == null) return a.equals(null); >> > return a.equals(b); >> > } >> > >> > This one could cover case when null is considered as object in object >> > equals method [...] >> >> An equals implementation that can return true when its argument is >> null violates its contract since >> it is not symmetric. In fact, the spec of Object.equals specifically >> says that the method must >> return false when the argument is null. >> > > The spec, you mention, refers to the instance method equals(), but here > we are talking about static helpers. > > But anyway, I don't understand the point of Marek's implementation. > > -Ulf > > From Ulf.Zibis at gmx.de Fri Oct 9 02:39:17 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 09 Oct 2009 11:39:17 +0200 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <4ACF0414.70500@sun.com> References: <4ACE2AF9.4070104@sun.com> <28bca0ff0910082358m7aef2399m5fa436c858b27f28@mail.gmail.com> <4ACEFAD7.5060108@sun.com> <4ACF02A5.1020000@gmx.de> <4ACF0414.70500@sun.com> Message-ID: <4ACF04C5.20704@gmx.de> Am 09.10.2009 11:36, Eamonn McManus schrieb: > > The spec, you mention, refers to the instance method equals(), but here > > we are talking about static helpers. > > The difference between Marek's suggestion and Joe's is what happens when > the equals(Object) method of a or b returns true for a null argument, and > that is what I was saying violates the spec. > > I got it, thanks. -Ulf From Eamonn.McManus at Sun.COM Fri Oct 9 03:02:34 2009 From: Eamonn.McManus at Sun.COM (Eamonn McManus) Date: Fri, 09 Oct 2009 12:02:34 +0200 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? In-Reply-To: <4ACF0371.8090407@gmx.de> References: <4ACE44A9.8060506@sun.com> <4ACF02B9.8070708@sun.com> <4ACF0371.8090407@gmx.de> Message-ID: <4ACF0A3A.3020805@sun.com> > Don't you know about assertArrayEquals() in JUnit ? It's in version 4.5. I can use that if I know the values are arrays. The sort of case I'm thinking of is a data-driven test where I have a big array with a lot of inputs and the corresponding expected outputs, some but not all of which might be arrays, including primitive arrays. For example, the inputs are expressions in a script language and the outputs are what those expressions should evaluate to. The test iterates over the array and does assertDeepEquals for each input/output pair. But it is true that I could use the same new Object[] {x} trick there, in other words define assertDeepEquals in terms of assertArrayEquals, to get better failure messages. The main advantages I see of deepEquals(Object, Object) are that it avoids allocating a throw-away array (which is not a concern in unit tests), and more importantly that it is easier to find than the new Object[] {x} trick. ?amonn McManus ? JMX Spec Lead ? http://weblogs.java.net/blog/emcmanus Ulf Zibis wrote: > Am 09.10.2009 11:30, Eamonn McManus schrieb: >> Joseph D. Darcy wrote: >> > What are scenarios where this method would be used? >> >> I use a similar method fairly often in unit tests. JUnit's >> assertEquals doesn't >> do the right thing if its arguments happen to be arrays, so I use the >> following >> simple if inefficient implementation: > > Don't you know about assertArrayEquals() in JUnit ? It's in version 4.5. > > -Ulf > > From develop4lasu at gmail.com Fri Oct 9 03:58:09 2009 From: develop4lasu at gmail.com (=?UTF-8?Q?Marek_Kozie=C5=82?=) Date: Fri, 9 Oct 2009 12:58:09 +0200 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <4ACF0414.70500@sun.com> References: <4ACE2AF9.4070104@sun.com> <28bca0ff0910082358m7aef2399m5fa436c858b27f28@mail.gmail.com> <4ACEFAD7.5060108@sun.com> <4ACF02A5.1020000@gmx.de> <4ACF0414.70500@sun.com> Message-ID: <28bca0ff0910090358r6772246dudb29d6583d7059e8@mail.gmail.com> 2009/10/9 Eamonn McManus : >> The spec, you mention, refers to the instance method equals(), but here >> we are talking about static helpers. > > The difference between Marek's suggestion and Joe's is what happens when > the equals(Object) method of a or b returns true for a null argument, and > that is what I was saying violates the spec. > > ?amonn McManus ? JMX Spec Lead ? http://weblogs.java.net/blog/emcmanus > > Hello, Try to understand my point of view. Fist of all we need to notice that returning true for double null-s are not correct for 100% cases. Depending from logic, null might mean 'no object' or 'unknown object' so any way at this point implementation take most common usage. At second hand if we establish that null == Any Object is false we do not gain anything while suggested implementation: 1. It allow to detects if called equals(Object o) is null safe, So there will be no problem if some will use equals(Object o1,Object o2) and then start to use a.equals(b) because it will be called this way in suggested implementation. 2. If some one will need include null in equal logic (is not important now what is the reason) he will be able to do it without re-implementing this part of code. So with suggested implementation we do not lose anything because specification of equals(Object o) is still valid, it just allow to extend it with null support which is main reason why it should be called from Objects. -- Regards. Lasu aka Marek Kozie? http://lasu2string.blogspot.com/ From opinali at gmail.com Fri Oct 9 05:50:23 2009 From: opinali at gmail.com (Osvaldo Doederlein) Date: Fri, 9 Oct 2009 09:50:23 -0300 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? In-Reply-To: <4ACE44A9.8060506@sun.com> References: <4ACE44A9.8060506@sun.com> Message-ID: Hi, Some suggestions: 1) Any equals*(a, b) methods should support a==null && b==null returning true, only a==null returning -1, and only b==null returning +1. This is very useful for much the same reasons that it's useful in SQL (although the exact ordering of null/non-null is debatable - SQL defaults to "nulls last" but allows you to specify NULLS FIRST, and I agree that its default "nulls first" makes more sense most of the time). This handling of nulls should also extend to any elements of a and b. 2) What the platform REALLY needs is a System.arrayequals(Object src1, int pos1, Object src2, int pos2, int length) that, just like the existing arraycopy(), handles arrays of arbitrary types (that's why src1/src2 are specified as Object). The implementation is trivial (with JNI): just compare the element types, do all the parameter/bound checking and if OK, call memcmp() with the addresses of src1[pos1] and src2[pos2], and length translated to bytes. A better implementation would perform intrinsic compilation. I think the various typed Arrays.equals(a,b) methods already do such optimization (the reason for documentation like: "Unlike the ==operator, this method considers NaN equals to itself, and 0.0d unequal to -0.0d."), but these still leave use with the cost of a long case analysis for scenarios like deepEquals() that must handle arrays of arbitrary element-types. IMHO all those typed equals(a,b) should just delegate to a single method, in the System class (not Arrays, not ObjectUtils or whatever), that provides a low-level "raw equals" function. With this low-level (but still safe) function, we can build higher-level APIs like a deepEquals(a,b) with optimum performance. Also, in the current platform there's ByteBuffer.equals() that supports comparison of buffers of arbitrary element types without case analysis, and I guess is also compiled as intrinsic; but I don't want to wrap all my arrays in NIO buffers. The ByteBuffer.equals() should also delegate to the unified System.arrayequals(). A+ Osvaldo 2009/10/8 Joseph D. Darcy > Another piece of functionality requested in the j.u.Objects thread was a > deepEquals(Object a, Object b.) method that "did the right thing" if the > arguments happened to dynamically be arrays. > > I've been thinking a bit how this might be implemented. > > The array-ness of a and b would need to be determined, after any up-front > null-checks > > boolean aIsArray = a.getClass().isArray(); > boolean bIsArray = b.getClass().isArray(); > > followed various case-analyses. > > if (aIsArray && bIsArray) { > Class aComponentType = a.getClass().getComponentType(); > Class bComponentType = b.getClass().getComponentType(); > if (aComponentType == bComponentType) { > // long case analysis to cast and call Arrays.deepEquals if > ComponentType is a reference type > // or the matching Arrays.equals(primitiveComponent[], > primitiveComponent[]) method if > // aComponentType.isPrimitive(). > } else > return false; > } else > return a.equals(b); > > Certainly a bit messy internally. > > What are scenarios where this method would be used? > > -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091009/0bb5265a/attachment.html From John.Rose at Sun.COM Fri Oct 9 08:12:00 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 09 Oct 2009 08:12:00 -0700 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: <38a53eb30910051101n1cd69750r99455ec8dfc5a6b9@mail.gmail.com> References: <1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr> <7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com> <38a53eb30910051101n1cd69750r99455ec8dfc5a6b9@mail.gmail.com> Message-ID: Thanks, Ben; well said. Putting a multi-language JVM feature under java.lang would be the wrong signal. OTOH, if we ever do a type "Dynamic" in the Java language (a la C#) that would belong in java.lang. But we are not, at present. (Despite an earlier blog proposal of mine!) JVM changes are a big enough job for now. -- John On Oct 5, 2009, at 11:01 AM, Ben Evans wrote: > I think this is somewhat of a red herring. > > After all, there are many classes which live in java.lang which are > fundamental to the operation of the platform, and which any language > which lived on top of the VM would have an intimate relationship > with (eg Object, Class, String, etc). > > If we are moving to a point of view in which the Java language is > not central to the platform, but rather first among equals (by > removing all direct dependencies of the JVM spec on the JLS, etc), > then in an ideal world these classes would live in java.core or > java.platform or something. That would of course break the whole > world, so is clearly not going to happen. The best we can do is not > make the situation worse for future amendments, by not placing > additional classes which are not specific to the Java language into > java.lang. > > I am puzzled, however, by your assertion that dynamic invocation is > closer to the language than 'not', ie closer to the language than > the platform. > > Non-Java languages have been making use (and shipping support for, > in some cases) of dynamic invocation for quite a few months now. The > experience of those language's implementors has been integral to the > development process of this feature. The Java language has been > playing catch-up throughout. It's fantastic that it's in the JLS now > and I look forward to seeing some first-class implementations of it, > but this feature really wasn't crafted with Java as the pre-eminent > use case. > > Ben From pbenedict at apache.org Fri Oct 9 08:26:55 2009 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 9 Oct 2009 10:26:55 -0500 Subject: JSR-292: Why not java.lang.dyn? Message-ID: For the background on my reasoning, the popular shift towards dynamic languages makes me wonder how far off a C#-like dynamic feature is for Java too. I hedge my bet that it will eventually happen -- years upon years away -- when more serious use cases are found. Thus, to prevent the case of split packages (java.dyn and java.lang.dyn), I chose to bring up the discussion. Ben and John, thank you for your responses. It is good to understand your vantage. Paul From schulz at e-spirit.de Fri Oct 9 02:18:20 2009 From: schulz at e-spirit.de (Schulz, Stefan) Date: Fri, 9 Oct 2009 11:18:20 +0200 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? In-Reply-To: <4ACE44A9.8060506@sun.com> References: <4ACE44A9.8060506@sun.com> Message-ID: <7D2077BFF677D2429DDDEE095D9A48AC13B81C69@osiris2.e-spirit.de> Joe wrote: > Another piece of functionality requested in the j.u.Objects > thread was a > deepEquals(Object a, Object b.) method that "did the right > thing" if the > arguments happened to dynamically be arrays. > > I've been thinking a bit how this might be implemented. > > The array-ness of a and b would need to be determined, after any > up-front null-checks > > boolean aIsArray = a.getClass().isArray(); > boolean bIsArray = b.getClass().isArray(); > > followed various case-analyses. > > if (aIsArray && bIsArray) { > Class aComponentType = a.getClass().getComponentType(); > Class bComponentType = b.getClass().getComponentType(); > if (aComponentType == bComponentType) { > // long case analysis to cast and call Arrays.deepEquals if > ComponentType is a reference type > // or the matching Arrays.equals(primitiveComponent[], > primitiveComponent[]) method if > // aComponentType.isPrimitive(). > } else > return false; > } else > return a.equals(b); > > Certainly a bit messy internally. I've attached the implementation we use below. And, yes, it is a bit messy ;) Two points, which might not be standard: if one of the argument is null or only one of the arguments is an array, the implementation returns false. I saw that your proposed equals() method does allow for an object to decide upon true or false, if only the second argument is null. As will the above approach allow for any object to decide upen true or false, if the given argument is an array. Both may or may not be desired, but usually should not according to the contract of equals(). > What are scenarios where this method would be used? We use it in generic environments. For example, some event handling implementation, that fires only on data change, where the concrete type of data is not known (as this knowledge is not important for handling mechanisms). Another one are generic key-based data caches. Stefan public static boolean deepEquals(final Object a, final Object b) { if (a == b) { return true; } if (a == null || b == null) { return false; } if (a.getClass().isArray()) { if ( ! b.getClass().isArray()) { return false; } final Class type = a.getClass().getComponentType(); if (type.isPrimitive()) { if (b.getClass().getComponentType() != type) { return false; } if (type == Byte.TYPE) { return Arrays.equals((byte[]) a, (byte[]) b); } if (type == Short.TYPE) { return Arrays.equals((short[]) a, (short[]) b); } if (type == Integer.TYPE) { return Arrays.equals((int[]) a, (int[]) b); } if (type == Long.TYPE) { return Arrays.equals((long[]) a, (long[]) b); } if (type == Character.TYPE) { return Arrays.equals((char[]) a, (char[]) b); } if (type == Float.TYPE) { return Arrays.equals((float[]) a, (float[]) b); } if (type == Double.TYPE) { return Arrays.equals((double[]) a, (double[]) b); } if (type == Boolean.TYPE) { return Arrays.equals((boolean[]) a, (boolean[]) b); } } return Arrays.deepEquals((Object[]) a, (Object[]) b); } return a.equals(b); } From jjb at google.com Fri Oct 9 09:55:46 2009 From: jjb at google.com (Joshua Bloch) Date: Fri, 9 Oct 2009 09:55:46 -0700 Subject: j.ul.Objects follow-up: methods for var-argification? In-Reply-To: <4ACE30B8.8070302@sun.com> References: <4ACE30B8.8070302@sun.com> Message-ID: <17b2302a0910090955t2c44539ch9212dc4ef31f2411@mail.gmail.com> Joe, I'm not sure I like this idea. My one experience with forcing an array method to do double duty as varargs method was a disaster. The method was Arrays.asList, and the result was Puzzler # 7 from "The Continuing Adventures of Java?Puzzlers: Tiger Traps." Here it is: *7. ?Fib O?Nacci?* public class Fibonacci { private static final int LENGTH = 7; public static void main(String[] args) { int[] fib = new int[LENGTH]; fib[0] = fib[1] = 1; // First 2 Fibonacci numbers for (inti = 2; i < LENGTH; i++) fib[i] = fib[i -2] + fib[i -1]; System.out.println(Arrays.asList(fib)); } } The main moral of the puzzle was: Use varargssparingly in your APIs ?It can hide errors and cause confusion ?This program wouldn't compile under 1.4 Arrays.hashCode, equals, and toString are already overloaded out the wazoo; adding varargs to the mix could be deadly. Also, Arrays is not the place where people would go looking for what is essentially a hashing utility. So I'm not in favor of varargifying the existing methods in Arrays, but I am in favor of adding a convenience method like this somewhere: /** * Generates a hash code for a sequence of input values. The hash code is * generated as if all the input values were placed into an array, and that * array were hashed by calling {@link Arrays#hashCode(Object[])}. *

*

This method is useful for implementing {@link Object#hashCode()} on * objects containing multiple fields. For example, if an object that has * three fields, {@code x}, {@code y}, and {@code z}, one could write: * 

     * @Override public int hashCode() {
     *     return Objects.hashCode(x, y, z);
     * }
     *
* Warning: When a single object reference is supplied, the returned * value does not equal the hash code of that object reference. This * value can be computed by calling {@link #hashCode(Object)}. */ public static int hash(Object... components) { return Arrays.hashCode(components); } Viewed in isolation, it's simple, straightforward, and will help people write high quality hashCode methods. I don't think Objects is a bad place for it, but you could put it is a "hash utility" class if we wrote such a thing. Josh On Thu, Oct 8, 2009 at 11:34 AM, Joseph D. Darcy wrote: > Hello. > > In the discussion about java.util.Objects, a few existing JDK methods were > mentioned for possible var-argification: > > java.util.Arrays.hashCode(Object[] a) > java.util.Arrays.deepHashCode(Object[] a) > java.util.Arrays.toString(Object[] a) > > Also of possible general interest are some methods on String (bug 6762452 > API change proposal: Enhance String constructor for varargs) > > java.lang.String.copyValueOf(char[] data) > java.lang.String.valueOf(char[] data) > java.lang.String(char[] value) > > Var-argification is fully binary compatible and is generally source > compatible, although new conversions are allowed of course and overloadings > may change. > > -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091009/27b1dc5d/attachment.html From Joe.Darcy at Sun.COM Fri Oct 9 11:46:35 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 09 Oct 2009 11:46:35 -0700 Subject: j.ul.Objects follow-up: methods for var-argification? In-Reply-To: <4ACEF564.8000407@gmx.de> References: <4ACE30B8.8070302@sun.com> <4ACEF564.8000407@gmx.de> Message-ID: <4ACF850B.4000804@sun.com> Ulf Zibis wrote: > Am 08.10.2009 20:34, Joseph D. Darcy schrieb: >> Hello. >> >> In the discussion about java.util.Objects, a few existing JDK methods >> were mentioned for possible var-argification: >> >> java.util.Arrays.hashCode(Object[] a) >> java.util.Arrays.deepHashCode(Object[] a) >> java.util.Arrays.toString(Object[] a) >> >> Also of possible general interest are some methods on String (bug >> 6762452 API change proposal: Enhance String constructor for varargs) >> >> java.lang.String.copyValueOf(char[] data) >> java.lang.String.valueOf(char[] data) >> java.lang.String(char[] value) >> >> Var-argification is fully binary compatible and is generally source >> compatible, although new conversions are allowed of course and >> overloadings may change. >> > > As String is final, there are no changed overloadings. > As the Arrays methods are static, there are too no changed overloadings. Being final and static alone are not enough to guarantee no new overloadings; although the overloading resolution rules are carefully crafted to try to select the same method if var-args is added to a class. > > OK, correct me, if I'm wrong. > FYI, here is a var-argification which breaks source compatibility: Consider in final class C Before: static void foo(int..) static void foo(Integer[]) After: static void foo(int...) static void foo(Integer...) Call site: C.foo(42); In the after scenario, both versions of foo *could* now be called and there is an ambiguity whereas before only the int... method could have been called. For some interesting discussion of overloading, see http://gbracha.blogspot.com/2009/09/systemic-overload.html -Joe From Joe.Darcy at Sun.COM Fri Oct 9 10:42:19 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 09 Oct 2009 10:42:19 -0700 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? In-Reply-To: <4ACF02B9.8070708@sun.com> References: <4ACE44A9.8060506@sun.com> <4ACF02B9.8070708@sun.com> Message-ID: <4ACF75FB.3000209@sun.com> Eamonn McManus wrote: > Joseph D. Darcy wrote: > > What are scenarios where this method would be used? > > I use a similar method fairly often in unit tests. JUnit's > assertEquals doesn't > do the right thing if its arguments happen to be arrays, so I use the > following > simple if inefficient implementation: > > static void deepEquals(Object x, Object y) { > return Arrays.deepEquals(new Object[] {x}, new Object[] {y}); > } > > What that shows of course is that the messy logic you mention is > already present in > Arrays.deepEquals so you could factor it out. Yes, the logic inside the for loop in deepEquals could be factored out into just the right package-private helper method. Thanks for the pointer! -Joe From Joe.Darcy at Sun.COM Fri Oct 9 14:50:56 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 09 Oct 2009 14:50:56 -0700 Subject: Code review request for 6648344: (reflect spec) State default of isAccessible for reflective objects Message-ID: <4ACFB040.3050503@sun.com> Hello. Please review this simple specification clarification (with accompanying test) for 6648344: (reflect spec) State default of isAccessible for reflective objects -Joe --- old/src/share/classes/java/lang/reflect/AccessibleObject.java 2009-10-09 14:48:35.000000000 -0700 +++ new/src/share/classes/java/lang/reflect/AccessibleObject.java 2009-10-09 14:48:35.000000000 -0700 @@ -44,6 +44,8 @@ * as Java Object Serialization or other persistence mechanisms, to * manipulate objects in a manner that would normally be prohibited. * + *

By default, a reflected object is not accessible. + * * @see Field * @see Method * @see Constructor --- /dev/null 2009-07-06 20:02:10.000000000 -0700 +++ new/test/java/lang/reflect/DefaultAccessibility.java 2009-10-09 14:48:36.000000000 -0700 @@ -0,0 +1,69 @@ +/* + * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, + * CA 95054 USA or visit www.sun.com if you need additional information or + * have any questions. + */ + +/* + * @test + * @bug 6648344 + * @summary Test that default accessibility is false + * @author Joseph D. Darcy + */ + +import java.lang.reflect.*; + +public class DefaultAccessibility { + private DefaultAccessibility() { + super(); + } + + private static int f = 42; + + public static void main(String... args) throws Exception { + Class daClass = (new DefaultAccessibility()).getClass(); + + int elementCount = 0; + for(Constructor ctor : daClass.getDeclaredConstructors()) { + elementCount++; + if (ctor.isAccessible()) + throw new RuntimeException("Unexpected accessibility for constructor " + + ctor); + } + + for(Method method : daClass.getDeclaredMethods()) { + elementCount++; + if (method.isAccessible()) + throw new RuntimeException("Unexpected accessibility for method " + + method); + } + + for(Field field : daClass.getDeclaredFields()) { + elementCount++; + if (field.isAccessible()) + throw new RuntimeException("Unexpected accessibility for field " + + field); + } + + if (elementCount < 3) + throw new RuntimeException("Expected at least three members; only found " + + elementCount); + } +} From Joe.Darcy at Sun.COM Fri Oct 9 11:43:45 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 09 Oct 2009 11:43:45 -0700 Subject: Quick code review request for 634992 (enum) Include links from java.lang.Enum to EnumSet and EnumMap Message-ID: <4ACF8461.9070302@sun.com> Please review this tiny doc fix to make EnumSet and EnumMap just a bit easier to find; patch below -Joe --- old/src/share/classes/java/lang/Enum.java 2009-10-09 11:41:23.000000000 -0700 +++ new/src/share/classes/java/lang/Enum.java 2009-10-09 11:41:23.000000000 -0700 @@ -44,6 +44,8 @@ * @author Josh Bloch * @author Neal Gafter * @see Class#getEnumConstants() + * @see java.util.EnumSet + * @see java.util.EnumMap * @since 1.5 */ public abstract class Enum> From neal at gafter.com Fri Oct 9 15:13:49 2009 From: neal at gafter.com (Neal Gafter) Date: Fri, 9 Oct 2009 15:13:49 -0700 Subject: Quick code review request for 634992 (enum) Include links from java.lang.Enum to EnumSet and EnumMap In-Reply-To: <4ACF8461.9070302@sun.com> References: <4ACF8461.9070302@sun.com> Message-ID: <15e8b9d20910091513g69b24616v535edb9fb44c278b@mail.gmail.com> Do EnumSet and EnumMap exist on all platform profiles? On Fri, Oct 9, 2009 at 11:43 AM, Joseph D. Darcy wrote: > Please review this tiny doc fix to make EnumSet and EnumMap just a bit > easier to find; patch below > > -Joe > > --- old/src/share/classes/java/lang/Enum.java ? ?2009-10-09 > 11:41:23.000000000 -0700 > +++ new/src/share/classes/java/lang/Enum.java ? ?2009-10-09 > 11:41:23.000000000 -0700 > @@ -44,6 +44,8 @@ > ?* @author ?Josh Bloch > ?* @author ?Neal Gafter > ?* @see ? ? Class#getEnumConstants() > + * @see ? ? java.util.EnumSet > + * @see ? ? java.util.EnumMap > ?* @since ? 1.5 > ?*/ > public abstract class Enum> > > > > From Joe.Darcy at Sun.COM Fri Oct 9 10:02:42 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 09 Oct 2009 10:02:42 -0700 Subject: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?] In-Reply-To: <4ACEFF44.4070806@sun.com> References: <4ACE2BFA.9060205@sun.com> <4ACE2FC5.7070702@sun.com> <4ACE7B80.3020401@sun.com> <4ACEFF44.4070806@sun.com> Message-ID: <4ACF6CB2.8000408@sun.com> Eamonn McManus wrote: > David Holmes - Sun Microsystems wrote: > > So to me: String toString(Object o, String useIfNull) is the only > method > > that provides true utility in this case. > > I agree with that, and would just suggest to the person specifying the > method > to add a @see String#valueOf(Object). I find that the behaviour of > that method Agreed, that @see, amongst others, has been in the patch for this change http://cr.openjdk.java.net/~darcy/6797535.1/ -Joe From Ulf.Zibis at gmx.de Fri Oct 9 14:19:51 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 09 Oct 2009 23:19:51 +0200 Subject: j.ul.Objects follow-up: methods for var-argification? In-Reply-To: <4ACF850B.4000804@sun.com> References: <4ACE30B8.8070302@sun.com> <4ACEF564.8000407@gmx.de> <4ACF850B.4000804@sun.com> Message-ID: <4ACFA8F7.7040803@gmx.de> Joe, much thank for your explanation. :-) -Ulf Am 09.10.2009 20:46, Joseph D. Darcy schrieb: > Ulf Zibis wrote: >> Am 08.10.2009 20:34, Joseph D. Darcy schrieb: >>> Hello. >>> >>> In the discussion about java.util.Objects, a few existing JDK >>> methods were mentioned for possible var-argification: >>> >>> java.util.Arrays.hashCode(Object[] a) >>> java.util.Arrays.deepHashCode(Object[] a) >>> java.util.Arrays.toString(Object[] a) >>> >>> Also of possible general interest are some methods on String (bug >>> 6762452 API change proposal: Enhance String constructor for varargs) >>> >>> java.lang.String.copyValueOf(char[] data) >>> java.lang.String.valueOf(char[] data) >>> java.lang.String(char[] value) >>> >>> Var-argification is fully binary compatible and is generally source >>> compatible, although new conversions are allowed of course and >>> overloadings may change. >>> >> >> As String is final, there are no changed overloadings. >> As the Arrays methods are static, there are too no changed overloadings. > > Being final and static alone are not enough to guarantee no new > overloadings; although the overloading resolution rules are carefully > crafted to try to select the same method if var-args is added to a class. > >> >> OK, correct me, if I'm wrong. >> > > FYI, here is a var-argification which breaks source compatibility: > > Consider in final class C > > Before: > static void foo(int..) > static void foo(Integer[]) > > After: > static void foo(int...) > static void foo(Integer...) > > Call site: > > C.foo(42); > > In the after scenario, both versions of foo *could* now be called and > there is an ambiguity whereas before only the int... method could have > been called. > > For some interesting discussion of overloading, see > http://gbracha.blogspot.com/2009/09/systemic-overload.html > > -Joe > > From Ulf.Zibis at gmx.de Fri Oct 9 13:47:58 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 09 Oct 2009 22:47:58 +0200 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <1ccfd1c10910072140j737d99a3ha2a6324b81db1fdd@mail.gmail.com> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> <1ccfd1c10910071501x11afd491ocf00289d10d9100d@mail.gmail.com> <4ACD1D21.4000805@gmx.de> <1ccfd1c10910072140j737d99a3ha2a6324b81db1fdd@mail.gmail.com> Message-ID: <4ACFA17E.4050905@gmx.de> Am 08.10.2009 06:40, Martin Buchholz schrieb: > If you can show that a simple test program that appears to access > only 2 charsets in fact causes accesses to 3 or 4, that is a serious > problem with the 2-element cache. > See attachment: - simple JUnit test class - NetBeans project, ready to build and run - charset usage log > People at Google are working on better caches, > but I don't think they are quite ready today. > > Perhaps, instead of a small charset cache, > we could cache all the charsets, but for the > large charsets like GB18030, we could, > inside the charset implementation, cache the > large data tables using a soft reference, and recompute > as needed. Then most of the static memory used > by an unused charset could be reclaimed. > I have implemented exactly this here: https://bugs.openjdk.java.net/show_bug.cgi?id=100098 -Ulf -------------- next part -------------- A non-text attachment was scrubbed... Name: CharsetTest.java Type: java/* Size: 1491 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091009/cf24f60a/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: nio_charset_usage.zip Type: application/x-zip-compressed Size: 21418 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091009/cf24f60a/attachment-0003.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: charset_usage.log Url: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091009/cf24f60a/attachment-0001.ksh From Ulf.Zibis at gmx.de Fri Oct 9 12:52:28 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 09 Oct 2009 21:52:28 +0200 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: References: Message-ID: <4ACF947C.7000808@gmx.de> I would name it javax.dyn. -Ulf Am 04.10.2009 06:43, Paul Benedict schrieb: > I've always found it a bit perplexing that java.lang was never chosen > for the parent package of the Dynamic API. Why is that? Dynamic types > are now "part of the language" as proven by spec itself and exotic > identifiers. Will this be reconsidered? > > Paul > > > From jjb at google.com Fri Oct 9 15:43:52 2009 From: jjb at google.com (Joshua Bloch) Date: Fri, 9 Oct 2009 15:43:52 -0700 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? In-Reply-To: <4ACF75FB.3000209@sun.com> References: <4ACE44A9.8060506@sun.com> <4ACF02B9.8070708@sun.com> <4ACF75FB.3000209@sun.com> Message-ID: <17b2302a0910091543m4e9044e8k926ead71fec6aef3@mail.gmail.com> I don't think method really pays for itself. If it belongs anywhere, it belongs in java.util.Arrays. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091009/f8e873fe/attachment.html From Joe.Darcy at Sun.COM Fri Oct 9 16:13:11 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Fri, 09 Oct 2009 16:13:11 -0700 Subject: Quick code review request for 634992 (enum) Include links from java.lang.Enum to EnumSet and EnumMap In-Reply-To: <15e8b9d20910091513g69b24616v535edb9fb44c278b@mail.gmail.com> References: <4ACF8461.9070302@sun.com> <15e8b9d20910091513g69b24616v535edb9fb44c278b@mail.gmail.com> Message-ID: <4ACFC387.6040501@sun.com> Neal Gafter wrote: > Do EnumSet and EnumMap exist on all platform profiles? They exist on JDK 7 where this change is intended. -Joe > On Fri, Oct 9, 2009 at 11:43 AM, Joseph D. Darcy wrote: >> Please review this tiny doc fix to make EnumSet and EnumMap just a bit >> easier to find; patch below >> >> -Joe >> >> --- old/src/share/classes/java/lang/Enum.java 2009-10-09 >> 11:41:23.000000000 -0700 >> +++ new/src/share/classes/java/lang/Enum.java 2009-10-09 >> 11:41:23.000000000 -0700 >> @@ -44,6 +44,8 @@ >> * @author Josh Bloch >> * @author Neal Gafter >> * @see Class#getEnumConstants() >> + * @see java.util.EnumSet >> + * @see java.util.EnumMap >> * @since 1.5 >> */ >> public abstract class Enum> >> >> >> >> From joe.darcy at sun.com Fri Oct 9 16:11:36 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Fri, 09 Oct 2009 23:11:36 +0000 Subject: hg: jdk7/tl/jdk: 6797535: Add shared two argument static equals method to the platform Message-ID: <20091009231219.E3E7F41408@hg.openjdk.java.net> Changeset: 3b45b809d8ff Author: darcy Date: 2009-10-09 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b45b809d8ff 6797535: Add shared two argument static equals method to the platform Reviewed-by: sherman ! make/java/java/FILES_java.gmk + src/share/classes/java/util/Objects.java + test/java/util/Objects/BasicObjectsTest.java From neal at gafter.com Fri Oct 9 17:09:36 2009 From: neal at gafter.com (Neal Gafter) Date: Fri, 9 Oct 2009 17:09:36 -0700 Subject: Quick code review request for 634992 (enum) Include links from java.lang.Enum to EnumSet and EnumMap In-Reply-To: <4ACFC387.6040501@sun.com> References: <4ACF8461.9070302@sun.com> <15e8b9d20910091513g69b24616v535edb9fb44c278b@mail.gmail.com> <4ACFC387.6040501@sun.com> Message-ID: <15e8b9d20910091709u66f1e03cve4ff57c6bfbd6501@mail.gmail.com> Generally speaking, lower levels in the system shouldn't refer to higher levels. In this case it's just a comment, but it isn't clear that every profile that includes Enum will include the collections framework. I'm thinking, for example, about ME profiles. -Neal On Fri, Oct 9, 2009 at 4:13 PM, Joe Darcy wrote: > Neal Gafter wrote: > >> Do EnumSet and EnumMap exist on all platform profiles? >> > > They exist on JDK 7 where this change is intended. > > -Joe > > > On Fri, Oct 9, 2009 at 11:43 AM, Joseph D. Darcy >> wrote: >> >>> Please review this tiny doc fix to make EnumSet and EnumMap just a bit >>> easier to find; patch below >>> >>> -Joe >>> >>> --- old/src/share/classes/java/lang/Enum.java 2009-10-09 >>> 11:41:23.000000000 -0700 >>> +++ new/src/share/classes/java/lang/Enum.java 2009-10-09 >>> 11:41:23.000000000 -0700 >>> @@ -44,6 +44,8 @@ >>> * @author Josh Bloch >>> * @author Neal Gafter >>> * @see Class#getEnumConstants() >>> + * @see java.util.EnumSet >>> + * @see java.util.EnumMap >>> * @since 1.5 >>> */ >>> public abstract class Enum> >>> >>> >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091009/4154eb2a/attachment.html From pbenedict at apache.org Fri Oct 9 18:20:59 2009 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 9 Oct 2009 20:20:59 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? Message-ID: Joe, I think java.util.Objects could benefit from the "final" modifier. Since its constructor always fails, there is no reason to subclass it (i.e., super constructor always fails). I believe Josh's "Effective Java" book makes such a point about static utility classes. Paul From Joe.Darcy at Sun.COM Fri Oct 9 18:38:40 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 09 Oct 2009 18:38:40 -0700 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: References: Message-ID: <4ACFE5A0.70202@sun.com> Paul Benedict wrote: > Joe, > > I think java.util.Objects could benefit from the "final" modifier. > Since its constructor always fails, there is no reason to subclass it > (i.e., super constructor always fails). I believe Josh's "Effective > Java" book makes such a point about static utility classes. > > Paul > Hello. Classes with only private constructors, like j.u.Objects, are effectively final. Adding final is harmless but unnecessary in these cases. The platform is a bit inconsistent here; j.u.Collections is *not* marked final while j.l.Math is. In practice, it doesn't matter very much; I'll consider final-izing j.u.Objects on the next round of edits. -Joe From pbenedict at apache.org Fri Oct 9 18:55:04 2009 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 9 Oct 2009 20:55:04 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACFE5A0.70202@sun.com> References: <4ACFE5A0.70202@sun.com> Message-ID: Joe, > Classes with only private constructors, like j.u.Objects, are effectively > final. ?Adding final is harmless but unnecessary in these cases. Understood, but the keyword (pun) here is "effectively". Why let a developer wait until runtime to find out his code will fail? At least by marking the class as final, anybody who wishes to subclass it will receive a compiler error. Rain on the parade early :-) Anyway, thanks for considering it in the next round. Paul From crazybob at crazybob.org Fri Oct 9 19:07:43 2009 From: crazybob at crazybob.org (Bob Lee) Date: Fri, 9 Oct 2009 19:07:43 -0700 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: References: <4ACFE5A0.70202@sun.com> Message-ID: On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict wrote: > Understood, but the keyword (pun) here is "effectively". Why let a > developer wait until runtime to find out his code will fail? At least > by marking the class as final, anybody who wishes to subclass it will > receive a compiler error. Rain on the parade early :-) > Paul, this is caught at compile time, since you can't call the private constructor. The "final" would be redundant. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091009/0d71f92e/attachment.html From pbenedict at apache.org Fri Oct 9 19:14:59 2009 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 9 Oct 2009 21:14:59 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: References: <4ACFE5A0.70202@sun.com> Message-ID: Thank you, Bob. I stand corrected. On Fri, Oct 9, 2009 at 9:07 PM, Bob Lee wrote: > On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict wrote: >> >> Understood, but the keyword (pun) here is "effectively". Why let a >> developer wait until runtime to find out his code will fail? At least >> by marking the class as final, anybody who wishes to subclass it will >> receive a compiler error. Rain on the parade early :-) > > Paul, this is caught at compile time, since you can't call the private > constructor. The "final" would be redundant. > Bob From John.Rose at Sun.COM Fri Oct 9 19:49:34 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 09 Oct 2009 19:49:34 -0700 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: <7c1bea4b0910091936v564b4c15i932831b64061c407@mail.gmail.com> References: <1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr> <7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com> <38a53eb30910051101n1cd69750r99455ec8dfc5a6b9@mail.gmail.com> <7c1bea4b0910091936v564b4c15i932831b64061c407@mail.gmail.com> Message-ID: <6DCA11A7-65FD-4EC1-A0C4-E81D0D8DBFDB@sun.com> On Oct 9, 2009, at 7:36 PM, Stepan Koltsov wrote: > John, how about multi-language java.lang.Class or > java.lang.reflect.Field? How about it? I don't know how to answer this. -- John From yozh at mx1.ru Fri Oct 9 19:36:22 2009 From: yozh at mx1.ru (Stepan Koltsov) Date: Sat, 10 Oct 2009 06:36:22 +0400 Subject: JSR-292: Why not java.lang.dyn? In-Reply-To: References: <1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr> <7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com> <38a53eb30910051101n1cd69750r99455ec8dfc5a6b9@mail.gmail.com> Message-ID: <7c1bea4b0910091936v564b4c15i932831b64061c407@mail.gmail.com> John, how about multi-language java.lang.Class or java.lang.reflect.Field? S. On Fri, Oct 9, 2009 at 19:12, John Rose wrote: > Thanks, Ben; well said. ?Putting a multi-language JVM feature under > java.lang would be the wrong signal. ?OTOH, if we ever do a type > "Dynamic" in the Java language (a la C#) that would belong in > java.lang. ?But we are not, at present. ?(Despite an earlier blog > proposal of mine!) ?JVM changes are a big enough job for now. ?-- John > > On Oct 5, 2009, at 11:01 AM, Ben Evans wrote: > >> I think this is somewhat of a red herring. >> >> After all, there are many classes which live in java.lang which are >> fundamental to the operation of the platform, and which any language >> which lived on top of the VM would have an intimate relationship >> with (eg Object, Class, String, etc). >> >> If we are moving to a point of view in which the Java language is >> not central to the platform, but rather first among equals (by >> removing all direct dependencies of the JVM spec on the JLS, etc), >> then in an ideal world these classes would live in java.core or >> java.platform or something. That would of course break the whole >> world, so is clearly not going to happen. The best we can do is not >> make the situation worse for future amendments, by not placing >> additional classes which are not specific to the Java language into >> java.lang. >> >> I am puzzled, however, by your assertion that dynamic invocation is >> closer to the language than 'not', ie closer to the language than >> the platform. >> >> Non-Java languages have been making use (and shipping support for, >> in some cases) of dynamic invocation for quite a few months now. The >> experience of those language's implementors has been integral to the >> development process of this feature. The Java language has been >> playing catch-up throughout. It's fantastic that it's in the JLS now >> and I look forward to seeing some first-class implementations of it, >> but this feature really wasn't crafted with Java as the pre-eminent >> use case. >> >> Ben > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From pbenedict at apache.org Sat Oct 10 16:00:02 2009 From: pbenedict at apache.org (Paul Benedict) Date: Sat, 10 Oct 2009 18:00:02 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: References: <4ACFE5A0.70202@sun.com> Message-ID: My final comment on this trifling matter is regarding the documentation. I don't think private methods/fields are included in the JDK's javadoc. If the private constructor will not appear, I recommend adding "final" and/or documenting the class as not instantiable/subclassable. Now that I know the compiler will warn about this issue (thank you Bob), the next consideration is for those who are reading the docs online. Paul On Fri, Oct 9, 2009 at 9:07 PM, Bob Lee wrote: > On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict wrote: >> >> Understood, but the keyword (pun) here is "effectively". Why let a >> developer wait until runtime to find out his code will fail? At least >> by marking the class as final, anybody who wishes to subclass it will >> receive a compiler error. Rain on the parade early :-) > > Paul, this is caught at compile time, since you can't call the private > constructor. The "final" would be redundant. > Bob From alan.bateman at sun.com Sun Oct 11 04:27:51 2009 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Sun, 11 Oct 2009 11:27:51 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20091011112912.CFA9F41536@hg.openjdk.java.net> Changeset: b84f40617f90 Author: alanb Date: 2009-10-09 09:59 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b84f40617f90 6889552: Sun provider should not require LDAP CertStore to be present Reviewed-by: vinnie, mullan ! src/share/classes/sun/security/provider/SunEntries.java + src/share/classes/sun/security/provider/certpath/CertStoreHelper.java - src/share/classes/sun/security/provider/certpath/LDAPCertStore.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java + src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java + src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java Changeset: a7ad133103c6 Author: alanb Date: 2009-10-09 10:06 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a7ad133103c6 6888552: Allow JNDI to be used when java.applet is not present Reviewed-by: vinnie ! src/share/classes/com/sun/naming/internal/ResourceManager.java Changeset: f6770138c0fa Author: alanb Date: 2009-10-10 10:14 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f6770138c0fa Merge From Joe.Darcy at Sun.COM Sun Oct 11 15:51:12 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Sun, 11 Oct 2009 15:51:12 -0700 Subject: Quick code review request for 634992 (enum) Include links from java.lang.Enum to EnumSet and EnumMap In-Reply-To: <15e8b9d20910091709u66f1e03cve4ff57c6bfbd6501@mail.gmail.com> References: <4ACF8461.9070302@sun.com> <15e8b9d20910091513g69b24616v535edb9fb44c278b@mail.gmail.com> <4ACFC387.6040501@sun.com> <15e8b9d20910091709u66f1e03cve4ff57c6bfbd6501@mail.gmail.com> Message-ID: <4AD26160.409@sun.com> Neal Gafter wrote: > Generally speaking, lower levels in the system shouldn't refer to > higher levels. In this case it's just a comment, but it isn't clear > that every profile that includes Enum will include the collections > framework. I'm thinking, for example, about ME profiles. A few comments on this. Yes, in general it is true that lower levels shouldn't depend on higher levels. That was the primary reason we decided to have the new reflection methods in JDK 5 return arrays rather than generic collections. However, than are many nuances here. First, there is a difference between an API level dependency, like a type used in a signature, and an implementation dependency, something that only appears in a method body. A further distinction is between a compile-time implementation dependency and a runtime-only one, such as when a class is looked up reflectively. Additionally, if collections and java.lang.Enum are in the same grouping, there is no problem in having the dependency. Second, the underlying model for creating platform javadoc is "compile the world" so the presence of absence of particular edges in the dependency graph don't really affect what needs to happen. Finally, the onus for subsetting the API documentation for platform subsets ultimately falls on those doing the subsetting. The javadoc build warnings will be there to guide them. In short, IMO this is an entirely innocuous change that will help those learning Java find the enum-optimized set and map implementations. I would even consider adding "Note that when using enums in sets or as keys in a map, optimized set and map implementations are available." Which is probably about an order of magnitude more consideration than this change deserves! -Joe > > -Neal > > On Fri, Oct 9, 2009 at 4:13 PM, Joe Darcy > wrote: > > Neal Gafter wrote: > > Do EnumSet and EnumMap exist on all platform profiles? > > > They exist on JDK 7 where this change is intended. > > -Joe > > > On Fri, Oct 9, 2009 at 11:43 AM, Joseph D. Darcy > > wrote: > > Please review this tiny doc fix to make EnumSet and > EnumMap just a bit > easier to find; patch below > > -Joe > > --- old/src/share/classes/java/lang/Enum.java 2009-10-09 > 11:41:23.000000000 -0700 > +++ new/src/share/classes/java/lang/Enum.java 2009-10-09 > 11:41:23.000000000 -0700 > @@ -44,6 +44,8 @@ > * @author Josh Bloch > * @author Neal Gafter > * @see Class#getEnumConstants() > + * @see java.util.EnumSet > + * @see java.util.EnumMap > * @since 1.5 > */ > public abstract class Enum> > > > > > > From Thomas.Hawtin at Sun.COM Mon Oct 12 04:54:38 2009 From: Thomas.Hawtin at Sun.COM (Tom Hawtin) Date: Mon, 12 Oct 2009 12:54:38 +0100 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4ACFE5A0.70202@sun.com> References: <4ACFE5A0.70202@sun.com> Message-ID: <4AD318FE.1090206@sun.com> Joseph D. Darcy wrote: > Classes with only private constructors, like j.u.Objects, are > effectively final. Adding final is harmless but unnecessary in these > cases. The platform is a bit inconsistent here; j.u.Collections is > *not* marked final while j.l.Math is. For a certain value of effective. *Current* *Java* *source* may not subclass a non-final class with only private constructors. I believe a verfiable subclass can be created as a class file that does not have a constructor (or possibly definitely throws an exception?). Unless something is seriously wrong, that shouldn't cause a security issue. It might be an issue for other languages on the JVM. > In practice, it doesn't matter > very much; I'll consider final-izing j.u.Objects on the next round of > edits. Oh don't put a finalizer on it. ;) Tom Hawtin From Alan.Bateman at Sun.COM Mon Oct 12 06:43:37 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 12 Oct 2009 14:43:37 +0100 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD3290E.2010507@gmx.de> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> Message-ID: <4AD33289.3000600@sun.com> Ulf Zibis wrote: > : > Anyway, I would like to see zip/jar URIs as valid parameter to open a > file/path/stream/channel via new File(URI) or Paths.get(URI). There is a file system provider (albeit demo/prototype quality) for zip file in the nio repository. Just add ZipFileSystem.jar to your classpath and you can treat the contents of a zip or JAR file as a read-only file system. You can use URIs, such as zip:///home/foo.zip#/top/bar, to locate files if you wish. -Alan. From Alan.Bateman at Sun.COM Mon Oct 12 07:26:44 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 12 Oct 2009 15:26:44 +0100 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD3375C.9030400@gmx.de> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> <4AD3375C.9030400@gmx.de> Message-ID: <4AD33CA4.5020608@sun.com> Ulf Zibis wrote: > Am 12.10.2009 15:03, Ulf Zibis schrieb: >> Additionally something like Path#unlock() would be helpful, if >> copy/delete fails. For example see: >> http://diamondcs.com.au/freeutilities/fileunlocker.php > > Additionally see: http://ccollomb.free.fr/unlocker/ I assume this type of thing can lead to data loss and/or hard to diagnose corruption. If you are running into sharing violations then try out the file system API as the Windows provider opens files by default to allow delete access (ie: close to Unix semantics by default with provider specific options to control the DOS sharing mode if you really want). The only case where we still have a problem is memory-mapped files. Changing the long standing behavior of the java.io classes is another matter as that would likely break existing applications that rely on the current/long standing behavior. -Alan. From Ulf.Zibis at gmx.de Mon Oct 12 07:23:55 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Oct 2009 16:23:55 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD33289.3000600@sun.com> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> <4AD33289.3000600@sun.com> Message-ID: <4AD33BFB.3040201@gmx.de> Am 12.10.2009 15:43, Alan Bateman schrieb: > Ulf Zibis wrote: >> : >> Anyway, I would like to see zip/jar URIs as valid parameter to open a >> file/path/stream/channel via new File(URI) or Paths.get(URI). > There is a file system provider (albeit demo/prototype quality) for > zip file in the nio repository. Just add ZipFileSystem.jar to your > classpath and you can treat the contents of a zip or JAR file as a > read-only file system. You can use URIs, such as > zip:///home/foo.zip#/top/bar, to locate files if you wish. > Alan, that's cool, thanks. Hopefully this goes into trunk of JDK 7, (+ write access ?). Can you give me direct link of ZipFileSystem.jar + javadoc + sources ? If I run this example: System.out.println( sun.nio.cs.ext.SJIS_0213.class.getResource("sjis0213.dat").toURI()); I get: jar:file:/C:/Programme/Java/jdk1.7.0/fastdebug/jre/lib/charsets.jar!/sun/nio/cs/ext/sjis0213.dat This looks little different from your example (scheme + '!' instead '#'). Is that covered too by ZipFileSystem.jar ? -Ulf From Ulf.Zibis at gmx.de Mon Oct 12 04:53:33 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Oct 2009 13:53:33 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4b4f45e00909160433w1c78fa3ct4ae06b35f368ea72@mail.gmail.com> References: <4AA812D0.309@sun.com> <4b4f45e00909091654t7891127bh24cc1df9c38bec7d@mail.gmail.com> <1ccfd1c10909091704i1f4f75dfm4ae1988d0903cd99@mail.gmail.com> <4AA849B1.1090005@sun.com> <1ccfd1c10909091808s772d454epfe7a1057ccb9ca9f@mail.gmail.com> <4AA857A8.1010700@sun.com> <4AAAAE03.5010002@sun.com> <1ccfd1c10909151102r460396fct103b032023311606@mail.gmail.com> <4b4f45e00909160433w1c78fa3ct4ae06b35f368ea72@mail.gmail.com> Message-ID: <4AD318BD.50607@gmx.de> +1 -Ulf Am 16.09.2009 13:33, Stephen Colebourne schrieb: > 2009/9/15 Martin Buchholz : > >> This test is particularly uninteresting. I'll commit soon even if I >> don't get any review comments. >> > > * Returns a hash code for this {@code Byte}; equal to the result > * of invoking {@code intValue()}. > > Doesn't this mean that the added part about intValue() will appear in > the summary text for the method in Javadoc? I'd consider the 'how the > method operates' to be detail, not summary, so would prefer: > > * Returns a hash code for this {@code Byte}. > * The hash code is equal to the result of invoking {@code intValue()}. > > Stephen > > > From Ulf.Zibis at gmx.de Mon Oct 12 06:03:10 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Oct 2009 15:03:10 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AB10D85.8040402@sun.com> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> Message-ID: <4AD3290E.2010507@gmx.de> Am 16.09.2009 18:08, Alan Bateman schrieb: > Joel Kamentz wrote: > >> : >> >> Attempt to convert an URL to a local file, taking into >> account that it might be wrappered by jar:, that File.toURL doesn't >> process %20 and the like, etc. >> > File.toURL is deprecated. You might want to look at File.toURI. Anyway, I would like to see zip/jar URIs as valid parameter to open a file/path/stream/channel via new File(URI) or Paths.get(URI). > > >> Delete files or sub-trees, catching exceptions and instead >> just return success / failure. >> > This one comes up a lot and has been addressed in the file system API > work in jdk7. So if you have a File f you can replace f.delete() with > f.toPath().delete() and it will do what you want. > > Recursive delete is relatively easy too, using Files.walkFileTree. > There's an example in the javadoc that does this (look in > java.nio.file.FileVisitor). I would like to see some convenience methods for deleting/copying subtrees, without having to implement the FileVisitor examples. Additionally something like Path#unlock() would be helpful, if copy/delete fails. For example see: http://diamondcs.com.au/freeutilities/fileunlocker.php -Ulf From Alan.Bateman at Sun.COM Mon Oct 12 08:40:44 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 12 Oct 2009 16:40:44 +0100 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD33BFB.3040201@gmx.de> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> <4AD33289.3000600@sun.com> <4AD33BFB.3040201@gmx.de> Message-ID: <4AD34DFC.3040506@sun.com> Ulf Zibis wrote: > : > Alan, that's cool, thanks. Hopefully this goes into trunk of JDK 7, (+ > write access ?). > Can you give me direct link of ZipFileSystem.jar + javadoc + sources ? Just clone the nio/nio repository. There's a README in jdk/src/share/demo/nio/ZipFileSystem. > > If I run this example: > System.out.println( > > sun.nio.cs.ext.SJIS_0213.class.getResource("sjis0213.dat").toURI()); > I get: > jar:file:/C:/Programme/Java/jdk1.7.0/fastdebug/jre/lib/charsets.jar!/sun/nio/cs/ext/sjis0213.dat > > > This looks little different from your example (scheme + '!' instead '#'). > Is that covered too by ZipFileSystem.jar ? The URI syntax is defined by the provider and this demo provider uses hierarchical URIs with "zip" as the scheme. It wouldn't hard to wrap this provider with another that supports the legacy JAR URL syntax (although that syntax worries me in that it uses opaque URIs and will likely be a challenge if/when the platform is updated to support RFC 3986). -Alan. From Ulf.Zibis at gmx.de Mon Oct 12 07:04:12 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Oct 2009 16:04:12 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD3290E.2010507@gmx.de> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> Message-ID: <4AD3375C.9030400@gmx.de> Am 12.10.2009 15:03, Ulf Zibis schrieb: > Additionally something like Path#unlock() would be helpful, if > copy/delete fails. For example see: > http://diamondcs.com.au/freeutilities/fileunlocker.php Additionally see: http://ccollomb.free.fr/unlocker/ -Ulf From Ulf.Zibis at gmx.de Mon Oct 12 09:11:06 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Oct 2009 18:11:06 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD33CA4.5020608@sun.com> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> <4AD3375C.9030400@gmx.de> <4AD33CA4.5020608@sun.com> Message-ID: <4AD3551A.3090602@gmx.de> Am 12.10.2009 16:26, Alan Bateman schrieb: > Ulf Zibis wrote: >> Am 12.10.2009 15:03, Ulf Zibis schrieb: >>> Additionally something like Path#unlock() would be helpful, if >>> copy/delete fails. For example see: >>> http://diamondcs.com.au/freeutilities/fileunlocker.php >> >> Additionally see: http://ccollomb.free.fr/unlocker/ > I assume this type of thing can lead to data loss and/or hard to > diagnose corruption. Of course, such method should be used with care. The developer/user should first retrieve/examine some information like the blocking process from the locked file. But this option should be more comfortable, than rebooting the hole system, which too could have data loss/corruption in consequence. ... and delete always has data loss in effect. ;-) > If you are running into sharing violations then try out the file > system API as the Windows provider opens files by default to allow > delete access (ie: close to Unix semantics by default with provider > specific options to control the DOS sharing mode if you really want). In java.nio.file.Filesystem b72 I don't find information about sharing attributes. > The only case where we still have a problem is memory-mapped files. > Changing the long standing behavior of the java.io classes is another > matter as that would likely break existing applications that rely on > the current/long standing behavior. > > -Alan. > > -Ulf From Joe.Darcy at Sun.COM Mon Oct 12 10:25:42 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 12 Oct 2009 10:25:42 -0700 Subject: j.ul.Objects follow-up: methods for var-argification? In-Reply-To: <17b2302a0910090955t2c44539ch9212dc4ef31f2411@mail.gmail.com> References: <4ACE30B8.8070302@sun.com> <17b2302a0910090955t2c44539ch9212dc4ef31f2411@mail.gmail.com> Message-ID: <4AD36696.1020807@sun.com> Joshua Bloch wrote: > Joe, > > I'm not sure I like this idea. My one experience with forcing an > array method to do double duty as varargs method was a disaster. The > method was Arrays.asList, and the result was Puzzler # 7 from "The > Continuing Adventures of Java?Puzzlers: Tiger Traps." Here it is: > > *7. ?Fib O?Nacci?* > > public class Fibonacci { > private static final int LENGTH = 7; > public static void main(String[] args) { > int[] fib = new int[LENGTH]; > fib[0] = fib[1] = 1; // First 2 Fibonacci numbers > for (inti = 2; i < LENGTH; i++) > fib[i] = fib[i -2] + fib[i -1]; > System.out.println(Arrays.asList(fib)); > } > } > > The main moral of the puzzle was: > > Use varargssparingly in your APIs > ?It can hide errors and cause confusion > ?This program wouldn't compile under 1.4 > > Arrays.hashCode, equals, and toString are already overloaded out the > wazoo; adding varargs to the mix could be deadly. Also, Arrays is not > the place where people would go looking for what is essentially a > hashing utility. So I'm not in favor of varargifying the existing > methods in Arrays, but I am in favor of adding a convenience method > like this somewhere: > > /** > * Generates a hash code for a sequence of input values. The hash > code is > * generated as if all the input values were placed into an array, > and that > * array were hashed by calling {@link Arrays#hashCode(Object[])}. > *

> *

This method is useful for implementing {@link > Object#hashCode()} on > * objects containing multiple fields. For example, if an object > that has > * three fields, {@code x}, {@code y}, and {@code z}, one could > write: > * 

>      * @Override public int hashCode() {
>      *     return Objects.hashCode(x, y, z);
>      * }
>      *
> * Warning: When a single object reference is supplied, the > returned > * value does not equal the hash code of that object > reference. This > * value can be computed by calling {@link #hashCode(Object)}. > */ > public static int hash(Object... components) { > return Arrays.hashCode(components); > } > > Viewed in isolation, it's simple, straightforward, and will help > people write high quality hashCode methods. I don't think Objects is > a bad place for it, but you could put it is a "hash utility" class if > we wrote such a thing. > Okay; unless and until a hash utility is added somewhere, this hash(Object ...) can live in Objects. -Joe From Alan.Bateman at Sun.COM Mon Oct 12 12:01:13 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 12 Oct 2009 20:01:13 +0100 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD3551A.3090602@gmx.de> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> <4AD3375C.9030400@gmx.de> <4AD33CA4.5020608@sun.com> <4AD3551A.3090602@gmx.de> Message-ID: <4AD37CF9.8030203@sun.com> Ulf Zibis wrote: > : > In java.nio.file.Filesystem b72 I don't find information about sharing > attributes. These are provider specific open options so they aren't in the javadoc. If you look at the dosSharingOptionTests in jdk/test/java/nio/Path/SBC.java you will see tests for these options. -Alan. From forax at univ-mlv.fr Mon Oct 12 12:52:39 2009 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Mon, 12 Oct 2009 21:52:39 +0200 Subject: j.ul.Objects follow-up: methods for var-argification? In-Reply-To: <4AD37849.4080701@sun.com> References: <4ACE30B8.8070302@sun.com> <17b2302a0910090955t2c44539ch9212dc4ef31f2411@mail.gmail.com> <4AD36696.1020807@sun.com> <4AD36CF5.6000601@univ-mlv.fr> <4AD37849.4080701@sun.com> Message-ID: <4AD38907.1090103@univ-mlv.fr> Le 12/10/2009 20:41, Joseph D. Darcy a ?crit : > R?mi Forax wrote: >> Le 12/10/2009 19:25, Joseph D. Darcy a ?crit : >>> Joshua Bloch wrote: >>>> Joe, >>>> >>>> I'm not sure I like this idea. My one experience with forcing an >>>> array method to do double duty as varargs method was a disaster. >>>> The method was Arrays.asList, and the result was Puzzler # 7 from >>>> "The Continuing Adventures of Java?Puzzlers: Tiger Traps." Here it >>>> is: >>>> >>>> *7. ?Fib O?Nacci?* >>>> >>>> public class Fibonacci { >>>> private static final int LENGTH = 7; >>>> public static void main(String[] args) { >>>> int[] fib = new int[LENGTH]; >>>> fib[0] = fib[1] = 1; // First 2 Fibonacci numbers >>>> for (inti = 2; i < LENGTH; i++) >>>> fib[i] = fib[i -2] + fib[i -1]; >>>> System.out.println(Arrays.asList(fib)); >>>> } >>>> } >>>> >>>> The main moral of the puzzle was: >>>> >>>> Use varargssparingly in your APIs >>>> ?It can hide errors and cause confusion >>>> ?This program wouldn't compile under 1.4 >>>> >>>> Arrays.hashCode, equals, and toString are already overloaded out >>>> the wazoo; adding varargs to the mix could be deadly. Also, Arrays >>>> is not the place where people would go looking for what is >>>> essentially a hashing utility. So I'm not in favor of varargifying >>>> the existing methods in Arrays, but I am in favor of adding a >>>> convenience method like this somewhere: >>>> >>>> /** >>>> * Generates a hash code for a sequence of input values. The >>>> hash code is >>>> * generated as if all the input values were placed into an >>>> array, and that >>>> * array were hashed by calling {@link Arrays#hashCode(Object[])}. >>>> *

>>>> *

This method is useful for implementing {@link >>>> Object#hashCode()} on >>>> * objects containing multiple fields. For example, if an >>>> object that has >>>> * three fields, {@code x}, {@code y}, and {@code z}, one >>>> could write: >>>> * 

>>>>      * @Override public int hashCode() {
>>>>      *     return Objects.hashCode(x, y, z);
>>>>      * }
>>>>      *
>>>> * Warning: When a single object reference is supplied, the >>>> returned >>>> * value does not equal the hash code of that object >>>> reference. This >>>> * value can be computed by calling {@link #hashCode(Object)}. >>>> */ >>>> public static int hash(Object... components) { >>>> return Arrays.hashCode(components); >>>> } >>>> >>>> Viewed in isolation, it's simple, straightforward, and will help >>>> people write high quality hashCode methods. I don't think Objects >>>> is a bad place for it, but you could put it is a "hash utility" >>>> class if we wrote such a thing. >>>> >>> >>> Okay; unless and until a hash utility is added somewhere, this >>> hash(Object ...) can live in Objects. >>> >>> -Joe >> >> In that case, we can also add some methods hash that avoid create an >> array >> for let say 2 to 5 arguments: >> hash(Object, Object), hash-Object, Object, Object), >> hash(Object,Object,Object,Object) >> and hash(Object,Object,Object,Object,Object). >> > > I don't think such methods are justified at present. > > -Joe > It's not a good idea to have a hashCode() that allocate objects, at least until escape analysis is implemented in all VMs. R?mi From forax at univ-mlv.fr Mon Oct 12 10:52:53 2009 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Mon, 12 Oct 2009 19:52:53 +0200 Subject: j.ul.Objects follow-up: methods for var-argification? In-Reply-To: <4AD36696.1020807@sun.com> References: <4ACE30B8.8070302@sun.com> <17b2302a0910090955t2c44539ch9212dc4ef31f2411@mail.gmail.com> <4AD36696.1020807@sun.com> Message-ID: <4AD36CF5.6000601@univ-mlv.fr> Le 12/10/2009 19:25, Joseph D. Darcy a ?crit : > Joshua Bloch wrote: >> Joe, >> >> I'm not sure I like this idea. My one experience with forcing an >> array method to do double duty as varargs method was a disaster. The >> method was Arrays.asList, and the result was Puzzler # 7 from "The >> Continuing Adventures of Java?Puzzlers: Tiger Traps." Here it is: >> >> *7. ?Fib O?Nacci?* >> >> public class Fibonacci { >> private static final int LENGTH = 7; >> public static void main(String[] args) { >> int[] fib = new int[LENGTH]; >> fib[0] = fib[1] = 1; // First 2 Fibonacci numbers >> for (inti = 2; i < LENGTH; i++) >> fib[i] = fib[i -2] + fib[i -1]; >> System.out.println(Arrays.asList(fib)); >> } >> } >> >> The main moral of the puzzle was: >> >> Use varargssparingly in your APIs >> ?It can hide errors and cause confusion >> ?This program wouldn't compile under 1.4 >> >> Arrays.hashCode, equals, and toString are already overloaded out the >> wazoo; adding varargs to the mix could be deadly. Also, Arrays is >> not the place where people would go looking for what is essentially a >> hashing utility. So I'm not in favor of varargifying the existing >> methods in Arrays, but I am in favor of adding a convenience method >> like this somewhere: >> >> /** >> * Generates a hash code for a sequence of input values. The hash >> code is >> * generated as if all the input values were placed into an >> array, and that >> * array were hashed by calling {@link Arrays#hashCode(Object[])}. >> *

>> *

This method is useful for implementing {@link >> Object#hashCode()} on >> * objects containing multiple fields. For example, if an object >> that has >> * three fields, {@code x}, {@code y}, and {@code z}, one could >> write: >> * 

>>      * @Override public int hashCode() {
>>      *     return Objects.hashCode(x, y, z);
>>      * }
>>      *
>> * Warning: When a single object reference is supplied, the >> returned >> * value does not equal the hash code of that object >> reference. This >> * value can be computed by calling {@link #hashCode(Object)}. >> */ >> public static int hash(Object... components) { >> return Arrays.hashCode(components); >> } >> >> Viewed in isolation, it's simple, straightforward, and will help >> people write high quality hashCode methods. I don't think Objects is >> a bad place for it, but you could put it is a "hash utility" class if >> we wrote such a thing. >> > > Okay; unless and until a hash utility is added somewhere, this > hash(Object ...) can live in Objects. > > -Joe In that case, we can also add some methods hash that avoid create an array for let say 2 to 5 arguments: hash(Object, Object), hash-Object, Object, Object), hash(Object,Object,Object,Object) and hash(Object,Object,Object,Object,Object). R?mi From crazybob at crazybob.org Tue Oct 13 12:09:19 2009 From: crazybob at crazybob.org (Bob Lee) Date: Tue, 13 Oct 2009 12:09:19 -0700 Subject: j.ul.Objects follow-up: methods for var-argification? In-Reply-To: <4AD38907.1090103@univ-mlv.fr> References: <4ACE30B8.8070302@sun.com> <17b2302a0910090955t2c44539ch9212dc4ef31f2411@mail.gmail.com> <4AD36696.1020807@sun.com> <4AD36CF5.6000601@univ-mlv.fr> <4AD37849.4080701@sun.com> <4AD38907.1090103@univ-mlv.fr> Message-ID: On Mon, Oct 12, 2009 at 12:52 PM, R?mi Forax wrote: > It's not a good idea to have a hashCode() that allocate objects, > at least until escape analysis is implemented in all VMs. Agree with Joe--these methods don't carry their weight. If the allocation is too much to bear, it's easy enough to write the hash by hand. Plus, it won't have the overhead of a method invocation. ;-) That's not to say I don't think you should ever do this. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091013/262af105/attachment.html From jjb at google.com Tue Oct 13 11:40:46 2009 From: jjb at google.com (Joshua Bloch) Date: Tue, 13 Oct 2009 11:40:46 -0700 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <4AD4C321.2080401@sun.com> References: <4ACE2AF9.4070104@sun.com> <17b2302a0910081456n3379569dnf031b18a1d949e43@mail.gmail.com> <4ACE9030.3030801@sun.com> <17b2302a0910122338m83d82c4pe2b333a5a6fa9e28@mail.gmail.com> <4AD4C321.2080401@sun.com> Message-ID: <17b2302a0910131140m64db6a72i9eba577452af222c@mail.gmail.com> Joe, Thanks very much! Josh On Tue, Oct 13, 2009 at 11:12 AM, Joseph D. Darcy wrote: > Joshua Bloch wrote: > >> Joe, >> >> Hi. I've attached a file containing the methods and a JTReg "basic test" >> for inclusion in your BasicObjectTests. I adhered to your style, for easy >> integration. If you could take it from here, I'd be ever so grateful. >> > > Will do. > > Cheers, > > -Joe > > >> Thanks, >> >> Josh >> >> >> On Thu, Oct 8, 2009 at 6:21 PM, Joe Darcy > Joe.Darcy at sun.com>> wrote: >> >> >> I strongly suggest that you do add these two methods: >> >> /** >> * Checks that the specified object reference is not {@code >> null}. This >> * method is designed primarily for doing parameter >> validation in methods >> * and constructors, as demonstrated below: >> * 
>>            * public Foo(Bar bar) {
>>            *     this.bar = Objects.nonNull(bar);
>>            * }
>>            *
>> * >> * @param obj the object reference to check for nullity >> * @return {@code obj} if not {@code null} >> * @throws NullPointerException if {@code obj} is {@code null} >> */ >> public static T nonNull(T obj) { >> if (obj == null) >> throw new NullPointerException(); >> return obj; >> } >> >> /** >> * Checks that the specified object reference is not {@code >> null} and >> * throws a customized {@Link NullPointerException} if it >> is. This method >> * is designed primarily for doing parameter validation in >> methods and >> * constructors with multiple parameters, as demonstrated >> below: >> * 
>>            * public Foo(Bar bar, Baz baz) {
>>            *     this.bar = Objects.nonNull(bar, "bar must not be null");
>>            *     this.baz = Objects.nonNull(baz, "baz must not be null");
>>            * }
>>            *
>> * >> * @param obj the object reference to check for nullity >> * @param message detail message to be used in the event >> that a {@code >> * NullPointerException} is thrown >> * @return {@code obj} if not {@code null} >> * @throws NullPointerException if {@code obj} is {@code null} >> */ >> public static T nonNull(T obj, String message) { >> if (obj == null) >> throw new NullPointerException(message); >> return obj; >> } >> >> They do a great job reducing the verbiage in validity-checking >> of arguments that must not be null. >> >> >> I've filed bug 6889858 "Add nonNull methods to java.util.Objects" for >> these last two methods. If you want to finish off the engineering >> need for a changeset, some light tests, etc., I'll file the >> Sun-internal paperwork for these. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091013/3b2c3c84/attachment.html From Joe.Darcy at Sun.COM Tue Oct 13 11:12:49 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 13 Oct 2009 11:12:49 -0700 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <17b2302a0910122338m83d82c4pe2b333a5a6fa9e28@mail.gmail.com> References: <4ACE2AF9.4070104@sun.com> <17b2302a0910081456n3379569dnf031b18a1d949e43@mail.gmail.com> <4ACE9030.3030801@sun.com> <17b2302a0910122338m83d82c4pe2b333a5a6fa9e28@mail.gmail.com> Message-ID: <4AD4C321.2080401@sun.com> Joshua Bloch wrote: > Joe, > > Hi. I've attached a file containing the methods and a JTReg "basic > test" for inclusion in your BasicObjectTests. I adhered to your > style, for easy integration. If you could take it from here, I'd be > ever so grateful. Will do. Cheers, -Joe > > Thanks, > > Josh > > On Thu, Oct 8, 2009 at 6:21 PM, Joe Darcy > wrote: > > > I strongly suggest that you do add these two methods: > > /** > * Checks that the specified object reference is not {@code > null}. This > * method is designed primarily for doing parameter > validation in methods > * and constructors, as demonstrated below: > * 
>             * public Foo(Bar bar) {
>             *     this.bar = Objects.nonNull(bar);
>             * }
>             *
> * > * @param obj the object reference to check for nullity > * @return {@code obj} if not {@code null} > * @throws NullPointerException if {@code obj} is {@code null} > */ > public static T nonNull(T obj) { > if (obj == null) > throw new NullPointerException(); > return obj; > } > > /** > * Checks that the specified object reference is not {@code > null} and > * throws a customized {@Link NullPointerException} if it > is. This method > * is designed primarily for doing parameter validation in > methods and > * constructors with multiple parameters, as demonstrated > below: > * 
>             * public Foo(Bar bar, Baz baz) {
>             *     this.bar = Objects.nonNull(bar, "bar must not be null");
>             *     this.baz = Objects.nonNull(baz, "baz must not be null");
>             * }
>             *
> * > * @param obj the object reference to check for nullity > * @param message detail message to be used in the event > that a {@code > * NullPointerException} is thrown > * @return {@code obj} if not {@code null} > * @throws NullPointerException if {@code obj} is {@code null} > */ > public static T nonNull(T obj, String message) { > if (obj == null) > throw new NullPointerException(message); > return obj; > } > > They do a great job reducing the verbiage in validity-checking > of arguments that must not be null. > > > I've filed bug 6889858 "Add nonNull methods to java.util.Objects" for > these last two methods. If you want to finish off the engineering > need for a changeset, some light tests, etc., I'll file the > Sun-internal paperwork for these. > From Ulf.Zibis at gmx.de Tue Oct 13 06:55:50 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 13 Oct 2009 15:55:50 +0200 Subject: Benchmark for java.nio.charset.Charset cache Message-ID: <4AD486E6.2010501@gmx.de> Hi, Martin, Xueming, I did a benchmark: unsynchronized 2-ElementCache ./. synchronized 4-ElementCache Result: Usage: java -Xint -Xbootclasspath/p:..\build\classes;..\build\test\classes java.nio.charset.CharsetBenchmark As in real world, excessive loops on Charset.forName() are unlikely, only use interpreter mode here! Benchmark for 100000 from 1 charsets: - time of unsynchronized 2-ElementCache: 40 + 42 = 82 ms - time of synchronized 4-ElementCache: 48 + 49 = 97 ms Benchmark for 100000 from 2 charsets: - time of unsynchronized 2-ElementCache: 83 + 90 = 173 ms - time of synchronized 4-ElementCache: 138 + 110 = 248 ms Benchmark for 100000 from 3 charsets: - time of unsynchronized 2-ElementCache: 801 + 823 = 1624 ms - time of synchronized 4-ElementCache: 134 + 135 = 269 ms Benchmark for 100000 from 4 charsets: - time of unsynchronized 2-ElementCache: 1232 + 1284 = 2516 ms - time of synchronized 4-ElementCache: 142 + 145 = 287 ms Benchmark for 100000 from 5 charsets: - time of unsynchronized 2-ElementCache: 1408 + 1547 = 2955 ms - time of synchronized 4-ElementCache: 617 + 683 = 1300 ms Benchmark for 100000 from 6 charsets: - time of unsynchronized 2-ElementCache: 1666 + 1671 = 3337 ms - time of synchronized 4-ElementCache: 1086 + 995 = 2081 ms For the sources see attachment. -Ulf From Joe.Darcy at Sun.COM Mon Oct 12 11:41:13 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 12 Oct 2009 11:41:13 -0700 Subject: j.ul.Objects follow-up: methods for var-argification? In-Reply-To: <4AD36CF5.6000601@univ-mlv.fr> References: <4ACE30B8.8070302@sun.com> <17b2302a0910090955t2c44539ch9212dc4ef31f2411@mail.gmail.com> <4AD36696.1020807@sun.com> <4AD36CF5.6000601@univ-mlv.fr> Message-ID: <4AD37849.4080701@sun.com> R?mi Forax wrote: > Le 12/10/2009 19:25, Joseph D. Darcy a ?crit : >> Joshua Bloch wrote: >>> Joe, >>> >>> I'm not sure I like this idea. My one experience with forcing an >>> array method to do double duty as varargs method was a disaster. >>> The method was Arrays.asList, and the result was Puzzler # 7 from >>> "The Continuing Adventures of Java?Puzzlers: Tiger Traps." Here it is: >>> >>> *7. ?Fib O?Nacci?* >>> >>> public class Fibonacci { >>> private static final int LENGTH = 7; >>> public static void main(String[] args) { >>> int[] fib = new int[LENGTH]; >>> fib[0] = fib[1] = 1; // First 2 Fibonacci numbers >>> for (inti = 2; i < LENGTH; i++) >>> fib[i] = fib[i -2] + fib[i -1]; >>> System.out.println(Arrays.asList(fib)); >>> } >>> } >>> >>> The main moral of the puzzle was: >>> >>> Use varargssparingly in your APIs >>> ?It can hide errors and cause confusion >>> ?This program wouldn't compile under 1.4 >>> >>> Arrays.hashCode, equals, and toString are already overloaded out the >>> wazoo; adding varargs to the mix could be deadly. Also, Arrays is >>> not the place where people would go looking for what is essentially >>> a hashing utility. So I'm not in favor of varargifying the existing >>> methods in Arrays, but I am in favor of adding a convenience method >>> like this somewhere: >>> >>> /** >>> * Generates a hash code for a sequence of input values. The >>> hash code is >>> * generated as if all the input values were placed into an >>> array, and that >>> * array were hashed by calling {@link Arrays#hashCode(Object[])}. >>> *

>>> *

This method is useful for implementing {@link >>> Object#hashCode()} on >>> * objects containing multiple fields. For example, if an object >>> that has >>> * three fields, {@code x}, {@code y}, and {@code z}, one could >>> write: >>> * 

>>>      * @Override public int hashCode() {
>>>      *     return Objects.hashCode(x, y, z);
>>>      * }
>>>      *
>>> * Warning: When a single object reference is supplied, the >>> returned >>> * value does not equal the hash code of that object >>> reference. This >>> * value can be computed by calling {@link #hashCode(Object)}. >>> */ >>> public static int hash(Object... components) { >>> return Arrays.hashCode(components); >>> } >>> >>> Viewed in isolation, it's simple, straightforward, and will help >>> people write high quality hashCode methods. I don't think Objects >>> is a bad place for it, but you could put it is a "hash utility" >>> class if we wrote such a thing. >>> >> >> Okay; unless and until a hash utility is added somewhere, this >> hash(Object ...) can live in Objects. >> >> -Joe > > In that case, we can also add some methods hash that avoid create an > array > for let say 2 to 5 arguments: > hash(Object, Object), hash-Object, Object, Object), > hash(Object,Object,Object,Object) > and hash(Object,Object,Object,Object,Object). > I don't think such methods are justified at present. -Joe From Joe.Darcy at Sun.COM Mon Oct 12 10:40:24 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 12 Oct 2009 10:40:24 -0700 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? In-Reply-To: <17b2302a0910091543m4e9044e8k926ead71fec6aef3@mail.gmail.com> References: <4ACE44A9.8060506@sun.com> <4ACF02B9.8070708@sun.com> <4ACF75FB.3000209@sun.com> <17b2302a0910091543m4e9044e8k926ead71fec6aef3@mail.gmail.com> Message-ID: <4AD36A08.4000207@sun.com> Joshua Bloch wrote: > I don't think method really pays for itself. If it belongs anywhere, > it belongs in java.util.Arrays. > > Josh I think there is room in the platform for this functionality. Even if this is mostly used in tests, code used in tests is code too :-) I think Objects is a better home for deepEquals(Object, Object) than Arrays since the arguments are not arrays and since it is a sibling method to equals(Object, Object). -Joe From jjb at google.com Mon Oct 12 15:42:17 2009 From: jjb at google.com (Joshua Bloch) Date: Mon, 12 Oct 2009 15:42:17 -0700 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? In-Reply-To: <4AD36A08.4000207@sun.com> References: <4ACE44A9.8060506@sun.com> <4ACF02B9.8070708@sun.com> <4ACF75FB.3000209@sun.com> <17b2302a0910091543m4e9044e8k926ead71fec6aef3@mail.gmail.com> <4AD36A08.4000207@sun.com> Message-ID: <17b2302a0910121542t5d3e4dadj84efe02f48f6e4f8@mail.gmail.com> Joe, I don't feel too strongly about this one. Do the right thing. Josh On Mon, Oct 12, 2009 at 10:40 AM, Joseph D. Darcy wrote: > Joshua Bloch wrote: > >> I don't think method really pays for itself. If it belongs anywhere, it >> belongs in java.util.Arrays. >> >> Josh >> > > I think there is room in the platform for this functionality. Even if this > is mostly used in tests, code used in tests is code too :-) > > I think Objects is a better home for deepEquals(Object, Object) than Arrays > since the arguments are not arrays and since it is a sibling method to > equals(Object, Object). > > -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091012/1dc2f29c/attachment.html From jjb at google.com Mon Oct 12 23:38:04 2009 From: jjb at google.com (Joshua Bloch) Date: Mon, 12 Oct 2009 23:38:04 -0700 Subject: First round of java.util.Objects for code review (bug 6797535) In-Reply-To: <4ACE9030.3030801@sun.com> References: <4ACE2AF9.4070104@sun.com> <17b2302a0910081456n3379569dnf031b18a1d949e43@mail.gmail.com> <4ACE9030.3030801@sun.com> Message-ID: <17b2302a0910122338m83d82c4pe2b333a5a6fa9e28@mail.gmail.com> Joe, Hi. I've attached a file containing the methods and a JTReg "basic test" for inclusion in your BasicObjectTests. I adhered to your style, for easy integration. If you could take it from here, I'd be ever so grateful. Thanks, Josh On Thu, Oct 8, 2009 at 6:21 PM, Joe Darcy wrote: > >> I strongly suggest that you do add these two methods: >> >> /** >> * Checks that the specified object reference is not {@code null}. This >> * method is designed primarily for doing parameter validation in >> methods >> * and constructors, as demonstrated below: >> * 
>>     * public Foo(Bar bar) {
>>     *     this.bar = Objects.nonNull(bar);
>>     * }
>>     *
>> * >> * @param obj the object reference to check for nullity >> * @return {@code obj} if not {@code null} >> * @throws NullPointerException if {@code obj} is {@code null} >> */ >> public static T nonNull(T obj) { >> if (obj == null) >> throw new NullPointerException(); >> return obj; >> } >> >> /** >> * Checks that the specified object reference is not {@code null} and >> * throws a customized {@Link NullPointerException} if it is. This >> method >> * is designed primarily for doing parameter validation in methods and >> * constructors with multiple parameters, as demonstrated below: >> * 
>>     * public Foo(Bar bar, Baz baz) {
>>     *     this.bar = Objects.nonNull(bar, "bar must not be null");
>>     *     this.baz = Objects.nonNull(baz, "baz must not be null");
>>     * }
>>     *
>> * >> * @param obj the object reference to check for nullity >> * @param message detail message to be used in the event that a {@code >> * NullPointerException} is thrown >> * @return {@code obj} if not {@code null} >> * @throws NullPointerException if {@code obj} is {@code null} >> */ >> public static T nonNull(T obj, String message) { >> if (obj == null) >> throw new NullPointerException(message); >> return obj; >> } >> >> They do a great job reducing the verbiage in validity-checking of >> arguments that must not be null. >> > > I've filed bug 6889858 "Add nonNull methods to java.util.Objects" for > these last two methods. If you want to finish off the engineering need for > a changeset, some light tests, etc., I'll file the Sun-internal paperwork > for these. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091012/9ccee837/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: NonNull.java Type: application/octet-stream Size: 3415 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091012/9ccee837/attachment.obj From i30817 at gmail.com Tue Oct 13 13:38:38 2009 From: i30817 at gmail.com (Paulo Levi) Date: Tue, 13 Oct 2009 21:38:38 +0100 Subject: More native closeable resources Message-ID: <212322090910131338k39adf5ffo39fabef90f4d1133@mail.gmail.com> Probably JavaSound is another candidate for closeable refactoring for jdk7? Specifically all the Line implementations : TargetDataLine, SourceDataline, Clip. From Alan.Bateman at Sun.COM Tue Oct 13 13:39:28 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 13 Oct 2009 21:39:28 +0100 Subject: Code review request for 6648344: (reflect spec) State default of isAccessible for reflective objects In-Reply-To: <4ACFB040.3050503@sun.com> References: <4ACFB040.3050503@sun.com> Message-ID: <4AD4E580.7070408@sun.com> Joseph D. Darcy wrote: > Hello. > > Please review this simple specification clarification (with > accompanying test) for > 6648344: (reflect spec) State default of isAccessible for reflective > objects This looks good to me. -Alan. From jonathan.gibbons at sun.com Tue Oct 13 14:03:59 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 13 Oct 2009 21:03:59 +0000 Subject: hg: jdk7/tl/langtools: 6887895: CONSTANT_Class_info getBaseName does not handle arrays of primitives correctly Message-ID: <20091013210402.1570D41421@hg.openjdk.java.net> Changeset: e526e39579ae Author: jjg Date: 2009-10-13 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e526e39579ae 6887895: CONSTANT_Class_info getBaseName does not handle arrays of primitives correctly Reviewed-by: ksrini ! src/share/classes/com/sun/tools/classfile/ConstantPool.java + test/tools/javap/classfile/T6887895.java From joe.darcy at sun.com Tue Oct 13 14:09:28 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Tue, 13 Oct 2009 21:09:28 +0000 Subject: hg: jdk7/tl/jdk: 6648344: (reflect spec) State default of isAccessible for reflective objects Message-ID: <20091013210956.9F86841426@hg.openjdk.java.net> Changeset: 9d240dbadaa3 Author: darcy Date: 2009-10-13 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d240dbadaa3 6648344: (reflect spec) State default of isAccessible for reflective objects Reviewed-by: alanb ! src/share/classes/java/lang/reflect/AccessibleObject.java + test/java/lang/reflect/DefaultAccessibility.java From jonathan.gibbons at sun.com Tue Oct 13 15:27:23 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 13 Oct 2009 22:27:23 +0000 Subject: hg: jdk7/tl/langtools: 6891079: Compiler allows invalid binary literals 0b and oBL Message-ID: <20091013222725.32E7E4143B@hg.openjdk.java.net> Changeset: 8a4543b30586 Author: jjg Date: 2009-10-13 15:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8a4543b30586 6891079: Compiler allows invalid binary literals 0b and oBL Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/literals/T6891079.java + test/tools/javac/literals/T6891079.out From Joe.Darcy at Sun.COM Tue Oct 13 16:18:13 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 13 Oct 2009 16:18:13 -0700 Subject: java.util.Objects, round two Message-ID: <4AD50AB5.4000804@sun.com> Hello. After recent discussions on the list, the following methods will be included in round two of the evolution of java.util.Objects: Under bug 6889858: Add nonNull methods to java.util.Objects: /** * Checks that the specified object reference is not {@code null}. This * method is designed primarily for doing parameter validation in methods * and constructors, as demonstrated below: * 
     * public Foo(Bar bar) {
     *     this.bar = Objects.nonNull(bar);
     * }
     *
* * @param obj the object reference to check for nullity * @return {@code obj} if not {@code null} * @throws NullPointerException if {@code obj} is {@code null} */ public static T nonNull(T obj); /** * Checks that the specified object reference is not {@code null} and * throws a customized {@link NullPointerException} if it is. This method * is designed primarily for doing parameter validation in methods and * constructors with multiple parameters, as demonstrated below: * 
     * public Foo(Bar bar, Baz baz) {
     *     this.bar = Objects.nonNull(bar, "bar must not be null");
     *     this.baz = Objects.nonNull(baz, "baz must not be null");
     * }
     *
* * @param obj the object reference to check for nullity * @param message detail message to be used in the event that a {@code * NullPointerException} is thrown * @return {@code obj} if not {@code null} * @throws NullPointerException if {@code obj} is {@code null} */ public static T nonNull(T obj, String message); Under bug 6891113: More methods for java.util.Objects: deepEquals, hash, toString with default /** * Returns {@code true} if the arguments are deeply equal to each other * and {@code false} otherwise. * * Two {@code null} values are deeply equal. If both arguments are * arrays, the algorithm in {@link Arrays.deepEquals(Object[], * Object[]) Arrays.deepEquals) is used to determine equality. * Otherwise, equality is determined by using the {@link Object#equals * equals} method of the first argument. * * @return {@code true} if the arguments are deeply equal to each other * and {@code false} otherwise * @see Arrays#deepEquals(Object[], Object[]) * @see Objects#equals(Object, Object) */ public static deepEquals(Object a, Object b); /** * Returns the result of calling {@code toString} on the first * argument if the first argument is not {@code null} and returns * the second argument otherwise. * * @return the result of calling {@code toString} on the first * argument if it is not {@code null} and the second argument * otherwise. * @see Objects#toString(Object) */ public static toString(Object a, String nullDefault); /** * Generates a hash code for a sequence of input values. The hash code is * generated as if all the input values were placed into an array, and that * array were hashed by calling {@link Arrays#hashCode(Object[])}. * *

This method is useful for implementing {@link Object#hashCode()} on * objects containing multiple fields. For example, if an object that has * three fields, {@code x}, {@code y}, and {@code z}, one could write: * 

     * @Override public int hashCode() {
     *     return Objects.hashCode(x, y, z);
     * }
     *
* Warning: When a single object reference is supplied, the returned * value does not equal the hash code of that object reference. This * value can be computed by calling {@link #hashCode(Object)}. * * @return a hash value of the sequence of input values * @see Arrays#hashCode */ public static int hash(Object... components); In addition, the Objects class will be explicitly marked as "final" to indicate its already implicit status as a non-instantiable, non-extendable class. I've closed as "will not fix" the bug requesting to var-argify various constructors in String. I'm open having being convinced that "toDefaultString(Object)" is a worthwhile addition to j.u.Objects as well. Likewise, for "toDebugString(Object)", although someone else would have to specify, implement, and test that method. -Joe From Joe.Darcy at Sun.COM Tue Oct 13 16:32:04 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 13 Oct 2009 16:32:04 -0700 Subject: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7 Message-ID: <4AD50DF4.8010503@sun.com> Hello. Following up from threads earlier this year, http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html I'm willing and interested to sponsor getting String.join functionality into JDK 7. To address this particular bug, I think there should be new "join" methods on String as opposed to a general "joiner" class. A more general class could be added later. Remi, please point to a current draft of the specification and implementation for your change. Kevin, I'm interested in hearing your comments on the API design. Thanks, -Joe From crazybob at crazybob.org Tue Oct 13 16:48:53 2009 From: crazybob at crazybob.org (Bob Lee) Date: Tue, 13 Oct 2009 16:48:53 -0700 Subject: j.u.Objects follow-up: deepEquals(Object, Object)? In-Reply-To: <4AD36A08.4000207@sun.com> References: <4ACE44A9.8060506@sun.com> <4ACF02B9.8070708@sun.com> <4ACF75FB.3000209@sun.com> <17b2302a0910091543m4e9044e8k926ead71fec6aef3@mail.gmail.com> <4AD36A08.4000207@sun.com> Message-ID: On Mon, Oct 12, 2009 at 10:40 AM, Joseph D. Darcy wrote: > I think Objects is a better home for deepEquals(Object, Object) than Arrays > since the arguments are not arrays and since it is a sibling method to > equals(Object, Object). > While the argument types are Object, the behavior and usage is tightly coupled to arrays. It took me awhile to grok what this method does, even after looking at the impl. I think I would have caught on a little faster if the method were in Arrays. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091013/9f0c97eb/attachment.html From joe.darcy at sun.com Tue Oct 13 17:35:03 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Wed, 14 Oct 2009 00:35:03 +0000 Subject: hg: jdk7/tl/jdk: 6349921: (enum) Include links from java.lang.Enum to EnumSet and EnumMap Message-ID: <20091014003517.45F3141463@hg.openjdk.java.net> Changeset: 151baf5e19ca Author: darcy Date: 2009-10-13 17:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/151baf5e19ca 6349921: (enum) Include links from java.lang.Enum to EnumSet and EnumMap Reviewed-by: martin ! src/share/classes/java/lang/Enum.java From pbenedict at apache.org Wed Oct 14 01:05:01 2009 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 14 Oct 2009 03:05:01 -0500 Subject: java.util.Objects, round two Message-ID: Joe, I am confused over this warning: > * Warning: When a single object reference is supplied, the returned > * value does not equal the hash code of that object reference. This > * value can be computed by calling {@link #hashCode(Object)}. I first looked into Arrays#deepHashCode and did not see any companion warning there; therefore I am presuming this is new functionality. Two questions remain based on looking at the javadoc alone and not knowing its implementation: For when a single object reference is supplied: 1) Why is the hash code not the hash code of the single object? Is there harm in doing so? 2) Then what gets hashed? Dunno... I think the second question is begged but not explicitly answered by the documentation. Paul From i30817 at gmail.com Wed Oct 14 02:11:01 2009 From: i30817 at gmail.com (Paulo Levi) Date: Wed, 14 Oct 2009 10:11:01 +0100 Subject: Why does util.timer does not expose interrupt Message-ID: <212322090910140211w4288cefcwd5f3cbb40ba49bb9@mail.gmail.com> Would be really helpful for those tasks that are "paused" purposefully or not. From i30817 at gmail.com Wed Oct 14 02:54:26 2009 From: i30817 at gmail.com (Paulo Levi) Date: Wed, 14 Oct 2009 10:54:26 +0100 Subject: Why does util.timer does not expose interrupt In-Reply-To: <212322090910140211w4288cefcwd5f3cbb40ba49bb9@mail.gmail.com> References: <212322090910140211w4288cefcwd5f3cbb40ba49bb9@mail.gmail.com> Message-ID: <212322090910140254h16e194d6laea2d0e83aab0918@mail.gmail.com> Never mind, just realized that there is no guarantee of what Task would see it at the correct time. Its easier to set a flag to false before the sleep and check it after it. Not thinking concurrently enough. On Wed, Oct 14, 2009 at 10:11 AM, Paulo Levi wrote: > Would be really helpful for those tasks that are "paused" purposefully or not. > From scolebourne at joda.org Wed Oct 14 03:38:26 2009 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 14 Oct 2009 11:38:26 +0100 Subject: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)] In-Reply-To: <17b2302a0910122338m83d82c4pe2b333a5a6fa9e28@mail.gmail.com> References: <4ACE2AF9.4070104@sun.com> <17b2302a0910081456n3379569dnf031b18a1d949e43@mail.gmail.com> <4ACE9030.3030801@sun.com> <17b2302a0910122338m83d82c4pe2b333a5a6fa9e28@mail.gmail.com> Message-ID: <4AD5AA22.2060208@joda.org> All, While I agree that the nonNull methods below are useful and should be in the JDK, I question whether they should be on j.u.Objects. I believe that there is a whole category of methods to pre-validate the arguments of a method, such as Commons Lang Validate, or Google Prevalidate. http://commons.apache.org/lang/apidocs/org/apache/commons/lang/Validate.html http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Preconditions.html Adding such a set of validation methods would be a useful way to allow developers to strengthen method input checking. Stephen Joshua Bloch wrote: > Joe, > > Hi. I've attached a file containing the methods and a JTReg "basic > test" for inclusion in your BasicObjectTests. I adhered to your style, > for easy integration. If you could take it from here, I'd be ever so > grateful. > > Thanks, > > Josh > > On Thu, Oct 8, 2009 at 6:21 PM, Joe Darcy > wrote: > > > I strongly suggest that you do add these two methods: > > /** > * Checks that the specified object reference is not {@code > null}. This > * method is designed primarily for doing parameter > validation in methods > * and constructors, as demonstrated below: > * 
>             * public Foo(Bar bar) {
>             *     this.bar = Objects.nonNull(bar);
>             * }
>             *
> * > * @param obj the object reference to check for nullity > * @return {@code obj} if not {@code null} > * @throws NullPointerException if {@code obj} is {@code null} > */ > public static T nonNull(T obj) { > if (obj == null) > throw new NullPointerException(); > return obj; > } > > /** > * Checks that the specified object reference is not {@code > null} and > * throws a customized {@Link NullPointerException} if it is. > This method > * is designed primarily for doing parameter validation in > methods and > * constructors with multiple parameters, as demonstrated below: > * 
>             * public Foo(Bar bar, Baz baz) {
>             *     this.bar = Objects.nonNull(bar, "bar must not be null");
>             *     this.baz = Objects.nonNull(baz, "baz must not be null");
>             * }
>             *
> * > * @param obj the object reference to check for nullity > * @param message detail message to be used in the event that > a {@code > * NullPointerException} is thrown > * @return {@code obj} if not {@code null} > * @throws NullPointerException if {@code obj} is {@code null} > */ > public static T nonNull(T obj, String message) { > if (obj == null) > throw new NullPointerException(message); > return obj; > } > > They do a great job reducing the verbiage in validity-checking > of arguments that must not be null. > > > I've filed bug 6889858 "Add nonNull methods to java.util.Objects" for > these last two methods. If you want to finish off the engineering > need for a changeset, some light tests, etc., I'll file the > Sun-internal paperwork for these. > From sean.mullan at sun.com Wed Oct 14 06:48:14 2009 From: sean.mullan at sun.com (sean.mullan at sun.com) Date: Wed, 14 Oct 2009 13:48:14 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20091014134850.E2D5F41558@hg.openjdk.java.net> Changeset: 5f326176855d Author: mullan Date: 2009-10-14 09:36 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5f326176855d 6885667: CertPath/CertPathValidatorTest/bugs/bug6383078 fails on jdk6u18/b02, jdk7/pit/b73 and passes on b72. Summary: Wrap all OCSP exceptions in CertPathValidatorException so that we can fallback to CRLs, if enabled. Reviewed-by: dgu, xuelei ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java Changeset: edeb687e2d9a Author: mullan Date: 2009-10-14 09:47 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/edeb687e2d9a Merge From Anthony.Petrov at Sun.COM Wed Oct 14 07:02:24 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 14 Oct 2009 18:02:24 +0400 Subject: Review request #1: 6863566 (Java should support the freedesktop.org startup notification specification) Message-ID: <4AD5D9F0.3000801@sun.com> Hello, Please review the next version of the fix contributed by Damjan Jovanovic: RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094 There you can also find some latest comments regarding the fix. webrev: http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.1/ Since the patch includes changes to the src/solaris/classes/java/lang/ProcessEnvironment.java, I'm CC'ing the Core Libs alias to review the changes in that file. From AWT perspective, the changes look good to me. -- best regards, Anthony From forax at univ-mlv.fr Wed Oct 14 07:35:02 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 14 Oct 2009 16:35:02 +0200 Subject: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7 In-Reply-To: <4AD50DF4.8010503@sun.com> References: <4AD50DF4.8010503@sun.com> Message-ID: <4AD5E196.5090600@univ-mlv.fr> Le 14/10/2009 01:32, Joseph D. Darcy a ?crit : > Hello. > > Following up from threads earlier this year, > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html > > > I'm willing and interested to sponsor getting String.join > functionality into JDK 7. > > To address this particular bug, I think there should be new "join" > methods on String as opposed to a general "joiner" class. A more > general class could be added later. > > Remi, please point to a current draft of the specification and > implementation for your change. > > Kevin, I'm interested in hearing your comments on the API design. > > Thanks, > > -Joe Hi Joe, the webrev is here: http://cr.openjdk.java.net/~forax/5015163/webrev.00/ There is no specification, i.e no more than the javadoc. I will dig this evening to find the tests I've used, they are on another computer at home which is currently shutdown. As Kevin said String.join is perhaps better as a static method, see first part of: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001065.html regards, R?mi From pbenedict at apache.org Wed Oct 14 07:43:51 2009 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 14 Oct 2009 09:43:51 -0500 Subject: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)] Message-ID: I agree with Stephen. There are a slew of validation methods that would be beneficial, and if you really want to drive the JDK towards standard validation, refactor them out into a Validation class. Look at what Spring has written for themselves: http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/util/Assert.html Paul From Ulf.Zibis at gmx.de Wed Oct 14 07:47:42 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 14 Oct 2009 16:47:42 +0200 Subject: Fix for 5015163, and my first webrev In-Reply-To: <498CA4CE.1090207@univ-mlv.fr> References: <498CA4CE.1090207@univ-mlv.fr> Message-ID: <4AD5E48E.80107@gmx.de> R?mi, can you tell me how you got the cr.openjdk.java.net account ? Is there any registration link? Thanks, Ulf Am 06.02.2009 21:59, R?mi Forax schrieb: > Hi all, > bug 5015163 is a RFE that advocate to add a method join (like in Python) > to String/StringBuilder/StringBuffer. > > Here is the corresponding webrev (using the new infrastucture :) > http://cr.openjdk.java.net/~forax/5015163/webrev.00/ > The patch is against tl repository. > > Who want to review it ? > > For the record, i have previously proposed this fix using the > jdk-collaboration forum more than > one year ago but because i am lazy i haven't take the time to post it > here. > > cheers, > R?mi Forax > > > From forax at univ-mlv.fr Wed Oct 14 08:01:49 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 14 Oct 2009 17:01:49 +0200 Subject: Fix for 5015163, and my first webrev In-Reply-To: <4AD5E48E.80107@gmx.de> References: <498CA4CE.1090207@univ-mlv.fr> <4AD5E48E.80107@gmx.de> Message-ID: <4AD5E7DD.7080509@univ-mlv.fr> Le 14/10/2009 16:47, Ulf Zibis a ?crit : > R?mi, > > can you tell me how you got the cr.openjdk.java.net account ? > Is there any registration link? > > Thanks, > > Ulf I've got it because I've the right to push codes on mlvm repository (the DaVinci machine repository). I can use the same openjdk account to push webrevs on cr.openjdk.java.net. R?mi PS: now, I feel guilty because you remember me that I have to work on a patch to mlvm repository for John Rose . > > > Am 06.02.2009 21:59, R?mi Forax schrieb: >> Hi all, >> bug 5015163 is a RFE that advocate to add a method join (like in Python) >> to String/StringBuilder/StringBuffer. >> >> Here is the corresponding webrev (using the new infrastucture :) >> http://cr.openjdk.java.net/~forax/5015163/webrev.00/ >> The patch is against tl repository. >> >> Who want to review it ? >> >> For the record, i have previously proposed this fix using the >> jdk-collaboration forum more than >> one year ago but because i am lazy i haven't take the time to post it >> here. >> >> cheers, >> R?mi Forax >> >> >> > From serverperformance at gmail.com Wed Oct 14 08:07:23 2009 From: serverperformance at gmail.com (=?iso-8859-1?Q?Jes=FAs_Vi=F1uales?=) Date: Wed, 14 Oct 2009 17:07:23 +0200 Subject: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)] In-Reply-To: References: Message-ID: <004401ca4ce0$0ab1cc10$20156430$@com> > I agree with Stephen. There are a slew of validation methods that > would be beneficial, and if you really want to drive the JDK towards > standard validation, refactor them out into a Validation class. Look > at what Spring has written for themselves: > >http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/ut il/Assert.html > >Paul Fully agree with you both, Stephan and Paul. A Validation class with a broad perspective makes much more sense to me. --Jesus From schlosna at gmail.com Wed Oct 14 08:11:17 2009 From: schlosna at gmail.com (David Schlosnagle) Date: Wed, 14 Oct 2009 11:11:17 -0400 Subject: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7 In-Reply-To: <4AD5E196.5090600@univ-mlv.fr> References: <4AD50DF4.8010503@sun.com> <4AD5E196.5090600@univ-mlv.fr> Message-ID: <9146341c0910140811j20b6b3a4w98bd96cd0ba001f0@mail.gmail.com> Hi R?mi, One quick comment on AbstractStringBuilder.join(String, Object, Object...) -- I'd propose to check that 'elements' is not null prior to appending 'first' so that if the preconditions are violated and the NullPointerException is thrown, there are no side effects. This would also be a nice use of the proposed java.util.Objects validation/precondition/assert methods. The other two join methods in AbstractStringBuilder will implicitly throw NullPointerException when getting the length or iterator respectively, both prior to any modification to the underlying AbstractStringBuilder. I'd be in favor of making those more explicit, but that is more of a stylistic comment. Thanks, Dave Schlosnagle On Wed, Oct 14, 2009 at 10:35 AM, R?mi Forax wrote: > Le 14/10/2009 01:32, Joseph D. Darcy a ?crit : >> >> Hello. >> >> Following up from threads earlier this year, >> >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html >> >> I'm willing and interested to sponsor getting String.join functionality >> into JDK 7. >> >> To address this particular bug, I think there should be new "join" methods >> on String as opposed to a general "joiner" class. ?A more general class >> could be added later. >> >> Remi, please point to a current draft of the specification and >> implementation for your change. >> >> Kevin, I'm interested in hearing your comments on the API design. >> >> Thanks, >> >> -Joe > > Hi Joe, > the webrev is here: > http://cr.openjdk.java.net/~forax/5015163/webrev.00/ > There is no specification, i.e no more than the javadoc. > > I will dig this evening to find the tests I've used, > they are on another computer at home which is currently shutdown. > > As Kevin said String.join is perhaps better as a static method, > see first part of: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001065.html > > regards, > R?mi > > > From Joe.Darcy at Sun.COM Wed Oct 14 10:14:18 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 14 Oct 2009 10:14:18 -0700 Subject: java.util.Objects, round two In-Reply-To: References: Message-ID: <4AD606EA.6040009@sun.com> Paul Benedict wrote: > Joe, > > I am confused over this warning: > >> * Warning: When a single object reference is supplied, the returned >> * value does not equal the hash code of that object reference. This >> * value can be computed by calling {@link #hashCode(Object)}. >> > > I first looked into Arrays#deepHashCode and did not see any companion > warning there; therefore I am presuming this is new functionality. No, the behavior is the same. Objects.hash is just a var-arg wrapper around Arrays.hashCode(Object[]). The semantic difference is that for Object.hash, one is passing a number of objects, which happen to get bundled into an array, whereas in Arrays.hashCode an array is being explicitly passed. > Two > questions remain based on looking at the javadoc alone and not knowing > its implementation: > > For when a single object reference is supplied: > 1) Why is the hash code not the hash code of the single object? Is > there harm in doing so? > As implied by the chain of javadocs, for a single object, hashcode + 31 is returned via the List.hashCode algorithm on a single element list. -Joe From pbenedict at apache.org Wed Oct 14 10:42:55 2009 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 14 Oct 2009 12:42:55 -0500 Subject: Constants for @SuppressWarnings Message-ID: Question for anyone on the list. What do you think about adding a limited number of String constants to identify common warning types? I personally don't like raw string in my code and would prefer to use constants for them. I would prefer something like: @SuppressWarnings(UNCHECKED) // static import from SuppressWarnings My choices would be: public static final String ALL = "all"; public static final String FALL_THROUGH = "fallthrough"; public static final String SERIAL = "serial"; public static final String UNCHECKED = "unchecked"; >From what I understand, the warnings are vendor specific, but reality shows me there's a practical pool of constants already in use. From the javadoc: > Compiler vendors should document the warning names they support in > conjunction with this annotation type. They are encouraged to cooperate > to ensure that the same names work across multiple compilers. Would such a patch be considered? Paul From Ulf.Zibis at gmx.de Wed Oct 14 11:35:15 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 14 Oct 2009 20:35:15 +0200 Subject: Request for review: Race conditions in java.nio.charset.Charset In-Reply-To: <4ACD01B6.5030607@sun.com> References: <4ACBC00B.9060602@gmx.de> <4ACCD641.5080809@sun.com> <4ACCF217.6000303@gmx.de> <4ACD01B6.5030607@sun.com> Message-ID: <4AD619E3.1020204@gmx.de> Am 07.10.2009 23:01, Xueming Shen schrieb: > Ulf Zibis wrote: >> Sherman, thanks for your review ... >> >> Am 07.10.2009 19:56, Xueming Shen schrieb: >>> Though I did not write the cache code my reading suggests the >>> existing cache >>> impl tries to avoid the relatively "expensive" synchronization for >>> most use scenarios, >>> your approach however hits the synchronization for each/every lookup >>> invocation. >>> So you should at least consider to put the sync block in a separate >>> lookup2. >> >> Agreed: >> (But why separate lookup2? I suspect that Charset.forName() would >> occur in excessive loops, so hotspot potentially cold inline it.) > > Maybe I meant to say "to put the sync in a separate block" I have updated the changeset accordingly: https://bugs.openjdk.java.net/show_bug.cgi?id=100107 > >> >> Is synchronization more expensive, than instantiating new Object[] >> each time + 2 castings (to String + to Charset)? >> > > The difference is fast cpu + a good gc probably can make > "instantiating new Object[] each time + 2 castings" trivial, > but a synchronization only allows one thread run into the code block > and keeps anyone else outside waiting till the > first done. > See my benchmark I posted yesterday. The synchronized cache is ~10-20 % slower, if only 2 charsets are retrieved, but this should not count much, because the operations after (de/encoding some/many characters) should be much more expensive. If 4 charsets are retrieved, the new synchronized cache is up to 800 % faster. -Ulf From Ulf.Zibis at gmx.de Wed Oct 14 11:38:45 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 14 Oct 2009 20:38:45 +0200 Subject: Fix for 5015163, and my first webrev In-Reply-To: <4AD5E7DD.7080509@univ-mlv.fr> References: <498CA4CE.1090207@univ-mlv.fr> <4AD5E48E.80107@gmx.de> <4AD5E7DD.7080509@univ-mlv.fr> Message-ID: <4AD61AB5.4050409@gmx.de> Am 14.10.2009 17:01, R?mi Forax schrieb: > Le 14/10/2009 16:47, Ulf Zibis a ?crit : >> R?mi, >> >> can you tell me how you got the cr.openjdk.java.net account ? >> Is there any registration link? >> >> Thanks, >> >> Ulf > > I've got it because I've the right to push codes on mlvm repository > (the DaVinci machine repository). > I can use the same openjdk account to push webrevs on > cr.openjdk.java.net. Ah, ok, so I'm wondering why you are asking for sponsorship if you have commit rights. -Ulf From Joe.Darcy at Sun.COM Wed Oct 14 12:24:00 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 14 Oct 2009 12:24:00 -0700 Subject: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)] In-Reply-To: <004401ca4ce0$0ab1cc10$20156430$@com> References: <004401ca4ce0$0ab1cc10$20156430$@com> Message-ID: <4AD62550.5030206@sun.com> Jes?s Vi?uales wrote: >> I agree with Stephen. There are a slew of validation methods that >> would be beneficial, and if you really want to drive the JDK towards >> standard validation, refactor them out into a Validation class. Look >> at what Spring has written for themselves: >> >> http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/ut >> > il/Assert.html > >> Paul >> > > Fully agree with you both, Stephan and Paul. A Validation class with a > broad perspective makes much more sense to me. > --Jesus > > If such a validation class is added to the platform, the nonNull methods can be moved there. Until then, they can live in Objects. -Joe From gnu_andrew at member.fsf.org Wed Oct 14 14:19:44 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 14 Oct 2009 22:19:44 +0100 Subject: Fix for 5015163, and my first webrev In-Reply-To: <4AD61AB5.4050409@gmx.de> References: <498CA4CE.1090207@univ-mlv.fr> <4AD5E48E.80107@gmx.de> <4AD5E7DD.7080509@univ-mlv.fr> <4AD61AB5.4050409@gmx.de> Message-ID: <17c6771e0910141419n7878e9cenb9d0ce8ac4f78d39@mail.gmail.com> 2009/10/14 Ulf Zibis : > Am 14.10.2009 17:01, R?mi Forax schrieb: >> >> Le 14/10/2009 16:47, Ulf Zibis a ?crit : >>> >>> R?mi, >>> >>> can you tell me how you got the cr.openjdk.java.net account ? >>> Is there any registration link? >>> >>> Thanks, >>> >>> Ulf >> >> I've got it because I've the right to push codes on mlvm repository >> (the DaVinci machine repository). >> I can use the same openjdk account to push webrevs on cr.openjdk.java.net. > > Ah, ok, so I'm wondering why you are asking for sponsorship if you have > commit rights. > > -Ulf > > > Ulf, >From what I saw, he was asking for a review and approval of the patch rather than sponsorship. Patches still need to be approved even if the person has commit rights (even if this is not so clear from the number of Sun commits that are approved behind the scenes). -- 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 scolebourne at joda.org Wed Oct 14 14:42:19 2009 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 14 Oct 2009 22:42:19 +0100 Subject: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)] Message-ID: <4AD645BB.5070707@joda.org> Joseph D. Darcy wrote: > If such a validation class is added to the platform, the nonNull > methods can be moved there. Until then, they can live in Objects. At first glance, such an approach makes perfect sense. However, we should really stop and question whether it is right or not. One point that has been made about Java over recent times is that it lacks a clear direction. A number of small changes are being added (Project Coin and here) which don't necessarily have a cohesive goal. To my eye it seems that one reason for these getting the go-ahead is that they are suposedly low-risk and low-issue. Each individual change seems small and relatively minor that sometimes its tempting to think that they can cause no harm. Yet even with these seemingly simple changes we find that the lack of a clear vision for Java kicks in and causes trouble. I mention Coin here, because there have been real debates there on various features (including diamond type inference, ARM and map literals vs pair literals) and their proposed implementation. The question is whether the choices made *now* will hinder future evolution of the Java language. Because we (the Java community, and, I strongly suspect, Sun) have no clear view of where Java is going, it becomes impossible to judge whether those choices are the right ones or not. In this specific case, again we have a case where a change *now* may hinder the future evolution of the JDK libraries. If we add nonNull to "Objects", then it will be in the wrong place and confusing if we then add a "Validate" class in JDK8. Or we all have to accept duplication. More broadly, and looking at this discussion overall and Joe's responses, I read between the lines that Joe only has approval to add a single class "Objects", and no other classes (such as "Hasher", "Joiner", "Strings", "Validate", and many others we might find useful). Because the remit is so narrow, we don't get to properly examine more broadly what additions are needed to the core libraries. As such, it feels like the decisions taken here and now have the potential to be remarkably hit and miss. Stephen From pbenedict at apache.org Wed Oct 14 14:57:23 2009 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 14 Oct 2009 16:57:23 -0500 Subject: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)] Message-ID: Stephen, My interpretation of Joe's email was that it would stay in j.u.Objects unless someone (other than him) contributes the Validate class and tests. Granting your point, his choice would otherwise stand and re-factoring it after JDK 7 would be impossible. I am interested in such a class and will try submit my first patch for JDK. Do you want to help? I am open to doing it together. Paul From Joe.Darcy at Sun.COM Wed Oct 14 15:06:01 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Wed, 14 Oct 2009 15:06:01 -0700 Subject: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)] In-Reply-To: <4AD645BB.5070707@joda.org> References: <4AD645BB.5070707@joda.org> Message-ID: <4AD64B49.40901@sun.com> Stephen Colebourne wrote: > Joseph D. Darcy wrote: >> If such a validation class is added to the platform, the nonNull >> methods can be moved there. Until then, they can live in Objects. > At first glance, such an approach makes perfect sense. However, we > should really stop and question whether it is right or not. > > One point that has been made about Java over recent times is that it > lacks a clear direction. A number of small changes are being added > (Project Coin and here) which don't necessarily have a cohesive goal. To > my eye it seems that one reason for these getting the go-ahead is that > they are suposedly low-risk and low-issue. Each individual change seems > small and relatively minor that sometimes its tempting to think that > they can cause no harm. Yet even with these seemingly simple changes we > find that the lack of a clear vision for Java kicks in and causes > trouble. > > I mention Coin here, because there have been real debates there on There have more often been long exchanges dominated by heat rather than light, but that is not unique to the Coin list. [snip] > More broadly, and looking at this discussion overall and Joe's > responses, I read between the lines that Joe only has approval to add a > single class "Objects", and no other classes (such as "Hasher", > "Joiner", "Strings", "Validate", and many others we might find useful). My side project here is defining java.util.Objects. It is not defining "Hasher," "Joiner," "Splitter," "Validator," or any other possibly useful class. Anyone else is free to send in proposals, implementations, and tests for such facilities and someone might offer to sponsor such proposals through the currently Sun-internal processes to get API changes in JDK 7, as I've recently offered to do for String.join. -Joe From jonathan.gibbons at sun.com Wed Oct 14 15:42:52 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 14 Oct 2009 22:42:52 +0000 Subject: hg: jdk7/tl/langtools: 6838467: JSR199 FileObjects don't obey general contract of equals. Message-ID: <20091014224254.C62AB41628@hg.openjdk.java.net> Changeset: 86b773b7cb40 Author: jjg Date: 2009-10-14 15:41 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/86b773b7cb40 6838467: JSR199 FileObjects don't obey general contract of equals. Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! test/tools/javac/api/6440528/T6440528.java + test/tools/javac/api/T6838467.java From Mandy.Chung at Sun.COM Wed Oct 14 16:57:50 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Wed, 14 Oct 2009 16:57:50 -0700 Subject: Review request for 6891707: Eliminate the java.io.FilePermission dependency on PolicyFile Message-ID: <4AD6657E.8010907@sun.com> Alan, Sean, Can you review the fix for: 6891707: Eliminate the java.io.FilePermission dependency on PolicyFile Webrev: http://cr.openjdk.java.net/~mchung/6891707/webrev.00/ FilePermission and PolicyFile are the two callers to the sun.security.provider.PolicyFile.canonPath method. Adding a new class for the canonPath method seems unnecessary. So the fix just duplicates the code in FilePermission class. Thanks Mandy From jodastephen at gmail.com Wed Oct 14 14:40:05 2009 From: jodastephen at gmail.com (Stephen Colebourne) Date: Wed, 14 Oct 2009 22:40:05 +0100 Subject: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)] In-Reply-To: <4AD62550.5030206@sun.com> References: <004401ca4ce0$0ab1cc10$20156430$@com> <4AD62550.5030206@sun.com> Message-ID: <4AD64535.7060104@gmail.com> Joseph D. Darcy wrote: > If such a validation class is added to the platform, the nonNull > methods can be moved there. Until then, they can live in Objects. At first glance, such an approach makes perfect sense. However, we should really stop and question whether it is right or not. One point that has been made about Java over recent times is that it lacks a clear direction. A number of small changes are being added (Project Coin and here) which don't necessarily have a cohesive goal. To my eye it seems that one reason for these getting the go-ahead is that they are suposedly low-risk and low-issue. Each individual change seems small and relatively minor that sometimes its tempting to think that they can cause no harm. Yet even with these seemingly simple changes we find that the lack of a clear vision for Java kicks in and causes trouble. I mention Coin here, because there have been real debates there on various features (including diamond type inference, ARM and map literals vs pair literals) and their proposed implementation. The question is whether the choices made *now* will hinder future evolution of the Java language. Because we (the Java community, and, I strongly suspect, Sun) have no clear view of where Java is going, it becomes impossible to judge whether those choices are the right ones or not. In this specific case, again we have a case where a change *now* may hinder the future evolution of the JDK libraries. If we add nonNull to "Objects", then it will be in the wrong place and confusing if we then add a "Validate" class in JDK8. Or we all have to accept duplication. More broadly, and looking at this discussion overall and Joe's responses, I read between the lines that Joe only has approval to add a single class "Objects", and no other classes (such as "Hasher", "Joiner", "Strings", "Validate", and many others we might find useful). Because the remit is so narrow, we don't get to properly examine more broadly what additions are needed to the core libraries. As such, it feels like the decisions taken here and now have the potential to be remarkably hit and miss. Stephen From joe.darcy at sun.com Wed Oct 14 18:56:59 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Thu, 15 Oct 2009 01:56:59 +0000 Subject: hg: jdk7/tl/langtools: 6558804: Specification for Elements.getDocComment(Element e) should be clarified Message-ID: <20091015015701.41FC541661@hg.openjdk.java.net> Changeset: b8936a7930fe Author: darcy Date: 2009-10-14 18:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b8936a7930fe 6558804: Specification for Elements.getDocComment(Element e) should be clarified Reviewed-by: jjg ! src/share/classes/javax/lang/model/util/Elements.java From mandy.chung at sun.com Wed Oct 14 20:22:22 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Thu, 15 Oct 2009 03:22:22 +0000 Subject: hg: jdk7/tl/jdk: 6891701: test/java/lang/management/RuntimeMXBean/GetSystemProperties should restore the system property Message-ID: <20091015032235.2FB2F41679@hg.openjdk.java.net> Changeset: 16b33372af1c Author: mchung Date: 2009-10-14 20:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16b33372af1c 6891701: test/java/lang/management/RuntimeMXBean/GetSystemProperties should restore the system property Summary: Restore the system properties when the test finishes Reviewed-by: jjg ! test/java/lang/management/RuntimeMXBean/GetSystemProperties.java ! test/java/lang/management/RuntimeMXBean/PropertiesTest.java From Alan.Bateman at Sun.COM Thu Oct 15 02:12:01 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 15 Oct 2009 10:12:01 +0100 Subject: Review request for 6891707: Eliminate the java.io.FilePermission dependency on PolicyFile In-Reply-To: <4AD6657E.8010907@sun.com> References: <4AD6657E.8010907@sun.com> Message-ID: <4AD6E761.1030701@sun.com> Mandy Chung wrote: > Alan, Sean, > > Can you review the fix for: > 6891707: Eliminate the java.io.FilePermission dependency on PolicyFile > > Webrev: > http://cr.openjdk.java.net/~mchung/6891707/webrev.00/ > > FilePermission and PolicyFile are the two callers to the > sun.security.provider.PolicyFile.canonPath method. Adding a new class > for the canonPath method seems unnecessary. So the fix just > duplicates the code in FilePermission class. > > Thanks > Mandy This looks okay to me. Minor comment is this is just a wrapper about getCanonicalPath to avoid calling it with paths that are intended to match all entries in the directory. It might be good to include this in a comment in both places (and this would avoid needing to say that it duplicated in FilePermission). -Alan From Ulf.Zibis at gmx.de Thu Oct 15 03:19:57 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 15 Oct 2009 12:19:57 +0200 Subject: Fix for 5015163, and my first webrev In-Reply-To: <17c6771e0910141419n7878e9cenb9d0ce8ac4f78d39@mail.gmail.com> References: <498CA4CE.1090207@univ-mlv.fr> <4AD5E48E.80107@gmx.de> <4AD5E7DD.7080509@univ-mlv.fr> <4AD61AB5.4050409@gmx.de> <17c6771e0910141419n7878e9cenb9d0ce8ac4f78d39@mail.gmail.com> Message-ID: <4AD6F74D.9000501@gmx.de> Am 14.10.2009 23:19, Andrew John Hughes schrieb: > 2009/10/14 Ulf Zibis : > >> Am 14.10.2009 17:01, R?mi Forax schrieb: >> >>> Le 14/10/2009 16:47, Ulf Zibis a ?crit : >>> >>>> R?mi, >>>> >>>> can you tell me how you got the cr.openjdk.java.net account ? >>>> Is there any registration link? >>>> >>>> Thanks, >>>> >>>> Ulf >>>> >>> I've got it because I've the right to push codes on mlvm repository >>> (the DaVinci machine repository). >>> I can use the same openjdk account to push webrevs on cr.openjdk.java.net. >>> >> Ah, ok, so I'm wondering why you are asking for sponsorship if you have >> commit rights. >> >> -Ulf >> >> >> >> > > Ulf, > > >From what I saw, he was asking for a review and approval of the patch > rather than sponsorship. Patches still need to be approved even if > the person has commit rights (even if this is not so clear from the > number of Sun commits that are approved behind the scenes). > Andrew, sorry for the confusion. My question regarding sponsorship referred to http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-October/002967.html Thanks for your answer anyway! -Ulf From michael.mcmahon at sun.com Thu Oct 15 04:06:30 2009 From: michael.mcmahon at sun.com (michael.mcmahon at sun.com) Date: Thu, 15 Oct 2009 11:06:30 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20091015110656.4DF32416FB@hg.openjdk.java.net> Changeset: 57fe28f3878a Author: michaelm Date: 2009-10-15 12:03 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/57fe28f3878a 6886436: Lightwight HTTP Container (com.sun.* package) is unstable Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ExchangeImpl.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/com/sun/net/httpserver/bugs/B6886436.java Changeset: 9cf64e7a9978 Author: michaelm Date: 2009-10-15 12:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cf64e7a9978 Merge - src/share/classes/sun/security/provider/certpath/LDAPCertStore.java From alan.bateman at sun.com Thu Oct 15 06:03:17 2009 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Thu, 15 Oct 2009 13:03:17 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20091015130355.EA3454171B@hg.openjdk.java.net> Changeset: f6833a276c1d Author: alanb Date: 2009-10-15 11:54 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f6833a276c1d 6883983: JarVerifier dependency on sun.security.pkcs should be removed Reviewed-by: sherman, wetmore ! src/share/classes/java/util/jar/JarVerifier.java Changeset: cb903c9eaebf Author: alanb Date: 2009-10-15 11:55 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb903c9eaebf 6891404: (fs) ACL tests fail with "Invalid argument" on ZFS (sol) Reviewed-by: sherman ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! test/java/nio/file/attribute/AclFileAttributeView/Basic.java Changeset: 0f92452973eb Author: alanb Date: 2009-10-15 14:02 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f92452973eb Merge From frederic.martini at gmail.com Thu Oct 15 06:32:30 2009 From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=) Date: Thu, 15 Oct 2009 15:32:30 +0200 Subject: C system() equivalent method. In-Reply-To: References: Message-ID: Hello, Sorry to revive this request, but I think this is as simple but very useful method that must be present on Java 7. No one have an opinion on this? Fred, Le 17 septembre 2009 09:16, Fr?d?ric Martini a ?crit : > Hello (before to start, sorry for my bad english) > > > I have seen in the last JDK's build that ProcessBuilder allow to > manage the process I/O more efficiently. > In particular, the inheritIO() set the subprocess standard I/O to be > the same as those of the current Java process, and offer a behavior > "equivalent" to the standard C library function system(). This is very > great an usefull ! > > But there is another BIG difference between ProcessBuilder and the C > library function system() : ProcessBuilder execute an application, and > C system() evaluate a command-line using the OS's shell. So C's > system() can use a lot of OS's specific syntax ($ENV or %ENV%, * ?, > pipe, redirect, etc...) witch is incorrect on a ProcessBuilder > (because this syntax is not interpreted but directly passed to the > application). > > This is a common misunderstanding for Java's developer... > > > My proposal simply consist to add a method that create a > ProcessBuilder pre-filled with a shell command's line, by invoking the > OS's shell ("/bin/sh" on Unixes, "command.com" on Win9x, "cmd.exe" on > WinNT, etc. ? ) in order to evaluate a more complex command-line. > A "basic" implementation can be like this : > > ====================================================================== > > /** > * Create a new ProcessBuilder initialized to call an OS's > * specific command-line. > */ > public static ProcessBuilder createShellFor(String commandLine) { > String osName = System.getProperty("os.name"); > if (osName.startsWith("Windows")) { > if (osName.startsWith("Windows 95") || > osName.startsWith("Windows 98") || > osName.startsWith("Windows Me") ) { > return new > ProcessBuilder("command.com", "/C", commandLine); > } > return new ProcessBuilder("cmd.exe", "/C", > commandLine); > } > return new ProcessBuilder("/bin/sh", "-c", commandLine); > } > > ====================================================================== > This method can be improved with more specific code depending on OS. > > > > > And a "system()" method with a behavior really equivalent to the > standard C library function system(), like this : > > ====================================================================== > > /** > * Executes a command specified in 'commandLine' by calling > * the OS shell program, and returns after the command has been > completed. > * @param commandLine The command-line to execute, using OS shell. > * @return the exit value of the subprocess > */ > public static int system(String commandLine) throws IOException, > InterruptedException { > final Process process = > createShellFor(commandLine).inheritIO().start(); > try { > return process.waitFor(); > } finally { > process.destroy(); > } > } > > ====================================================================== > > So, more complex and specific command-line can be used directly, like > in lots of others languages... > > > Thanks for reading, > Fred > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091015/e26c5771/attachment.html From Alan.Bateman at Sun.COM Thu Oct 15 06:47:56 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 15 Oct 2009 14:47:56 +0100 Subject: Review request #1: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <4AD5D9F0.3000801@sun.com> References: <4AD5D9F0.3000801@sun.com> Message-ID: <4AD7280C.2010102@sun.com> Martin, Michael - have either of you looked at the filtering that they are proposing to add to ProcessEnvironment? Anthony Petrov wrote: > Hello, > > Please review the next version of the fix contributed by Damjan > Jovanovic: > > RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094 > There you can also find some latest comments regarding the fix. > > webrev: > http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.1/ > > Since the patch includes changes to the > src/solaris/classes/java/lang/ProcessEnvironment.java, I'm > CC'ing the Core Libs alias to review the changes in that file. > > > From AWT perspective, the changes look good to me. > > -- > best regards, > Anthony From mario.torre at aicas.com Thu Oct 15 06:50:48 2009 From: mario.torre at aicas.com (Mario Torre) Date: Thu, 15 Oct 2009 15:50:48 +0200 Subject: C system() equivalent method. In-Reply-To: References: Message-ID: <4AD728B8.9080005@aicas.com> Il 15/10/2009 15:32, Fr?d?ric Martini ha scritto: > Hello, > > > Sorry to revive this request, but I think this is as simple but very useful > method that must be present on Java 7. > > No one have an opinion on this? > > Fred, I'm not sure. In my opinion this is easy to do in application code using something similar to what you did or Runtime.exec, but doesn't fit into the core library. Also, in this implementation you are assuming lots of things that are not valid everywhere, like: The system is either Windows or Linux or Solaris (or some other "sane" unix variant), the system has /bin/sh, and it's possible to use it to execute process etc... I would not like much to see this in the standard library, especially in java.lang, as this thing is non portable by definition. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Michael.McMahon at Sun.COM Thu Oct 15 08:10:03 2009 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 15 Oct 2009 16:10:03 +0100 Subject: Review request #1: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <4AD7280C.2010102@sun.com> References: <4AD5D9F0.3000801@sun.com> <4AD7280C.2010102@sun.com> Message-ID: <4AD73B4B.2020405@sun.com> It doesn't seem right to filter out arbitrary environment variables like that (inside ProcessEnvironment). Sorry, I haven't been following this issue closely, but is it not possible to unset this variable somewhere else? - Michael. Alan Bateman wrote: > > Martin, Michael - have either of you looked at the filtering that they > are proposing to add to ProcessEnvironment? > > > Anthony Petrov wrote: >> Hello, >> >> Please review the next version of the fix contributed by Damjan >> Jovanovic: >> >> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094 >> There you can also find some latest comments regarding the fix. >> >> webrev: >> http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.1/ >> >> Since the patch includes changes to the >> src/solaris/classes/java/lang/ProcessEnvironment.java, I'm >> CC'ing the Core Libs alias to review the changes in that file. >> >> >> From AWT perspective, the changes look good to me. >> >> -- >> best regards, >> Anthony > From gnu_andrew at member.fsf.org Thu Oct 15 08:23:23 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 15 Oct 2009 16:23:23 +0100 Subject: Review request #1: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <4AD73B4B.2020405@sun.com> References: <4AD5D9F0.3000801@sun.com> <4AD7280C.2010102@sun.com> <4AD73B4B.2020405@sun.com> Message-ID: <17c6771e0910150823n5afdc222p3702f7d793a1134@mail.gmail.com> 2009/10/15 Michael McMahon : > It doesn't seem right to filter out arbitrary environment variables > like that (inside ProcessEnvironment). Sorry, I haven't been following this > issue closely, > but is it not possible to unset this variable somewhere else? > I concur. That's a nasty hack that's going to create an artificial difference between the native environment and the environment as seen from Java. > - Michael. > > Alan Bateman wrote: >> >> Martin, Michael - have either of you looked at the filtering that they are >> proposing to add to ProcessEnvironment? >> >> >> Anthony Petrov wrote: >>> >>> Hello, >>> >>> Please review the next version of the fix contributed by Damjan >>> Jovanovic: >>> >>> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094 >>> There you can also find some latest comments regarding the fix. >>> >>> webrev: >>> http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.1/ >>> >>> Since the patch includes changes to the >>> src/solaris/classes/java/lang/ProcessEnvironment.java, I'm >>> CC'ing the Core Libs alias to review the changes in that file. >>> >>> >>> From AWT perspective, the changes look good to me. >>> >>> -- >>> best regards, >>> Anthony >> > > -- 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 Dmitry.Nadezhin at Sun.COM Thu Oct 15 10:03:41 2009 From: Dmitry.Nadezhin at Sun.COM (Dmitry Nadezhin) Date: Thu, 15 Oct 2009 21:03:41 +0400 Subject: BigInteger.bitLength() can return negative result In-Reply-To: References: Message-ID: <4AD755ED.1040704@sun.com> BigInteger is a class implementing arbitrary-precision integers. Of course, it is an idealization. Let's look at implementation limits of this type. The bits are stored in "int[] mag" array. This sets the maximum bit length 32*(2^31 - 1). The "BigInteger.magSerializedForm()" converts bits to "byte[]" array. Serialization of BigInteger will throw an exception on values with bit length larger than 8*(2^31 - 1). The methods "BigInteger.bitLength()", "BigInteger.bitCount()", "BigInteger.getLowestSetBit()" return result as "int". So they may wrap around when bit length is larger than "2^31 - 1". The method "BigInteger.toByteArray()" can fail on such values because it uses "bitLength()". In fact, the output of this program public static void main(String[] args) { BigInteger x = BigInteger.ONE.shiftLeft(Integer.MAX_VALUE); // x = 2^Integer.MAX_VALUE; System.out.println("bitLength="+x.bitLength()); try { byte[] bytes = x.toByteArray(); } catch (Exception e) { e.printStackTrace(System.out); } } is: bitLength=-2147483648 java.lang.NegativeArraySizeException at java_math.BigInteger.toByteArray(BigInteger.java:2689) Shouldn't BigInteger.bitLength()" conform its specification on all possible values of BigInteger ? This can be achieved in different ways: a) Don't change code but write about the wrap around in the specification of "bitLength()" and other methods ; b) Change the return type of "bitLength()" from "int" to "long"; c) "bitLength()" throws an exception when bit length is larger than 2^31 - 1; d) All BigInteger constructors ensure that the bit length is no larger than 2^31 - 1; Which way is better ? From Joe.Darcy at Sun.COM Thu Oct 15 10:42:31 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 15 Oct 2009 10:42:31 -0700 Subject: BigInteger.bitLength() can return negative result In-Reply-To: <4AD755ED.1040704@sun.com> References: <4AD755ED.1040704@sun.com> Message-ID: <4AD75F07.805@sun.com> Dmitry Nadezhin wrote: > BigInteger is a class implementing arbitrary-precision integers. Of > course, it is an idealization. Let's look at implementation limits of > this type. > > The bits are stored in "int[] mag" array. This sets the maximum bit > length 32*(2^31 - 1). > > The "BigInteger.magSerializedForm()" converts bits to "byte[]" array. > Serialization of BigInteger will throw an exception on values with bit > length larger than 8*(2^31 - 1). > > The methods "BigInteger.bitLength()", "BigInteger.bitCount()", > "BigInteger.getLowestSetBit()" return result as "int". > So they may wrap around when bit length is larger than "2^31 - 1". The > method "BigInteger.toByteArray()" can fail on such values because it > uses "bitLength()". > > In fact, the output of this program > public static void main(String[] args) { > BigInteger x = BigInteger.ONE.shiftLeft(Integer.MAX_VALUE); // x = > 2^Integer.MAX_VALUE; > System.out.println("bitLength="+x.bitLength()); > try { > byte[] bytes = x.toByteArray(); > } catch (Exception e) { > e.printStackTrace(System.out); > } > } > is: > bitLength=-2147483648 > java.lang.NegativeArraySizeException > at java_math.BigInteger.toByteArray(BigInteger.java:2689) Yes, the internal bookkeeping of BigInteger is not robust when extremely large values are used. > Shouldn't BigInteger.bitLength()" conform its specification on all > possible values of BigInteger ? > This can be achieved in different ways: > a) Don't change code but write about the wrap around in the > specification of "bitLength()" and other methods ; > b) Change the return type of "bitLength()" from "int" to "long"; Should we break binary compatibility of a commonly used class by changing the return type to fix this problem? Obviously not. > c) "bitLength()" throws an exception when bit length is larger than > 2^31 - 1; > d) All BigInteger constructors ensure that the bit length is no larger > than 2^31 - 1; d) is arguably the most correct approach to address the problem. However, I think the practical consequences of this flaw are low. -Joe From martinrb at google.com Thu Oct 15 10:59:09 2009 From: martinrb at google.com (Martin Buchholz) Date: Thu, 15 Oct 2009 10:59:09 -0700 Subject: C system() equivalent method. In-Reply-To: References: Message-ID: <1ccfd1c10910151059r22aaa62by45646467d1ffdaf3@mail.gmail.com> Hi Fr?d?ric, Thanks for your suggestion. The JDK has long had a culture of pushing people to write portable code, and so any facility that would make it easier to interact with the operating system in a non-portable way meets resistance. Another issue is that the "default" C system shell tends to become dated over time - there are often better command interpreters. Nevertheless, the existence of C "system" and the "shell" keyword arg to python's subprocess.Popen are strong arguments that the concept of a default shell is entrenched in the programmer community. Therefore, I support this proposal in principle. Would someone at Sun like to sponsor this API change? The spec probably needs a bit more work, so that readers will know that we're talking about e.g. /bin/sh without making that explicit. Martin 2009/9/17 Fr?d?ric Martini : > Hello (before to start, sorry for my bad english) > > > I have seen in the last JDK's build that ProcessBuilder allow to > manage the process I/O more efficiently. > In particular, the inheritIO() set the subprocess standard I/O to be > the same as those of the current Java process, and offer a behavior > "equivalent" to the standard C library function system(). This is very > great an usefull ! > > But there is another BIG difference between ProcessBuilder and the C > library function system() : ProcessBuilder execute an application, and > C system() evaluate a command-line using the OS's shell. So C's > system() can use a lot of OS's specific syntax ($ENV or %ENV%, * ?, > pipe, redirect, etc...) witch is incorrect on a ProcessBuilder > (because this syntax is not interpreted but directly passed to the > application). > > This is a common misunderstanding for Java's developer... > > > My proposal simply consist to add a method that create a > ProcessBuilder pre-filled with a shell command's line, by invoking the > OS's shell ("/bin/sh" on Unixes, "command.com" on Win9x, "cmd.exe" on > WinNT, etc. ? ) in order to evaluate a more complex command-line. > A "basic" implementation can be like this : > > ====================================================================== > > ? ? ? /** > ? ? ? ?* Create a new ProcessBuilder initialized to call an OS's > ? ? ? ?* specific command-line. > ? ? ? ?*/ > ? ? ? public static ProcessBuilder createShellFor(String commandLine) { > ? ? ? ? ? ? ? String osName = System.getProperty("os.name"); > ? ? ? ? ? ? ? if (osName.startsWith("Windows")) { > ? ? ? ? ? ? ? ? ? ? ? if (osName.startsWith("Windows 95") || > ? ? ? ? ? ? ? ? ? ? ? ?osName.startsWith("Windows 98") || > ? ? ? ? ? ? ? ? ? ? ? ?osName.startsWith("Windows Me") ) { > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? return new > ProcessBuilder("command.com", "/C", commandLine); > ? ? ? ? ? ? ? ? ? ? ? } > ? ? ? ? ? ? ? ? ? ? ? return new ProcessBuilder("cmd.exe", "/C", commandLine); > ? ? ? ? ? ? ? } > ? ? ? ? ? ? ? return new ProcessBuilder("/bin/sh", "-c", commandLine); > ? ? ? } > > ====================================================================== > This method can be improved with more specific code depending on OS. > > > > > And a "system()" method with a behavior really equivalent to the > standard C library function system(), like this : > > ====================================================================== > > ? ? ? /** > ? ? ? ?* Executes a command specified in 'commandLine' by calling > ? ? ? ?* the OS shell program, and returns after the command has been > completed. > ? ? ? ?* @param commandLine The command-line to execute, using OS shell. > ? ? ? ?* @return the exit value of the subprocess > ? ? ? ?*/ > ? ? ? public static int system(String commandLine) throws IOException, > InterruptedException { > ? ? ? ? ? ? ? final Process process = > createShellFor(commandLine).inheritIO().start(); > ? ? ? ? ? ? ? try { > ? ? ? ? ? ? ? ? ? ? ? return process.waitFor(); > ? ? ? ? ? ? ? } finally { > ? ? ? ? ? ? ? ? ? ? ? process.destroy(); > ? ? ? ? ? ? ? } > ? ? ? } > > ====================================================================== > > So, more complex and specific command-line can be used directly, like > in lots of others languages... > > > Thanks for reading, > Fred > From damjan.jov at gmail.com Thu Oct 15 11:04:30 2009 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Thu, 15 Oct 2009 20:04:30 +0200 Subject: Review request #1: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <4AD73B4B.2020405@sun.com> References: <4AD5D9F0.3000801@sun.com> <4AD7280C.2010102@sun.com> <4AD73B4B.2020405@sun.com> Message-ID: <9e89675b0910151104u130a23c4ka3de99295f618076@mail.gmail.com> The environment variable: * Must not be inherited by child processes * Ideally, should not be seen by Java apps AFAIK Java has no API to unset environment variables. Even if it did, it would be too late for an AWT window to unset it, because child processes can be launched sooner and would still inherit the environment variable. My previous solution (http://bugs.openjdk.java.net/attachment.cgi?id=119) was to modify the *nix launcher so it moves the variable into a java.lang.System property early during Java startup, but then people were unhappy about modifying the launcher (http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-July/002216.html and replies). So what's left? What solution would be acceptable? Please suggest something. Thank you Damjan On Thu, Oct 15, 2009 at 5:10 PM, Michael McMahon wrote: > It doesn't seem right to filter out arbitrary environment variables > like that (inside ProcessEnvironment). Sorry, I haven't been following this > issue closely, > but is it not possible to unset this variable somewhere else? > > - Michael. > > Alan Bateman wrote: >> >> Martin, Michael - have either of you looked at the filtering that they are >> proposing to add to ProcessEnvironment? >> >> >> Anthony Petrov wrote: >>> >>> Hello, >>> >>> Please review the next version of the fix contributed by Damjan >>> Jovanovic: >>> >>> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094 >>> There you can also find some latest comments regarding the fix. >>> >>> webrev: >>> http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.1/ >>> >>> Since the patch includes changes to the >>> src/solaris/classes/java/lang/ProcessEnvironment.java, I'm >>> CC'ing the Core Libs alias to review the changes in that file. >>> >>> >>> From AWT perspective, the changes look good to me. >>> >>> -- >>> best regards, >>> Anthony >> > > From Dmitry.Nadezhin at Sun.COM Thu Oct 15 11:11:11 2009 From: Dmitry.Nadezhin at Sun.COM (Dmitry Nadezhin) Date: Thu, 15 Oct 2009 22:11:11 +0400 Subject: BigInteger.bitLength() can return negative result In-Reply-To: <4AD75F07.805@sun.com> References: <4AD755ED.1040704@sun.com> <4AD75F07.805@sun.com> Message-ID: <4AD765BF.5050909@sun.com> >> d) All BigInteger constructors ensure that the bit length is no >> larger than 2^31 - 1; > > d) is arguably the most correct approach to address the problem. > However, I think the practical consequences of this flaw are low. Nevertheless, may I use this unimportant flaw as a lesson of Java bug fixing ? -Dima From Joe.Darcy at Sun.COM Thu Oct 15 11:27:16 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 15 Oct 2009 11:27:16 -0700 Subject: BigInteger.bitLength() can return negative result In-Reply-To: <4AD765BF.5050909@sun.com> References: <4AD755ED.1040704@sun.com> <4AD75F07.805@sun.com> <4AD765BF.5050909@sun.com> Message-ID: <4AD76984.4080208@sun.com> Dmitry Nadezhin wrote: > >>> d) All BigInteger constructors ensure that the bit length is no >>> larger than 2^31 - 1; >> >> d) is arguably the most correct approach to address the problem. >> However, I think the practical consequences of this flaw are low. > Nevertheless, may I use this unimportant flaw as a lesson of Java bug > fixing ? > No fix for the bug has yet been offered. You're independently rediscovered a bug that has been in the platform for about 12 years. -Joe From Joe.Darcy at Sun.COM Thu Oct 15 17:16:59 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 15 Oct 2009 17:16:59 -0700 Subject: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7 In-Reply-To: <4AD5E196.5090600@univ-mlv.fr> References: <4AD50DF4.8010503@sun.com> <4AD5E196.5090600@univ-mlv.fr> Message-ID: <4AD7BB7B.2030802@sun.com> R?mi Forax wrote: > Le 14/10/2009 01:32, Joseph D. Darcy a ?crit : >> Hello. >> >> Following up from threads earlier this year, >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html >> >> >> I'm willing and interested to sponsor getting String.join >> functionality into JDK 7. >> >> To address this particular bug, I think there should be new "join" >> methods on String as opposed to a general "joiner" class. A more >> general class could be added later. >> >> Remi, please point to a current draft of the specification and >> implementation for your change. >> >> Kevin, I'm interested in hearing your comments on the API design. >> >> Thanks, >> >> -Joe > > Hi Joe, > the webrev is here: > http://cr.openjdk.java.net/~forax/5015163/webrev.00/ > There is no specification, i.e no more than the javadoc. > > I will dig this evening to find the tests I've used, > they are on another computer at home which is currently shutdown. > > As Kevin said String.join is perhaps better as a static method, > see first part of: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001065.html > Yes, I'd also lean toward static methods for this functionality. -Joe From joe.darcy at sun.com Thu Oct 15 18:26:45 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Fri, 16 Oct 2009 01:26:45 +0000 Subject: hg: jdk7/tl/jdk: 4428022: System.out.println(0.001) outputs 0.0010 Message-ID: <20091016012658.432BA41803@hg.openjdk.java.net> Changeset: f85aa3aedf41 Author: darcy Date: 2009-10-15 18:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f85aa3aedf41 4428022: System.out.println(0.001) outputs 0.0010 Reviewed-by: darcy Contributed-by: aph at redhat.com ! src/share/classes/sun/misc/FloatingDecimal.java + test/java/lang/Double/ToString.java From mandy.chung at sun.com Thu Oct 15 21:44:56 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Fri, 16 Oct 2009 04:44:56 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20091016044521.B5B7E4183F@hg.openjdk.java.net> Changeset: 16e4bbb7488d Author: mchung Date: 2009-10-15 17:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16e4bbb7488d 6891707: Eliminate the java.io.FilePermission dependency on PolicyFile Summary: Replace call to PolicyFile.canonPath with its own implementation Reviewed-by: alanb, mullan ! src/share/classes/java/io/FilePermission.java ! src/share/classes/sun/security/provider/PolicyFile.java Changeset: f1dab27d668a Author: mchung Date: 2009-10-15 20:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1dab27d668a Merge From martinrb at google.com Fri Oct 16 00:09:54 2009 From: martinrb at google.com (Martin Buchholz) Date: Fri, 16 Oct 2009 00:09:54 -0700 Subject: Review request #1: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <4AD73B4B.2020405@sun.com> References: <4AD5D9F0.3000801@sun.com> <4AD7280C.2010102@sun.com> <4AD73B4B.2020405@sun.com> Message-ID: <1ccfd1c10910160009h6d6cac43vb31ace4cd4efd72c@mail.gmail.com> (I'm the original author of ProcessEnvironment) I agree with other nay-sayers that we really don't want to have special treatment of magic environment variables. It's no surprise that the launcher and process maintainers resist the addition of AWT-specific code into their area. Immutability of the process environment is generally considered a feature, even though it is occasionally annoying - just like the immutability of String. The party line as of 7 years ago was that environment variables were evil and shouldn't be used at all - favor system properties instead. Martin On Thu, Oct 15, 2009 at 08:10, Michael McMahon wrote: > It doesn't seem right to filter out arbitrary environment variables > like that (inside ProcessEnvironment). Sorry, I haven't been following this > issue closely, > but is it not possible to unset this variable somewhere else? > > - Michael. > > Alan Bateman wrote: >> >> Martin, Michael - have either of you looked at the filtering that they are >> proposing to add to ProcessEnvironment? >> >> >> Anthony Petrov wrote: >>> >>> Hello, >>> >>> Please review the next version of the fix contributed by Damjan >>> Jovanovic: >>> >>> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094 >>> There you can also find some latest comments regarding the fix. >>> >>> webrev: >>> http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.1/ >>> >>> Since the patch includes changes to the >>> src/solaris/classes/java/lang/ProcessEnvironment.java, I'm >>> CC'ing the Core Libs alias to review the changes in that file. >>> >>> >>> From AWT perspective, the changes look good to me. >>> >>> -- >>> best regards, >>> Anthony >> > > From Michael.McMahon at Sun.COM Fri Oct 16 04:21:56 2009 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Fri, 16 Oct 2009 12:21:56 +0100 Subject: Review request #1: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <9e89675b0910151104u130a23c4ka3de99295f618076@mail.gmail.com> References: <4AD5D9F0.3000801@sun.com> <4AD7280C.2010102@sun.com> <4AD73B4B.2020405@sun.com> <9e89675b0910151104u130a23c4ka3de99295f618076@mail.gmail.com> Message-ID: <4AD85754.3050809@sun.com> Damjan Jovanovic wrote: > The environment variable: > * Must not be inherited by child processes > * Ideally, should not be seen by Java apps > > AFAIK Java has no API to unset environment variables. > > It is possible to manipulate the environment passed to sub-processes though. However, the spec is clear on the point that :- "environment variables which are not modified by Java code will have an unmodified native representation in the subprocess." I wonder if it might make sense to change this, so that some kind of default filtering could be applied? I don't know if it warrants a new API to do this, but maybe a system property could define a list of environment variables that are not passed to child processes. And this could be used in the desktop launcher scripts. - Michael. From martinrb at google.com Fri Oct 16 06:41:08 2009 From: martinrb at google.com (Martin Buchholz) Date: Fri, 16 Oct 2009 06:41:08 -0700 Subject: Review request #1: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <4AD85754.3050809@sun.com> References: <4AD5D9F0.3000801@sun.com> <4AD7280C.2010102@sun.com> <4AD73B4B.2020405@sun.com> <9e89675b0910151104u130a23c4ka3de99295f618076@mail.gmail.com> <4AD85754.3050809@sun.com> Message-ID: <1ccfd1c10910160641g41e3abe4wdc3afdee9d2377fa@mail.gmail.com> On Fri, Oct 16, 2009 at 04:21, Michael McMahon wrote: > Damjan Jovanovic wrote: > "environment variables which are not modified by Java code will have > ?an unmodified native representation in the subprocess." The intent of that statement is to promise not to mangle environment variables that cannot be represented as a String, perhaps because they contain undecodable binary data. IIRC, bash doesn't get this right. > > I wonder if it might make sense to change this, so that some kind > of default filtering could be applied? I don't know if it warrants a new API > to do this, but maybe a system property could define a list of environment > variables that are not passed to child processes. And this could be used > in the desktop launcher scripts. I continue to resist the addition of such a global mechanism. Martin From tim.bell at sun.com Fri Oct 16 10:36:49 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 16 Oct 2009 17:36:49 +0000 Subject: hg: jdk7/tl: 2 new changesets Message-ID: <20091016173649.9102141929@hg.openjdk.java.net> Changeset: 2c88089b6e1c Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/2c88089b6e1c Added tag jdk7-b73 for changeset 3ac6dcf78232 ! .hgtags Changeset: d1516b9f2395 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/d1516b9f2395 Added tag jdk7-b74 for changeset 2c88089b6e1c ! .hgtags From tim.bell at sun.com Fri Oct 16 10:36:54 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 16 Oct 2009 17:36:54 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20091016173655.F1DC54192A@hg.openjdk.java.net> Changeset: 5d0cf59a3203 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/5d0cf59a3203 Added tag jdk7-b73 for changeset b751c528c555 ! .hgtags Changeset: 0fb137085952 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/0fb137085952 Added tag jdk7-b74 for changeset 5d0cf59a3203 ! .hgtags From tim.bell at sun.com Fri Oct 16 10:38:19 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 16 Oct 2009 17:38:19 +0000 Subject: hg: jdk7/tl/hotspot: 54 new changesets Message-ID: <20091016174008.A133B4192B@hg.openjdk.java.net> Changeset: 489a4f8dcd0f Author: twisti Date: 2009-08-27 06:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/489a4f8dcd0f 6865583: Verbose CIPrintMethodCodes asserts when ldc an empty String Summary: ldc seems to load an empty String and that leads to an assert on offset < length, which are both zero. Reviewed-by: kvn, never ! src/share/vm/classfile/javaClasses.cpp Changeset: 8fe1963e3964 Author: kvn Date: 2009-08-28 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8fe1963e3964 6875577: CTW fails with /hotspot/src/share/vm/opto/memnode.cpp Summary: Fix do_null_check to check for unloaded klass for all oop pointers. Reviewed-by: never, cfang ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp Changeset: 1fbd5d696bf4 Author: twisti Date: 2009-08-31 02:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1fbd5d696bf4 6875967: CTW fails with./generated/adfiles/ad_sparc.cpp:6711 Reviewed-by: cfang, never ! src/cpu/sparc/vm/sparc.ad Changeset: ace8397c8563 Author: cfang Date: 2009-08-31 08:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ace8397c8563 6876276: assert(!is_visited,"visit only once") Summary: schedule the superword loads based on dependence constraints Reviewed-by: kvn, never ! src/share/vm/opto/superword.cpp ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java Changeset: ff1a29907b6c Author: never Date: 2009-08-31 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ff1a29907b6c 6855215: Calculation error (NaN) after about 1500 calculations Reviewed-by: kvn ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp + test/compiler/6855215/Test6855215.java Changeset: 0f1c19b7a52d Author: kvn Date: 2009-09-08 10:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0f1c19b7a52d 6875619: CTW fails with /hotspot/src/share/vm/opto/type.hpp Summary: In load_array_length() cast array's type to TypeOopPtr when calling make_ideal_length() method. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp Changeset: 26fbe81d30cf Author: kvn Date: 2009-09-08 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/26fbe81d30cf 6880052: SIGSEGV in GraphKit::null_check_common() Summary: Check that a klass is not NULL before the is_loaded() call. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp Changeset: 9a4e87ba1a90 Author: kvn Date: 2009-09-09 16:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9a4e87ba1a90 6880533: test/compiler/6865031/Test.java miss -XX:+IgnoreUnrecognizedVMOptions Summary: Add missing test option -XX:+IgnoreUnrecognizedVMOptions. Reviewed-by: never ! test/compiler/6865031/Test.java Changeset: 159d56b94894 Author: kvn Date: 2009-09-10 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/159d56b94894 6880574: C2 assert in escape.cpp:445 on linux-amd64 Summary: Look through chained AddP nodes in get_addp_base(). Reviewed-by: jrose ! src/share/vm/opto/escape.cpp Changeset: c7e94e8fff43 Author: kvn Date: 2009-09-10 18:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c7e94e8fff43 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Summary: Removed second CheckCastPP and use MembarCPUOrder after arraycopy to cloned object. Reviewed-by: never ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: a6f533fc33e0 Author: kvn Date: 2009-09-14 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a6f533fc33e0 Merge Changeset: eb058abd0562 Author: ysr Date: 2009-09-15 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/eb058abd0562 6861557: G1: assert(top() == bottom() || zfs == Allocated,"Region must be empty, or ...") Summary: Druing heap shrinking, check for emptiness of a region before modifying its ZF status. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: d7c9544cc141 Author: apetrusenko Date: 2009-09-18 06:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d7c9544cc141 Merge Changeset: aafa4232dfd7 Author: asaha Date: 2009-08-28 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/aafa4232dfd7 6821003: Update hotspot windows os_win32 for windows 7 Reviewed-by: xlu ! src/os/windows/vm/os_windows.cpp Changeset: 9601152ccfc1 Author: dcubed Date: 2009-08-28 12:25 -0600 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9601152ccfc1 6875393: 2/3 JNI itable index cache is broken Summary: Add missing initialization of cache size. Reviewed-by: tbell ! src/share/vm/oops/instanceKlass.cpp Changeset: 75e30968ebe1 Author: dcubed Date: 2009-08-28 12:32 -0600 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/75e30968ebe1 Merge ! src/share/vm/oops/instanceKlass.cpp Changeset: df97b1cf46d8 Author: dcubed Date: 2009-08-28 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/df97b1cf46d8 Merge Changeset: bb287c042e99 Author: apangin Date: 2009-08-30 15:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bb287c042e99 Merge Changeset: 6918603297f7 Author: poonam Date: 2009-09-01 23:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6918603297f7 6858208: jvm crash when specifying TypeProfileWidth=0 on jdk 6.0 Summary: Add an explicit check for TypeProfileWidth == 0 in record_klass_in_profile_helper() functions. Reviewed-by: never, coleenp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp Changeset: 5fdbe2cdf565 Author: andrew Date: 2009-09-08 09:01 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5fdbe2cdf565 6879689: Fix warning about ignored return value when compiling with -O2 Summary: Store the return value of fwrite and check it matches the size of the array. Reviewed-by: twisti, dholmes ! src/share/vm/adlc/archDesc.cpp Changeset: 0804a88ed4f5 Author: andrew Date: 2009-09-08 09:02 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0804a88ed4f5 Merge Changeset: 682194ca1d8d Author: acorn Date: 2009-09-10 09:04 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/682194ca1d8d Merge - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 0fc81f0a8ca8 Author: andrew Date: 2009-09-12 12:50 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0fc81f0a8ca8 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk Summary: The build fails if the bootstrap JDK defaults to <1.5 Reviewed-by: jcoomes ! make/linux/makefiles/jvmti.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/jvmti.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/sa.make ! make/solaris/makefiles/top.make ! make/windows/makefiles/generated.make ! make/windows/makefiles/jvmti.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/projectfiles/common/Makefile Changeset: e5b31fd85b72 Author: acorn Date: 2009-09-15 16:28 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e5b31fd85b72 Merge Changeset: ad6585fd4087 Author: acorn Date: 2009-09-04 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ad6585fd4087 6830542: Performance: JVM_DefineClass already verified. Reviewed-by: kamg, phh ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 26b774d693aa Author: acorn Date: 2009-09-16 09:10 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/26b774d693aa Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp Changeset: 83c29a26f67c Author: acorn Date: 2009-09-16 15:42 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/83c29a26f67c 6879572: SA fails _is_marked_dependent not found Reviewed-by: kamg, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 723131383de6 Author: acorn Date: 2009-09-18 15:14 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/723131383de6 Merge Changeset: 74a5db69c1fe Author: dcubed Date: 2009-09-21 09:30 -0600 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/74a5db69c1fe 6419370: 4/4 new jmethodID code has tiny holes in synchronization Summary: Fix races in jmethodID cache and JNI itable index cache. Reviewed-by: ikrylov, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.hpp Changeset: d72ba3205918 Author: acorn Date: 2009-09-21 18:10 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d72ba3205918 Merge Changeset: 87770dcf831b Author: dcubed Date: 2009-09-22 21:12 -0600 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/87770dcf831b 6876794: 4/4 sp07t002 hangs very intermittently Summary: remove over locking by VMThread on "is thread suspended?" check Reviewed-by: dholmes, acorn, andrew ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: c3c4a1d3801a Author: andrew Date: 2009-09-23 11:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c3c4a1d3801a 6884552: remove some unnecessary #ifdef's introduced in the fix for 4957990 Summary: Removed the unnecessary #ifdef's which were interfering with the build of the Zero-assembler port Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: 1af62b6ca0f9 Author: apetrusenko Date: 2009-09-25 04:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1af62b6ca0f9 Merge Changeset: 7a102acc9f17 Author: trims Date: 2009-09-25 12:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7a102acc9f17 Merge ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/prims/jvm.h Changeset: faf94d94786b Author: trims Date: 2009-09-25 12:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/faf94d94786b 6885900: Bump the HS17 build number to 02 Summary: Update the HS17 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6ddec5389232 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6ddec5389232 Added tag jdk7-b73 for changeset faf94d94786b ! .hgtags Changeset: 685e959d09ea Author: cfang Date: 2009-09-14 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/685e959d09ea 6877254: Server vm crashes with no branches off of store slice" when run with CMS and UseSuperWord(default) Summary: design StoreCMNode::Ideal to promote its oopStore input if the input is a MergeMem node Reviewed-by: kvn, never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/superword.cpp + test/compiler/6877254/Test.java Changeset: 62001a362ce9 Author: kvn Date: 2009-09-14 12:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/62001a362ce9 6827605: new String intrinsics may prevent EA scalar replacement 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 Summary: Modify String intrinsic methods to pass char[] pointers instead of string oops. Reviewed-by: never ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6875866/Test.java Changeset: 00977607da34 Author: cfang Date: 2009-09-15 11:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/00977607da34 6879921: CTW failure jdk6_18/hotspot/src/share/vm/utilities/globalDefinitions.cpp:268 Summary: filter out non-primitives before deciding whether two ops can be packed Reviewed-by: kvn, never ! src/share/vm/opto/superword.cpp Changeset: 7e309ecb83ce Author: kvn Date: 2009-09-15 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7e309ecb83ce 6879362: assert(!klass_is_exact(),"only non-exact klass") Summary: Do nothing for AddP node which has type not related to the type of allocated object. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: 148e5441d916 Author: jrose Date: 2009-09-15 21:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/148e5441d916 6863023: need non-perm oops in code cache for JSR 292 Summary: Make a special root-list for those few nmethods which might contain non-perm oops. Reviewed-by: twisti, kvn, never, jmasa, ysr ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! src/cpu/sparc/vm/c1_LIRAssembler_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/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline2.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/utilities/debug.cpp Changeset: be094e0c089a Author: jrose Date: 2009-09-15 22:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/be094e0c089a Merge Changeset: 3a2aa26bdc58 Author: never Date: 2009-09-16 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3a2aa26bdc58 6854812: 6.0_14-b08 crashes with a SIGSEGV Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/opto/parse1.cpp Changeset: 6a8ccac44f41 Author: kvn Date: 2009-09-18 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6a8ccac44f41 6820514: meet not symmetric failure in ctw Summary: Add missing instance_id meet. Reviewed-by: never ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 54b3b351d6f9 Author: jrose Date: 2009-09-23 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/54b3b351d6f9 Merge ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 753cf9794df9 Author: jrose Date: 2009-09-23 23:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/753cf9794df9 6885169: merge of 4957990 and 6863023 causes conflict on do_nmethods Summary: After mechanically merging changes, some by-hand adjustments are needed. Reviewed-by: ysr ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp Changeset: ddd6f1182ae3 Author: kvn Date: 2009-09-25 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ddd6f1182ae3 6883468: C2 compiler enters infinite loop in PhaseIterGVN::transform Summary: Avoid ideal transformation ping-pong between AddPNode::Ideal() and CastX2PNode::Ideal(). Reviewed-by: cfang ! src/share/vm/opto/connode.cpp Changeset: d6b9fd78f389 Author: cfang Date: 2009-09-28 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d6b9fd78f389 6886353: For DeoptimizeALot, JTreg tests should "IgnoreUnrecognizedVMOptions on a product build Summary: Add IgnoreUnrecognizedVMOptions for JTreg tests (on a product build) to pass with DeoptimizeALot Reviewed-by: kvn ! test/compiler/6823453/Test.java ! test/compiler/6833129/Test.java Changeset: 46b819ba120b Author: jrose Date: 2009-09-30 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/46b819ba120b Merge ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: a0107ba3bc53 Author: johnc Date: 2009-10-01 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a0107ba3bc53 6887186: G1: Incorrect code generated for G1 pre-barrier by C1 on SPARC Summary: Modify operand passed to C1 pre-barrier to be the operand representing the address of the object field that is being stored. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp Changeset: 708275a44e4a Author: tonyp Date: 2009-10-03 10:53 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/708275a44e4a Merge ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp Changeset: a1423fe86a18 Author: trims Date: 2009-10-09 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a1423fe86a18 Merge ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: f4b900403d6e Author: trims Date: 2009-10-09 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f4b900403d6e 6890293: Bump the HS17 build number to 03 Summary: Update the HS17 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 411c9c4ca96a Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/411c9c4ca96a Added tag jdk7-b74 for changeset f4b900403d6e ! .hgtags From tim.bell at sun.com Fri Oct 16 10:42:24 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 16 Oct 2009 17:42:24 +0000 Subject: hg: jdk7/tl/jaxp: 3 new changesets Message-ID: <20091016174229.3E0634192F@hg.openjdk.java.net> Changeset: feb05980f9f2 Author: ohair Date: 2009-09-28 19:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/feb05980f9f2 6886359: Missing jaxws property files and missing changes in jaxp/jaxws drop bundles Reviewed-by: jjg, tbell ! build-defs.xml ! jaxp.properties Changeset: ea7b88c676dd Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/ea7b88c676dd Added tag jdk7-b73 for changeset feb05980f9f2 ! .hgtags Changeset: 555fb78ee4ce Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/555fb78ee4ce Added tag jdk7-b74 for changeset ea7b88c676dd ! .hgtags From tim.bell at sun.com Fri Oct 16 10:42:36 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 16 Oct 2009 17:42:36 +0000 Subject: hg: jdk7/tl/jaxws: 3 new changesets Message-ID: <20091016174240.574D341930@hg.openjdk.java.net> Changeset: 558985e26fe1 Author: ohair Date: 2009-09-28 19:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/558985e26fe1 6886359: Missing jaxws property files and missing changes in jaxp/jaxws drop bundles Reviewed-by: jjg, tbell ! build-defs.xml ! jaxws.properties Changeset: f4466e1b6080 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/f4466e1b6080 Added tag jdk7-b73 for changeset 558985e26fe1 ! .hgtags Changeset: fcf2b8b5d606 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/fcf2b8b5d606 Added tag jdk7-b74 for changeset f4466e1b6080 ! .hgtags From tim.bell at sun.com Fri Oct 16 10:46:18 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 16 Oct 2009 17:46:18 +0000 Subject: hg: jdk7/tl/jdk: 42 new changesets Message-ID: <20091016175515.C9DCC41934@hg.openjdk.java.net> Changeset: 59b45d636384 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59b45d636384 Added tag jdk7-b73 for changeset f708138c9aca ! .hgtags Changeset: 8e5d45fc8d1e Author: jgodinez Date: 2009-07-01 12:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8e5d45fc8d1e 6848799: Reg-test java/awt/print/PageFormat/PageFormatFromAttributes.java fails on Rhel_5 Reviewed-by: tdv, prr ! src/solaris/classes/sun/print/IPPPrintService.java + test/java/awt/print/PageFormat/PageFormatFromAttributes.java Changeset: 837bb8760bad Author: yan Date: 2009-07-13 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/837bb8760bad Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - src/share/classes/sun/swing/AccessibleMethod.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: a0b315ecdc78 Author: rkennke Date: 2009-07-22 15:52 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a0b315ecdc78 6857358: Two testcases are failing in jdk7 b64 pit build with java.security.AccessControlException Summary: Try to load GraphicsEnvironment with bootclassloader first, only then try app classloader. Reviewed-by: prr, tdv, igor ! src/share/classes/java/awt/GraphicsEnvironment.java Changeset: 9fa696ed1f38 Author: jgodinez Date: 2009-07-30 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9fa696ed1f38 Merge Changeset: 7fe0497ee5b5 Author: jgodinez Date: 2009-08-04 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fe0497ee5b5 6829673: ThinLineTest: A line < 1 pixel disappears. Reviewed-by: igor, prr Contributed-by: rkennke ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java + test/sun/pisces/ThinLineTest.java Changeset: 64b0c953635d Author: rkennke Date: 2009-08-07 18:31 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/64b0c953635d 6795908: Refactor FontManager Reviewed-by: prr, igor ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/make.depend ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/font/mapfile-vers ! make/sun/font/mapfile-vers.openjdk ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/font/CMap.java ! src/share/classes/sun/font/CompositeFont.java ! src/share/classes/sun/font/CompositeGlyphMapper.java ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontDesignMetrics.java ! src/share/classes/sun/font/FontFamily.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/FontManagerNativeLibrary.java ! src/share/classes/sun/font/FontResolver.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/classes/sun/font/PhysicalStrike.java ! src/share/classes/sun/font/StandardGlyphVector.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/TrueTypeGlyphMapper.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/font/Type1GlyphMapper.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/PathGraphics.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/font/sunfontids.h ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/font/NativeFont.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/windows/WFontConfiguration.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: 92607d652d7a Author: rkennke Date: 2009-08-07 19:36 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/92607d652d7a 6869705: Missing files of CR6795908, FontManager refactoring Reviewed-by: prr, igor + src/share/classes/sun/font/FontAccess.java + src/share/classes/sun/font/FontManagerFactory.java + src/share/classes/sun/font/FontManagerForSGE.java + src/share/classes/sun/font/FontUtilities.java + src/share/classes/sun/font/SunFontManager.java + src/solaris/classes/sun/awt/X11FontManager.java + src/solaris/classes/sun/font/FontConfigManager.java + src/windows/classes/sun/awt/Win32FontManager.java Changeset: 11b38980893c Author: rkennke Date: 2009-08-12 17:21 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/11b38980893c 6870238: Font2DTest fails on Debian after FontManager refactoring Summary: Use fontManager field instead of querying the FontManagerFactory Reviewed-by: igor, prr ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: a389af17df10 Author: prr Date: 2009-08-14 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a389af17df10 6867603: sun.font.FontManager.getDefaultPlatformFont throws NPE in OpenJDK on Solaris 10 10/08 Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FontConfigManager.java ! src/solaris/native/sun/awt/fontpath.c Changeset: e90f58148115 Author: jgodinez Date: 2009-09-16 19:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e90f58148115 Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java - src/share/classes/com/sun/crypto/provider/JarVerifier.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Component.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/classes/sun/security/pkcs11/JarVerifier.java ! src/share/classes/sun/swing/SwingUtilities2.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h ! src/solaris/classes/sun/awt/X11/XToolkit.java - src/windows/classes/sun/security/mscapi/JarVerifier.java - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 27d58a02bb9d Author: srl Date: 2009-09-28 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/27d58a02bb9d 6795060: VM crash on Linux in ICU layout library when processing \u0DDD (Sinhalese) Reviewed-by: igor, prr ! src/share/native/sun/font/layout/IndicClassTables.cpp + test/java/awt/font/TextLayout/TestSinhalaChar.java Changeset: e6ced7714609 Author: jgodinez Date: 2009-09-29 09:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e6ced7714609 Merge - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java - src/share/native/sun/security/ec/ec.c Changeset: c74d38ef118c Author: srl Date: 2009-09-29 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c74d38ef118c 6501644: sync LayoutEngine *code* structure to match ICU Reviewed-by: prr ! make/sun/font/Makefile ! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp ! src/share/native/sun/font/layout/AlternateSubstSubtables.h ! src/share/native/sun/font/layout/AnchorTables.cpp ! src/share/native/sun/font/layout/AnchorTables.h ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/ArabicShaping.h ! src/share/native/sun/font/layout/AttachmentPosnSubtables.h ! src/share/native/sun/font/layout/CanonData.cpp ! src/share/native/sun/font/layout/CanonShaping.cpp ! src/share/native/sun/font/layout/CanonShaping.h ! src/share/native/sun/font/layout/CharSubstitutionFilter.h ! src/share/native/sun/font/layout/ClassDefinitionTables.cpp ! src/share/native/sun/font/layout/ClassDefinitionTables.h ! src/share/native/sun/font/layout/ContextualGlyphInsertion.h ! src/share/native/sun/font/layout/ContextualGlyphSubstProc.cpp ! src/share/native/sun/font/layout/ContextualGlyphSubstProc.h ! src/share/native/sun/font/layout/ContextualGlyphSubstitution.h ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CoverageTables.h ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.h ! src/share/native/sun/font/layout/DefaultCharMapper.h ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/DeviceTables.h ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/Features.cpp ! src/share/native/sun/font/layout/Features.h ! src/share/native/sun/font/layout/GDEFMarkFilter.cpp ! src/share/native/sun/font/layout/GDEFMarkFilter.h ! src/share/native/sun/font/layout/GXLayoutEngine.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.h ! src/share/native/sun/font/layout/GlyphDefinitionTables.cpp ! src/share/native/sun/font/layout/GlyphDefinitionTables.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphLookupTables.cpp ! src/share/native/sun/font/layout/GlyphLookupTables.h ! src/share/native/sun/font/layout/GlyphPositionAdjustments.cpp ! src/share/native/sun/font/layout/GlyphPositionAdjustments.h ! src/share/native/sun/font/layout/GlyphPositioningTables.cpp ! src/share/native/sun/font/layout/GlyphPositioningTables.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphPosnLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp ! src/share/native/sun/font/layout/GlyphSubstitutionTables.h ! src/share/native/sun/font/layout/HanLayoutEngine.cpp ! src/share/native/sun/font/layout/HanLayoutEngine.h ! src/share/native/sun/font/layout/IndicClassTables.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.h ! src/share/native/sun/font/layout/IndicRearrangement.h ! src/share/native/sun/font/layout/IndicRearrangementProcessor.cpp ! src/share/native/sun/font/layout/IndicRearrangementProcessor.h ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/KernTable.h ! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.h ! src/share/native/sun/font/layout/KhmerReordering.cpp ! src/share/native/sun/font/layout/KhmerReordering.h ! src/share/native/sun/font/layout/LEFontInstance.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphFilter.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEInsertionList.cpp ! src/share/native/sun/font/layout/LEInsertionList.h ! src/share/native/sun/font/layout/LELanguages.h ! src/share/native/sun/font/layout/LEScripts.h + src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LESwaps.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LayoutTables.h ! src/share/native/sun/font/layout/LigatureSubstProc.cpp ! src/share/native/sun/font/layout/LigatureSubstProc.h ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LigatureSubstSubtables.h ! src/share/native/sun/font/layout/LigatureSubstitution.h ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/LookupProcessor.h ! src/share/native/sun/font/layout/LookupTables.cpp ! src/share/native/sun/font/layout/LookupTables.h ! src/share/native/sun/font/layout/Lookups.cpp ! src/share/native/sun/font/layout/Lookups.h ! src/share/native/sun/font/layout/MPreFixups.cpp ! src/share/native/sun/font/layout/MPreFixups.h ! src/share/native/sun/font/layout/MarkArrays.cpp ! src/share/native/sun/font/layout/MarkArrays.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.h ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.h ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.h ! src/share/native/sun/font/layout/MirroredCharData.cpp ! src/share/native/sun/font/layout/MorphStateTables.h ! src/share/native/sun/font/layout/MorphTables.cpp ! src/share/native/sun/font/layout/MorphTables.h ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.h ! src/share/native/sun/font/layout/NonContextualGlyphSubst.h ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.cpp ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.h ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/OpenTypeTables.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp ! src/share/native/sun/font/layout/OpenTypeUtilities.h ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.h ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguage.h ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp ! src/share/native/sun/font/layout/SegmentArrayProcessor.h ! src/share/native/sun/font/layout/SegmentSingleProcessor.cpp ! src/share/native/sun/font/layout/SegmentSingleProcessor.h ! src/share/native/sun/font/layout/ShapingTypeData.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.h ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.h ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.h ! src/share/native/sun/font/layout/SingleTableProcessor.cpp ! src/share/native/sun/font/layout/SingleTableProcessor.h ! src/share/native/sun/font/layout/StateTableProcessor.cpp ! src/share/native/sun/font/layout/StateTableProcessor.h ! src/share/native/sun/font/layout/StateTables.h ! src/share/native/sun/font/layout/SubstitutionLookups.cpp ! src/share/native/sun/font/layout/SubstitutionLookups.h ! src/share/native/sun/font/layout/SubtableProcessor.cpp ! src/share/native/sun/font/layout/SubtableProcessor.h ! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp ! src/share/native/sun/font/layout/ThaiLayoutEngine.h ! src/share/native/sun/font/layout/ThaiShaping.cpp ! src/share/native/sun/font/layout/ThaiShaping.h ! src/share/native/sun/font/layout/ThaiStateTables.cpp ! src/share/native/sun/font/layout/TrimmedArrayProcessor.cpp ! src/share/native/sun/font/layout/TrimmedArrayProcessor.h ! src/share/native/sun/font/layout/ValueRecords.cpp ! src/share/native/sun/font/layout/ValueRecords.h Changeset: e8a764450aa7 Author: srl Date: 2009-09-29 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8a764450aa7 Merge - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java - src/share/native/sun/security/ec/ec.c Changeset: e8b1b4c00e8a Author: srl Date: 2009-09-29 16:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8b1b4c00e8a 6886718: missing license info Reviewed-by: igor, prr ! test/java/awt/font/TextLayout/TestSinhalaChar.java Changeset: ec67b240b727 Author: mchung Date: 2009-09-29 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ec67b240b727 6879044: Eliminate the dependency on logging from the AWT/2D/Swing classes Summary: Replace calls to Logger with sun.util.logging.PlatformLogger Reviewed-by: prr, art, alexp, dcherepanov, igor, dav, anthony ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AttributeValue.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/ComponentAccessor.java ! src/share/classes/sun/awt/DebugSettings.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/ScrollPaneWheelScroller.java ! src/share/classes/sun/awt/SunDisplayChanger.java ! src/share/classes/sun/awt/SunGraphicsCallback.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/WindowAccessor.java ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11/InfoWindow.java ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/UnsafeXDisposerRecord.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XCheckboxMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XContentWindow.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFocusProxyWindow.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java ! src/solaris/classes/sun/awt/X11/XInputMethod.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XMSelection.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XMenuPeer.java ! src/solaris/classes/sun/awt/X11/XMenuWindow.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XQueryTree.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java ! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XWINProtocol.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XWrapperBase.java ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/classes/sun/awt/X11FontManager.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11InputMethod.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/font/FontConfigManager.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/classes/sun/awt/windows/WPanelPeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 5b52851b0927 Author: mchung Date: 2009-09-29 22:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5b52851b0927 Merge Changeset: 633806cdab51 Author: jgodinez Date: 2009-10-05 18:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/633806cdab51 Merge Changeset: 405fd587f13f Author: tbell Date: 2009-10-07 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/405fd587f13f Merge ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java Changeset: 317ac0bf2285 Author: anthony Date: 2009-09-15 16:15 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/317ac0bf2285 6868255: Requirements for correct operating of the HW/LW Mixing feature need to be specified Summary: The specification is updated Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java Changeset: 986ec552383f Author: yan Date: 2009-09-22 01:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/986ec552383f Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: b6980b0d8440 Author: dcherepanov Date: 2009-09-30 13:21 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b6980b0d8440 6853592: VM test nsk.regression.b4261880 fails with "X Error of failed request: BadWindow" inconsistently. Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: a21d00087df9 Author: dcherepanov Date: 2009-09-30 15:48 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a21d00087df9 6878284: Sometimes test/javax/swing/system/6799345/TestShutdown.java "hangs" Reviewed-by: art, ant ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/AWTAutoShutdown.java Changeset: cf3f9c09ba1d Author: anthony Date: 2009-10-01 14:48 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cf3f9c09ba1d 6886868: giflib has a memory leak in the MakeMapObject() function Summary: free() the object before returning NULL Reviewed-by: art, dcherepanov ! src/share/native/sun/awt/giflib/gifalloc.c Changeset: 80db944866a9 Author: anthony Date: 2009-10-01 15:06 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/80db944866a9 6862611: Reg testcase closed/java/awt/Component/NativeInLightShow/NativeInLightShow.html fails Summary: The recursiveShowHeavyweightChildren() must be invoked unconditionally in mixOnShowing() Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Container.java Changeset: 4358934555bc Author: yan Date: 2009-10-06 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4358934555bc Merge ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 6216604c05e2 Author: alexp Date: 2009-09-09 17:32 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6216604c05e2 6878792: Sample provided in javax.swing.JLayer class description is not usable Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java Changeset: afd85f72784b Author: peterz Date: 2009-09-10 12:30 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/afd85f72784b 6827786: Mnemonic cycling for multiple equal mnemonic armed menu items stops when encountering a submenu Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java Changeset: 51ccbb892a1f Author: alexp Date: 2009-09-15 16:26 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/51ccbb892a1f 6875716: JLayer.remove((Component)null) should behave consistently in (not) throwing NPE Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6875716/bug6875716.java Changeset: a64dbe61a984 Author: gsm Date: 2009-09-16 16:15 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a64dbe61a984 4337267: Arabic Numeral Shaping Reviewed-by: peterz ! src/share/classes/javax/swing/text/TextLayoutStrategy.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JComponent/4337267/bug4337267.java Changeset: 481c01572c62 Author: alexp Date: 2009-09-17 19:08 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/481c01572c62 4833524: BasicTreeUI.isToggleSelectionEvent() does not properly handle popup triggers Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/text/DefaultCaret.java Changeset: 1c7abc800502 Author: rupashka Date: 2009-09-18 15:11 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1c7abc800502 6840086: JFileChooser lacks icons on top right when running on Windows 7 Reviewed-by: peterz, uta ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/native/sun/windows/ShellFolder2.cpp + test/javax/swing/JFileChooser/6840086/bug6840086.java Changeset: fa71ca7a3655 Author: yan Date: 2009-09-21 01:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa71ca7a3655 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 9d78c3d9def2 Author: alexp Date: 2009-09-21 17:58 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d78c3d9def2 6883341: SWAT: jdk7-b72 swat build(2009-09-17) threw exceptions when running Java2D demo by clicking Paint ta Reviewed-by: peterz ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JMenuItem/6883341/bug6883341.java Changeset: 6115613a3386 Author: peterz Date: 2009-09-23 21:14 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6115613a3386 6857888: closed/javax/swing/JMenuItem/6458123/bug6458123.java fails with InvocationTargetException. Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/nimbus/skin.laf ! src/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java Changeset: d5045dd60c29 Author: rupashka Date: 2009-10-06 17:01 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d5045dd60c29 6489130: FileChooserDemo hung by keeping pressing Enter key Reviewed-by: alexp ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/6489130/bug6489130.java Changeset: dca0ab1a1ac3 Author: yan Date: 2009-10-06 23:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dca0ab1a1ac3 Merge ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 77f213891ce3 Author: lana Date: 2009-10-13 15:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/77f213891ce3 Merge Changeset: eacb36e30327 Author: vinnie Date: 2009-10-14 23:41 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eacb36e30327 6891632: Remove duplicate ECC source files Reviewed-by: wetmore - src/share/native/sun/security/ec/ec.h - src/share/native/sun/security/ec/ec2.h - src/share/native/sun/security/ec/ec2_163.c - src/share/native/sun/security/ec/ec2_193.c - src/share/native/sun/security/ec/ec2_233.c - src/share/native/sun/security/ec/ec2_aff.c - src/share/native/sun/security/ec/ec2_mont.c - src/share/native/sun/security/ec/ec_naf.c - src/share/native/sun/security/ec/ecc_impl.h - src/share/native/sun/security/ec/ecdecode.c - src/share/native/sun/security/ec/ecl-curve.h - src/share/native/sun/security/ec/ecl-exp.h - src/share/native/sun/security/ec/ecl-priv.h - src/share/native/sun/security/ec/ecl.c - src/share/native/sun/security/ec/ecl.h - src/share/native/sun/security/ec/ecl_curve.c - src/share/native/sun/security/ec/ecl_gf.c - src/share/native/sun/security/ec/ecl_mult.c - src/share/native/sun/security/ec/ecp.h - src/share/native/sun/security/ec/ecp_192.c - src/share/native/sun/security/ec/ecp_224.c - src/share/native/sun/security/ec/ecp_256.c - src/share/native/sun/security/ec/ecp_384.c - src/share/native/sun/security/ec/ecp_521.c - src/share/native/sun/security/ec/ecp_aff.c - src/share/native/sun/security/ec/ecp_jac.c - src/share/native/sun/security/ec/ecp_jm.c - src/share/native/sun/security/ec/ecp_mont.c - src/share/native/sun/security/ec/logtab.h - src/share/native/sun/security/ec/mp_gf2m-priv.h - src/share/native/sun/security/ec/mp_gf2m.c - src/share/native/sun/security/ec/mp_gf2m.h - src/share/native/sun/security/ec/mpi-config.h - src/share/native/sun/security/ec/mpi-priv.h - src/share/native/sun/security/ec/mpi.c - src/share/native/sun/security/ec/mpi.h - src/share/native/sun/security/ec/mplogic.c - src/share/native/sun/security/ec/mplogic.h - src/share/native/sun/security/ec/mpmontg.c - src/share/native/sun/security/ec/mpprime.h - src/share/native/sun/security/ec/oid.c - src/share/native/sun/security/ec/secitem.c - src/share/native/sun/security/ec/secoidt.h Changeset: 99dfeece98e2 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/99dfeece98e2 Added tag jdk7-b74 for changeset eacb36e30327 ! .hgtags Changeset: 368bb282464a Author: tbell Date: 2009-10-15 22:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/368bb282464a Merge - src/share/classes/sun/security/provider/certpath/LDAPCertStore.java From tim.bell at sun.com Fri Oct 16 11:00:39 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 16 Oct 2009 18:00:39 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20091016180046.D16FD41936@hg.openjdk.java.net> Changeset: d498d6ef9c6c Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d498d6ef9c6c Added tag jdk7-b73 for changeset 9596dff46093 ! .hgtags Changeset: 1a66b08deed0 Author: tbell Date: 2009-10-07 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1a66b08deed0 Merge - src/share/classes/com/sun/tools/javac/file/Old199.java - src/share/classes/com/sun/tools/javah/MainDoclet.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties Changeset: 79c13af9217e Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/79c13af9217e Added tag jdk7-b74 for changeset 1a66b08deed0 ! .hgtags Changeset: d1e62f78c48b Author: tbell Date: 2009-10-15 22:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d1e62f78c48b Merge From jonathan.gibbons at sun.com Fri Oct 16 12:57:56 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 16 Oct 2009 19:57:56 +0000 Subject: hg: jdk7/tl/langtools: 6888367: classfile library parses signature attributes incorrectly Message-ID: <20091016195758.9DEF341956@hg.openjdk.java.net> Changeset: 6ba399eff2cb Author: jjg Date: 2009-10-16 12:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6ba399eff2cb 6888367: classfile library parses signature attributes incorrectly Reviewed-by: ksrini ! src/share/classes/com/sun/tools/classfile/Signature.java ! src/share/classes/com/sun/tools/classfile/Type.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/LocalVariableTypeTableWriter.java + test/tools/javap/classfile/6888367/T6888367.java From pbenedict at apache.org Fri Oct 16 13:25:30 2009 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 16 Oct 2009 15:25:30 -0500 Subject: JDK7 b74: Where is j.u.Objects? Message-ID: I saw in the release notes the tickets regarding j.u.Objects, but I don't see the class in the javadoc: http://download.java.net/jdk7/docs/api/java/util/package-summary.html Thoughts? Paul From Joe.Darcy at Sun.COM Fri Oct 16 14:14:55 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 16 Oct 2009 14:14:55 -0700 Subject: JDK7 b74: Where is j.u.Objects? In-Reply-To: References: Message-ID: <4AD8E24F.5030505@sun.com> Paul Benedict wrote: > I saw in the release notes the tickets regarding j.u.Objects, but I > don't see the class in the javadoc: > http://download.java.net/jdk7/docs/api/java/util/package-summary.html > > Thoughts? > > Paul > I believe there was a problem in either generating or posting the b74 docs and the currently posted docs are from b73. -Joe From pbenedict at apache.org Fri Oct 16 14:19:56 2009 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 16 Oct 2009 16:19:56 -0500 Subject: JDK7 b74: Where is j.u.Objects? In-Reply-To: <4AD8E24F.5030505@sun.com> References: <4AD8E24F.5030505@sun.com> Message-ID: All the labels and titles on the API doc say its b74, so it must be some generation problem. On Fri, Oct 16, 2009 at 4:14 PM, Joseph D. Darcy wrote: > Paul Benedict wrote: >> >> I saw in the release notes the tickets regarding j.u.Objects, but I >> don't see the class in the javadoc: >> http://download.java.net/jdk7/docs/api/java/util/package-summary.html >> >> Thoughts? >> >> Paul >> > > I believe there was a problem in either generating or posting the b74 docs > and the currently posted docs are from b73. > > -Joe > From Joe.Darcy at Sun.COM Fri Oct 16 14:28:10 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 16 Oct 2009 14:28:10 -0700 Subject: JDK7 b74: Where is j.u.Objects? In-Reply-To: References: <4AD8E24F.5030505@sun.com> Message-ID: <4AD8E56A.709@sun.com> Upon further inspection, j.u.Objects is in the TL staging repository but has not yet hit the master. j.u.Objects will be included in the next build TL integrates into. -Joe Paul Benedict wrote: > All the labels and titles on the API doc say its b74, so it must be > some generation problem. > > On Fri, Oct 16, 2009 at 4:14 PM, Joseph D. Darcy wrote: > >> Paul Benedict wrote: >> >>> I saw in the release notes the tickets regarding j.u.Objects, but I >>> don't see the class in the javadoc: >>> http://download.java.net/jdk7/docs/api/java/util/package-summary.html >>> >>> Thoughts? >>> >>> Paul >>> >>> >> I believe there was a problem in either generating or posting the b74 docs >> and the currently posted docs are from b73. >> >> -Joe >> >> From Tim.Bell at Sun.COM Fri Oct 16 14:58:54 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 16 Oct 2009 14:58:54 -0700 Subject: JDK7 b74: Where is j.u.Objects? In-Reply-To: <4AD8E56A.709@sun.com> References: <4AD8E24F.5030505@sun.com> <4AD8E56A.709@sun.com> Message-ID: <4AD8EC9E.5070101@sun.com> Joseph D. Darcy wrote: > Upon further inspection, j.u.Objects is in the TL staging repository but > has not yet hit the master. j.u.Objects will be included in the next > build TL integrates into. If you want these changes today, you could 'hg fclone'[1] them from the TL forest: http://hg.openjdk.java.net/jdk7/tl and build your own copy. If all goes as planned (standard disclaimer applies when making forward-looking statements :-) TL will integrate into the master for b75 on October 23. b75 should be promoted on October 29. If you want the very latest thing during the interval between October 23 ... 29, you could look at the nightly builds of the JDK7 master, available here: http://download.java.net/jdk7/nightly/ That nightly download does not include the javadocs, unfortunately. You would need to build them from source yourself. HTH - Tim Bell [gatekeeper for the TL (tools and libraries) forest] [1] http://openjdk.java.net/guide/repositories.html#clone From pbenedict at apache.org Sat Oct 17 22:06:53 2009 From: pbenedict at apache.org (Paul Benedict) Date: Sun, 18 Oct 2009 00:06:53 -0500 Subject: JDK7 b74: Where is j.u.Objects? In-Reply-To: <4AD8E56A.709@sun.com> References: <4AD8E24F.5030505@sun.com> <4AD8E56A.709@sun.com> Message-ID: Since the Javadocs are being updated without everything integrated into master, wouldn't this indicate a process problem? On Fri, Oct 16, 2009 at 4:28 PM, Joseph D. Darcy wrote: > Upon further inspection, j.u.Objects is in the TL staging repository but has > not yet hit the master. ?j.u.Objects will be included in the next build TL > integrates into. > > -Joe > > Paul Benedict wrote: >> >> All the labels and titles on the API doc say its b74, so it must be >> some generation problem. >> >> On Fri, Oct 16, 2009 at 4:14 PM, Joseph D. Darcy >> wrote: >> >>> >>> Paul Benedict wrote: >>> >>>> >>>> I saw in the release notes the tickets regarding j.u.Objects, but I >>>> don't see the class in the javadoc: >>>> http://download.java.net/jdk7/docs/api/java/util/package-summary.html >>>> >>>> Thoughts? >>>> >>>> Paul >>>> >>>> >>> >>> I believe there was a problem in either generating or posting the b74 >>> docs >>> and the currently posted docs are from b73. >>> >>> -Joe >>> >>> > > From Alan.Bateman at Sun.COM Sun Oct 18 00:44:28 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 18 Oct 2009 08:44:28 +0100 Subject: JDK7 b74: Where is j.u.Objects? In-Reply-To: References: <4AD8E24F.5030505@sun.com> <4AD8E56A.709@sun.com> Message-ID: <4ADAC75C.10307@sun.com> Paul Benedict wrote: > Since the Javadocs are being updated without everything integrated > into master, wouldn't this indicate a process problem? > As Tim said, all going well, TL is due to integrate on Oct 23 for b75. That build is due to be promoted on Oct 29 so that's when the b75 javadoc and builds should come out. In the mean-time you can use your own build (or the other alternative, as Tim also suggested, is to use the nightly builds in the days leading up to the promotion). -Alan From iaroslavski at mail.ru Mon Oct 19 06:18:16 2009 From: iaroslavski at mail.ru (Vladimir Iaroslavski) Date: Mon, 19 Oct 2009 17:18:16 +0400 Subject: Replacement of Quicksort in java.util.Arrays with new Dual-Pivot Quicksort In-Reply-To: References: Message-ID: <4ADC6718.7000603@mail.ru> > Date: Tue, 6 Oct 2009 23:11:25 +0000 (UTC) > From: quitos > Subject: Re: Replacement of Quicksort in java.util.Arrays with new Dual-Pivot Quicksort > To: core-libs-dev at openjdk.java.net > > I suppose if the array is small enough, it is better to use simple Quicksort. > And the larger the array, the more sense it makes to use more pivots, because > the calculation cost of comparing against many pivots becomes more affordable > than iterating for a larger subset. > So you think the optimal number of pivots to use could be directly linked to the > size of the array you're trying to sort? I've tried several cases with different numbers of pivots on different length, and experiments show that 2 pivots from 5 candidates is optimal. Note that if you have many pivots (> 3) the loop of sorting becomes more complex and slower. For small arrays the best choice is Insertion sort which is simpler and faster than any quicksort. Vladimir From iaroslavski at mail.ru Mon Oct 19 07:05:29 2009 From: iaroslavski at mail.ru (Vladimir Iaroslavski) Date: Mon, 19 Oct 2009 18:05:29 +0400 Subject: Final version of Dual-Pivot Quicksort for replacement quicksort in java.util.Arrays Message-ID: <4ADC7229.1070103@mail.ru> Hello, I'd like to provide you the final version of Dual-Pivot Quicksort for replacement of Quicksort in java.util.Arrays. Here is the webrev of changes: http://cr.openjdk.java.net/~alanb/6880672/webrev.02 also you can see classes in attachment. The following modifications have been done to improve the code (thank you very much to Josh, Jon and other for your ideas and suggestions): 1. Implementation of Dual-Pivot Quicksort has been moved to separate class DualPivotQuicksort.java, it makes Arrays.java more readable and easy to maintain. If in the future somebody suggests new very fast Quicksort, the replacement "DualPivotQuicksort.sort(...)" with "NewVeryFastQuicksort.sort(...)" should be done only in class Arrays.java. 2. Improved and added javadoc. 3. Method swap(a, i, j) has been eliminated. All sort loops had the structure: for (int k = ...; ...) { int ak = a[k]; if (ak < ...) swap(a, k, ..) This standard method "swap" swaps the values of two elements using 3 assignments, but we already have value of a[k] stored in temporary local variable ak, so we can do it via 2 assignments only: a[k] = a[...]; a[...] = ak; 4. Standard implementation of Insertion sort (with swaps inside inner loop) has been replaced by faster one: for (int k = left + 1; k <= right; k++) { int ak = a[k]; int j; for (j = k - 1; j >= left && ak < a[j]; j--) { a[j + 1] = a[j]; } a[j + 1] = ak; } 5. Insertion sort threshold has been changed to 32. 6. Five candidates, evenly spaced elements, are used for choosing 2 pivots (in previous version only 2 evenly spaced elements are used). 7. These five elements are sorted by sorting network 8. Main sorting loop was separated into two: when pivots are equal and not. 9. Swap of conditions in inner while loop: a[great] > pivot2 && k < great (was k < great && a[great] > pivot2). 10. Changes in code after main sorting loop: if pivots are equals, no need to handle and sort central part: if (!pivotsDiffer) { return; } 11. Condition of handling central part (looking of elements, equal to pivots, and swap them to ends) has been simplified: if (less < e1 && e5 < great) ... instead of if (dist > len - 13 && pivot1 != pivot2) 12. Loop of handling central part has been corrected and updated. 13. Parameter "dist" has been eliminated. Also I'd like to show you how the new version works faster. I run two versions against current jdk's implementation on jdk 1.7.0-ea-b66, Windows XP. The test framework is Bentley's tests which were used for testing Quicksort. I run for arrays with length = 1'000'000 and calculated arithmetics and geometric means: Client VM Server VM old version: arithm = 81.78%, geom = 76.15% arithm = 91.97%, geom = 72.58% new versi