From forax at univ-mlv.fr  Fri Jul  1 07:16:07 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 01 Jul 2011 09:16:07 +0200
Subject: Return type of Object.getClass()
In-Reply-To: <BANLkTinW1UB8d+0yzxhhV0owm42XOVovVg@mail.gmail.com>
References: <BANLkTinW1UB8d+0yzxhhV0owm42XOVovVg@mail.gmail.com>
Message-ID: <4E0D7437.4010707@univ-mlv.fr>

  Le 30/06/2011 23:16, Zhong Yu a ?crit :
> Why does it return Class<? extends |X|>  instead of Class<? extends X>? Quote:
>
> The actual result type is Class<? extends |X|>  where |X| is the
> erasure of the static type of the expression on which getClass is
> called.
>
> This means the following code does not compile
>      T obj = ...;
>      Class<T>  clazz = obj.getClass();
>
> What's the reason for erasure here? Thanks.
>
> Zhong Yu

StackOverflow is better for this kind of question:
http://stackoverflow.com/questions/4703557/a-strange-error-in-java-generic

R?mi



From Ulf.Zibis at gmx.de  Fri Jul  1 09:09:49 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 01 Jul 2011 11:09:49 +0200
Subject: Return type of Object.getClass()
In-Reply-To: <BANLkTinW1UB8d+0yzxhhV0owm42XOVovVg@mail.gmail.com>
References: <BANLkTinW1UB8d+0yzxhhV0owm42XOVovVg@mail.gmail.com>
Message-ID: <4E0D8EDD.4090002@gmx.de>

Am 30.06.2011 23:16, schrieb Zhong Yu:
> Why does it return Class<? extends |X|>  instead of Class<? extends X>? Quote:
>
> The actual result type is Class<? extends |X|>  where |X| is the
> erasure of the static type of the expression on which getClass is
> called.
>
> This means the following code does not compile
>      T obj = ...;
>      Class<T>  clazz = obj.getClass();
>
> What's the reason for erasure here? Thanks.
>
> Zhong Yu

Maybe this bug is additionally related:
Bug ID: 6850338 State generification of Class.forName() more precisely 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850338>

-Ulf



From roger.riggs at oracle.com  Fri Jul  1 19:00:39 2011
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Fri, 1 Jul 2011 12:00:39 -0700 (PDT)
Subject: Auto Reply: core-libs-dev Digest, Vol 51, Issue 1
Message-ID: <63f7a391-30cc-431b-92d2-4eca6eef95ab@default>

Roger will get back to you after the July 4th holiday.


From kumar.x.srinivasan at oracle.com  Fri Jul  1 20:49:48 2011
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Fri, 01 Jul 2011 20:49:48 +0000
Subject: hg: jdk8/tl/langtools: 6735320: StringIndexOutOfBoundsException for
	empty @serialField tag
Message-ID: <20110701204950.A4AB5470F8@hg.openjdk.java.net>

Changeset: 409b104f8b86
Author:    ksrini
Date:      2011-07-01 13:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/409b104f8b86

6735320: StringIndexOutOfBoundsException for empty @serialField tag
Reviewed-by: jjg, bpatel

! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java
+ test/com/sun/javadoc/T6735320/SerialFieldTest.java
+ test/com/sun/javadoc/T6735320/T6735320.java
! test/com/sun/javadoc/lib/JavadocTester.java



From jonathan.gibbons at oracle.com  Fri Jul  1 21:07:08 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 01 Jul 2011 21:07:08 +0000
Subject: hg: jdk8/tl: 7061195: Clean up makefiles for JDK 8
Message-ID: <20110701210709.063EE470FA@hg.openjdk.java.net>

Changeset: 0b615980879e
Author:    jjg
Date:      2011-06-30 16:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/0b615980879e

7061195: Clean up makefiles for JDK 8
Reviewed-by: ohair, jjg
Contributed-by: alexandre.boulgakov at oracle.com

! make/sanity-rules.gmk



From jonathan.gibbons at oracle.com  Fri Jul  1 21:07:24 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 01 Jul 2011 21:07:24 +0000
Subject: hg: jdk8/tl/jdk: 3 new changesets
Message-ID: <20110701210801.3BC1F470FB@hg.openjdk.java.net>

Changeset: e4c936c28960
Author:    jjg
Date:      2011-06-30 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4c936c28960

7061190: Update boot JDK version for JDK 8
Reviewed-by: ohair, jjg
Contributed-by: alexandre.boulgakov at oracle.com

! make/common/shared/Defs-versions.gmk

Changeset: cf4edfcd7119
Author:    jjg
Date:      2011-06-30 16:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119

7061195: Clean up makefiles for JDK 8
Reviewed-by: ohair, jjg
Contributed-by: alexandre.boulgakov at oracle.com

! make/common/shared/Defs-java.gmk

Changeset: 74328e59a4bf
Author:    jjg
Date:      2011-06-30 17:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74328e59a4bf

7058708: Eliminate JDK build tools build warnings
Reviewed-by: ohair, jjg
Contributed-by: alexandre.boulgakov at oracle.com

! make/tools/Makefile
! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java
! make/tools/src/build/tools/compileproperties/CompileProperties.java
! make/tools/src/build/tools/dirdiff/DirDiff.java
! make/tools/src/build/tools/dtdbuilder/DTDBuilder.java
! make/tools/src/build/tools/dtdbuilder/DTDInputStream.java
! make/tools/src/build/tools/dtdbuilder/DTDParser.java
! make/tools/src/build/tools/dtdbuilder/PublicMapping.java
! make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
! make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
! make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
! make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
! make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
! make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
! make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java
! make/tools/src/build/tools/generatecharacter/UnicodeSpec.java
! make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java
! make/tools/src/build/tools/hasher/Hasher.java
! make/tools/src/build/tools/jarsplit/JarSplit.java
! make/tools/src/build/tools/javazic/Gen.java
! make/tools/src/build/tools/javazic/GenDoc.java
! make/tools/src/build/tools/javazic/Main.java
! make/tools/src/build/tools/javazic/Mappings.java
! make/tools/src/build/tools/javazic/Simple.java
! make/tools/src/build/tools/javazic/Time.java
! make/tools/src/build/tools/javazic/Zoneinfo.java
! make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java
! make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java
! make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java
! make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java
! make/tools/src/build/tools/jdwpgen/AltNode.java
! make/tools/src/build/tools/jdwpgen/CommandSetNode.java
! make/tools/src/build/tools/jdwpgen/ConstantSetNode.java
! make/tools/src/build/tools/jdwpgen/ErrorSetNode.java
! make/tools/src/build/tools/jdwpgen/Node.java
! make/tools/src/build/tools/jdwpgen/OutNode.java
! make/tools/src/build/tools/jdwpgen/RootNode.java
! make/tools/src/build/tools/jdwpgen/SelectNode.java
! make/tools/src/build/tools/makeclasslist/MakeClasslist.java
! make/tools/src/build/tools/stripproperties/StripProperties.java



From kumar.x.srinivasan at oracle.com  Fri Jul  1 21:28:56 2011
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Fri, 01 Jul 2011 21:28:56 +0000
Subject: hg: jdk8/tl/langtools: 7060642: (javadoc) improve performance on
	accessing inlinedTags
Message-ID: <20110701212858.44F0147107@hg.openjdk.java.net>

Changeset: 0d8edba73d70
Author:    ksrini
Date:      2011-07-01 14:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d8edba73d70

7060642: (javadoc) improve performance on accessing inlinedTags
Reviewed-by: jjg, bpatel

! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java
! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java



From valerie.peng at oracle.com  Sat Jul  2 00:16:45 2011
From: valerie.peng at oracle.com (valerie.peng at oracle.com)
Date: Sat, 02 Jul 2011 00:16:45 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20110702001704.9357B4710F@hg.openjdk.java.net>

Changeset: e93679cf1e1a
Author:    valeriep
Date:      2011-06-30 18:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e93679cf1e1a

7058133: Javah should use the freshly built classes instead of those from the BOOTDIR jdk
Summary: Changed javah to use the newly built classes specified by $(CLASSDESTDIR)
Reviewed-by: vinnie

! make/sun/security/ec/Makefile
! make/sun/security/mscapi/Makefile

Changeset: f0ec49c21d09
Author:    valeriep
Date:      2011-07-01 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0ec49c21d09

Merge




From lvjing at linux.vnet.ibm.com  Tue Jul  5 09:14:26 2011
From: lvjing at linux.vnet.ibm.com (Jing LV)
Date: Tue, 05 Jul 2011 17:14:26 +0800
Subject: A method with return type size_t returns negative value
In-Reply-To: <4DC24218.6070009@linux.vnet.ibm.com>
References: <4D89BB76.5060900@linux.vnet.ibm.com>
	<4D89CA29.7040302@oracle.com>	<4D8AF3C4.7020005@linux.vnet.ibm.com>
	<4D8B3A6B.8040005@oracle.com>	<4DB68125.7080003@linux.vnet.ibm.com>
	<4DB685AF.9070602@oracle.com> <4DC24218.6070009@linux.vnet.ibm.com>
Message-ID: <4E12D5F2.4010409@linux.vnet.ibm.com>

Hello,

     It's been quite a long time and it seems jdk7 is doing well now. I 
know there is still several days before its release, anyway, Alan or 
someone else, would you please tell me if we can start work on jdk8, and 
restart the discussion on the bugs like this (I remember there are still 
some to be discussed)? Thanks!


? 2011-5-5 14:22, Jing LV ??:
> ? 2011-4-26 16:43, Alan Bateman ??:
>> Jing LV wrote:
>>> Hello,
>>>
>>>      Thanks for raising the defect. I see there is no patch now, so 
>>> I create one (as the defect mentioned jint may be good, I use jint 
>>> here).
>>>      I have no Sun Online Account Id, would someone take a look?
>> The function prototypes would also require to be updated and there 
>> are a couple of other areas that would require clean-up too. If it's 
>> okay with you, I think we should postpone this to jdk8. This code has 
>> been using size_t for many years and I don't think is actually 
>> causing a real problem. I agree it should be cleaned up but we are 
>> out of time in jdk7. Another point is that jdk8 will be our 
>> opportunity to remove the dependencies on the JVM_* functions and so 
>> this code will be changing anyway (I realize we're not using these in 
>> the Windows code but the functions need to match as they are used 
>> from shared code).
>>
>> -Alan.
> Hi Alan,
>
>      I am OK with Java8. And I am wondering if a portlib or something 
> may help. I'd think deeper and provide some proposal.
>


-- 
Best Regards,
Jimmy, Jing LV




From sean.coffey at oracle.com  Tue Jul  5 14:27:02 2011
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Tue, 05 Jul 2011 14:27:02 +0000
Subject: hg: jdk8/tl/jdk: 7041125: LDAP API does not catch malformed filters
	that contain two operands for the ! operator
Message-ID: <20110705142726.3BB92471CB@hg.openjdk.java.net>

Changeset: e88093d75e36
Author:    coffeys
Date:      2011-07-05 15:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e88093d75e36

7041125: LDAP API does not catch malformed filters that contain two operands for the ! operator
Reviewed-by: weijun, xuelei

! src/share/classes/com/sun/jndi/ldap/Filter.java
! test/com/sun/jndi/ldap/InvalidLdapFilters.java



From joe.darcy at oracle.com  Tue Jul  5 23:38:48 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 05 Jul 2011 23:38:48 +0000
Subject: hg: jdk8/tl/langtools: 7025809: Provided new utility visitors
	supporting SourceVersion.RELEASE_8
Message-ID: <20110705233850.38127471E1@hg.openjdk.java.net>

Changeset: 111bbf1ad913
Author:    darcy
Date:      2011-07-05 16:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/111bbf1ad913

7025809: Provided new utility visitors supporting SourceVersion.RELEASE_8
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java
! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java
! src/share/classes/com/sun/tools/javah/JavahTask.java
! src/share/classes/com/sun/tools/javah/LLNI.java
! src/share/classes/com/sun/tools/javah/TypeSignature.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java
+ src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java
! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java
! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java
+ src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java
+ src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java
+ src/share/classes/javax/lang/model/util/ElementKindVisitor8.java
! src/share/classes/javax/lang/model/util/ElementScanner6.java
! src/share/classes/javax/lang/model/util/ElementScanner7.java
+ src/share/classes/javax/lang/model/util/ElementScanner8.java
! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java
! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java
+ src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java
! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java
! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java
+ src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java
! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java
! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java
+ src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java
! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java
! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java
+ src/share/classes/javax/lang/model/util/TypeKindVisitor8.java
! src/share/sample/javac/processing/src/CheckNamesProcessor.java
! test/tools/javac/6402516/CheckLocalElements.java
! test/tools/javac/api/TestOperators.java
! test/tools/javac/enum/6350057/T6350057.java
! test/tools/javac/enum/6424358/T6424358.java
! test/tools/javac/failover/FailOver15.out
! test/tools/javac/lib/JavacTestingAbstractProcessor.java
! test/tools/javac/multicatch/model/ModelChecker.java
! test/tools/javac/processing/model/6194785/T6194785.java
! test/tools/javac/processing/model/TestSymtabItems.java
! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
! test/tools/javac/processing/model/element/TestResourceVariable.java
! test/tools/javac/processing/model/type/NoTypes.java
! test/tools/javac/processing/model/type/TestUnionType.java
! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java



From sean.mullan at oracle.com  Wed Jul  6 15:14:20 2011
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Wed, 06 Jul 2011 15:14:20 +0000
Subject: hg: jdk8/tl/jdk: 7054969: Null-check-in-finally pattern in
	java/security documentation
Message-ID: <20110706151446.09DB44720B@hg.openjdk.java.net>

Changeset: f68d30c0a2e3
Author:    mullan
Date:      2011-07-06 11:08 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f68d30c0a2e3

7054969: Null-check-in-finally pattern in java/security documentation
Reviewed-by: vinnie

! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/security/cert/X509CRL.java
! src/share/classes/java/security/cert/X509Certificate.java
! src/share/classes/java/security/cert/X509Extension.java



From jonathan.gibbons at oracle.com  Thu Jul  7 20:29:54 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 07 Jul 2011 20:29:54 +0000
Subject: hg: jdk8/tl/langtools: 7061125: Proposed javac argument processing
	performance improvement
Message-ID: <20110707202959.16B3247265@hg.openjdk.java.net>

Changeset: 7337295434b6
Author:    jjg
Date:      2011-07-07 13:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7337295434b6

7061125: Proposed javac argument processing performance improvement
Reviewed-by: jjg, dlsmith, mcimadamore, forax
Contributed-by: schlosna at gmail.com

! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! test/tools/javac/T6358166.java
! test/tools/javac/T6358168.java



From kumar.x.srinivasan at oracle.com  Sat Jul  9 19:24:36 2011
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Sat, 09 Jul 2011 19:24:36 +0000
Subject: hg: jdk8/tl/jdk: 7060849: Eliminate pack200 build warnings
Message-ID: <20110709192500.45625472FE@hg.openjdk.java.net>

Changeset: 63be90976177
Author:    ksrini
Date:      2011-07-08 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/63be90976177

7060849: Eliminate pack200 build warnings
Reviewed-by: ksrini, jjg
Contributed-by: alexandre.boulgakov at oracle.com

! make/com/sun/java/pack/Makefile
! make/common/shared/Defs-java.gmk
! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java
! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java
! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java
! src/share/classes/com/sun/java/util/jar/pack/Code.java
! src/share/classes/com/sun/java/util/jar/pack/Coding.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/Constants.java
! src/share/classes/com/sun/java/util/jar/pack/Fixups.java
! src/share/classes/com/sun/java/util/jar/pack/Instruction.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/Package.java
! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java
! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
! src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java
! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/Utils.java



From yuka.kamiya at oracle.com  Mon Jul 11 22:32:41 2011
From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com)
Date: Mon, 11 Jul 2011 22:32:41 +0000
Subject: hg: jdk8/tl/jdk: 7012364: test/java/util/Locale/LocaleCategory.sh
	fails on Cygwin
Message-ID: <20110711223255.8E2FF47371@hg.openjdk.java.net>

Changeset: 5adf431673ac
Author:    peytoia
Date:      2011-07-12 07:32 +0900
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5adf431673ac

7012364: test/java/util/Locale/LocaleCategory.sh fails on Cygwin
Reviewed-by: okutsu

! test/java/util/Locale/LocaleCategory.sh



From jandam at crcdata.cz  Tue Jul 12 11:32:31 2011
From: jandam at crcdata.cz (Janda Martin)
Date: Tue, 12 Jul 2011 13:32:31 +0200 (CEST)
Subject: Byte.parseByte throws NumberFormatException for value "95", radix: 16
In-Reply-To: <8442043.431310470188302.JavaMail.root@zs.crcpraha>
Message-ID: <16947562.451310470351237.JavaMail.root@zs.crcpraha>

I have question about parsing hex string. Java 6u25

When I call Byte.parseByte("95", 16) I get.

java.lang.NumberFormatException: Value out of range. Value:"95" Radix:16
	at java.lang.Byte.parseByte(Byte.java:153)

95 hex is 149 dec, Integer value '149' can be cast to valid byte value -107

Is the exception correct?

  Thank you very much for answer

 Martin JANDA
 jandam at crcdata.cz


Code from Byte.java

    public static byte parseByte(String s, int radix)
	throws NumberFormatException {
	int i = Integer.parseInt(s, radix);
	if (i < MIN_VALUE || i > MAX_VALUE)
	    throw new NumberFormatException(
                "Value out of range. Value:\"" + s + "\" Radix:" + radix);
	return (byte)i;
    }


From fweimer at bfk.de  Tue Jul 12 12:17:51 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Tue, 12 Jul 2011 12:17:51 +0000
Subject: Byte.parseByte throws NumberFormatException for value "95",
	radix: 16
In-Reply-To: <16947562.451310470351237.JavaMail.root@zs.crcpraha> (Janda
	Martin's message of "Tue, 12 Jul 2011 13:32:31 +0200 (CEST)")
References: <16947562.451310470351237.JavaMail.root@zs.crcpraha>
Message-ID: <82ipr7r8uo.fsf@mid.bfk.de>

* Janda Martin:

> Is the exception correct?

I think so.  The specification says this:

| The value represented by the string is not a value of type byte.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From David.Holmes at oracle.com  Tue Jul 12 12:19:25 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 12 Jul 2011 22:19:25 +1000
Subject: Byte.parseByte throws NumberFormatException for value "95", radix:
	16
In-Reply-To: <16947562.451310470351237.JavaMail.root@zs.crcpraha>
References: <16947562.451310470351237.JavaMail.root@zs.crcpraha>
Message-ID: <4E1C3BCD.50704@oracle.com>

Janda Martin said the following on 07/12/11 21:32:
> I have question about parsing hex string. Java 6u25
> 
> When I call Byte.parseByte("95", 16) I get.
> 
> java.lang.NumberFormatException: Value out of range. Value:"95" Radix:16
> 	at java.lang.Byte.parseByte(Byte.java:153)
> 
> 95 hex is 149 dec, Integer value '149' can be cast to valid byte value -107
> 
> Is the exception correct?

Yes. 95 hex == 149 dec which is > 127 and so is out of range for byte. 
If you want to use the bit pattern of 95 hex as a byte then you need to 
parse it as an int and do the cast yourself.

David Holmes

>   Thank you very much for answer
> 
>  Martin JANDA
>  jandam at crcdata.cz
> 
> 
> Code from Byte.java
> 
>     public static byte parseByte(String s, int radix)
> 	throws NumberFormatException {
> 	int i = Integer.parseInt(s, radix);
> 	if (i < MIN_VALUE || i > MAX_VALUE)
> 	    throw new NumberFormatException(
>                 "Value out of range. Value:\"" + s + "\" Radix:" + radix);
> 	return (byte)i;
>     }


From jandam at crcdata.cz  Tue Jul 12 12:26:56 2011
From: jandam at crcdata.cz (Janda Martin)
Date: Tue, 12 Jul 2011 14:26:56 +0200 (CEST)
Subject: Byte.parseByte throws NumberFormatException for value "95",
	radix: 16
In-Reply-To: <4E1C3BCD.50704@oracle.com>
Message-ID: <3242781.531310473616437.JavaMail.root@zs.crcpraha>

Thank you very much for fast reply.

  I use (byte)Integer.parseInt....

  Martin

----- Original Message -----
From: "David Holmes" <David.Holmes at oracle.com>
To: "Janda Martin" <jandam at crcdata.cz>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Tuesday, July 12, 2011 2:19:25 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: Byte.parseByte throws NumberFormatException for value "95", radix: 16

Janda Martin said the following on 07/12/11 21:32:
> I have question about parsing hex string. Java 6u25
> 
> When I call Byte.parseByte("95", 16) I get.
> 
> java.lang.NumberFormatException: Value out of range. Value:"95" Radix:16
> 	at java.lang.Byte.parseByte(Byte.java:153)
> 
> 95 hex is 149 dec, Integer value '149' can be cast to valid byte value -107
> 
> Is the exception correct?

Yes. 95 hex == 149 dec which is > 127 and so is out of range for byte. 
If you want to use the bit pattern of 95 hex as a byte then you need to 
parse it as an int and do the cast yourself.

David Holmes

>   Thank you very much for answer
> 
>  Martin JANDA
>  jandam at crcdata.cz
> 
> 
> Code from Byte.java
> 
>     public static byte parseByte(String s, int radix)
> 	throws NumberFormatException {
> 	int i = Integer.parseInt(s, radix);
> 	if (i < MIN_VALUE || i > MAX_VALUE)
> 	    throw new NumberFormatException(
>                 "Value out of range. Value:\"" + s + "\" Radix:" + radix);
> 	return (byte)i;
>     }


From chris.hegarty at oracle.com  Tue Jul 12 14:24:52 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 12 Jul 2011 14:24:52 +0000
Subject: hg: jdk8/tl/jdk: 7058828:
	test/java/util/concurrent/Phaser/Arrive.java fails intermittently
Message-ID: <20110712142517.56AC24739F@hg.openjdk.java.net>

Changeset: 549b7c3f0bdc
Author:    dl
Date:      2011-07-12 15:23 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/549b7c3f0bdc

7058828: test/java/util/concurrent/Phaser/Arrive.java fails intermittently
Reviewed-by: chegar

! test/java/util/concurrent/Phaser/Arrive.java



From naoto.sato at oracle.com  Tue Jul 12 17:36:48 2011
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 12 Jul 2011 17:36:48 +0000
Subject: hg: jdk8/tl/jdk: 7022407: Spinning CPU in LocaleObjectCache.get()
Message-ID: <20110712173710.21D48473A7@hg.openjdk.java.net>

Changeset: 42fe05e54e69
Author:    naoto
Date:      2011-07-12 10:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42fe05e54e69

7022407: Spinning CPU in LocaleObjectCache.get()
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/LocaleObjectCache.java



From jeffhain at rocketmail.com  Tue Jul 12 23:13:51 2011
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Wed, 13 Jul 2011 00:13:51 +0100 (BST)
Subject: AbstractCollection.removeAll(Collection) and
	AbstractSet.removeAll(Collection)
Message-ID: <1310512431.54634.YahooMailRC@web29212.mail.ird.yahoo.com>

Hello.
?
I have some remarks about the methods named in the subject (JDK 6u26, JDK 
7b147).
?
?
1) AbstractCollection.removeAll(Collection)
?? This method could return immediately if the specified collection is empty,
not to iterate uselessly over all "this", or if "this" is empty, not to create 
an
iterator for nothing.public boolean removeAll(Collection<?> c) {
???boolean modified = false;
?? if (size() > c.size()) {
???? ?for (Iterator<?> i = c.iterator(); i.hasNext(); )
???? ??? modified |= remove(i.next());
???} else {
???? ?for (Iterator<?> i = iterator(); i.hasNext(); ) {
???????? if (c.contains(i.next())) {
??????????? i.remove();
???? ?????? modified = true;
???? ??? }
????? }
?? }
?? return modified;
}
?
# Alternative implementation (not tested):public boolean removeAll(Collection<?> 
c) {
?? // Quick check on emptinesses, to make later treatments simpler.
?? if (isEmpty() || c.isEmpty()) {
????? return false;
?? }
?? boolean modified = false;
?? final int n1 = size();
?? final int n2 = c.size();
?? // If the "c" is not a set, we are pessimistic about its "contains" method 
complexity.
?? final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2;
?? // If we iterate over "this", assumed complexity is O(n2).
?? // If we iterate over "c", assumed complexity is O(n1 * 
cContainsAssumedComplexity).
?? // Cast to long to avoid overflow.
?? if (n2 < n1 * (long)cContainsAssumedComplexity) {
????? for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
???????? if (remove(i.next())) {
??????????? modified = true;
???????? ?? if (isEmpty()) {
????? ???????? break;
?? ???????? }
???????? }
????? }
?? } else {
????? for (Iterator<?> i = iterator(); i.hasNext(); ) {
???????? if (c.contains(i.next())) {
??????????? i.remove();
??????????? modified = true;
???????? }
????? }
?? }
?? return modified;
}
???I also thought about returning as soon as as many elements as the specified 
collection
contains?have been?removed, but it would not behave properly with collections 
containing
more than Integer.MAX_VALUE elements, or with some overriden?equals methods etc.
?
?
2) AbstractSet.removeAll(Collection)
?? Let n1 be the size of "this", and n2 the size of the specified collection.
?? This method is in O(n1*n2) if the specified collection has a contains(Object) 
method in O(n2)
(as an ArrayList does), and n1?<= n2.
?? I think?a better implementation could be done by taking care of the "setness" 
of the specified collection,
and taking care of collections sizes differently.
?? Also:
- when iterating on the specified collection, the method could return as soon 
as?"this" is empty,
? not to continue useless iterations.
- when iterating on "this", the method could return if the specified collection 
is empty,
??not to iterate over all "this" uselessly.
?
# Current implementation:


Regards,

Jeff


From jeffhain at rocketmail.com  Wed Jul 13 07:29:52 2011
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Wed, 13 Jul 2011 08:29:52 +0100 (BST)
Subject: Tr : AbstractCollection.removeAll(Collection) and
	AbstractSet.removeAll(Collection)
Message-ID: <1310542192.91464.YahooMailRC@web29213.mail.ird.yahoo.com>

Sorry, all paragraphs were in disorder ; looks like my mail app is not wysiwyg 
at all.
I hope this time content doesn't get messed up, else I'll just give up.

----- Message transf?r? ----
De : Jeff Hain <jeffhain at rocketmail.com>
? : core-libs-dev at openjdk.java.net
Envoy? le : Mer 13 juillet 2011, 1h 13min 51s
Objet?: AbstractCollection.removeAll(Collection) and 
AbstractSet.removeAll(Collection)

Hello.
?
I have some remarks about the methods named in the subject
(JDK 6u26, JDK 7b147).
?
?
1) AbstractCollection.removeAll(Collection)
?? This method could return immediately if the specified collection is empty,
not to iterate uselessly over all "this", or if "this" is empty, not to create 
an iterator for nothing.
???I also thought about returning as soon as as many elements as the specified
collection contains?have been?removed, but it would not behave properly with
collections containing more than Integer.MAX_VALUE elements, or with some
overriden?equals methods etc.
?
?
2) AbstractSet.removeAll(Collection)
?? Let n1 be the size of "this", and n2 the size of the specified collection.
?? This method is in O(n1*n2) if the specified collection has a contains(Object)
method in O(n2) (as an ArrayList does), and n1?<= n2.
?? I think?a better implementation could be done by taking care of the "setness"
of the specified collection, and taking care of collections sizes differently.
?? Also:
- when iterating on the specified collection, the method could return as soon
? as?"this" is empty, not to continue useless iterations.
- when iterating on "this", the method could return if the specified collection
? is empty, not to iterate over all "this" uselessly.
?
# Current implementation:
public boolean removeAll(Collection<?> c) {
???boolean modified = false;
?? if (size() > c.size()) {
???? ?for (Iterator<?> i = c.iterator(); i.hasNext(); )
???? ??? modified |= remove(i.next());
???} else {
???? ?for (Iterator<?> i = iterator(); i.hasNext(); ) {
???????? if (c.contains(i.next())) {
??????????? i.remove();
???? ?????? modified = true;
???? ??? }
????? }
?? }
?? return modified;
}
?
# Alternative implementation (not tested):
public boolean removeAll(Collection<?> c) {
?? // Quick check on emptinesses, to make later treatments simpler.
?? if (isEmpty() || c.isEmpty()) {
????? return false;
?? }
?? boolean modified = false;
?? final int n1 = size();
?? final int n2 = c.size();
?? // If the "c" is not a set, we are pessimistic about its "contains" 
method?complexity.
?? final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2;
?? // If we iterate over "this", assumed complexity is O(n2).
?? // If we iterate over "c", assumed complexity is O(n1 * 
cContainsAssumedComplexity).
?? // Cast to long to avoid overflow.
?? if (n2 < n1 * (long)cContainsAssumedComplexity) {
????? for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
???????? if (remove(i.next())) {
??????????? modified = true;
???????? ?? if (isEmpty()) {
????? ???????? break;
?? ???????? }
???????? }
????? }
?? } else {
????? for (Iterator<?> i = iterator(); i.hasNext(); ) {
???????? if (c.contains(i.next())) {
??????????? i.remove();
??????????? modified = true;
???????? }
????? }
?? }
?? return modified;
}


Regards,

Jeff


From scolebourne at joda.org  Wed Jul 13 07:48:33 2011
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 13 Jul 2011 08:48:33 +0100
Subject: Possible JDK 7 issue
Message-ID: <CACzrW9BZ_06Z0+PspO4cALfwJa28-ESSPGuG-oXC1+KTvvx-EQ@mail.gmail.com>

This message is forwarded from Apache Commons, where a question was
raised as to whether the change in behaviour of year formatting in JDK
7 was deliberate:

Stephen

---------- Forwarded message ----------
From: J?rg Schaible <joerg.schaible at gmx.de>
Date: 12 July 2011 18:56
Subject: Re: [lang] RC4 heads up
To: dev at commons.apache.org

1/ FastDateFormat
The date format "yyyy yyy yy y" is formatted with JDK 7 as "2003 2003 03
2003" instead of "2003 03 03 03". So, should FastDateFormat follow the JDK
in any case and adjust its result according the runtime? Interestingly
Javadoc states already for Java 6: "For formatting, if the number of pattern
letters is 2, the year is truncated to 2 digits; otherwise it is interpreted
as a number."


From chris.hegarty at oracle.com  Wed Jul 13 11:25:47 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 13 Jul 2011 11:25:47 +0000
Subject: hg: jdk8/tl/jdk: 7057320:
	test/java/util/concurrent/Executors/AutoShutdown.java failing
	intermittently
Message-ID: <20110713112607.CC1A7473D8@hg.openjdk.java.net>

Changeset: db419c454f92
Author:    dl
Date:      2011-07-13 12:24 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db419c454f92

7057320: test/java/util/concurrent/Executors/AutoShutdown.java failing intermittently
Summary: Add retry/timeout for checking activeCount
Reviewed-by: chegar

! test/java/util/concurrent/Executors/AutoShutdown.java



From sebastian.sickelmann at gmx.de  Wed Jul 13 15:40:39 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 13 Jul 2011 17:40:39 +0200
Subject: AbstractCollection.removeAll(Collection) and
	AbstractSet.removeAll(Collection)
In-Reply-To: <1310512431.54634.YahooMailRC@web29212.mail.ird.yahoo.com>
References: <1310512431.54634.YahooMailRC@web29212.mail.ird.yahoo.com>
Message-ID: <20110713154039.194850@gmx.net>

Jeff Hain wrote:
> Hello.
> ?
> I have some remarks about the methods named in the subject (JDK 6u26, JDK 
> 7b147).
> ?
> ?
> 1) AbstractCollection.removeAll(Collection)
> ?? This method could return immediately if the specified collection is
> empty,
> not to iterate uselessly over all "this", or if "this" is empty, not to
> create 
> an
> iterator for nothing.public boolean removeAll(Collection<?> c) {
> ???boolean modified = false;
> ?? if (size() > c.size()) {
> ???? ?for (Iterator<?> i = c.iterator(); i.hasNext(); )
> ???? ??? modified |= remove(i.next());
> ???} else {
> ???? ?for (Iterator<?> i = iterator(); i.hasNext(); ) {
> ???????? if (c.contains(i.next())) {
> ??????????? i.remove();
> ???? ?????? modified = true;
> ???? ??? }
> ????? }
> ?? }
> ?? return modified;
> }
> ?
> # Alternative implementation (not tested):public boolean
> removeAll(Collection<?> 
> c) {
> ?? // Quick check on emptinesses, to make later treatments simpler.
> ?? if (isEmpty() || c.isEmpty()) {
> ????? return false;
> ?? }
> ?? boolean modified = false;
> ?? final int n1 = size();
> ?? final int n2 = c.size();
> ?? // If the "c" is not a set, we are pessimistic about its "contains"
> method 
> complexity.
> ?? final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 :
> n2;
> ?? // If we iterate over "this", assumed complexity is O(n2).
> ?? // If we iterate over "c", assumed complexity is O(n1 * 
> cContainsAssumedComplexity).
> ?? // Cast to long to avoid overflow.
> ?? if (n2 < n1 * (long)cContainsAssumedComplexity) {
> ????? for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
> ???????? if (remove(i.next())) {
> ??????????? modified = true;
> ???????? ?? if (isEmpty()) {
> ????? ???????? break;
> ?? ???????? }
> ???????? }
> ????? }
> ?? } else {
> ????? for (Iterator<?> i = iterator(); i.hasNext(); ) {
> ???????? if (c.contains(i.next())) {
> ??????????? i.remove();
> ??????????? modified = true;
> ???????? }
> ????? }
> ?? }
> ?? return modified;
> }

look good to me. 

> ???I also thought about returning as soon as as many elements as the
> specified 
> collection
> contains?have been?removed, but it would not behave properly with
> collections 
> containing
> more than Integer.MAX_VALUE elements, or with some overriden?equals
> methods etc.

The overriden equals method should be no problem if the Implementation is an set. So it should be possible to exit in this case in the AbstractSet Implementation, isn't it?

> ?
> ?
> 2) AbstractSet.removeAll(Collection)
> ?? Let n1 be the size of "this", and n2 the size of the specified
> collection.
> ?? This method is in O(n1*n2) if the specified collection has a
> contains(Object) 
> method in O(n2)
> (as an ArrayList does), and n1?<= n2.
> ?? I think?a better implementation could be done by taking care of the
> "setness" 
> of the specified collection,
> and taking care of collections sizes differently.
> ?? Also:
> - when iterating on the specified collection, the method could return as
> soon 
> as?"this" is empty,
> ? not to continue useless iterations.
> - when iterating on "this", the method could return if the specified
> collection 
> is empty,
> ??not to iterate over all "this" uselessly.
> ?
> # Current implementation:
> 
> 
> Regards,
> 
> Jeff
> 

-- 
NEU: FreePhone - kostenlos mobil telefonieren!			
Jetzt informieren: http://www.gmx.net/de/go/freephone


From forax at univ-mlv.fr  Wed Jul 13 16:27:48 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Wed, 13 Jul 2011 18:27:48 +0200
Subject: AbstractCollection.removeAll(Collection)
	and	AbstractSet.removeAll(Collection)
In-Reply-To: <20110713154039.194850@gmx.net>
References: <1310512431.54634.YahooMailRC@web29212.mail.ird.yahoo.com>
	<20110713154039.194850@gmx.net>
Message-ID: <4E1DC784.9000401@univ-mlv.fr>

It doesn't work because the complexity of size() can be O(n).
In my opinion, only the checks for emptyness are Ok.

R?mi


On 07/13/2011 05:40 PM, Sebastian Sickelmann wrote:
> Jeff Hain wrote:
>> Hello.
>>   
>> I have some remarks about the methods named in the subject (JDK 6u26, JDK
>> 7b147).
>>   
>>   
>> 1) AbstractCollection.removeAll(Collection)
>>     This method could return immediately if the specified collection is
>> empty,
>> not to iterate uselessly over all "this", or if "this" is empty, not to
>> create
>> an
>> iterator for nothing.public boolean removeAll(Collection<?>  c) {
>>     boolean modified = false;
>>     if (size()>  c.size()) {
>>        for (Iterator<?>  i = c.iterator(); i.hasNext(); )
>>           modified |= remove(i.next());
>>     } else {
>>        for (Iterator<?>  i = iterator(); i.hasNext(); ) {
>>           if (c.contains(i.next())) {
>>              i.remove();
>>              modified = true;
>>           }
>>        }
>>     }
>>     return modified;
>> }
>>   
>> # Alternative implementation (not tested):public boolean
>> removeAll(Collection<?>
>> c) {
>>     // Quick check on emptinesses, to make later treatments simpler.
>>     if (isEmpty() || c.isEmpty()) {
>>        return false;
>>     }
>>     boolean modified = false;
>>     final int n1 = size();
>>     final int n2 = c.size();
>>     // If the "c" is not a set, we are pessimistic about its "contains"
>> method
>> complexity.
>>     final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 :
>> n2;
>>     // If we iterate over "this", assumed complexity is O(n2).
>>     // If we iterate over "c", assumed complexity is O(n1 *
>> cContainsAssumedComplexity).
>>     // Cast to long to avoid overflow.
>>     if (n2<  n1 * (long)cContainsAssumedComplexity) {
>>        for (Iterator<?>  i = c.iterator(); i.hasNext(); ) {
>>           if (remove(i.next())) {
>>              modified = true;
>>              if (isEmpty()) {
>>                 break;
>>              }
>>           }
>>        }
>>     } else {
>>        for (Iterator<?>  i = iterator(); i.hasNext(); ) {
>>           if (c.contains(i.next())) {
>>              i.remove();
>>              modified = true;
>>           }
>>        }
>>     }
>>     return modified;
>> }
> look good to me.
>
>>     I also thought about returning as soon as as many elements as the
>> specified
>> collection
>> contains have been removed, but it would not behave properly with
>> collections
>> containing
>> more than Integer.MAX_VALUE elements, or with some overriden equals
>> methods etc.
> The overriden equals method should be no problem if the Implementation is an set. So it should be possible to exit in this case in the AbstractSet Implementation, isn't it?
>
>>   
>>   
>> 2) AbstractSet.removeAll(Collection)
>>     Let n1 be the size of "this", and n2 the size of the specified
>> collection.
>>     This method is in O(n1*n2) if the specified collection has a
>> contains(Object)
>> method in O(n2)
>> (as an ArrayList does), and n1<= n2.
>>     I think a better implementation could be done by taking care of the
>> "setness"
>> of the specified collection,
>> and taking care of collections sizes differently.
>>     Also:
>> - when iterating on the specified collection, the method could return as
>> soon
>> as "this" is empty,
>>    not to continue useless iterations.
>> - when iterating on "this", the method could return if the specified
>> collection
>> is empty,
>>    not to iterate over all "this" uselessly.
>>   
>> # Current implementation:
>>
>>
>> Regards,
>>
>> Jeff
>>



From jeffhain at rocketmail.com  Wed Jul 13 20:02:07 2011
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Wed, 13 Jul 2011 21:02:07 +0100 (BST)
Subject: AbstractCollection.removeAll(Collection) and
	AbstractSet.removeAll(Collection)
Message-ID: <1310587327.20729.YahooMailRC@web29219.mail.ird.yahoo.com>


> It doesn't work because the complexity of size() can be O(n).
> In my opinion, only the checks for emptyness are Ok.

   The calls to "size()" are already there in current implementation,
and I think with the idea that in most cases they are O(1).
   If they are O(n), it's of course pointless to use them, since it
makes the whole treatment at least O(max(n1,n2)) (with n1 = this.size()
and n2 = c.size()), while simply iterating on "c" without checking
sizes makes it O(n2) (considering this.remove(Object) to be in O(1) (*)).
   But, then, the whole treatment remains linear at worse, and if,
as it is often the case, they are O(1), it allows to make it
O(min(n2,n1)) if "c" is also a set.
   Considering sizes  therefore allows to have O(max(n1,n2))  instead
of O(n2) in rare cases, and O(min(n1,n2)) instead of O(n2) in a fair
amount of cases, which can be considered a win. Also, if size()'s
are O(n), you are most likely doing concurrency, so you are smart,
know what you do, and can make your own removeAll ;)
   What seems to have been overlooked in current implementation,
is that this optimization, that works for sets, makes things actually
worse if "c" is a list, in which case it's best to always iterate on
"c", iterating on "this" resulting in a quadratic behavior.

   To make things simple, and have a treatment always in O(n2),
we could just stick to iterating on "c" without checking sizes:

public boolean AbstractSet.removeAll(Collection<?> c) {
   if (isEmpty() || c.isEmpty()) {
      return false;
   }
   boolean modified = false;
   for  (Iterator<?> i = c.iterator(); i.hasNext(); ) {
      if (remove(i.next())) {
         modified = true;
         if (isEmpty()) {
            break;
         }
      }
   }
   return modified;
}

(*) We could refine considering the case of tree sets.



> The overriden equals method should be no problem
> if the Implementation is an set. So it should be
> possible to exit in this case in the AbstractSet
> Implementation, isn't it?

   For AbstractCollection.removeAll(Collection),
that wouldn't work, since each instance to remove
in "c" can have multiple occurrences in "this".

   For  AbstractSet.removeAll(Collection),
that wouldn't work either, because if "c" is
based on "equals", and "c" is an identity set
(based on "=="), multiple elements of "this"
could be equal to a same element of "c",
and removing as many as "c" contains doesn't
mean you can't find more elements in "this"
that would be equal to elements of "c".

   A best effort implementation, that should
work if collections are not sets of different
kinds, would look like this:

public boolean AbstractSet.removeAll(Collection<?> c) {
   if (isEmpty() || c.isEmpty()) {
      return false;
   }
   boolean modified = false;
   final int n1 = size();
   final int n2 = c.size();
   final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2;
   if (n2 <= n1 *  (long)cContainsAssumedComplexity) {
      for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
         if (remove(i.next())) {
            modified = true;
            if (isEmpty()) {
               break;
            }
         }
      }
   } else {
      // Here, we know "c" is a Set
      // (else, we tested "n2 <= n1 * (long)n2",
      // which is always true for n1 > 0 and n2 > 0).
      if (n2 != Integer.MAX_VALUE)  {
         // Will stop iterating once
         // we removed from "this" as
         // many elements as "c" contains.
         // XXX Does not work if "this" is an identity set,
         // and "c" based on "equals".
         int toRemove = n2;
         for (Iterator<?> i = iterator(); i.hasNext(); ) {
            if (c.contains(i.next())) {
               i.remove();
               modified =  true;
               if (--toRemove == 0) {
                  break;
               }
            }
         }
      } else {
         // "c" might contain more than Integer.MAX_VALUE
         // elements, so we can't break early.
         for (Iterator<?> i = iterator(); i.hasNext(); ) {
            if (c.contains(i.next()))  {
               i.remove();
               modified = true;
            }
         }
      }
   }
   return modified;
}



Jeff



________________________________
De : R?mi Forax <forax at univ-mlv.fr>
? : core-libs-dev at openjdk.java.net
Envoy? le : Mer 13 juillet 2011, 18h 27min 48s
Objet : Re: AbstractCollection.removeAll(Collection) and 
AbstractSet.removeAll(Collection)

It doesn't work because the  complexity of size() can be O(n).
In my opinion, only the checks for emptyness are Ok.

R?mi


On 07/13/2011 05:40 PM, Sebastian Sickelmann wrote:
> Jeff Hain wrote:
>> Hello.
>>   I have some remarks about the methods named in the subject (JDK 6u26, JDK
>> 7b147).
>>     1) AbstractCollection.removeAll(Collection)
>>     This method could return immediately if the specified collection is
>> empty, not to iterate uselessly over all "this", or if "this" is empty, not 
to
>> create an iterator for nothing.
>>     I also thought about returning as soon as as many elements as the
>> specified collection contains have been removed, but it would not behave
>>  properly with collections containing more than Integer.MAX_VALUE elements,
>> or with some overriden equals methods etc.
>  The overriden equals method should be no problem if the Implementation  is an 
>set. So it should be possible to exit in this case in the  AbstractSet 
>Implementation, isn't it?
> 
>>     2) AbstractSet.removeAll(Collection)
>>     Let n1 be the size of "this", and n2 the size of the specified 
collection.
>>     This method is in O(n1*n2) if the specified collection has a 
>>contains(Object)
>> method in O(n2) (as an ArrayList does), and n1<= n2.
>>     I think a better implementation could be done by taking care of the
>> "setness" of the specified collection, and taking care of collections sizes
>> differently.
>>     Also:
>> - when iterating on the specified collection, the method  could return as
>> soon as "this" is empty, not to continue useless iterations.
>> - when iterating on "this", the method could return if the specified
>> collection is empty, not to iterate over all "this" uselessly.
>> 
>>   # Current implementation:
>> public boolean removeAll(Collection<?>  c) {
>>     boolean modified = false;
>>     if (size()>  c.size()) {
>>        for (Iterator<?>  i = c.iterator(); i.hasNext(); )
>>           modified |= remove(i.next());
>>     } else {
>>        for (Iterator<?>  i = iterator(); i.hasNext(); ) {
>>           if (c.contains(i.next())) {
>>              i.remove();
>>               modified = true;
>>           }
>>        }
>>     }
>>     return modified;
>> }
>> 
>>   # Alternative implementation (not tested):public boolean
>> removeAll(Collection<?> c) {
>>     // Quick check on emptinesses, to make later treatments simpler.
>>     if (isEmpty() || c.isEmpty()) {
>>        return false;
>>     }
>>     boolean modified = false;
>>     final int n1 = size();
>>     final int n2 = c.size();
>>     // If the "c" is not a set, we are pessimistic about its "contains"
>>    // method
>>    // complexity.
>>     final int  cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2;
>>     // If we iterate over "this", assumed complexity is O(n2).
>>     // If we iterate over "c", assumed complexity is O(n1 * 
>>cContainsAssumedComplexity).
>>     // Cast to long to avoid overflow.
>>     if (n2<  n1 * (long)cContainsAssumedComplexity) {
>>        for (Iterator<?>  i = c.iterator(); i.hasNext(); ) {
>>           if (remove(i.next())) {
>>              modified = true;
>>              if (isEmpty()) {
>>                 break;
>>              }
>>           }
>>         }
>>     } else {
>>        for (Iterator<?>  i = iterator(); i.hasNext(); ) {
>>           if (c.contains(i.next())) {
>>              i.remove();
>>              modified = true;
>>           }
>>        }
>>     }
>>     return modified;
>> }
> look good to me.
> 
>> 
>> 
>> Regards,
>> 
>> Jeff
>> 

From mike.duigou at oracle.com  Wed Jul 13 20:34:43 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 13 Jul 2011 13:34:43 -0700
Subject: AbstractCollection.removeAll(Collection) and
	AbstractSet.removeAll(Collection)
In-Reply-To: <1310587327.20729.YahooMailRC@web29219.mail.ird.yahoo.com>
References: <1310587327.20729.YahooMailRC@web29219.mail.ird.yahoo.com>
Message-ID: <B4E6CFFE-69D9-49A6-BCDA-9108840A14B7@oracle.com>

It looks to me that AbstractCollection could benefit from a c.isEmpty() check but that's the only optimization I currently see. It's necessary to iterate the target collection because values can be repeated for some collection types.

I agree that AbstractSet.removeAll appears to make a poor judgement that the cost of this.contains() and c.contains() are similar. I'd like to know if there are common usage patterns where iteration over c isn't the best choice. (adding isEmpty() checks for both this and c of course).

Josh? Martin? Doug? Any history why AbstractSet has this optimization?

Mike

On Jul 13 2011, at 13:02 , Jeff Hain wrote:

> 
>> It doesn't work because the complexity of size() can be O(n).
>> In my opinion, only the checks for emptyness are Ok.
> 
>   The calls to "size()" are already there in current implementation,
> and I think with the idea that in most cases they are O(1).
>   If they are O(n), it's of course pointless to use them, since it
> makes the whole treatment at least O(max(n1,n2)) (with n1 = this.size()
> and n2 = c.size()), while simply iterating on "c" without checking
> sizes makes it O(n2) (considering this.remove(Object) to be in O(1) (*)).
>   But, then, the whole treatment remains linear at worse, and if,
> as it is often the case, they are O(1), it allows to make it
> O(min(n2,n1)) if "c" is also a set.
>   Considering sizes  therefore allows to have O(max(n1,n2))  instead
> of O(n2) in rare cases, and O(min(n1,n2)) instead of O(n2) in a fair
> amount of cases, which can be considered a win. Also, if size()'s
> are O(n), you are most likely doing concurrency, so you are smart,
> know what you do, and can make your own removeAll ;)
>   What seems to have been overlooked in current implementation,
> is that this optimization, that works for sets, makes things actually
> worse if "c" is a list, in which case it's best to always iterate on
> "c", iterating on "this" resulting in a quadratic behavior.
> 
>   To make things simple, and have a treatment always in O(n2),
> we could just stick to iterating on "c" without checking sizes:
> 
> public boolean AbstractSet.removeAll(Collection<?> c) {
>   if (isEmpty() || c.isEmpty()) {
>      return false;
>   }
>   boolean modified = false;
>   for  (Iterator<?> i = c.iterator(); i.hasNext(); ) {
>      if (remove(i.next())) {
>         modified = true;
>         if (isEmpty()) {
>            break;
>         }
>      }
>   }
>   return modified;
> }
> 
> (*) We could refine considering the case of tree sets.
> 
> 
> 
>> The overriden equals method should be no problem
>> if the Implementation is an set. So it should be
>> possible to exit in this case in the AbstractSet
>> Implementation, isn't it?
> 
>   For AbstractCollection.removeAll(Collection),
> that wouldn't work, since each instance to remove
> in "c" can have multiple occurrences in "this".
> 
>   For  AbstractSet.removeAll(Collection),
> that wouldn't work either, because if "c" is
> based on "equals", and "c" is an identity set
> (based on "=="), multiple elements of "this"
> could be equal to a same element of "c",
> and removing as many as "c" contains doesn't
> mean you can't find more elements in "this"
> that would be equal to elements of "c".
> 
>   A best effort implementation, that should
> work if collections are not sets of different
> kinds, would look like this:
> 
> public boolean AbstractSet.removeAll(Collection<?> c) {
>   if (isEmpty() || c.isEmpty()) {
>      return false;
>   }
>   boolean modified = false;
>   final int n1 = size();
>   final int n2 = c.size();
>   final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2;
>   if (n2 <= n1 *  (long)cContainsAssumedComplexity) {
>      for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
>         if (remove(i.next())) {
>            modified = true;
>            if (isEmpty()) {
>               break;
>            }
>         }
>      }
>   } else {
>      // Here, we know "c" is a Set
>      // (else, we tested "n2 <= n1 * (long)n2",
>      // which is always true for n1 > 0 and n2 > 0).
>      if (n2 != Integer.MAX_VALUE)  {
>         // Will stop iterating once
>         // we removed from "this" as
>         // many elements as "c" contains.
>         // XXX Does not work if "this" is an identity set,
>         // and "c" based on "equals".
>         int toRemove = n2;
>         for (Iterator<?> i = iterator(); i.hasNext(); ) {
>            if (c.contains(i.next())) {
>               i.remove();
>               modified =  true;
>               if (--toRemove == 0) {
>                  break;
>               }
>            }
>         }
>      } else {
>         // "c" might contain more than Integer.MAX_VALUE
>         // elements, so we can't break early.
>         for (Iterator<?> i = iterator(); i.hasNext(); ) {
>            if (c.contains(i.next()))  {
>               i.remove();
>               modified = true;
>            }
>         }
>      }
>   }
>   return modified;
> }
> 
> 
> 
> Jeff
> 
> 
> 
> ________________________________
> De : R?mi Forax <forax at univ-mlv.fr>
> ? : core-libs-dev at openjdk.java.net
> Envoy? le : Mer 13 juillet 2011, 18h 27min 48s
> Objet : Re: AbstractCollection.removeAll(Collection) and 
> AbstractSet.removeAll(Collection)
> 
> It doesn't work because the  complexity of size() can be O(n).
> In my opinion, only the checks for emptyness are Ok.
> 
> R?mi
> 
> 
> On 07/13/2011 05:40 PM, Sebastian Sickelmann wrote:
>> Jeff Hain wrote:
>>> Hello.
>>>  I have some remarks about the methods named in the subject (JDK 6u26, JDK
>>> 7b147).
>>>    1) AbstractCollection.removeAll(Collection)
>>>    This method could return immediately if the specified collection is
>>> empty, not to iterate uselessly over all "this", or if "this" is empty, not 
> to
>>> create an iterator for nothing.
>>>    I also thought about returning as soon as as many elements as the
>>> specified collection contains have been removed, but it would not behave
>>> properly with collections containing more than Integer.MAX_VALUE elements,
>>> or with some overriden equals methods etc.
>> The overriden equals method should be no problem if the Implementation  is an 
>> set. So it should be possible to exit in this case in the  AbstractSet 
>> Implementation, isn't it?
>> 
>>>    2) AbstractSet.removeAll(Collection)
>>>    Let n1 be the size of "this", and n2 the size of the specified 
> collection.
>>>    This method is in O(n1*n2) if the specified collection has a 
>>> contains(Object)
>>> method in O(n2) (as an ArrayList does), and n1<= n2.
>>>    I think a better implementation could be done by taking care of the
>>> "setness" of the specified collection, and taking care of collections sizes
>>> differently.
>>>    Also:
>>> - when iterating on the specified collection, the method  could return as
>>> soon as "this" is empty, not to continue useless iterations.
>>> - when iterating on "this", the method could return if the specified
>>> collection is empty, not to iterate over all "this" uselessly.
>>> 
>>>  # Current implementation:
>>> public boolean removeAll(Collection<?>  c) {
>>>    boolean modified = false;
>>>    if (size()>  c.size()) {
>>>       for (Iterator<?>  i = c.iterator(); i.hasNext(); )
>>>          modified |= remove(i.next());
>>>    } else {
>>>       for (Iterator<?>  i = iterator(); i.hasNext(); ) {
>>>          if (c.contains(i.next())) {
>>>             i.remove();
>>>              modified = true;
>>>          }
>>>       }
>>>    }
>>>    return modified;
>>> }
>>> 
>>>  # Alternative implementation (not tested):public boolean
>>> removeAll(Collection<?> c) {
>>>    // Quick check on emptinesses, to make later treatments simpler.
>>>    if (isEmpty() || c.isEmpty()) {
>>>       return false;
>>>    }
>>>    boolean modified = false;
>>>    final int n1 = size();
>>>    final int n2 = c.size();
>>>    // If the "c" is not a set, we are pessimistic about its "contains"
>>>   // method
>>>   // complexity.
>>>    final int  cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2;
>>>    // If we iterate over "this", assumed complexity is O(n2).
>>>    // If we iterate over "c", assumed complexity is O(n1 * 
>>> cContainsAssumedComplexity).
>>>    // Cast to long to avoid overflow.
>>>    if (n2<  n1 * (long)cContainsAssumedComplexity) {
>>>       for (Iterator<?>  i = c.iterator(); i.hasNext(); ) {
>>>          if (remove(i.next())) {
>>>             modified = true;
>>>             if (isEmpty()) {
>>>                break;
>>>             }
>>>          }
>>>        }
>>>    } else {
>>>       for (Iterator<?>  i = iterator(); i.hasNext(); ) {
>>>          if (c.contains(i.next())) {
>>>             i.remove();
>>>             modified = true;
>>>          }
>>>       }
>>>    }
>>>    return modified;
>>> }
>> look good to me.
>> 
>>> 
>>> 
>>> Regards,
>>> 
>>> Jeff
>>> 



From jason_mehrens at hotmail.com  Wed Jul 13 22:19:04 2011
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Wed, 13 Jul 2011 17:19:04 -0500
Subject: AbstractCollection.removeAll(Collection) and
	AbstractSet.removeAll(Collection)
In-Reply-To: <B4E6CFFE-69D9-49A6-BCDA-9108840A14B7@oracle.com>
References: <1310587327.20729.YahooMailRC@web29219.mail.ird.yahoo.com>,
	<B4E6CFFE-69D9-49A6-BCDA-9108840A14B7@oracle.com>
Message-ID: <SNT114-W12395A35CB863702DB114C83470@phx.gbl>


Mike,
 
The history is in the evaluation of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6394757
 
I don't think that even adding a empty check can be considered an optimization when dealing with two abstract things.  The iterator creation here is 'good garbage' and worst case AbstractCollection.isEmpty could be O(N).
JDKs 5 and 6 shipped with two collections (CHM views) that had O(N) isEmpty methods. 
 
 
I think the following evaluations really cover the issues regarding this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519662
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5028425
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6633605
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6250140
 
 
Jason
 

> Subject: Re: AbstractCollection.removeAll(Collection) and AbstractSet.removeAll(Collection)
> From: mike.duigou at oracle.com
> Date: Wed, 13 Jul 2011 13:34:43 -0700
> To: jeffhain at rocketmail.com
> CC: core-libs-dev at openjdk.java.net
> 
> It looks to me that AbstractCollection could benefit from a c.isEmpty() check but that's the only optimization I currently see. It's necessary to iterate the target collection because values can be repeated for some collection types.
> 
> I agree that AbstractSet.removeAll appears to make a poor judgement that the cost of this.contains() and c.contains() are similar. I'd like to know if there are common usage patterns where iteration over c isn't the best choice. (adding isEmpty() checks for both this and c of course).
> 
> Josh? Martin? Doug? Any history why AbstractSet has this optimization?
> 
> Mike
> 
> On Jul 13 2011, at 13:02 , Jeff Hain wrote:
> 
> > 
> >> It doesn't work because the complexity of size() can be O(n).
> >> In my opinion, only the checks for emptyness are Ok.
> > 
> > The calls to "size()" are already there in current implementation,
> > and I think with the idea that in most cases they are O(1).
> > If they are O(n), it's of course pointless to use them, since it
> > makes the whole treatment at least O(max(n1,n2)) (with n1 = this.size()
> > and n2 = c.size()), while simply iterating on "c" without checking
> > sizes makes it O(n2) (considering this.remove(Object) to be in O(1) (*)).
> > But, then, the whole treatment remains linear at worse, and if,
> > as it is often the case, they are O(1), it allows to make it
> > O(min(n2,n1)) if "c" is also a set.
> > Considering sizes therefore allows to have O(max(n1,n2)) instead
> > of O(n2) in rare cases, and O(min(n1,n2)) instead of O(n2) in a fair
> > amount of cases, which can be considered a win. Also, if size()'s
> > are O(n), you are most likely doing concurrency, so you are smart,
> > know what you do, and can make your own removeAll ;)
> > What seems to have been overlooked in current implementation,
> > is that this optimization, that works for sets, makes things actually
> > worse if "c" is a list, in which case it's best to always iterate on
> > "c", iterating on "this" resulting in a quadratic behavior.
> > 
> > To make things simple, and have a treatment always in O(n2),
> > we could just stick to iterating on "c" without checking sizes:
> > 
> > public boolean AbstractSet.removeAll(Collection<?> c) {
> > if (isEmpty() || c.isEmpty()) {
> > return false;
> > }
> > boolean modified = false;
> > for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
> > if (remove(i.next())) {
> > modified = true;
> > if (isEmpty()) {
> > break;
> > }
> > }
> > }
> > return modified;
> > }
> > 
> > (*) We could refine considering the case of tree sets.
> > 
> > 
> > 
> >> The overriden equals method should be no problem
> >> if the Implementation is an set. So it should be
> >> possible to exit in this case in the AbstractSet
> >> Implementation, isn't it?
> > 
> > For AbstractCollection.removeAll(Collection),
> > that wouldn't work, since each instance to remove
> > in "c" can have multiple occurrences in "this".
> > 
> > For AbstractSet.removeAll(Collection),
> > that wouldn't work either, because if "c" is
> > based on "equals", and "c" is an identity set
> > (based on "=="), multiple elements of "this"
> > could be equal to a same element of "c",
> > and removing as many as "c" contains doesn't
> > mean you can't find more elements in "this"
> > that would be equal to elements of "c".
> > 
> > A best effort implementation, that should
> > work if collections are not sets of different
> > kinds, would look like this:
> > 
> > public boolean AbstractSet.removeAll(Collection<?> c) {
> > if (isEmpty() || c.isEmpty()) {
> > return false;
> > }
> > boolean modified = false;
> > final int n1 = size();
> > final int n2 = c.size();
> > final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2;
> > if (n2 <= n1 * (long)cContainsAssumedComplexity) {
> > for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
> > if (remove(i.next())) {
> > modified = true;
> > if (isEmpty()) {
> > break;
> > }
> > }
> > }
> > } else {
> > // Here, we know "c" is a Set
> > // (else, we tested "n2 <= n1 * (long)n2",
> > // which is always true for n1 > 0 and n2 > 0).
> > if (n2 != Integer.MAX_VALUE) {
> > // Will stop iterating once
> > // we removed from "this" as
> > // many elements as "c" contains.
> > // XXX Does not work if "this" is an identity set,
> > // and "c" based on "equals".
> > int toRemove = n2;
> > for (Iterator<?> i = iterator(); i.hasNext(); ) {
> > if (c.contains(i.next())) {
> > i.remove();
> > modified = true;
> > if (--toRemove == 0) {
> > break;
> > }
> > }
> > }
> > } else {
> > // "c" might contain more than Integer.MAX_VALUE
> > // elements, so we can't break early.
> > for (Iterator<?> i = iterator(); i.hasNext(); ) {
> > if (c.contains(i.next())) {
> > i.remove();
> > modified = true;
> > }
> > }
> > }
> > }
> > return modified;
> > }
> > 
> > 
> > 
> > Jeff
> > 
> > 
> > 
> > ________________________________
> > De : R?mi Forax <forax at univ-mlv.fr>
> > ? : core-libs-dev at openjdk.java.net
> > Envoy? le : Mer 13 juillet 2011, 18h 27min 48s
> > Objet : Re: AbstractCollection.removeAll(Collection) and 
> > AbstractSet.removeAll(Collection)
> > 
> > It doesn't work because the complexity of size() can be O(n).
> > In my opinion, only the checks for emptyness are Ok.
> > 
> > R?mi
> > 
> > 
> > On 07/13/2011 05:40 PM, Sebastian Sickelmann wrote:
> >> Jeff Hain wrote:
> >>> Hello.
> >>> I have some remarks about the methods named in the subject (JDK 6u26, JDK
> >>> 7b147).
> >>> 1) AbstractCollection.removeAll(Collection)
> >>> This method could return immediately if the specified collection is
> >>> empty, not to iterate uselessly over all "this", or if "this" is empty, not 
> > to
> >>> create an iterator for nothing.
> >>> I also thought about returning as soon as as many elements as the
> >>> specified collection contains have been removed, but it would not behave
> >>> properly with collections containing more than Integer.MAX_VALUE elements,
> >>> or with some overriden equals methods etc.
> >> The overriden equals method should be no problem if the Implementation is an 
> >> set. So it should be possible to exit in this case in the AbstractSet 
> >> Implementation, isn't it?
> >> 
> >>> 2) AbstractSet.removeAll(Collection)
> >>> Let n1 be the size of "this", and n2 the size of the specified 
> > collection.
> >>> This method is in O(n1*n2) if the specified collection has a 
> >>> contains(Object)
> >>> method in O(n2) (as an ArrayList does), and n1<= n2.
> >>> I think a better implementation could be done by taking care of the
> >>> "setness" of the specified collection, and taking care of collections sizes
> >>> differently.
> >>> Also:
> >>> - when iterating on the specified collection, the method could return as
> >>> soon as "this" is empty, not to continue useless iterations.
> >>> - when iterating on "this", the method could return if the specified
> >>> collection is empty, not to iterate over all "this" uselessly.
> >>> 
> >>> # Current implementation:
> >>> public boolean removeAll(Collection<?> c) {
> >>> boolean modified = false;
> >>> if (size()> c.size()) {
> >>> for (Iterator<?> i = c.iterator(); i.hasNext(); )
> >>> modified |= remove(i.next());
> >>> } else {
> >>> for (Iterator<?> i = iterator(); i.hasNext(); ) {
> >>> if (c.contains(i.next())) {
> >>> i.remove();
> >>> modified = true;
> >>> }
> >>> }
> >>> }
> >>> return modified;
> >>> }
> >>> 
> >>> # Alternative implementation (not tested):public boolean
> >>> removeAll(Collection<?> c) {
> >>> // Quick check on emptinesses, to make later treatments simpler.
> >>> if (isEmpty() || c.isEmpty()) {
> >>> return false;
> >>> }
> >>> boolean modified = false;
> >>> final int n1 = size();
> >>> final int n2 = c.size();
> >>> // If the "c" is not a set, we are pessimistic about its "contains"
> >>> // method
> >>> // complexity.
> >>> final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2;
> >>> // If we iterate over "this", assumed complexity is O(n2).
> >>> // If we iterate over "c", assumed complexity is O(n1 * 
> >>> cContainsAssumedComplexity).
> >>> // Cast to long to avoid overflow.
> >>> if (n2< n1 * (long)cContainsAssumedComplexity) {
> >>> for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
> >>> if (remove(i.next())) {
> >>> modified = true;
> >>> if (isEmpty()) {
> >>> break;
> >>> }
> >>> }
> >>> }
> >>> } else {
> >>> for (Iterator<?> i = iterator(); i.hasNext(); ) {
> >>> if (c.contains(i.next())) {
> >>> i.remove();
> >>> modified = true;
> >>> }
> >>> }
> >>> }
> >>> return modified;
> >>> }
> >> look good to me.
> >> 
> >>> 
> >>> 
> >>> Regards,
> >>> 
> >>> Jeff
> >>> 
> 
 		 	   		  

From mike.duigou at oracle.com  Wed Jul 13 22:42:22 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 13 Jul 2011 15:42:22 -0700
Subject: AbstractCollection.removeAll(Collection) and
	AbstractSet.removeAll(Collection)
In-Reply-To: <SNT114-W12395A35CB863702DB114C83470@phx.gbl>
References: <1310587327.20729.YahooMailRC@web29219.mail.ird.yahoo.com>,
	<B4E6CFFE-69D9-49A6-BCDA-9108840A14B7@oracle.com>
	<SNT114-W12395A35CB863702DB114C83470@phx.gbl>
Message-ID: <6968A51B-CD07-488E-8DE2-277E0190B499@oracle.com>


On Jul 13 2011, at 15:19 , Jason Mehrens wrote:

> worst case AbstractCollection.isEmpty could be O(N).
> JDKs 5 and 6 shipped with two collections (CHM views) that had O(N) isEmpty methods.  

This is very interesting. The common wisdom has been that size() should be avoided because of O(>1) concerns but that isEmpty() is "safe". My assumptions are now amended. :-)

Mike

From joe.darcy at oracle.com  Thu Jul 14 02:21:46 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 13 Jul 2011 19:21:46 -0700
Subject: JDK 8 code review request for 7007535: (reflect) Please generalize
	Constructor and Method
Message-ID: <4E1E52BA.6070705@oracle.com>

Hello.

Please code review my JDK 8 changes for

    7007535: (reflect) Please generalize Constructor and Method
    http://cr.openjdk.java.net/~darcy/7007535.3

To summarize the changes, a new superclass is defined to capture the 
common functionality of java.lang.reflect.Method and 
java.lang.reflect.Constructor.  That superclass is named "Executable" 
along the lines of javax.lang.model.ExecutableElement, which models 
constructors and methods in the JSR 269 language model.

Both specification and implementation code are shared.  To preserve the 
right @since behavior, it is common that in Method/Constructor the 
javadoc for a method will now look like:

/**
 * {@inheritDoc}
 * @since 1.5
 */

Since Executable is being created in JDK 8, it would be incorrect for 
methods in that class to have an @since of 1.5; adding the @since in 
Method/Constructor preserves the right information.

It would have been natural to also move common fields to Executable; 
however, HotSpot treats the Constructor and Method type specially and 
relies on the existing field ordering.  Since altering the field layout 
would require coordinated HotSpot changes, I'm opting to not perform 
such a change right now.  At least one abstract accessor method is 
declared in Executable to still allow code sharing even though the 
required field is not present.  In other cases, package private instance 
methods on Executable are passed the needed state from overridden public 
methods in Method/Constructor.

All java/lang/reflect regression tests pass on a full build with these 
changes.

Thanks,

-Joe


From ahughes at redhat.com  Thu Jul 14 21:55:32 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 14 Jul 2011 22:55:32 +0100
Subject: JDK 8 code review request for 7007535: (reflect) Please
	generalize Constructor and Method
In-Reply-To: <4E1E52BA.6070705@oracle.com>
References: <4E1E52BA.6070705@oracle.com>
Message-ID: <20110714215532.GG32334@rivendell.middle-earth.co.uk>

On 19:21 Wed 13 Jul     , joe.darcy at oracle.com wrote:
> Hello.
> 
> Please code review my JDK 8 changes for
> 
>     7007535: (reflect) Please generalize Constructor and Method
>     http://cr.openjdk.java.net/~darcy/7007535.3
> 
> To summarize the changes, a new superclass is defined to capture the 
> common functionality of java.lang.reflect.Method and 
> java.lang.reflect.Constructor.  That superclass is named "Executable" 
> along the lines of javax.lang.model.ExecutableElement, which models 
> constructors and methods in the JSR 269 language model.
> 
> Both specification and implementation code are shared.  To preserve the 
> right @since behavior, it is common that in Method/Constructor the 
> javadoc for a method will now look like:
> 
> /**
>  * {@inheritDoc}
>  * @since 1.5
>  */
> 
> Since Executable is being created in JDK 8, it would be incorrect for 
> methods in that class to have an @since of 1.5; adding the @since in 
> Method/Constructor preserves the right information.
> 

I assume this is why we have some methods in the subclass that just
call the superclass.

> It would have been natural to also move common fields to Executable; 
> however, HotSpot treats the Constructor and Method type specially and 
> relies on the existing field ordering.  Since altering the field layout 
> would require coordinated HotSpot changes, I'm opting to not perform 
> such a change right now.  At least one abstract accessor method is 
> declared in Executable to still allow code sharing even though the 
> required field is not present.  In other cases, package private instance 
> methods on Executable are passed the needed state from overridden public 
> methods in Method/Constructor.
> 
> All java/lang/reflect regression tests pass on a full build with these 
> changes.
> 

The changes look good (though hard to read in places due to additional
whitespace changes mixed in).  Nice to see these two finally being grouped
together.

> Thanks,
> 
> -Joe

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From joe.darcy at oracle.com  Thu Jul 14 23:48:48 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 14 Jul 2011 16:48:48 -0700
Subject: JDK 8 code review request for 7007535: (reflect) Please generalize
	Constructor and Method
In-Reply-To: <20110714215532.GG32334@rivendell.middle-earth.co.uk>
References: <4E1E52BA.6070705@oracle.com>
	<20110714215532.GG32334@rivendell.middle-earth.co.uk>
Message-ID: <4E1F8060.7010303@oracle.com>

Dr Andrew John Hughes wrote:
> On 19:21 Wed 13 Jul     , joe.darcy at oracle.com wrote:
>   
>> Hello.
>>
>> Please code review my JDK 8 changes for
>>
>>     7007535: (reflect) Please generalize Constructor and Method
>>     http://cr.openjdk.java.net/~darcy/7007535.3
>>
>> To summarize the changes, a new superclass is defined to capture the 
>> common functionality of java.lang.reflect.Method and 
>> java.lang.reflect.Constructor.  That superclass is named "Executable" 
>> along the lines of javax.lang.model.ExecutableElement, which models 
>> constructors and methods in the JSR 269 language model.
>>
>> Both specification and implementation code are shared.  To preserve the 
>> right @since behavior, it is common that in Method/Constructor the 
>> javadoc for a method will now look like:
>>
>> /**
>>  * {@inheritDoc}
>>  * @since 1.5
>>  */
>>
>> Since Executable is being created in JDK 8, it would be incorrect for 
>> methods in that class to have an @since of 1.5; adding the @since in 
>> Method/Constructor preserves the right information.
>>
>>     
>
> I assume this is why we have some methods in the subclass that just
> call the superclass.
>   

Correct.  This would not have been necessary if Executable were added 
back in, say, JDK 5.

>   
>> It would have been natural to also move common fields to Executable; 
>> however, HotSpot treats the Constructor and Method type specially and 
>> relies on the existing field ordering.  Since altering the field layout 
>> would require coordinated HotSpot changes, I'm opting to not perform 
>> such a change right now.  At least one abstract accessor method is 
>> declared in Executable to still allow code sharing even though the 
>> required field is not present.  In other cases, package private instance 
>> methods on Executable are passed the needed state from overridden public 
>> methods in Method/Constructor.
>>
>> All java/lang/reflect regression tests pass on a full build with these 
>> changes.
>>
>>     
>
> The changes look good (though hard to read in places due to additional
> whitespace changes mixed in).  Nice to see these two finally being grouped
> together.
>
>   

Thanks,

-Joe



From joe.darcy at oracle.com  Fri Jul 15 01:14:45 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 14 Jul 2011 18:14:45 -0700
Subject: JDK 8 code review request for 7062430 "Minor iconsistency in ulp
	descriptions"
Message-ID: <4E1F9485.9070100@oracle.com>

Hello.

Please review this small doc change to spell out what "ulp" means in the 
methods named "ulp" in the Math and StrictMath classes; patch below, 
webrev at:

    7062430 "Minor iconsistency in ulp descriptions"
    http://cr.openjdk.java.net/~darcy/7062430.0/

Due to paragraph reformatting, the change takes up many more physical 
lines than logical ones.  In each of the four ulp methods (for for float 
and one for double in each of Math and StrictMath) the phrase

    "An ulp of a [...] value is the positive distance..."

is replaced with

    "An ulp, unit in the last place, of a [...] value is the positive 
distance..."

Additionally, the reference to ulp in one the opening paragraphs of the 
Math class description is replaced with a link to one of the ulp methods 
in Math.

Thanks,

-Joe

--- old/src/share/classes/java/lang/Math.java    2011-07-14 
18:07:17.000000000 -0700
+++ new/src/share/classes/java/lang/Math.java    2011-07-14 
18:07:17.000000000 -0700
@@ -50,34 +50,34 @@
  *
  * <p>The quality of implementation specifications concern two
  * properties, accuracy of the returned result and monotonicity of the
- * method.  Accuracy of the floating-point {@code Math} methods
- * is measured in terms of <i>ulps</i>, units in the last place.  For
- * a given floating-point format, an ulp of a specific real number
- * value is the distance between the two floating-point values
- * bracketing that numerical value.  When discussing the accuracy of a
- * method as a whole rather than at a specific argument, the number of
- * ulps cited is for the worst-case error at any argument.  If a
- * method always has an error less than 0.5 ulps, the method always
- * returns the floating-point number nearest the exact result; such a
- * method is <i>correctly rounded</i>.  A correctly rounded method is
- * generally the best a floating-point approximation can be; however,
- * it is impractical for many floating-point methods to be correctly
- * rounded.  Instead, for the {@code Math} class, a larger error
- * bound of 1 or 2 ulps is allowed for certain methods.  Informally,
- * with a 1 ulp error bound, when the exact result is a representable
- * number, the exact result should be returned as the computed result;
- * otherwise, either of the two floating-point values which bracket
- * the exact result may be returned.  For exact results large in
- * magnitude, one of the endpoints of the bracket may be infinite.
- * Besides accuracy at individual arguments, maintaining proper
- * relations between the method at different arguments is also
- * important.  Therefore, most methods with more than 0.5 ulp errors
- * are required to be <i>semi-monotonic</i>: whenever the mathematical
- * function is non-decreasing, so is the floating-point approximation,
- * likewise, whenever the mathematical function is non-increasing, so
- * is the floating-point approximation.  Not all approximations that
- * have 1 ulp accuracy will automatically meet the monotonicity
- * requirements.
+ * method.  Accuracy of the floating-point {@code Math} methods is
+ * measured in terms of <i>ulps</i>, units in the last place.  For a
+ * given floating-point format, an {@linkplain #ulp(double) ulp} of a
+ * specific real number value is the distance between the two
+ * floating-point values bracketing that numerical value.  When
+ * discussing the accuracy of a method as a whole rather than at a
+ * specific argument, the number of ulps cited is for the worst-case
+ * error at any argument.  If a method always has an error less than
+ * 0.5 ulps, the method always returns the floating-point number
+ * nearest the exact result; such a method is <i>correctly
+ * rounded</i>.  A correctly rounded method is generally the best a
+ * floating-point approximation can be; however, it is impractical for
+ * many floating-point methods to be correctly rounded.  Instead, for
+ * the {@code Math} class, a larger error bound of 1 or 2 ulps is
+ * allowed for certain methods.  Informally, with a 1 ulp error bound,
+ * when the exact result is a representable number, the exact result
+ * should be returned as the computed result; otherwise, either of the
+ * two floating-point values which bracket the exact result may be
+ * returned.  For exact results large in magnitude, one of the
+ * endpoints of the bracket may be infinite.  Besides accuracy at
+ * individual arguments, maintaining proper relations between the
+ * method at different arguments is also important.  Therefore, most
+ * methods with more than 0.5 ulp errors are required to be
+ * <i>semi-monotonic</i>: whenever the mathematical function is
+ * non-decreasing, so is the floating-point approximation, likewise,
+ * whenever the mathematical function is non-increasing, so is the
+ * floating-point approximation.  Not all approximations that have 1
+ * ulp accuracy will automatically meet the monotonicity requirements.
  *
  * @author  unascribed
  * @author  Joseph D. Darcy
@@ -940,11 +940,11 @@
     }
 
     /**
-     * Returns the size of an ulp of the argument.  An ulp of a
-     * {@code double} value is the positive distance between this
-     * floating-point value and the {@code double} value next
-     * larger in magnitude.  Note that for non-NaN <i>x</i>,
-     * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
+     * Returns the size of an ulp of the argument.  An ulp, unit in
+     * the last place, of a {@code double} value is the positive
+     * distance between this floating-point value and the {@code
+     * double} value next larger in magnitude.  Note that for non-NaN
+     * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
      *
      * <p>Special Cases:
      * <ul>
@@ -967,11 +967,11 @@
     }
 
     /**
-     * Returns the size of an ulp of the argument.  An ulp of a
-     * {@code float} value is the positive distance between this
-     * floating-point value and the {@code float} value next
-     * larger in magnitude.  Note that for non-NaN <i>x</i>,
-     * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
+     * Returns the size of an ulp of the argument.  An ulp, unit in
+     * the last place, of a {@code float} value is the positive
+     * distance between this floating-point value and the {@code
+     * float} value next larger in magnitude.  Note that for non-NaN
+     * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
      *
      * <p>Special Cases:
      * <ul>
--- old/src/share/classes/java/lang/StrictMath.java    2011-07-14 
18:07:18.000000000 -0700
+++ new/src/share/classes/java/lang/StrictMath.java    2011-07-14 
18:07:18.000000000 -0700
@@ -932,11 +932,11 @@
     }
 
     /**
-     * Returns the size of an ulp of the argument.  An ulp of a
-     * {@code double} value is the positive distance between this
-     * floating-point value and the {@code double} value next
-     * larger in magnitude.  Note that for non-NaN <i>x</i>,
-     * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
+     * Returns the size of an ulp of the argument.  An ulp, unit in
+     * the last place, of a {@code double} value is the positive
+     * distance between this floating-point value and the {@code
+     * double} value next larger in magnitude.  Note that for non-NaN
+     * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
      *
      * <p>Special Cases:
      * <ul>
@@ -959,11 +959,11 @@
     }
 
     /**
-     * Returns the size of an ulp of the argument.  An ulp of a
-     * {@code float} value is the positive distance between this
-     * floating-point value and the {@code float} value next
-     * larger in magnitude.  Note that for non-NaN <i>x</i>,
-     * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
+     * Returns the size of an ulp of the argument.  An ulp, unit in
+     * the last place, of a {@code float} value is the positive
+     * distance between this floating-point value and the {@code
+     * float} value next larger in magnitude.  Note that for non-NaN
+     * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
      *
      * <p>Special Cases:
      * <ul>



From David.Holmes at oracle.com  Fri Jul 15 05:49:30 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 15 Jul 2011 15:49:30 +1000
Subject: JDK 8 code review request for 7007535: (reflect) Please generalize
	Constructor and Method
In-Reply-To: <4E1E52BA.6070705@oracle.com>
References: <4E1E52BA.6070705@oracle.com>
Message-ID: <4E1FD4EA.4090800@oracle.com>

Hi Joe,

On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
> Please code review my JDK 8 changes for
>
> 7007535: (reflect) Please generalize Constructor and Method
> http://cr.openjdk.java.net/~darcy/7007535.3
>
> To summarize the changes, a new superclass is defined to capture the common
> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor.
> That superclass is named "Executable" along the lines of
> javax.lang.model.ExecutableElement, which models constructors and methods in
> the JSR 269 language model.
>
> Both specification and implementation code are shared. To preserve the right
> @since behavior, it is common that in Method/Constructor the javadoc for a
> method will now look like:
>
> /**
> * {@inheritDoc}
> * @since 1.5
> */

Unless they have fixed/changed javadoc (entirely possible) it used to be 
that the above would not cause @throws declarations for unchecked exceptions 
to be inherited - you have/had to explicitly repeat them as:

@throws <exception-type> {@inheritDoc}

Cheers,
David
-----

> Since Executable is being created in JDK 8, it would be incorrect for
> methods in that class to have an @since of 1.5; adding the @since in
> Method/Constructor preserves the right information.
>
> It would have been natural to also move common fields to Executable;
> however, HotSpot treats the Constructor and Method type specially and relies
> on the existing field ordering. Since altering the field layout would
> require coordinated HotSpot changes, I'm opting to not perform such a change
> right now. At least one abstract accessor method is declared in Executable
> to still allow code sharing even though the required field is not present.
> In other cases, package private instance methods on Executable are passed
> the needed state from overridden public methods in Method/Constructor.
>
> All java/lang/reflect regression tests pass on a full build with these changes.
>
> Thanks,
>
> -Joe


From lana.steuck at oracle.com  Fri Jul 15 05:57:54 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 15 Jul 2011 05:57:54 +0000
Subject: hg: jdk8/tl: 5 new changesets
Message-ID: <20110715055754.5765F47440@hg.openjdk.java.net>

Changeset: 8da980eedab6
Author:    jeff
Date:      2011-06-22 10:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/8da980eedab6

7057046: Add embedded license to THIRD PARTY README
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: d91364304d7c
Author:    lana
Date:      2011-06-22 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/d91364304d7c

Merge


Changeset: ee67ee3bd597
Author:    schien
Date:      2011-06-27 13:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/ee67ee3bd597

Added tag jdk7-b147 for changeset d91364304d7c

! .hgtags

Changeset: 04734fe746f0
Author:    schien
Date:      2011-06-27 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/04734fe746f0

Merge


Changeset: 05e24d6ed56d
Author:    lana
Date:      2011-07-14 18:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/05e24d6ed56d

Merge




From lana.steuck at oracle.com  Fri Jul 15 05:57:58 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 15 Jul 2011 05:57:58 +0000
Subject: hg: jdk8/tl/jaxws: 4 new changesets
Message-ID: <20110715055758.2205647441@hg.openjdk.java.net>

Changeset: 632e38191caa
Author:    jeff
Date:      2011-06-22 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/632e38191caa

7057046: Add embedded license to THIRD PARTY README
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: d13b1f877bb5
Author:    lana
Date:      2011-06-22 12:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d13b1f877bb5

Merge


Changeset: 2605f832dfbf
Author:    schien
Date:      2011-06-27 13:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2605f832dfbf

Added tag jdk7-b147 for changeset d13b1f877bb5

! .hgtags

Changeset: 47022a1b59be
Author:    schien
Date:      2011-06-27 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/47022a1b59be

Merge




From lana.steuck at oracle.com  Fri Jul 15 05:57:54 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 15 Jul 2011 05:57:54 +0000
Subject: hg: jdk8/tl/corba: 4 new changesets
Message-ID: <20110715055758.65FBB47442@hg.openjdk.java.net>

Changeset: bba0e37d7006
Author:    jeff
Date:      2011-06-22 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/bba0e37d7006

7057046: Add embedded license to THIRD PARTY README
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: 73323cb33962
Author:    lana
Date:      2011-06-22 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/73323cb33962

Merge


Changeset: 960011ba4bf2
Author:    schien
Date:      2011-06-27 13:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/960011ba4bf2

Added tag jdk7-b147 for changeset 73323cb33962

! .hgtags

Changeset: 97014e43181f
Author:    schien
Date:      2011-06-27 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/97014e43181f

Merge




From lana.steuck at oracle.com  Fri Jul 15 05:57:59 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 15 Jul 2011 05:57:59 +0000
Subject: hg: jdk8/tl/jaxp: 4 new changesets
Message-ID: <20110715055759.AADBF47443@hg.openjdk.java.net>

Changeset: eed2486cb10b
Author:    jeff
Date:      2011-06-22 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/eed2486cb10b

7057046: Add embedded license to THIRD PARTY README
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: fc268cd1dd5d
Author:    lana
Date:      2011-06-22 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/fc268cd1dd5d

Merge


Changeset: 6c9ac74190a0
Author:    schien
Date:      2011-06-27 13:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6c9ac74190a0

Added tag jdk7-b147 for changeset fc268cd1dd5d

! .hgtags

Changeset: 58dfc6f729e8
Author:    schien
Date:      2011-06-27 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/58dfc6f729e8

Merge




From lana.steuck at oracle.com  Fri Jul 15 05:58:06 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 15 Jul 2011 05:58:06 +0000
Subject: hg: jdk8/tl/langtools: 6 new changesets
Message-ID: <20110715055821.BB8D847444@hg.openjdk.java.net>

Changeset: a72412b148d7
Author:    jeff
Date:      2011-06-22 10:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a72412b148d7

7057046: Add embedded license to THIRD PARTY README
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: 58bc532d6341
Author:    lana
Date:      2011-06-22 12:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58bc532d6341

Merge


Changeset: ce654f4ecfd8
Author:    schien
Date:      2011-06-27 13:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ce654f4ecfd8

Added tag jdk7-b147 for changeset 58bc532d6341

! .hgtags

Changeset: e0dec1645823
Author:    schien
Date:      2011-06-27 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e0dec1645823

Merge


Changeset: 469e3bec9b27
Author:    lana
Date:      2011-06-30 14:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/469e3bec9b27

Merge


Changeset: 025a370b9fc3
Author:    lana
Date:      2011-07-14 18:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/025a370b9fc3

Merge




From lana.steuck at oracle.com  Fri Jul 15 05:58:17 2011
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 15 Jul 2011 05:58:17 +0000
Subject: hg: jdk8/tl/jdk: 9 new changesets
Message-ID: <20110715055956.8327947445@hg.openjdk.java.net>

Changeset: cfd7602f5c52
Author:    jeff
Date:      2011-06-22 10:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfd7602f5c52

7057046: Add embedded license to THIRD PARTY README
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: f097ca2434b1
Author:    lana
Date:      2011-06-22 12:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f097ca2434b1

Merge


Changeset: 9b8c96f96a0f
Author:    schien
Date:      2011-06-27 13:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b8c96f96a0f

Added tag jdk7-b147 for changeset f097ca2434b1

! .hgtags

Changeset: fc350fd41f31
Author:    schien
Date:      2011-06-27 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc350fd41f31

Merge


Changeset: 685a01aa8cd2
Author:    prr
Date:      2011-05-25 19:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/685a01aa8cd2

7044394: TrueTypeFont inner class DirectoryEntry should be static
Reviewed-by: bae, jgodinez

! src/share/classes/sun/font/TrueTypeFont.java

Changeset: 73d420a7199b
Author:    dlila
Date:      2011-06-24 16:22 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73d420a7199b

7049339: AnyBlit is broken with non-rectangular clips.
Reviewed-by: flar

! src/share/classes/sun/java2d/loops/Blit.java
+ test/sun/java2d/loops/Bug7049339.java

Changeset: bb481604e929
Author:    lana
Date:      2011-06-30 14:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb481604e929

Merge


Changeset: 9bcf6217a374
Author:    lana
Date:      2011-06-30 14:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bcf6217a374

Merge

- src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java

Changeset: 7ac6a297f9a0
Author:    lana
Date:      2011-07-14 18:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ac6a297f9a0

Merge




From kumar.x.srinivasan at oracle.COM  Fri Jul 15 18:38:28 2011
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Fri, 15 Jul 2011 11:38:28 -0700
Subject: Easy review...rebrand issue with java launcher
Message-ID: <4E208924.6050808@oracle.COM>

Hello,

http://cr.openjdk.java.net/~ksrini/7062969/

Thanks
Kumar


From joe.darcy at oracle.com  Fri Jul 15 18:58:12 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 15 Jul 2011 11:58:12 -0700
Subject: Easy review...rebrand issue with java launcher
In-Reply-To: <4E208924.6050808@oracle.COM>
References: <4E208924.6050808@oracle.COM>
Message-ID: <4E208DC4.4050706@oracle.com>

On 7/15/2011 11:38 AM, Kumar Srinivasan wrote:
> Hello,
>
> http://cr.openjdk.java.net/~ksrini/7062969/
>
> Thanks
> Kumar

Approved.  However, I note that the new URL is different from what the 
old URL gets redirected too; just wanted to verify that was intentional.

-Joe


From jeffhain at rocketmail.com  Fri Jul 15 19:51:05 2011
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Fri, 15 Jul 2011 20:51:05 +0100 (BST)
Subject: AbstractCollection.removeAll(Collection) and
	AbstractSet.removeAll(Collection)
In-Reply-To: <SNT114-W12395A35CB863702DB114C83470@phx.gbl>
References: <1310587327.20729.YahooMailRC@web29219.mail.ird.yahoo.com>,
	<B4E6CFFE-69D9-49A6-BCDA-9108840A14B7@oracle.com>
	<SNT114-W12395A35CB863702DB114C83470@phx.gbl>
Message-ID: <1310759465.16650.YahooMailRC@web29213.mail.ird.yahoo.com>


So, it looks like bug 4266874 pointed out the same performance issue I did,
and that its fix did break things as described in bug 6394757
(Why wasn't the AbstractSet implementation removed?
Not to break performances?).

A work-around for the quadratic behavior is proposed in
discussion about bug 5028425 : "foo.removeAll(new HashSet(baz));"

The fix I proposed makes use of the faulty algorithm systematically if
"c" is not a Set, whereas as it is now it only occurs if "size() > c.size()".

Anyway, in case anyone would like to override AbstractSet.removeAll(Collection)
with it, here is a n'th version of this removeAll operation, which uses possibly 
O(n)
"isEmpty()" in less cases (not in the loop, and allowing "good garbage" 
iterators instead),
and only checks sizes if "c" is a Set:

public boolean removeAll(Collection<?> c) {
   boolean modified = false;
   if (c instanceof Set<?>) {
      // Not using "c.isEmpty()", which might be in O(n):
      // if "c" is empty, "c.size()" should be fast even if also in O(n),
      // and if "c" is not empty, we need to compute it anyway.
      final int cSize = c.size();
      if (cSize == 0) {
         return false;
      }
      final int thisSize = size();
      if (thisSize < cSize) {
         if (thisSize == 0) {
            return false;
         }
         for (Iterator<?> i = iterator(); i.hasNext(); ) {
            if (c.contains(i.next()))  {
               i.remove();
               modified = true;
            }
         }
         return modified;
      }
      // Will iterate on "c".
   } else {
      if (isEmpty()) {
         return false;
      }
   }

   // Sometimes bad (bug 6394757) but often faster.
   for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
      modified |= remove(i.next());
   }
   return modified;
}


Jeff




________________________________
De : Jason Mehrens <jason_mehrens at hotmail.com>
? : mike.duigou at oracle.com; jeffhain at rocketmail.com
Cc : core-libs-dev at openjdk.java.net
Envoy? le : Jeu 14 juillet 2011, 0h 19min 04s
Objet : RE: AbstractCollection.removeAll(Collection) and 
AbstractSet.removeAll(Collection)

 
Mike,
 
The history is in the evaluation of 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6394757
 
I don't think that even adding a empty check can be considered an optimization 
when dealing with two abstract things.  The iterator creation here is 'good 
garbage' and worst case AbstractCollection.isEmpty could be O(N).
JDKs 5 and 6 shipped with two collections (CHM views) that had O(N) isEmpty 
methods. 
 
 
I think the following evaluations really cover the issues regarding this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519662
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5028425
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6633605
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6250140
 
 
Jason
 

> Subject: Re: AbstractCollection.removeAll(Collection) and 
>AbstractSet.removeAll(Collection)
> From: mike.duigou at oracle.com
> Date: Wed, 13 Jul 2011 13:34:43 -0700
> To: jeffhain at rocketmail.com
> CC: core-libs-dev at openjdk.java.net
> 
> It looks to me that AbstractCollection could benefit from a c.isEmpty() check 
>but that's the only optimization I currently see. It's necessary to iterate the 
>target collection because values can be repeated for some collection types.
> 
> I agree that AbstractSet.removeAll appears to make a poor judgement that the 
>cost of this.contains() and c.contains() are similar. I'd like to know if there 
>are common usage patterns where iteration over c isn't the best choice. (adding 
>isEmpty() checks for both this and c of course).
> 
> Josh? Martin? Doug? Any history why AbstractSet has this optimization?
> 
> Mike
> 
> On Jul 13 2011, at 13:02 , Jeff Hain wrote:
> 
> > 
> >> It doesn't work because the complexity of size() can be O(n).
> >> In my opinion, only the checks for emptyness are Ok.
> > 
> > The calls to "size()" are already there in current implementation,
> > and I think with the idea that in most cases they are O(1).
> > If they are O(n), it's of course pointless to use them, since it
> > makes the whole treatment at least O(max(n1,n2)) (with n1 = this.size()
> > and n2 = c.size()), while simply iterating on "c" without checking
> > sizes makes it O(n2) (considering this.remove(Object) to be in O(1) (*)).
> > But, then, the whole treatment remains linear at worse, and if,
> > as it is often the case, they are O(1), it allows to make it
> > O(min(n2,n1)) if "c" is also a set.
> > Considering sizes therefore allows to have O(max(n1,n2)) instead
> > of O(n2) in rare cases, and O(min(n1,n2)) instead of O(n2) in a fair
> > amount of cases, which can be considered a win. Also, if size()'s
> > are O(n), you are most likely doing concurrency, so you are smart,
> > know what you do, and can make your own removeAll ;)
> > What seems to have been overlooked in current implementation,
> > is that this optimization, that works for sets, makes things actually
> > worse if "c" is a list, in which case it's best to always iterate on
> > "c", iterating on "this" resulting in a quadratic behavior.
> > 
> > To make things simple, and have a treatment always in O(n2),
> > we could just stick to iterating on "c" without checking sizes:
> > 
> > public boolean AbstractSet.removeAll(Collection<?> c) {
> > if (isEmpty() || c.isEmpty()) {
> > return false;
> > }
> > boolean modified = false;
> > for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
> > if (remove(i.next())) {
> > modified = true;
> > if (isEmpty()) {
> > break;
> > }
> > }
> > }
> > return modified;
> > }
> > 
> > (*) We could refine considering the case of tree sets.
> > 
> > 
> > 
> >> The overriden equals method should be no problem
> >> if the Implementation is an set. So it should be
> >> possible to exit in this case in the AbstractSet
> >> Implementation, isn't it?
> > 
> > For AbstractCollection.removeAll(Collection),
> > that wouldn't work, since each instance to remove
> > in "c" can have multiple occurrences in "this".
> > 
> > For AbstractSet.removeAll(Collection),
> > that wouldn't work either, because if "c" is
> > based on "equals", and "c" is an identity set
> > (based on "=="), multiple elements of "this"
> > could be equal to a same element of "c",
> > and removing as many as "c" contains doesn't
> > mean you can't find more elements in "this"
> > that would be equal to elements of "c".
> > 
> > A best effort implementation, that should
> > work if collections are not sets of different
> > kinds, would look like this:
> > 
> > public boolean AbstractSet.removeAll(Collection<?> c) {
> > if (isEmpty() || c.isEmpty()) {
> > return false;
> > }
> > boolean modified = false;
> > final int n1 = size();
> > final int n2 = c.size();
> > final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2;
> > if (n2 <= n1 * (long)cContainsAssumedComplexity) {
> > for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
> > if (remove(i.next())) {
> > modified = true;
> > if (isEmpty()) {
> > break;
> > }
> > }
> > }
> > } else {
> > // Here, we know "c" is a Set
> > // (else, we tested "n2 <= n1 * (long)n2",
> > // which is always true for n1 > 0 and n2 > 0).
> > if (n2 != Integer.MAX_VALUE) {
> > // Will stop iterating once
> > // we removed from "this" as
> > // many elements as "c" contains.
> > // XXX Does not work if "this" is an identity set,
> > // and "c" based on "equals".
> > int toRemove = n2;
> > for (Iterator<?> i = iterator(); i.hasNext(); ) {
> > if (c.contains(i.next())) {
> > i.remove();
> > modified = true;
> > if (--toRemove == 0) {
> > break;
> > }
> > }
> > }
> > } else {
> > // "c" might contain more than Integer.MAX_VALUE
> > // elements, so we can't break early.
> > for (Iterator<?> i = iterator(); i.hasNext(); ) {
> > if (c.contains(i.next())) {
> > i.remove();
> > modified = true;
> > }
> > }
> > }
> > }
> > return modified;
> > }
> > 
> > 
> > 
> > Jeff
> > 
> > 
> > 
> > ________________________________
> > De : R?mi Forax <forax at univ-mlv.fr>
> > ? : core-libs-dev at openjdk.java.net
> > Envoy? le : Mer 13 juillet 2011, 18h 27min 48s
> > Objet : Re: AbstractCollection.removeAll(Collection) and 
> > AbstractSet.removeAll(Collection)
> > 
> > It doesn't work because the complexity of size() can be O(n).
> > In my opinion, only the checks for emptyness are Ok.
> > 
> > R?mi
> > 
> > 
> > On 07/13/2011 05:40 PM, Sebastian Sickelmann wrote:
> >> Jeff Hain wrote:
> >>> Hello.
> >>> I have some remarks about the methods named in the subject (JDK 6u26, JDK
> >>> 7b147).
> >>> 1) AbstractCollection.removeAll(Collection)
> >>> This method could return immediately if the specified collection is
> >>> empty, not to iterate uselessly over all "this", or if "this" is empty, not 
>
> > to
> >>> create an iterator for nothing.
> >>> I also thought about returning as soon as as many elements as the
> >>> specified collection contains have been removed, but it would not behave
> >>> properly with collections containing more than Integer.MAX_VALUE elements,
> >>> or with some overriden equals methods etc.
> >> The overriden equals method should be no problem if the Implementation is an 
>
> >> set. So it should be possible to exit in this case in the AbstractSet 
> >> Implementation, isn't it?
> >> 
> >>> 2) AbstractSet.removeAll(Collection)
> >>> Let n1 be the size of "this", and n2 the size of the specified 
> > collection.
> >>> This method is in O(n1*n2) if the specified collection has a 
> >>> contains(Object)
> >>> method in O(n2) (as an ArrayList does), and n1<= n2.
> >>> I think a better implementation could be done by taking care of the
> >>> "setness" of the specified collection, and taking care of collections 
sizes
> >>> differently.
> >>> Also:
> >>> - when iterating on the specified collection, the method could return as
> >>> soon as "this" is empty, not to continue useless iterations.
> >>> - when iterating on "this", the method could return if the specified
> >>> collection is empty, not to iterate over all "this" uselessly.
> >>> 
> >>> # Current implementation:
> >>> public boolean removeAll(Collection<?> c) {
> >>> boolean modified = false;
> >>> if (size()> c.size()) {
> >>> for (Iterator<?> i = c.iterator(); i.hasNext(); )
> >>> modified |= remove(i.next());
> >>> } else {
> >>> for (Iterator<?> i = iterator(); i.hasNext(); ) {
> >>> if (c.contains(i.next())) {
> >>> i.remove();
> >>> modified = true;
> >>> }
> >>> }
> >>> }
> >>> return modified;
> >>> }
> >>> 
> >>> # Alternative implementation (not tested):public boolean
> >>> removeAll(Collection<?> c) {
> >>> // Quick check on emptinesses, to make later treatments simpler.
> >>> if (isEmpty() || c.isEmpty()) {
> >>> return false;
> >>> }
> >>> boolean modified = false;
> >>> final int n1 = size();
> >>> final int n2 = c.size();
> >>> // If the "c" is not a set, we are pessimistic about its "contains"
> >>> // method
> >>> // complexity.
> >>> final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2;
> >>> // If we iterate over "this", assumed complexity is O(n2).
> >>> // If we iterate over "c", assumed complexity is O(n1 * 
> >>> cContainsAssumedComplexity).
> >>> // Cast to long to avoid overflow.
> >>> if (n2< n1 * (long)cContainsAssumedComplexity) {
> >>> for (Iterator<?> i = c.iterator(); i.hasNext(); ) {
> >>> if (remove(i.next())) {
> >>> modified = true;
> >>> if (isEmpty()) {
> >>> break;
> >>> }
> >>> }
> >>> }
> >>> } else {
> >>> for (Iterator<?> i = iterator(); i.hasNext(); ) {
> >>> if (c.contains(i.next())) {
> >>> i.remove();
> >>> modified = true;
> >>> }
> >>> }
> >>> }
> >>> return modified;
> >>> }
> >> look good to me.
> >> 
> >>> 
> >>> 
> >>> Regards,
> >>> 
> >>> Jeff
> >>> 
> 


From kumar.x.srinivasan at oracle.COM  Fri Jul 15 21:48:32 2011
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Fri, 15 Jul 2011 14:48:32 -0700
Subject: Easy review...rebrand issue with java launcher
In-Reply-To: <4E208DC4.4050706@oracle.com>
References: <4E208924.6050808@oracle.COM> <4E208DC4.4050706@oracle.com>
Message-ID: <4E20B5B0.7010207@oracle.COM>

Updated the webrev.

http://cr.openjdk.java.net/~ksrini/7062969/webrev/

Thanks
Kumar

> On 7/15/2011 11:38 AM, Kumar Srinivasan wrote:
>> Hello,
>>
>> http://cr.openjdk.java.net/~ksrini/7062969/
>>
>> Thanks
>> Kumar
>
> Approved.  However, I note that the new URL is different from what the 
> old URL gets redirected too; just wanted to verify that was intentional.
>
> -Joe



From kelly.ohair at oracle.com  Fri Jul 15 22:50:56 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 15 Jul 2011 15:50:56 -0700
Subject: Easy review...rebrand issue with java launcher
In-Reply-To: <4E20B5B0.7010207@oracle.COM>
References: <4E208924.6050808@oracle.COM> <4E208DC4.4050706@oracle.com>
	<4E20B5B0.7010207@oracle.COM>
Message-ID: <97134769-937B-440D-A0DE-18EBE47AF6EF@oracle.com>

Looks fine to me.

-kto

On Jul 15, 2011, at 2:48 PM, Kumar Srinivasan wrote:

> Updated the webrev.
> 
> http://cr.openjdk.java.net/~ksrini/7062969/webrev/
> 
> Thanks
> Kumar
> 
>> On 7/15/2011 11:38 AM, Kumar Srinivasan wrote:
>>> Hello,
>>> 
>>> http://cr.openjdk.java.net/~ksrini/7062969/
>>> 
>>> Thanks
>>> Kumar
>> 
>> Approved.  However, I note that the new URL is different from what the old URL gets redirected too; just wanted to verify that was intentional.
>> 
>> -Joe
> 



From kumar.x.srinivasan at oracle.com  Fri Jul 15 23:39:42 2011
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Fri, 15 Jul 2011 23:39:42 +0000
Subject: hg: jdk8/tl/jdk: 7062969: java -help still shows
	http://java.sun.com/javase/reference
Message-ID: <20110715234004.08B6447477@hg.openjdk.java.net>

Changeset: c0c983ca797b
Author:    ksrini
Date:      2011-07-15 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0c983ca797b

7062969: java -help still shows http://java.sun.com/javase/reference
Reviewed-by: ohair, darcy

! src/share/classes/sun/launcher/resources/launcher.properties



From stuart.marks at oracle.com  Sat Jul 16 00:16:57 2011
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 15 Jul 2011 17:16:57 -0700
Subject: JDK 8 code review request for 7062430 "Minor iconsistency in
	ulp descriptions"
In-Reply-To: <4E1F9485.9070100@oracle.com>
References: <4E1F9485.9070100@oracle.com>
Message-ID: <4E20D879.4040500@oracle.com>

The changes look fine.

If the text from the bug synopsis is used in the changeset comment, 
"iconsistency" should be corrected to "inconsistency". And maybe the bug 
synopsis itself should be fixed too.

s'marks

On 7/14/11 6:14 PM, Joe Darcy wrote:
> Hello.
>
> Please review this small doc change to spell out what "ulp" means in the
> methods named "ulp" in the Math and StrictMath classes; patch below, webrev at:
>
> 7062430 "Minor iconsistency in ulp descriptions"
> http://cr.openjdk.java.net/~darcy/7062430.0/
>
> Due to paragraph reformatting, the change takes up many more physical lines
> than logical ones. In each of the four ulp methods (for for float and one for
> double in each of Math and StrictMath) the phrase
>
> "An ulp of a [...] value is the positive distance..."
>
> is replaced with
>
> "An ulp, unit in the last place, of a [...] value is the positive distance..."
>
> Additionally, the reference to ulp in one the opening paragraphs of the Math
> class description is replaced with a link to one of the ulp methods in Math.
>
> Thanks,
>
> -Joe
>
> --- old/src/share/classes/java/lang/Math.java 2011-07-14 18:07:17.000000000 -0700
> +++ new/src/share/classes/java/lang/Math.java 2011-07-14 18:07:17.000000000 -0700
> @@ -50,34 +50,34 @@
> *
> * <p>The quality of implementation specifications concern two
> * properties, accuracy of the returned result and monotonicity of the
> - * method. Accuracy of the floating-point {@code Math} methods
> - * is measured in terms of <i>ulps</i>, units in the last place. For
> - * a given floating-point format, an ulp of a specific real number
> - * value is the distance between the two floating-point values
> - * bracketing that numerical value. When discussing the accuracy of a
> - * method as a whole rather than at a specific argument, the number of
> - * ulps cited is for the worst-case error at any argument. If a
> - * method always has an error less than 0.5 ulps, the method always
> - * returns the floating-point number nearest the exact result; such a
> - * method is <i>correctly rounded</i>. A correctly rounded method is
> - * generally the best a floating-point approximation can be; however,
> - * it is impractical for many floating-point methods to be correctly
> - * rounded. Instead, for the {@code Math} class, a larger error
> - * bound of 1 or 2 ulps is allowed for certain methods. Informally,
> - * with a 1 ulp error bound, when the exact result is a representable
> - * number, the exact result should be returned as the computed result;
> - * otherwise, either of the two floating-point values which bracket
> - * the exact result may be returned. For exact results large in
> - * magnitude, one of the endpoints of the bracket may be infinite.
> - * Besides accuracy at individual arguments, maintaining proper
> - * relations between the method at different arguments is also
> - * important. Therefore, most methods with more than 0.5 ulp errors
> - * are required to be <i>semi-monotonic</i>: whenever the mathematical
> - * function is non-decreasing, so is the floating-point approximation,
> - * likewise, whenever the mathematical function is non-increasing, so
> - * is the floating-point approximation. Not all approximations that
> - * have 1 ulp accuracy will automatically meet the monotonicity
> - * requirements.
> + * method. Accuracy of the floating-point {@code Math} methods is
> + * measured in terms of <i>ulps</i>, units in the last place. For a
> + * given floating-point format, an {@linkplain #ulp(double) ulp} of a
> + * specific real number value is the distance between the two
> + * floating-point values bracketing that numerical value. When
> + * discussing the accuracy of a method as a whole rather than at a
> + * specific argument, the number of ulps cited is for the worst-case
> + * error at any argument. If a method always has an error less than
> + * 0.5 ulps, the method always returns the floating-point number
> + * nearest the exact result; such a method is <i>correctly
> + * rounded</i>. A correctly rounded method is generally the best a
> + * floating-point approximation can be; however, it is impractical for
> + * many floating-point methods to be correctly rounded. Instead, for
> + * the {@code Math} class, a larger error bound of 1 or 2 ulps is
> + * allowed for certain methods. Informally, with a 1 ulp error bound,
> + * when the exact result is a representable number, the exact result
> + * should be returned as the computed result; otherwise, either of the
> + * two floating-point values which bracket the exact result may be
> + * returned. For exact results large in magnitude, one of the
> + * endpoints of the bracket may be infinite. Besides accuracy at
> + * individual arguments, maintaining proper relations between the
> + * method at different arguments is also important. Therefore, most
> + * methods with more than 0.5 ulp errors are required to be
> + * <i>semi-monotonic</i>: whenever the mathematical function is
> + * non-decreasing, so is the floating-point approximation, likewise,
> + * whenever the mathematical function is non-increasing, so is the
> + * floating-point approximation. Not all approximations that have 1
> + * ulp accuracy will automatically meet the monotonicity requirements.
> *
> * @author unascribed
> * @author Joseph D. Darcy
> @@ -940,11 +940,11 @@
> }
>
> /**
> - * Returns the size of an ulp of the argument. An ulp of a
> - * {@code double} value is the positive distance between this
> - * floating-point value and the {@code double} value next
> - * larger in magnitude. Note that for non-NaN <i>x</i>,
> - * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> + * Returns the size of an ulp of the argument. An ulp, unit in
> + * the last place, of a {@code double} value is the positive
> + * distance between this floating-point value and the {@code
> + * double} value next larger in magnitude. Note that for non-NaN
> + * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> *
> * <p>Special Cases:
> * <ul>
> @@ -967,11 +967,11 @@
> }
>
> /**
> - * Returns the size of an ulp of the argument. An ulp of a
> - * {@code float} value is the positive distance between this
> - * floating-point value and the {@code float} value next
> - * larger in magnitude. Note that for non-NaN <i>x</i>,
> - * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> + * Returns the size of an ulp of the argument. An ulp, unit in
> + * the last place, of a {@code float} value is the positive
> + * distance between this floating-point value and the {@code
> + * float} value next larger in magnitude. Note that for non-NaN
> + * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> *
> * <p>Special Cases:
> * <ul>
> --- old/src/share/classes/java/lang/StrictMath.java 2011-07-14
> 18:07:18.000000000 -0700
> +++ new/src/share/classes/java/lang/StrictMath.java 2011-07-14
> 18:07:18.000000000 -0700
> @@ -932,11 +932,11 @@
> }
>
> /**
> - * Returns the size of an ulp of the argument. An ulp of a
> - * {@code double} value is the positive distance between this
> - * floating-point value and the {@code double} value next
> - * larger in magnitude. Note that for non-NaN <i>x</i>,
> - * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> + * Returns the size of an ulp of the argument. An ulp, unit in
> + * the last place, of a {@code double} value is the positive
> + * distance between this floating-point value and the {@code
> + * double} value next larger in magnitude. Note that for non-NaN
> + * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> *
> * <p>Special Cases:
> * <ul>
> @@ -959,11 +959,11 @@
> }
>
> /**
> - * Returns the size of an ulp of the argument. An ulp of a
> - * {@code float} value is the positive distance between this
> - * floating-point value and the {@code float} value next
> - * larger in magnitude. Note that for non-NaN <i>x</i>,
> - * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> + * Returns the size of an ulp of the argument. An ulp, unit in
> + * the last place, of a {@code float} value is the positive
> + * distance between this floating-point value and the {@code
> + * float} value next larger in magnitude. Note that for non-NaN
> + * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> *
> * <p>Special Cases:
> * <ul>
>


From pcj at roundroom.net  Sat Jul 16 06:04:55 2011
From: pcj at roundroom.net (Peter Jones)
Date: Sat, 16 Jul 2011 02:04:55 -0400
Subject: JDK 8 code review request for 7007535: (reflect) Please
	generalize Constructor and Method
In-Reply-To: <4E1FD4EA.4090800@oracle.com>
References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com>
Message-ID: <62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>

Hi Joe,

On Jul 15, 2011, at 1:49 AM, David Holmes wrote:
> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
>> Please code review my JDK 8 changes for
>> 
>> 7007535: (reflect) Please generalize Constructor and Method
>> http://cr.openjdk.java.net/~darcy/7007535.3
>> 
>> To summarize the changes, a new superclass is defined to capture the common
>> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor.
>> That superclass is named "Executable" along the lines of
>> javax.lang.model.ExecutableElement, which models constructors and methods in
>> the JSR 269 language model.
>> 
>> Both specification and implementation code are shared. To preserve the right
>> @since behavior, it is common that in Method/Constructor the javadoc for a
>> method will now look like:
>> 
>> /**
>> * {@inheritDoc}
>> * @since 1.5
>> */
> 
> Unless they have fixed/changed javadoc (entirely possible) it used to be that the above would not cause @throws declarations for unchecked exceptions to be inherited - you have/had to explicitly repeat them as:
> 
> @throws <exception-type> {@inheritDoc}

Yes, that would seem to be needed for some of the inherited getters of generics info, which specify unchecked exception types.

>> Since Executable is being created in JDK 8, it would be incorrect for
>> methods in that class to have an @since of 1.5; adding the @since in
>> Method/Constructor preserves the right information.

In Executable.java, getAnnotation and getDeclaredAnnotations do have "@since 1.5"-- oversight?

In Constructor.java and Method.java, getExceptionTypes has "@since 1.5", but that method has existed in those classes since 1.1.

In Executable.java:

 216     /**
 217      * Returns an array of {@code Class} objects that represent the formal
 218      * parameter types, in declaration order, of the method
 219      * represented by this {@code Method} object.  Returns an array of length
 220      * 0 if the underlying method takes no parameters.
 221      *
 222      * @return the parameter types for the method this object
 223      * represents

At least "{@code Method}" needs to be generalized, and perhaps all occurrences of "method"?

Cheers,

-- Peter



From Alan.Bateman at oracle.com  Sat Jul 16 06:21:55 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 16 Jul 2011 07:21:55 +0100
Subject: JDK 8 code review request for 7062430 "Minor iconsistency in
	ulp descriptions"
In-Reply-To: <4E1F9485.9070100@oracle.com>
References: <4E1F9485.9070100@oracle.com>
Message-ID: <4E212E03.7090907@oracle.com>

Joe Darcy wrote:
> Hello.
>
> Please review this small doc change to spell out what "ulp" means in 
> the methods named "ulp" in the Math and StrictMath classes; patch 
> below, webrev at:
>
>    7062430 "Minor iconsistency in ulp descriptions"
>    http://cr.openjdk.java.net/~darcy/7062430.0/
>
> Due to paragraph reformatting, the change takes up many more physical 
> lines than logical ones.  In each of the four ulp methods (for for 
> float and one for double in each of Math and StrictMath) the phrase
>
>    "An ulp of a [...] value is the positive distance..."
>
> is replaced with
>
>    "An ulp, unit in the last place, of a [...] value is the positive 
> distance..."
>
> Additionally, the reference to ulp in one the opening paragraphs of 
> the Math class description is replaced with a link to one of the ulp 
> methods in Math.
This looks fine to me too.

-Alan.


From Alan.Bateman at oracle.com  Sat Jul 16 18:31:48 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 16 Jul 2011 19:31:48 +0100
Subject: Update to jdk/test/ProblemList.txt
Message-ID: <4E21D914.2000406@oracle.com>


I need a reviewer to update the ProblemList.txt file for jdk8. The patch 
adds several tests that are failing intermittently on various platforms 
due to timing issues in the tests (bugs are submitted for each of the 
issues). One java.util and two j.u.c tests are removed from the file as 
they are no longer issues (as far as I can tell, at least one of them 
was a hotspot bug that was fixed a long time ago).

Thanks,
-Alan.


diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -349,9 +349,18 @@ javax/print/attribute/AttributeTest.java
 # Only print test left, excluding just because all print tests have been
 javax/print/attribute/MediaMappingsTest.java                   generic-all
 
+# Filed 7058852
+javax/sound/sampled/FileWriter/AlawEncoderSync.java            generic-all
+
 ############################################################################
 
 # jdk_net
+
+# Filed 7052625
+com/sun/net/httpserver/bugs/6725892/Test.java                  generic-all
+
+# Filed 7036666
+com/sun/net/httpserver/Test9a.java                             generic-all
 
 ############################################################################
 
@@ -605,6 +614,18 @@ 
java/text/Bidi/Bug6665028.java                                     linu
 # Filed 6952105
 com/sun/jdi/SuspendThreadTest.java                             generic-all
 
+# Filed 6653793
+com/sun/jdi/RedefineCrossEvent.java                            generic-all
+
+# Filed 6987312
+com/sun/jdi/DoubleAgentTest.java                               generic-all
+
+# Filed 7020857
+com/sun/jdi/FieldWatchpoints.java                              generic-all
+
+# Filed 6402201
+com/sun/jdi/ProcessAttachTest.sh                               generic-all
+
 # Filed 6986875
 sun/tools/jps/jps-Vvml.sh                                      generic-all
 
@@ -626,18 +647,8 @@ java/util/concurrent/ThreadPoolExecutor/
 #   11 separate stacktraces created... file reuse problem?
 java/util/zip/ZipFile/ReadLongZipFileName.java                 generic-all
 
-# Assert error, failures, on Linux Fedora 9 -server
-#   Windows samevm failure, assert error "Passed = 134, failed = 2"
-java/util/Arrays/ArrayObjectMethods.java                       generic-all
-
-# Windows 2000, -client, samevm, java.lang.Error: Completed != 2
+# Filed 6772009
 java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java 
generic-all
-
-# Windows X64, Executor Stuck samevm mode:
-java/util/concurrent/FutureTask/BlockingTaskExecutor.java      generic-all
-
-# Problems on windows, jmap.exe hangs? (these run jmap), fails on 
Solaris 10 x86
-java/util/concurrent/locks/Lock/TimedAcquireLeak.java          generic-all
 
 ############################################################################



From mandy.chung at oracle.com  Sun Jul 17 07:37:59 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sun, 17 Jul 2011 15:37:59 +0800
Subject: Update to jdk/test/ProblemList.txt
In-Reply-To: <4E21D914.2000406@oracle.com>
References: <4E21D914.2000406@oracle.com>
Message-ID: <4E229157.7000904@oracle.com>

  On 7/17/11 2:31 AM, Alan Bateman wrote:
>
> I need a reviewer to update the ProblemList.txt file for jdk8. The 
> patch adds several tests that are failing intermittently on various 
> platforms due to timing issues in the tests (bugs are submitted for 
> each of the issues). One java.util and two j.u.c tests are removed 
> from the file as they are no longer issues (as far as I can tell, at 
> least one of them was a hotspot bug that was fixed a long time ago).
>
Looks good to me.

Mandy


From joe.darcy at oracle.com  Mon Jul 18 01:54:02 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Mon, 18 Jul 2011 01:54:02 +0000
Subject: hg: jdk8/tl/jdk: 7062430: Minor inconsistency in ulp descriptions
Message-ID: <20110718015423.68BC1474E3@hg.openjdk.java.net>

Changeset: d987f8738096
Author:    darcy
Date:      2011-07-17 18:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d987f8738096

7062430: Minor inconsistency in ulp descriptions
Reviewed-by: smarks, alanb

! src/share/classes/java/lang/Math.java
! src/share/classes/java/lang/StrictMath.java



From joe.darcy at oracle.com  Mon Jul 18 07:51:04 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 18 Jul 2011 00:51:04 -0700
Subject: JDK 8 code review request for 7007535: (reflect) Please generalize
	Constructor and Method
In-Reply-To: <62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>
References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com>
	<62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>
Message-ID: <4E23E5E8.4010507@oracle.com>

Peter and David.

Thanks for the careful review; the @throws information still needs its 
own {@inheritDoc}; I've uploaded a webrev with this and other corrections:

http://cr.openjdk.java.net/~darcy/7007535.4

More comments interspersed below.

Thanks,

-Joe

Peter Jones wrote:
> Hi Joe,
>
> On Jul 15, 2011, at 1:49 AM, David Holmes wrote:
>   
>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
>>     
>>> Please code review my JDK 8 changes for
>>>
>>> 7007535: (reflect) Please generalize Constructor and Method
>>> http://cr.openjdk.java.net/~darcy/7007535.3
>>>
>>> To summarize the changes, a new superclass is defined to capture the common
>>> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor.
>>> That superclass is named "Executable" along the lines of
>>> javax.lang.model.ExecutableElement, which models constructors and methods in
>>> the JSR 269 language model.
>>>
>>> Both specification and implementation code are shared. To preserve the right
>>> @since behavior, it is common that in Method/Constructor the javadoc for a
>>> method will now look like:
>>>
>>> /**
>>> * {@inheritDoc}
>>> * @since 1.5
>>> */
>>>       
>> Unless they have fixed/changed javadoc (entirely possible) it used to be that the above would not cause @throws declarations for unchecked exceptions to be inherited - you have/had to explicitly repeat them as:
>>
>> @throws <exception-type> {@inheritDoc}
>>     
>
> Yes, that would seem to be needed for some of the inherited getters of generics info, which specify unchecked exception types.
>
>   
>>> Since Executable is being created in JDK 8, it would be incorrect for
>>> methods in that class to have an @since of 1.5; adding the @since in
>>> Method/Constructor preserves the right information.
>>>       
>
> In Executable.java, getAnnotation and getDeclaredAnnotations do have "@since 1.5"-- oversight?
>   

Yes; that was incorrect.

> In Constructor.java and Method.java, getExceptionTypes has "@since 1.5", but that method has existed in those classes since 1.1.
>
>   
Fixed.

> In Executable.java:
>
>  216     /**
>  217      * Returns an array of {@code Class} objects that represent the formal
>  218      * parameter types, in declaration order, of the method
>  219      * represented by this {@code Method} object.  Returns an array of length
>  220      * 0 if the underlying method takes no parameters.
>  221      *
>  222      * @return the parameter types for the method this object
>  223      * represents
>
> At least "{@code Method}" needs to be generalized, and perhaps all occurrences of "method"?
>   
Corrected.


From chris.hegarty at oracle.com  Mon Jul 18 09:08:15 2011
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 18 Jul 2011 10:08:15 +0100
Subject: Update to jdk/test/ProblemList.txt
In-Reply-To: <4E21D914.2000406@oracle.com>
References: <4E21D914.2000406@oracle.com>
Message-ID: <4E23F7FF.5080100@oracle.com>

Looks ok to me.

-Chris.

On 07/16/11 07:31 PM, Alan Bateman wrote:
>
> I need a reviewer to update the ProblemList.txt file for jdk8. The patch
> adds several tests that are failing intermittently on various platforms
> due to timing issues in the tests (bugs are submitted for each of the
> issues). One java.util and two j.u.c tests are removed from the file as
> they are no longer issues (as far as I can tell, at least one of them
> was a hotspot bug that was fixed a long time ago).
>
> Thanks,
> -Alan.
>
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -349,9 +349,18 @@ javax/print/attribute/AttributeTest.java
> # Only print test left, excluding just because all print tests have been
> javax/print/attribute/MediaMappingsTest.java generic-all
>
> +# Filed 7058852
> +javax/sound/sampled/FileWriter/AlawEncoderSync.java generic-all
> +
> ############################################################################
>
>
> # jdk_net
> +
> +# Filed 7052625
> +com/sun/net/httpserver/bugs/6725892/Test.java generic-all
> +
> +# Filed 7036666
> +com/sun/net/httpserver/Test9a.java generic-all
>
> ############################################################################
>
>
> @@ -605,6 +614,18 @@ java/text/Bidi/Bug6665028.java linu
> # Filed 6952105
> com/sun/jdi/SuspendThreadTest.java generic-all
>
> +# Filed 6653793
> +com/sun/jdi/RedefineCrossEvent.java generic-all
> +
> +# Filed 6987312
> +com/sun/jdi/DoubleAgentTest.java generic-all
> +
> +# Filed 7020857
> +com/sun/jdi/FieldWatchpoints.java generic-all
> +
> +# Filed 6402201
> +com/sun/jdi/ProcessAttachTest.sh generic-all
> +
> # Filed 6986875
> sun/tools/jps/jps-Vvml.sh generic-all
>
> @@ -626,18 +647,8 @@ java/util/concurrent/ThreadPoolExecutor/
> # 11 separate stacktraces created... file reuse problem?
> java/util/zip/ZipFile/ReadLongZipFileName.java generic-all
>
> -# Assert error, failures, on Linux Fedora 9 -server
> -# Windows samevm failure, assert error "Passed = 134, failed = 2"
> -java/util/Arrays/ArrayObjectMethods.java generic-all
> -
> -# Windows 2000, -client, samevm, java.lang.Error: Completed != 2
> +# Filed 6772009
> java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
> generic-all
> -
> -# Windows X64, Executor Stuck samevm mode:
> -java/util/concurrent/FutureTask/BlockingTaskExecutor.java generic-all
> -
> -# Problems on windows, jmap.exe hangs? (these run jmap), fails on
> Solaris 10 x86
> -java/util/concurrent/locks/Lock/TimedAcquireLeak.java generic-all
>
> ############################################################################
>
>


From David.Holmes at oracle.com  Mon Jul 18 10:44:29 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 18 Jul 2011 20:44:29 +1000
Subject: JDK 8 code review request for 7007535: (reflect) Please generalize
	Constructor and Method
In-Reply-To: <4E23E5E8.4010507@oracle.com>
References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com>
	<62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>
	<4E23E5E8.4010507@oracle.com>
Message-ID: <4E240E8D.2090906@oracle.com>

Hi Joe,

Seems okay. Can you use blenderrev (or specdiff or some other tool) to 
actually compare the generated javadoc output?

One stylistic comment. The {@inheritDoc} in the main comment block of 
each method is superfluous as the default behaviour is to inherit those 
javadoc attributes ie this:

     /**
      * {@inheritDoc}
      */

is unnecessary, and this:

     /**
       * {@inheritDoc}
       * @throws GenericSignatureFormatError {@inheritDoc}
       * @since 1.5
       */

is equivalent to:

     /**
       * @throws GenericSignatureFormatError {@inheritDoc}
       * @since 1.5
       */

Cheers,
David

Joe Darcy said the following on 07/18/11 17:51:
> Peter and David.
> 
> Thanks for the careful review; the @throws information still needs its 
> own {@inheritDoc}; I've uploaded a webrev with this and other corrections:
> 
> http://cr.openjdk.java.net/~darcy/7007535.4
> 
> More comments interspersed below.
> 
> Thanks,
> 
> -Joe
> 
> Peter Jones wrote:
>> Hi Joe,
>>
>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote:
>>  
>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
>>>    
>>>> Please code review my JDK 8 changes for
>>>>
>>>> 7007535: (reflect) Please generalize Constructor and Method
>>>> http://cr.openjdk.java.net/~darcy/7007535.3
>>>>
>>>> To summarize the changes, a new superclass is defined to capture the 
>>>> common
>>>> functionality of java.lang.reflect.Method and 
>>>> java.lang.reflect.Constructor.
>>>> That superclass is named "Executable" along the lines of
>>>> javax.lang.model.ExecutableElement, which models constructors and 
>>>> methods in
>>>> the JSR 269 language model.
>>>>
>>>> Both specification and implementation code are shared. To preserve 
>>>> the right
>>>> @since behavior, it is common that in Method/Constructor the javadoc 
>>>> for a
>>>> method will now look like:
>>>>
>>>> /**
>>>> * {@inheritDoc}
>>>> * @since 1.5
>>>> */
>>>>       
>>> Unless they have fixed/changed javadoc (entirely possible) it used to 
>>> be that the above would not cause @throws declarations for unchecked 
>>> exceptions to be inherited - you have/had to explicitly repeat them as:
>>>
>>> @throws <exception-type> {@inheritDoc}
>>>     
>>
>> Yes, that would seem to be needed for some of the inherited getters of 
>> generics info, which specify unchecked exception types.
>>
>>  
>>>> Since Executable is being created in JDK 8, it would be incorrect for
>>>> methods in that class to have an @since of 1.5; adding the @since in
>>>> Method/Constructor preserves the right information.
>>>>       
>>
>> In Executable.java, getAnnotation and getDeclaredAnnotations do have 
>> "@since 1.5"-- oversight?
>>   
> 
> Yes; that was incorrect.
> 
>> In Constructor.java and Method.java, getExceptionTypes has "@since 
>> 1.5", but that method has existed in those classes since 1.1.
>>
>>   
> Fixed.
> 
>> In Executable.java:
>>
>>  216     /**
>>  217      * Returns an array of {@code Class} objects that represent 
>> the formal
>>  218      * parameter types, in declaration order, of the method
>>  219      * represented by this {@code Method} object.  Returns an 
>> array of length
>>  220      * 0 if the underlying method takes no parameters.
>>  221      *
>>  222      * @return the parameter types for the method this object
>>  223      * represents
>>
>> At least "{@code Method}" needs to be generalized, and perhaps all 
>> occurrences of "method"?
>>   
> Corrected.


From alan.bateman at oracle.com  Mon Jul 18 12:12:29 2011
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 18 Jul 2011 12:12:29 +0000
Subject: hg: jdk8/tl/jdk: 7068059: Update jdk/test/ProblemList.txt
Message-ID: <20110718121251.4A28B474F8@hg.openjdk.java.net>

Changeset: cbfc7f910af3
Author:    alanb
Date:      2011-07-18 13:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cbfc7f910af3

7068059: Update jdk/test/ProblemList.txt
Reviewed-by: mchung, chegar

! test/ProblemList.txt



From mike.duigou at oracle.com  Mon Jul 18 20:35:33 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 18 Jul 2011 13:35:33 -0700
Subject: JDK 8 code review request for 7062430 "Minor iconsistency in ulp
	descriptions"
In-Reply-To: <4E1F9485.9070100@oracle.com>
References: <4E1F9485.9070100@oracle.com>
Message-ID: <2E9EBB89-75B7-4A69-B6BD-6E662B9CBE5C@oracle.com>

Perhaps a linkplain from the method javadoc to an anchor in the Math class javadoc could be added so that an explanation for the added definition is available.

Mike

On Jul 14 2011, at 18:14 , Joe Darcy wrote:

> Hello.
> 
> Please review this small doc change to spell out what "ulp" means in the methods named "ulp" in the Math and StrictMath classes; patch below, webrev at:
> 
>   7062430 "Minor iconsistency in ulp descriptions"
>   http://cr.openjdk.java.net/~darcy/7062430.0/
> 
> Due to paragraph reformatting, the change takes up many more physical lines than logical ones.  In each of the four ulp methods (for for float and one for double in each of Math and StrictMath) the phrase
> 
>   "An ulp of a [...] value is the positive distance..."
> 
> is replaced with
> 
>   "An ulp, unit in the last place, of a [...] value is the positive distance..."
> 
> Additionally, the reference to ulp in one the opening paragraphs of the Math class description is replaced with a link to one of the ulp methods in Math.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/share/classes/java/lang/Math.java    2011-07-14 18:07:17.000000000 -0700
> +++ new/src/share/classes/java/lang/Math.java    2011-07-14 18:07:17.000000000 -0700
> @@ -50,34 +50,34 @@
> *
> * <p>The quality of implementation specifications concern two
> * properties, accuracy of the returned result and monotonicity of the
> - * method.  Accuracy of the floating-point {@code Math} methods
> - * is measured in terms of <i>ulps</i>, units in the last place.  For
> - * a given floating-point format, an ulp of a specific real number
> - * value is the distance between the two floating-point values
> - * bracketing that numerical value.  When discussing the accuracy of a
> - * method as a whole rather than at a specific argument, the number of
> - * ulps cited is for the worst-case error at any argument.  If a
> - * method always has an error less than 0.5 ulps, the method always
> - * returns the floating-point number nearest the exact result; such a
> - * method is <i>correctly rounded</i>.  A correctly rounded method is
> - * generally the best a floating-point approximation can be; however,
> - * it is impractical for many floating-point methods to be correctly
> - * rounded.  Instead, for the {@code Math} class, a larger error
> - * bound of 1 or 2 ulps is allowed for certain methods.  Informally,
> - * with a 1 ulp error bound, when the exact result is a representable
> - * number, the exact result should be returned as the computed result;
> - * otherwise, either of the two floating-point values which bracket
> - * the exact result may be returned.  For exact results large in
> - * magnitude, one of the endpoints of the bracket may be infinite.
> - * Besides accuracy at individual arguments, maintaining proper
> - * relations between the method at different arguments is also
> - * important.  Therefore, most methods with more than 0.5 ulp errors
> - * are required to be <i>semi-monotonic</i>: whenever the mathematical
> - * function is non-decreasing, so is the floating-point approximation,
> - * likewise, whenever the mathematical function is non-increasing, so
> - * is the floating-point approximation.  Not all approximations that
> - * have 1 ulp accuracy will automatically meet the monotonicity
> - * requirements.
> + * method.  Accuracy of the floating-point {@code Math} methods is
> + * measured in terms of <i>ulps</i>, units in the last place.  For a
> + * given floating-point format, an {@linkplain #ulp(double) ulp} of a
> + * specific real number value is the distance between the two
> + * floating-point values bracketing that numerical value.  When
> + * discussing the accuracy of a method as a whole rather than at a
> + * specific argument, the number of ulps cited is for the worst-case
> + * error at any argument.  If a method always has an error less than
> + * 0.5 ulps, the method always returns the floating-point number
> + * nearest the exact result; such a method is <i>correctly
> + * rounded</i>.  A correctly rounded method is generally the best a
> + * floating-point approximation can be; however, it is impractical for
> + * many floating-point methods to be correctly rounded.  Instead, for
> + * the {@code Math} class, a larger error bound of 1 or 2 ulps is
> + * allowed for certain methods.  Informally, with a 1 ulp error bound,
> + * when the exact result is a representable number, the exact result
> + * should be returned as the computed result; otherwise, either of the
> + * two floating-point values which bracket the exact result may be
> + * returned.  For exact results large in magnitude, one of the
> + * endpoints of the bracket may be infinite.  Besides accuracy at
> + * individual arguments, maintaining proper relations between the
> + * method at different arguments is also important.  Therefore, most
> + * methods with more than 0.5 ulp errors are required to be
> + * <i>semi-monotonic</i>: whenever the mathematical function is
> + * non-decreasing, so is the floating-point approximation, likewise,
> + * whenever the mathematical function is non-increasing, so is the
> + * floating-point approximation.  Not all approximations that have 1
> + * ulp accuracy will automatically meet the monotonicity requirements.
> *
> * @author  unascribed
> * @author  Joseph D. Darcy
> @@ -940,11 +940,11 @@
>    }
>    /**
> -     * Returns the size of an ulp of the argument.  An ulp of a
> -     * {@code double} value is the positive distance between this
> -     * floating-point value and the {@code double} value next
> -     * larger in magnitude.  Note that for non-NaN <i>x</i>,
> -     * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> +     * Returns the size of an ulp of the argument.  An ulp, unit in
> +     * the last place, of a {@code double} value is the positive
> +     * distance between this floating-point value and the {@code
> +     * double} value next larger in magnitude.  Note that for non-NaN
> +     * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
>     *
>     * <p>Special Cases:
>     * <ul>
> @@ -967,11 +967,11 @@
>    }
>    /**
> -     * Returns the size of an ulp of the argument.  An ulp of a
> -     * {@code float} value is the positive distance between this
> -     * floating-point value and the {@code float} value next
> -     * larger in magnitude.  Note that for non-NaN <i>x</i>,
> -     * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> +     * Returns the size of an ulp of the argument.  An ulp, unit in
> +     * the last place, of a {@code float} value is the positive
> +     * distance between this floating-point value and the {@code
> +     * float} value next larger in magnitude.  Note that for non-NaN
> +     * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
>     *
>     * <p>Special Cases:
>     * <ul>
> --- old/src/share/classes/java/lang/StrictMath.java    2011-07-14 18:07:18.000000000 -0700
> +++ new/src/share/classes/java/lang/StrictMath.java    2011-07-14 18:07:18.000000000 -0700
> @@ -932,11 +932,11 @@
>    }
>    /**
> -     * Returns the size of an ulp of the argument.  An ulp of a
> -     * {@code double} value is the positive distance between this
> -     * floating-point value and the {@code double} value next
> -     * larger in magnitude.  Note that for non-NaN <i>x</i>,
> -     * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> +     * Returns the size of an ulp of the argument.  An ulp, unit in
> +     * the last place, of a {@code double} value is the positive
> +     * distance between this floating-point value and the {@code
> +     * double} value next larger in magnitude.  Note that for non-NaN
> +     * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
>     *
>     * <p>Special Cases:
>     * <ul>
> @@ -959,11 +959,11 @@
>    }
>    /**
> -     * Returns the size of an ulp of the argument.  An ulp of a
> -     * {@code float} value is the positive distance between this
> -     * floating-point value and the {@code float} value next
> -     * larger in magnitude.  Note that for non-NaN <i>x</i>,
> -     * <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
> +     * Returns the size of an ulp of the argument.  An ulp, unit in
> +     * the last place, of a {@code float} value is the positive
> +     * distance between this floating-point value and the {@code
> +     * float} value next larger in magnitude.  Note that for non-NaN
> +     * <i>x</i>, <code>ulp(-<i>x</i>) == ulp(<i>x</i>)</code>.
>     *
>     * <p>Special Cases:
>     * <ul>
> 



From chris.hegarty at oracle.com  Mon Jul 18 21:31:13 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 18 Jul 2011 21:31:13 +0000
Subject: hg: jdk8/tl/jdk: 7021280: SocketPermission should accept wildcards
Message-ID: <20110718213131.DE79247511@hg.openjdk.java.net>

Changeset: 8bbea505b060
Author:    chegar
Date:      2011-07-18 22:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8bbea505b060

7021280: SocketPermission should accept wildcards
Reviewed-by: michaelm

! src/share/classes/java/net/SocketPermission.java
+ test/java/net/SocketPermission/Wildcard.java



From spoole at linux.vnet.ibm.com  Mon Jul 18 21:37:19 2011
From: spoole at linux.vnet.ibm.com (Steve Poole)
Date: Mon, 18 Jul 2011 22:37:19 +0100
Subject: FontConfig fails when optional system library is missing
Message-ID: <4E24A78F.40605@linux.vnet.ibm.com>


Hi all, a problem was discovered on JDK7 when using the Nimbus L&F on a 
system where libfontconfig.so was not installed (On AIX actually but in 
theory on any unix system)

Under the covers Nimbus uses the sun.font.FontConfigManager to retrieve 
fonts. sun.font.FontConfigManager in turn is intended to use (for a unix 
system) the libfontconfig.so system library if present.

The code is intended to cope with the library being missing but it 
unfortunately doesn't. A array is referenced without checking if it is 
null. On systems where the system library is present this array is never 
null but in this specific case the array is null and the reference fails 
as follows.

?
Exception in thread "main" java.lang.NullPointerException
at sun.font.FontConfigManager.getFontConfigFont(FontConfigManager.java:352)
at sun.awt.X11FontManager.getFontConfigFUIR(X11FontManager.java:817)
at sun.font.FontUtilities.getFontConfigFUIR(FontUtilities.java:472)
at javax.swing.plaf.nimbus.NimbusDefaults.<init>(NimbusDefaults.java:138)
at 
javax.swing.plaf.nimbus.NimbusLookAndFeel.<init>(NimbusLookAndFeel.java:100)
at Nimbus.main(Nimbus.java:6)
?

The fix is trivial (see attached) and probably just tactical.


Cheers,

Steve


From kumar.x.srinivasan at oracle.COM  Mon Jul 18 21:48:56 2011
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Mon, 18 Jul 2011 14:48:56 -0700
Subject: Launcher fix: 7067922, please review
Message-ID: <4E24AA48.70707@oracle.COM>

Hi,

Please review....
http://cr.openjdk.java.net/~ksrini/7067922

Thanks
Kumar



From philip.race at oracle.com  Mon Jul 18 22:12:56 2011
From: philip.race at oracle.com (Phil Race)
Date: Mon, 18 Jul 2011 15:12:56 -0700
Subject: FontConfig fails when optional system library is missing
In-Reply-To: <4E24A78F.40605@linux.vnet.ibm.com>
References: <4E24A78F.40605@linux.vnet.ibm.com>
Message-ID: <4E24AFE8.5030102@oracle.com>

Steve,

There's no attachment .. and this should be discussed on 2d-dev, not 
core-libs.

I do see in the code where the null de-ref can happen. This is some new 
JDK 7 code.
Although a system where the library is missing is basically DOA for 
client use.
I'd suspect you are running 32 bit JDK on a 64 bit Linux which hasn't had
the 32 bit libs installed. If so, likely you'll run into other problems too.

-phil.


On 7/18/2011 2:37 PM, Steve Poole wrote:
>
> Hi all, a problem was discovered on JDK7 when using the Nimbus L&F on 
> a system where libfontconfig.so was not installed (On AIX actually but 
> in theory on any unix system)
>
> Under the covers Nimbus uses the sun.font.FontConfigManager to 
> retrieve fonts. sun.font.FontConfigManager in turn is intended to use 
> (for a unix system) the libfontconfig.so system library if present.
>
> The code is intended to cope with the library being missing but it 
> unfortunately doesn't. A array is referenced without checking if it is 
> null. On systems where the system library is present this array is 
> never null but in this specific case the array is null and the 
> reference fails as follows.
>
> ?
> Exception in thread "main" java.lang.NullPointerException
> at 
> sun.font.FontConfigManager.getFontConfigFont(FontConfigManager.java:352)
> at sun.awt.X11FontManager.getFontConfigFUIR(X11FontManager.java:817)
> at sun.font.FontUtilities.getFontConfigFUIR(FontUtilities.java:472)
> at javax.swing.plaf.nimbus.NimbusDefaults.<init>(NimbusDefaults.java:138)
> at 
> javax.swing.plaf.nimbus.NimbusLookAndFeel.<init>(NimbusLookAndFeel.java:100)
> at Nimbus.main(Nimbus.java:6)
> ?
>
> The fix is trivial (see attached) and probably just tactical.
>
>
> Cheers,
>
> Steve
>



From philip.race at oracle.com  Mon Jul 18 22:14:27 2011
From: philip.race at oracle.com (Phil Race)
Date: Mon, 18 Jul 2011 15:14:27 -0700
Subject: FontConfig fails when optional system library is missing
In-Reply-To: <4E24AFE8.5030102@oracle.com>
References: <4E24A78F.40605@linux.vnet.ibm.com> <4E24AFE8.5030102@oracle.com>
Message-ID: <4E24B043.102@oracle.com>

Ah you said it was AIX, not Linux. Still,  it should have that library 
installed
even if the de-ref is fixed.

-phil.

On 7/18/2011 3:12 PM, Phil Race wrote:
> Steve,
>
> There's no attachment .. and this should be discussed on 2d-dev, not 
> core-libs.
>
> I do see in the code where the null de-ref can happen. This is some 
> new JDK 7 code.
> Although a system where the library is missing is basically DOA for 
> client use.
> I'd suspect you are running 32 bit JDK on a 64 bit Linux which hasn't had
> the 32 bit libs installed. If so, likely you'll run into other 
> problems too.
>
> -phil.
>
>
> On 7/18/2011 2:37 PM, Steve Poole wrote:
>>
>> Hi all, a problem was discovered on JDK7 when using the Nimbus L&F on 
>> a system where libfontconfig.so was not installed (On AIX actually 
>> but in theory on any unix system)
>>
>> Under the covers Nimbus uses the sun.font.FontConfigManager to 
>> retrieve fonts. sun.font.FontConfigManager in turn is intended to use 
>> (for a unix system) the libfontconfig.so system library if present.
>>
>> The code is intended to cope with the library being missing but it 
>> unfortunately doesn't. A array is referenced without checking if it 
>> is null. On systems where the system library is present this array is 
>> never null but in this specific case the array is null and the 
>> reference fails as follows.
>>
>> ?
>> Exception in thread "main" java.lang.NullPointerException
>> at 
>> sun.font.FontConfigManager.getFontConfigFont(FontConfigManager.java:352)
>> at sun.awt.X11FontManager.getFontConfigFUIR(X11FontManager.java:817)
>> at sun.font.FontUtilities.getFontConfigFUIR(FontUtilities.java:472)
>> at javax.swing.plaf.nimbus.NimbusDefaults.<init>(NimbusDefaults.java:138)
>> at 
>> javax.swing.plaf.nimbus.NimbusLookAndFeel.<init>(NimbusLookAndFeel.java:100)
>> at Nimbus.main(Nimbus.java:6)
>> ?
>>
>> The fix is trivial (see attached) and probably just tactical.
>>
>>
>> Cheers,
>>
>> Steve
>>
>



From joe.darcy at oracle.com  Mon Jul 18 23:09:50 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 18 Jul 2011 16:09:50 -0700
Subject: Launcher fix: 7067922, please review
In-Reply-To: <4E24AA48.70707@oracle.COM>
References: <4E24AA48.70707@oracle.COM>
Message-ID: <4E24BD3E.6030709@oracle.com>

On 7/18/2011 2:48 PM, Kumar Srinivasan wrote:
> Hi,
>
> Please review....
> http://cr.openjdk.java.net/~ksrini/7067922
>
> Thanks
> Kumar
>

Hi Kumar.

The change looks fine.

Cheers,

-Joe


From spoole at linux.vnet.ibm.com  Mon Jul 18 23:13:22 2011
From: spoole at linux.vnet.ibm.com (Steve Poole)
Date: Tue, 19 Jul 2011 00:13:22 +0100
Subject: FontConfig fails when optional system library is missing
In-Reply-To: <4E24B043.102@oracle.com>
References: <4E24A78F.40605@linux.vnet.ibm.com> <4E24AFE8.5030102@oracle.com>
	<4E24B043.102@oracle.com>
Message-ID: <4E24BE12.50708@linux.vnet.ibm.com>

On 18/07/11 23:14, Phil Race wrote:
> Ah you said it was AIX, not Linux. Still,  it should have that library 
> installed
> even if the de-ref is fixed.
>
Not on AIX - its completely optional - and as far we can tell (other 
than this particular problem) nothing else bad happens.    Having said 
that I would expect customers to install the package - this fix is 
simply a belt and braces change.
I don't know why the attachment is missing  - here it is inline:
---
diff --git a/src/solaris/classes/sun/font/FontConfigManager.java 
b/src/solaris/classes/sun/font/FontConfigManager.java
--- a/src/solaris/classes/sun/font/FontConfigManager.java
+++ b/src/solaris/classes/sun/font/FontConfigManager.java
@@ -348,6 +348,8 @@

          initFontConfigFonts(false);

+    if(fontConfigFonts==null) return null; // init failed
+
          FcCompFont fcInfo = null;
          for (int i=0; i<fontConfigFonts.length; i++) {
              if (name.equals(fontConfigFonts[i].fcFamily) &&
---

By the way - why is this 2d?  because it's font?    Anyway I've cc'd 
2d-dev as you suggest.  Thanks for the quick response.


> -phil.
>
> On 7/18/2011 3:12 PM, Phil Race wrote:
>> Steve,
>>
>> There's no attachment .. and this should be discussed on 2d-dev, not 
>> core-libs.
>>
>> I do see in the code where the null de-ref can happen. This is some 
>> new JDK 7 code.
>> Although a system where the library is missing is basically DOA for 
>> client use.
>> I'd suspect you are running 32 bit JDK on a 64 bit Linux which hasn't 
>> had
>> the 32 bit libs installed. If so, likely you'll run into other 
>> problems too.
>>
>> -phil.
>>
>>
>> On 7/18/2011 2:37 PM, Steve Poole wrote:
>>>
>>> Hi all, a problem was discovered on JDK7 when using the Nimbus L&F 
>>> on a system where libfontconfig.so was not installed (On AIX 
>>> actually but in theory on any unix system)
>>>
>>> Under the covers Nimbus uses the sun.font.FontConfigManager to 
>>> retrieve fonts. sun.font.FontConfigManager in turn is intended to 
>>> use (for a unix system) the libfontconfig.so system library if present.
>>>
>>> The code is intended to cope with the library being missing but it 
>>> unfortunately doesn't. A array is referenced without checking if it 
>>> is null. On systems where the system library is present this array 
>>> is never null but in this specific case the array is null and the 
>>> reference fails as follows.
>>>
>>> ?
>>> Exception in thread "main" java.lang.NullPointerException
>>> at 
>>> sun.font.FontConfigManager.getFontConfigFont(FontConfigManager.java:352) 
>>>
>>> at sun.awt.X11FontManager.getFontConfigFUIR(X11FontManager.java:817)
>>> at sun.font.FontUtilities.getFontConfigFUIR(FontUtilities.java:472)
>>> at 
>>> javax.swing.plaf.nimbus.NimbusDefaults.<init>(NimbusDefaults.java:138)
>>> at 
>>> javax.swing.plaf.nimbus.NimbusLookAndFeel.<init>(NimbusLookAndFeel.java:100)
>>> at Nimbus.main(Nimbus.java:6)
>>> ?
>>>
>>> The fix is trivial (see attached) and probably just tactical.
>>>
>>>
>>> Cheers,
>>>
>>> Steve
>>>
>>
>



From kelly.ohair at oracle.com  Mon Jul 18 23:16:58 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 18 Jul 2011 16:16:58 -0700
Subject: Launcher fix: 7067922, please review
In-Reply-To: <4E24AA48.70707@oracle.COM>
References: <4E24AA48.70707@oracle.COM>
Message-ID: <C02F5D9B-0BBD-44E7-9774-BD289FA52CC2@oracle.com>

Looks ok to me.

-kto

On Jul 18, 2011, at 2:48 PM, Kumar Srinivasan wrote:

> Hi,
> 
> Please review....
> http://cr.openjdk.java.net/~ksrini/7067922
> 
> Thanks
> Kumar
> 



From Alan.Bateman at oracle.com  Tue Jul 19 04:45:20 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Jul 2011 05:45:20 +0100
Subject: Launcher fix: 7067922, please review
In-Reply-To: <4E24AA48.70707@oracle.COM>
References: <4E24AA48.70707@oracle.COM>
Message-ID: <4E250BE0.9080105@oracle.com>

Kumar Srinivasan wrote:
> Hi,
>
> Please review....
> http://cr.openjdk.java.net/~ksrini/7067922
>
> Thanks
> Kumar
>
Looks okay to me too. Minor nit is the addition of that createJar in 
TestHelper means the indention at line 203 it out.

-Alan.


From kumar.x.srinivasan at oracle.COM  Tue Jul 19 13:58:04 2011
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Tue, 19 Jul 2011 06:58:04 -0700
Subject: Launcher fix: 7067922, please review
In-Reply-To: <4E250BE0.9080105@oracle.com>
References: <4E24AA48.70707@oracle.COM> <4E250BE0.9080105@oracle.com>
Message-ID: <4E258D6C.7050503@oracle.COM>

On 7/18/2011 9:45 PM, Alan Bateman wrote:
> Kumar Srinivasan wrote:
>> Hi,
>>
>> Please review....
>> http://cr.openjdk.java.net/~ksrini/7067922
>>
>> Thanks
>> Kumar
>>
> Looks okay to me too. Minor nit is the addition of that createJar in 
> TestHelper means the indention at line 203 it out.
Ah, ok fixed the whitespace.

Kumar

>
> -Alan.



From xuelei.fan at oracle.com  Tue Jul 19 15:22:38 2011
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Tue, 19 Jul 2011 15:22:38 +0000
Subject: hg: jdk8/tl/jdk: 7059709: close the IO in a final block
Message-ID: <20110719152258.C6DBC4753A@hg.openjdk.java.net>

Changeset: 5355b9ccd19d
Author:    xuelei
Date:      2011-07-19 08:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5355b9ccd19d

7059709: close the IO in a final block
Reviewed-by: smarks, mullan, wetmore

! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java



From mike.duigou at oracle.com  Tue Jul 19 17:02:52 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 19 Jul 2011 10:02:52 -0700
Subject: Launcher fix: 7067922, please review
In-Reply-To: <4E24AA48.70707@oracle.COM>
References: <4E24AA48.70707@oracle.COM>
Message-ID: <99C2A0D1-61EC-45D1-BC80-DD3665D1FA6D@oracle.com>

Looks good. There's no explicit handling for the trimmed string being empty but it doesn't appear that anything bad happens. The ClassNotFoundException resulting from an empty string might be confusing. 

Mike

On Jul 18 2011, at 14:48 , Kumar Srinivasan wrote:

> Hi,
> 
> Please review....
> http://cr.openjdk.java.net/~ksrini/7067922
> 
> Thanks
> Kumar
> 



From mike.duigou at oracle.com  Tue Jul 19 17:09:01 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 19 Jul 2011 10:09:01 -0700
Subject: JDK 8 code review request for 7007535: (reflect) Please
	generalize Constructor and Method
In-Reply-To: <4E23E5E8.4010507@oracle.com>
References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com>
	<62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>
	<4E23E5E8.4010507@oracle.com>
Message-ID: <C9421718-0E5B-484D-B085-CDA7E61F01BF@oracle.com>

This looks good to me but I agree with David that it's probably important to look at the generated javadoc and specdiff output before finalizing.

Mike

On Jul 18 2011, at 00:51 , Joe Darcy wrote:

> Peter and David.
> 
> Thanks for the careful review; the @throws information still needs its own {@inheritDoc}; I've uploaded a webrev with this and other corrections:
> 
> http://cr.openjdk.java.net/~darcy/7007535.4
> 
> More comments interspersed below.
> 
> Thanks,
> 
> -Joe
> 
> Peter Jones wrote:
>> Hi Joe,
>> 
>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote:
>>  
>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
>>>    
>>>> Please code review my JDK 8 changes for
>>>> 
>>>> 7007535: (reflect) Please generalize Constructor and Method
>>>> http://cr.openjdk.java.net/~darcy/7007535.3
>>>> 
>>>> To summarize the changes, a new superclass is defined to capture the common
>>>> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor.
>>>> That superclass is named "Executable" along the lines of
>>>> javax.lang.model.ExecutableElement, which models constructors and methods in
>>>> the JSR 269 language model.
>>>> 
>>>> Both specification and implementation code are shared. To preserve the right
>>>> @since behavior, it is common that in Method/Constructor the javadoc for a
>>>> method will now look like:
>>>> 
>>>> /**
>>>> * {@inheritDoc}
>>>> * @since 1.5
>>>> */
>>>>      
>>> Unless they have fixed/changed javadoc (entirely possible) it used to be that the above would not cause @throws declarations for unchecked exceptions to be inherited - you have/had to explicitly repeat them as:
>>> 
>>> @throws <exception-type> {@inheritDoc}
>>>    
>> 
>> Yes, that would seem to be needed for some of the inherited getters of generics info, which specify unchecked exception types.
>> 
>>  
>>>> Since Executable is being created in JDK 8, it would be incorrect for
>>>> methods in that class to have an @since of 1.5; adding the @since in
>>>> Method/Constructor preserves the right information.
>>>>      
>> 
>> In Executable.java, getAnnotation and getDeclaredAnnotations do have "@since 1.5"-- oversight?
>>  
> 
> Yes; that was incorrect.
> 
>> In Constructor.java and Method.java, getExceptionTypes has "@since 1.5", but that method has existed in those classes since 1.1.
>> 
>>  
> Fixed.
> 
>> In Executable.java:
>> 
>> 216     /**
>> 217      * Returns an array of {@code Class} objects that represent the formal
>> 218      * parameter types, in declaration order, of the method
>> 219      * represented by this {@code Method} object.  Returns an array of length
>> 220      * 0 if the underlying method takes no parameters.
>> 221      *
>> 222      * @return the parameter types for the method this object
>> 223      * represents
>> 
>> At least "{@code Method}" needs to be generalized, and perhaps all occurrences of "method"?
>>  
> Corrected.



From kumar.x.srinivasan at oracle.com  Tue Jul 19 17:59:27 2011
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Tue, 19 Jul 2011 17:59:27 +0000
Subject: hg: jdk8/tl/jdk: 7067922: (launcher) java -jar throws NPE if JAR file
	does not contain Main-Class attribute
Message-ID: <20110719175938.8D9E047540@hg.openjdk.java.net>

Changeset: d17eb3380a49
Author:    ksrini
Date:      2011-07-19 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d17eb3380a49

7067922: (launcher) java -jar throws NPE if JAR file does not contain Main-Class attribute
Reviewed-by: darcy, ohair, alanb, mduigou

! src/share/classes/sun/launcher/LauncherHelper.java
! test/tools/launcher/Arrrghs.java
! test/tools/launcher/TestHelper.java



From joe.darcy at oracle.com  Tue Jul 19 19:49:43 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 19 Jul 2011 12:49:43 -0700
Subject: JDK 8 code review request for 7007535: (reflect) Please generalize
	Constructor and Method
In-Reply-To: <C9421718-0E5B-484D-B085-CDA7E61F01BF@oracle.com>
References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com>
	<62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>
	<4E23E5E8.4010507@oracle.com>
	<C9421718-0E5B-484D-B085-CDA7E61F01BF@oracle.com>
Message-ID: <4E25DFD7.4090102@oracle.com>

Agreed; I've posted a BlenderRev corresponding to the current patch at:

    http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html

Thanks,

-Joe

Mike Duigou wrote:
> This looks good to me but I agree with David that it's probably important to look at the generated javadoc and specdiff output before finalizing.
>
> Mike
>
> On Jul 18 2011, at 00:51 , Joe Darcy wrote:
>
>   
>> Peter and David.
>>
>> Thanks for the careful review; the @throws information still needs its own {@inheritDoc}; I've uploaded a webrev with this and other corrections:
>>
>> http://cr.openjdk.java.net/~darcy/7007535.4
>>
>> More comments interspersed below.
>>
>> Thanks,
>>
>> -Joe
>>
>> Peter Jones wrote:
>>     
>>> Hi Joe,
>>>
>>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote:
>>>  
>>>       
>>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
>>>>    
>>>>         
>>>>> Please code review my JDK 8 changes for
>>>>>
>>>>> 7007535: (reflect) Please generalize Constructor and Method
>>>>> http://cr.openjdk.java.net/~darcy/7007535.3
>>>>>
>>>>> To summarize the changes, a new superclass is defined to capture the common
>>>>> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor.
>>>>> That superclass is named "Executable" along the lines of
>>>>> javax.lang.model.ExecutableElement, which models constructors and methods in
>>>>> the JSR 269 language model.
>>>>>
>>>>> Both specification and implementation code are shared. To preserve the right
>>>>> @since behavior, it is common that in Method/Constructor the javadoc for a
>>>>> method will now look like:
>>>>>
>>>>> /**
>>>>> * {@inheritDoc}
>>>>> * @since 1.5
>>>>> */
>>>>>      
>>>>>           
>>>> Unless they have fixed/changed javadoc (entirely possible) it used to be that the above would not cause @throws declarations for unchecked exceptions to be inherited - you have/had to explicitly repeat them as:
>>>>
>>>> @throws <exception-type> {@inheritDoc}
>>>>    
>>>>         
>>> Yes, that would seem to be needed for some of the inherited getters of generics info, which specify unchecked exception types.
>>>
>>>  
>>>       
>>>>> Since Executable is being created in JDK 8, it would be incorrect for
>>>>> methods in that class to have an @since of 1.5; adding the @since in
>>>>> Method/Constructor preserves the right information.
>>>>>      
>>>>>           
>>> In Executable.java, getAnnotation and getDeclaredAnnotations do have "@since 1.5"-- oversight?
>>>  
>>>       
>> Yes; that was incorrect.
>>
>>     
>>> In Constructor.java and Method.java, getExceptionTypes has "@since 1.5", but that method has existed in those classes since 1.1.
>>>
>>>  
>>>       
>> Fixed.
>>
>>     
>>> In Executable.java:
>>>
>>> 216     /**
>>> 217      * Returns an array of {@code Class} objects that represent the formal
>>> 218      * parameter types, in declaration order, of the method
>>> 219      * represented by this {@code Method} object.  Returns an array of length
>>> 220      * 0 if the underlying method takes no parameters.
>>> 221      *
>>> 222      * @return the parameter types for the method this object
>>> 223      * represents
>>>
>>> At least "{@code Method}" needs to be generalized, and perhaps all occurrences of "method"?
>>>  
>>>       
>> Corrected.
>>     
>
>   



From ahughes at redhat.com  Tue Jul 19 20:08:45 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Tue, 19 Jul 2011 21:08:45 +0100
Subject: JDK 8 code review request for 7007535: (reflect) Please
	generalize Constructor and Method
In-Reply-To: <4E25DFD7.4090102@oracle.com>
References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com>
	<62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>
	<4E23E5E8.4010507@oracle.com>
	<C9421718-0E5B-484D-B085-CDA7E61F01BF@oracle.com>
	<4E25DFD7.4090102@oracle.com>
Message-ID: <20110719200845.GE19626@rivendell.middle-earth.co.uk>

On 12:49 Tue 19 Jul     , Joe Darcy wrote:
> Agreed; I've posted a BlenderRev corresponding to the current patch at:
> 
>     http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html
> 

What is BlenderRev?  Google finds others posted by Oracle employees but
not how to generate them.

> Thanks,
> 
> -Joe
> 
> Mike Duigou wrote:
> > This looks good to me but I agree with David that it's probably important to look at the generated javadoc and specdiff output before finalizing.
> >
> > Mike
> >
> > On Jul 18 2011, at 00:51 , Joe Darcy wrote:
> >
> >   
> >> Peter and David.
> >>
> >> Thanks for the careful review; the @throws information still needs its own {@inheritDoc}; I've uploaded a webrev with this and other corrections:
> >>
> >> http://cr.openjdk.java.net/~darcy/7007535.4
> >>
> >> More comments interspersed below.
> >>
> >> Thanks,
> >>
> >> -Joe
> >>
> >> Peter Jones wrote:
> >>     
> >>> Hi Joe,
> >>>
> >>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote:
> >>>  
> >>>       
> >>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
> >>>>    
> >>>>         
> >>>>> Please code review my JDK 8 changes for
> >>>>>
> >>>>> 7007535: (reflect) Please generalize Constructor and Method
> >>>>> http://cr.openjdk.java.net/~darcy/7007535.3
> >>>>>
> >>>>> To summarize the changes, a new superclass is defined to capture the common
> >>>>> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor.
> >>>>> That superclass is named "Executable" along the lines of
> >>>>> javax.lang.model.ExecutableElement, which models constructors and methods in
> >>>>> the JSR 269 language model.
> >>>>>
> >>>>> Both specification and implementation code are shared. To preserve the right
> >>>>> @since behavior, it is common that in Method/Constructor the javadoc for a
> >>>>> method will now look like:
> >>>>>
> >>>>> /**
> >>>>> * {@inheritDoc}
> >>>>> * @since 1.5
> >>>>> */
> >>>>>      
> >>>>>           
> >>>> Unless they have fixed/changed javadoc (entirely possible) it used to be that the above would not cause @throws declarations for unchecked exceptions to be inherited - you have/had to explicitly repeat them as:
> >>>>
> >>>> @throws <exception-type> {@inheritDoc}
> >>>>    
> >>>>         
> >>> Yes, that would seem to be needed for some of the inherited getters of generics info, which specify unchecked exception types.
> >>>
> >>>  
> >>>       
> >>>>> Since Executable is being created in JDK 8, it would be incorrect for
> >>>>> methods in that class to have an @since of 1.5; adding the @since in
> >>>>> Method/Constructor preserves the right information.
> >>>>>      
> >>>>>           
> >>> In Executable.java, getAnnotation and getDeclaredAnnotations do have "@since 1.5"-- oversight?
> >>>  
> >>>       
> >> Yes; that was incorrect.
> >>
> >>     
> >>> In Constructor.java and Method.java, getExceptionTypes has "@since 1.5", but that method has existed in those classes since 1.1.
> >>>
> >>>  
> >>>       
> >> Fixed.
> >>
> >>     
> >>> In Executable.java:
> >>>
> >>> 216     /**
> >>> 217      * Returns an array of {@code Class} objects that represent the formal
> >>> 218      * parameter types, in declaration order, of the method
> >>> 219      * represented by this {@code Method} object.  Returns an array of length
> >>> 220      * 0 if the underlying method takes no parameters.
> >>> 221      *
> >>> 222      * @return the parameter types for the method this object
> >>> 223      * represents
> >>>
> >>> At least "{@code Method}" needs to be generalized, and perhaps all occurrences of "method"?
> >>>  
> >>>       
> >> Corrected.
> >>     
> >
> >   
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From mike.duigou at oracle.com  Tue Jul 19 20:54:07 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 19 Jul 2011 13:54:07 -0700
Subject: JDK 8 code review request for 7007535: (reflect) Please
	generalize Constructor and Method
In-Reply-To: <4E25DFD7.4090102@oracle.com>
References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com>
	<62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>
	<4E23E5E8.4010507@oracle.com>
	<C9421718-0E5B-484D-B085-CDA7E61F01BF@oracle.com>
	<4E25DFD7.4090102@oracle.com>
Message-ID: <A7EE24A6-1A3B-44DC-869A-B723E1DBF71F@oracle.com>

I reviewed the BlenderRev fairly closely and did not find any errors. The only weirdness I saw was several cases where multiple "Specified by:" declarations were present for a method and one of the instances referenced a class to which it didn't appear to be able to link to. 

Example: Method.getTypeParameters():

Specified by:
getTypeParameters in interface java.lang.reflect.GenericDeclaration

It wasn't clear to me why it needed two "Specified by:" entries and only one of them was hot linked to the specifying class.

Just javadoc weirdness?

Mike

On Jul 19 2011, at 12:49 , Joe Darcy wrote:

> Agreed; I've posted a BlenderRev corresponding to the current patch at:
> 
>   http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html
> 
> Thanks,
> 
> -Joe
> 
> Mike Duigou wrote:
>> This looks good to me but I agree with David that it's probably important to look at the generated javadoc and specdiff output before finalizing.
>> 
>> Mike
>> 
>> On Jul 18 2011, at 00:51 , Joe Darcy wrote:
>> 
>>  
>>> Peter and David.
>>> 
>>> Thanks for the careful review; the @throws information still needs its own {@inheritDoc}; I've uploaded a webrev with this and other corrections:
>>> 
>>> http://cr.openjdk.java.net/~darcy/7007535.4
>>> 
>>> More comments interspersed below.
>>> 
>>> Thanks,
>>> 
>>> -Joe
>>> 
>>> Peter Jones wrote:
>>>    
>>>> Hi Joe,
>>>> 
>>>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote:
>>>>       
>>>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
>>>>>           
>>>>>> Please code review my JDK 8 changes for
>>>>>> 
>>>>>> 7007535: (reflect) Please generalize Constructor and Method
>>>>>> http://cr.openjdk.java.net/~darcy/7007535.3
>>>>>> 
>>>>>> To summarize the changes, a new superclass is defined to capture the common
>>>>>> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor.
>>>>>> That superclass is named "Executable" along the lines of
>>>>>> javax.lang.model.ExecutableElement, which models constructors and methods in
>>>>>> the JSR 269 language model.
>>>>>> 
>>>>>> Both specification and implementation code are shared. To preserve the right
>>>>>> @since behavior, it is common that in Method/Constructor the javadoc for a
>>>>>> method will now look like:
>>>>>> 
>>>>>> /**
>>>>>> * {@inheritDoc}
>>>>>> * @since 1.5
>>>>>> */
>>>>>>               
>>>>> Unless they have fixed/changed javadoc (entirely possible) it used to be that the above would not cause @throws declarations for unchecked exceptions to be inherited - you have/had to explicitly repeat them as:
>>>>> 
>>>>> @throws <exception-type> {@inheritDoc}
>>>>>           
>>>> Yes, that would seem to be needed for some of the inherited getters of generics info, which specify unchecked exception types.
>>>> 
>>>>       
>>>>>> Since Executable is being created in JDK 8, it would be incorrect for
>>>>>> methods in that class to have an @since of 1.5; adding the @since in
>>>>>> Method/Constructor preserves the right information.
>>>>>>               
>>>> In Executable.java, getAnnotation and getDeclaredAnnotations do have "@since 1.5"-- oversight?
>>>>       
>>> Yes; that was incorrect.
>>> 
>>>    
>>>> In Constructor.java and Method.java, getExceptionTypes has "@since 1.5", but that method has existed in those classes since 1.1.
>>>> 
>>>>       
>>> Fixed.
>>> 
>>>    
>>>> In Executable.java:
>>>> 
>>>> 216     /**
>>>> 217      * Returns an array of {@code Class} objects that represent the formal
>>>> 218      * parameter types, in declaration order, of the method
>>>> 219      * represented by this {@code Method} object.  Returns an array of length
>>>> 220      * 0 if the underlying method takes no parameters.
>>>> 221      *
>>>> 222      * @return the parameter types for the method this object
>>>> 223      * represents
>>>> 
>>>> At least "{@code Method}" needs to be generalized, and perhaps all occurrences of "method"?
>>>>       
>>> Corrected.
>>>    
>> 
>>  
> 



From joe.darcy at oracle.com  Tue Jul 19 21:07:31 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 19 Jul 2011 14:07:31 -0700
Subject: JDK 8 code review request for 7007535: (reflect) Please generalize
	Constructor and Method
In-Reply-To: <A7EE24A6-1A3B-44DC-869A-B723E1DBF71F@oracle.com>
References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com>
	<62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>
	<4E23E5E8.4010507@oracle.com>
	<C9421718-0E5B-484D-B085-CDA7E61F01BF@oracle.com>
	<4E25DFD7.4090102@oracle.com>
	<A7EE24A6-1A3B-44DC-869A-B723E1DBF71F@oracle.com>
Message-ID: <4E25F213.9070209@oracle.com>

Hi Mike.

On 7/19/2011 1:54 PM, Mike Duigou wrote:
> I reviewed the BlenderRev fairly closely and did not find any errors. The only weirdness I saw was several cases where multiple "Specified by:" declarations were present for a method and one of the instances referenced a class to which it didn't appear to be able to link to.
>
> Example: Method.getTypeParameters():
>
> Specified by:
> getTypeParameters in interface java.lang.reflect.GenericDeclaration
>
> It wasn't clear to me why it needed two "Specified by:" entries and only one of them was hot linked to the specifying class.

I did a one-off javadoc run just of the classes in question to get the 
BlenderRev; I didn't include GenericDeclaration in the set of types for 
which javadoc was generated, which is probably why the link was missing 
for that type.

I don't know all the criteria for the generation of the "Specified by:" 
references; however, there are other cases in the platform where more 
than one appears, such as ArrayList.size:

http://download.java.net/jdk7/docs/api/java/util/ArrayList.html#size()

Thanks,

-Joe


> Just javadoc weirdness?
>
> Mike
>
> On Jul 19 2011, at 12:49 , Joe Darcy wrote:
>
>> Agreed; I've posted a BlenderRev corresponding to the current patch at:
>>
>>    http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html
>>
>> Thanks,
>>
>> -Joe
>>
>> Mike Duigou wrote:
>>> This looks good to me but I agree with David that it's probably important to look at the generated javadoc and specdiff output before finalizing.
>>>
>>> Mike
>>>
>>> On Jul 18 2011, at 00:51 , Joe Darcy wrote:
>>>
>>>
>>>> Peter and David.
>>>>
>>>> Thanks for the careful review; the @throws information still needs its own {@inheritDoc}; I've uploaded a webrev with this and other corrections:
>>>>
>>>> http://cr.openjdk.java.net/~darcy/7007535.4
>>>>
>>>> More comments interspersed below.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>> Peter Jones wrote:
>>>>
>>>>> Hi Joe,
>>>>>
>>>>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote:
>>>>>
>>>>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
>>>>>>
>>>>>>> Please code review my JDK 8 changes for
>>>>>>>
>>>>>>> 7007535: (reflect) Please generalize Constructor and Method
>>>>>>> http://cr.openjdk.java.net/~darcy/7007535.3
>>>>>>>
>>>>>>> To summarize the changes, a new superclass is defined to capture the common
>>>>>>> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor.
>>>>>>> That superclass is named "Executable" along the lines of
>>>>>>> javax.lang.model.ExecutableElement, which models constructors and methods in
>>>>>>> the JSR 269 language model.
>>>>>>>
>>>>>>> Both specification and implementation code are shared. To preserve the right
>>>>>>> @since behavior, it is common that in Method/Constructor the javadoc for a
>>>>>>> method will now look like:
>>>>>>>
>>>>>>> /**
>>>>>>> * {@inheritDoc}
>>>>>>> * @since 1.5
>>>>>>> */
>>>>>>>
>>>>>> Unless they have fixed/changed javadoc (entirely possible) it used to be that the above would not cause @throws declarations for unchecked exceptions to be inherited - you have/had to explicitly repeat them as:
>>>>>>
>>>>>> @throws<exception-type>  {@inheritDoc}
>>>>>>
>>>>> Yes, that would seem to be needed for some of the inherited getters of generics info, which specify unchecked exception types.
>>>>>
>>>>>
>>>>>>> Since Executable is being created in JDK 8, it would be incorrect for
>>>>>>> methods in that class to have an @since of 1.5; adding the @since in
>>>>>>> Method/Constructor preserves the right information.
>>>>>>>
>>>>> In Executable.java, getAnnotation and getDeclaredAnnotations do have "@since 1.5"-- oversight?
>>>>>
>>>> Yes; that was incorrect.
>>>>
>>>>
>>>>> In Constructor.java and Method.java, getExceptionTypes has "@since 1.5", but that method has existed in those classes since 1.1.
>>>>>
>>>>>
>>>> Fixed.
>>>>
>>>>
>>>>> In Executable.java:
>>>>>
>>>>> 216     /**
>>>>> 217      * Returns an array of {@code Class} objects that represent the formal
>>>>> 218      * parameter types, in declaration order, of the method
>>>>> 219      * represented by this {@code Method} object.  Returns an array of length
>>>>> 220      * 0 if the underlying method takes no parameters.
>>>>> 221      *
>>>>> 222      * @return the parameter types for the method this object
>>>>> 223      * represents
>>>>>
>>>>> At least "{@code Method}" needs to be generalized, and perhaps all occurrences of "method"?
>>>>>
>>>> Corrected.
>>>>
>>>



From joe.darcy at oracle.com  Tue Jul 19 23:58:02 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 19 Jul 2011 16:58:02 -0700
Subject: JDK 8 code review request for 7007535: (reflect) Please generalize
	Constructor and Method
In-Reply-To: <20110719200845.GE19626@rivendell.middle-earth.co.uk>
References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com>
	<62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>
	<4E23E5E8.4010507@oracle.com>
	<C9421718-0E5B-484D-B085-CDA7E61F01BF@oracle.com>
	<4E25DFD7.4090102@oracle.com>
	<20110719200845.GE19626@rivendell.middle-earth.co.uk>
Message-ID: <4E261A0A.2030509@oracle.com>

On 7/19/2011 1:08 PM, Dr Andrew John Hughes wrote:
> On 12:49 Tue 19 Jul     , Joe Darcy wrote:
>> Agreed; I've posted a BlenderRev corresponding to the current patch at:
>>
>>      http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html
>>
> What is BlenderRev?  Google finds others posted by Oracle employees but
> not how to generate them.

Hi Andrew.

BlenderRev is a Sun/Oracle internal tool to generate specification 
differences based on javadoc; specdiff is a similar replacement tool, 
also currently only available internally.

We are aware it would be desirable to have such tools more openly available.

-Joe



From joe.darcy at oracle.com  Wed Jul 20 00:36:44 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 20 Jul 2011 00:36:44 +0000
Subject: hg: jdk8/tl/jdk: 7007535: (reflect) Please generalize Constructor and
	Method
Message-ID: <20110720003657.82E9447552@hg.openjdk.java.net>

Changeset: d083644bc615
Author:    darcy
Date:      2011-07-19 17:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d083644bc615

7007535: (reflect) Please generalize Constructor and Method
Reviewed-by: mduigou, peterjones, dholmes, andrew

! src/share/classes/java/lang/reflect/Constructor.java
+ src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Method.java



From xuelei.fan at oracle.com  Wed Jul 20 04:48:28 2011
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Wed, 20 Jul 2011 04:48:28 +0000
Subject: hg: jdk8/tl/jdk: 7065972: Some race condition may happen in
	SSLSocketImpl class
Message-ID: <20110720044846.4F3144755D@hg.openjdk.java.net>

Changeset: 99dc852080e1
Author:    xuelei
Date:      2011-07-19 21:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99dc852080e1

7065972: Some race condition may happen in SSLSocketImpl class
Reviewed-by: wetmore, weijun, dgu

! src/share/classes/sun/security/ssl/SSLSocketImpl.java



From David.Holmes at oracle.com  Wed Jul 20 08:03:03 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 20 Jul 2011 18:03:03 +1000
Subject: JDK 8 code review request for 7007535: (reflect) Please generalize
	Constructor and Method
In-Reply-To: <4E25DFD7.4090102@oracle.com>
References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com>
	<62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net>
	<4E23E5E8.4010507@oracle.com>
	<C9421718-0E5B-484D-B085-CDA7E61F01BF@oracle.com>
	<4E25DFD7.4090102@oracle.com>
Message-ID: <4E268BB7.9090603@oracle.com>

Just realized this has come in too late ...

Joe Darcy said the following on 07/20/11 05:49:
> Agreed; I've posted a BlenderRev corresponding to the current patch at:
> 
>    http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html

Thanks. So now I can more readily see that the doc for Executable isn't 
quite suitable for Constructor in a few places:

getDeclaringClass:

183     /**
184      * Returns the {@code Class} object representing the class or 
interface
185      * that declares the method represented by this executable object.
186      */

For Constructor "method" should be "constructor". But I think, looking 
at the terminology elsewhere that the above could be rewritten as:

"Returns the Class object representing the class or interface that 
declares the executable represented by this object."

getParameterTypes:

219      * represented by this object.  Returns an array of length
220      * 0 if the underlying method takes no parameters.

method -> executable

getGenericParameterTypes:

229      * parameter types, in declaration order, of the method 
represented by
230      * this executable object. Returns an array of length 0 if the
231      * underlying method takes no parameters.

Again change to " the executable represented by this object".
And then: underlying method -> underlying executable

241      *     parameter types of the underlying method, in declaration 
order
243      *     if the generic method signature does not conform to the 
format
247      *     types of the underlying method refers to a non-existent type
250      *     the underlying method's parameter types refer to a 
parameterized

method -> executable

In fact do a search for "method" in Executable and most occurrences 
should be changed to "executable".


Finally, in getModifiers, why delete the "as an integer. The Modifier 
class should be used to decode the modifiers. " ?


BTW I also find the multiple "Specified by:" references to be quite 
strange. There can only be one specification for a method.

David
-----

> Thanks,
> 
> -Joe
> 
> Mike Duigou wrote:
>> This looks good to me but I agree with David that it's probably 
>> important to look at the generated javadoc and specdiff output before 
>> finalizing.
>>
>> Mike
>>
>> On Jul 18 2011, at 00:51 , Joe Darcy wrote:
>>
>>  
>>> Peter and David.
>>>
>>> Thanks for the careful review; the @throws information still needs 
>>> its own {@inheritDoc}; I've uploaded a webrev with this and other 
>>> corrections:
>>>
>>> http://cr.openjdk.java.net/~darcy/7007535.4
>>>
>>> More comments interspersed below.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> Peter Jones wrote:
>>>    
>>>> Hi Joe,
>>>>
>>>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote:
>>>>  
>>>>      
>>>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
>>>>>           
>>>>>> Please code review my JDK 8 changes for
>>>>>>
>>>>>> 7007535: (reflect) Please generalize Constructor and Method
>>>>>> http://cr.openjdk.java.net/~darcy/7007535.3
>>>>>>
>>>>>> To summarize the changes, a new superclass is defined to capture 
>>>>>> the common
>>>>>> functionality of java.lang.reflect.Method and 
>>>>>> java.lang.reflect.Constructor.
>>>>>> That superclass is named "Executable" along the lines of
>>>>>> javax.lang.model.ExecutableElement, which models constructors and 
>>>>>> methods in
>>>>>> the JSR 269 language model.
>>>>>>
>>>>>> Both specification and implementation code are shared. To preserve 
>>>>>> the right
>>>>>> @since behavior, it is common that in Method/Constructor the 
>>>>>> javadoc for a
>>>>>> method will now look like:
>>>>>>
>>>>>> /**
>>>>>> * {@inheritDoc}
>>>>>> * @since 1.5
>>>>>> */
>>>>>>                
>>>>> Unless they have fixed/changed javadoc (entirely possible) it used 
>>>>> to be that the above would not cause @throws declarations for 
>>>>> unchecked exceptions to be inherited - you have/had to explicitly 
>>>>> repeat them as:
>>>>>
>>>>> @throws <exception-type> {@inheritDoc}
>>>>>            
>>>> Yes, that would seem to be needed for some of the inherited getters 
>>>> of generics info, which specify unchecked exception types.
>>>>
>>>>  
>>>>      
>>>>>> Since Executable is being created in JDK 8, it would be incorrect for
>>>>>> methods in that class to have an @since of 1.5; adding the @since in
>>>>>> Method/Constructor preserves the right information.
>>>>>>                
>>>> In Executable.java, getAnnotation and getDeclaredAnnotations do have 
>>>> "@since 1.5"-- oversight?
>>>>  
>>>>       
>>> Yes; that was incorrect.
>>>
>>>    
>>>> In Constructor.java and Method.java, getExceptionTypes has "@since 
>>>> 1.5", but that method has existed in those classes since 1.1.
>>>>
>>>>  
>>>>       
>>> Fixed.
>>>
>>>    
>>>> In Executable.java:
>>>>
>>>> 216     /**
>>>> 217      * Returns an array of {@code Class} objects that represent 
>>>> the formal
>>>> 218      * parameter types, in declaration order, of the method
>>>> 219      * represented by this {@code Method} object.  Returns an 
>>>> array of length
>>>> 220      * 0 if the underlying method takes no parameters.
>>>> 221      *
>>>> 222      * @return the parameter types for the method this object
>>>> 223      * represents
>>>>
>>>> At least "{@code Method}" needs to be generalized, and perhaps all 
>>>> occurrences of "method"?
>>>>  
>>>>       
>>> Corrected.
>>>     
>>
>>   
> 


From neil.richards at ngmr.net  Wed Jul 20 10:51:59 2011
From: neil.richards at ngmr.net (Neil Richards)
Date: Wed, 20 Jul 2011 11:51:59 +0100
Subject: Request for review: Make MethodHandleProxies.isSingleMethod()
	agnostic of ordering of methods returned from Class.getMethods()
Message-ID: <1311159119.1024.56.camel@chalkhill>

java.lang.invoke.MethodHandleProxies.isSingleMethod(Class<?> intf)
returns a boolean indicating whether the provided interface has only one
defined method upon it.

When making this consideration, it tries not count any method defined on
the interface that is also defined by java.lang.Object (and so will
always be there for all implementations of the interface).

Because of this, for example, isSingleMethod should return 'true' for
java.util.Comparator, which has two defined methods - compare() and
equals() - as all but one of these methods are also defined by
java.lang.Object.

isSingleMethod() makes the consideration my iterating through the array
of Method objects returned from Class.getMethods().

The API javadoc for Class.getMethods() [1] says (amongst other things):
"The elements in the array returned are not sorted and are not in any
particular order." 

However, isSingleMethod() currently relies upon any methods defined on
java.lang.Object appearing in the list before any others.

I suppose this happens to be the case currently (at least, when using
hotspot), but it is a generally brittle assumption for this code to rely
upon.

Please find below a suggested change which removes this assumption by
making the algorithm agnostic to the ordering returned by
Class.getMethods().

Please consider this change for committal.

Thanks,
Neil

[1] http://download.oracle.com/javase/7/docs/api/java/lang/Class.html#getMethods%28%29

-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


# HG changeset patch
# User Neil Richards <neil.richards at ngmr.net>, <neil_richards at uk.ibm.com>
# Date 1311156497 -3600
# Branch ojdk-131
# Node ID 1062362b6e7a39d9bc3f468cfd33ae100371413e
# Parent  8bbea505b060fc7c97d9c241f8531a2a758cbe20
Summary: Make isSingleMethod() agnostic of ordering of methods returned from Class.getMethods()
Contributed-by: <neil.richards at ngmr.net>

diff -r 8bbea505b060 -r 1062362b6e7a src/share/classes/java/lang/invoke/MethodHandleProxies.java
--- a/src/share/classes/java/lang/invoke/MethodHandleProxies.java	Mon Jul 18 22:25:58 2011 +0100
+++ b/src/share/classes/java/lang/invoke/MethodHandleProxies.java	Wed Jul 20 11:08:17 2011 +0100
@@ -246,8 +246,8 @@
         Method sm = null;
         for (Method m : intfc.getMethods()) {
             int mod = m.getModifiers();
-            if (Modifier.isAbstract(mod)) {
-                if (sm != null && !isObjectMethod(sm))
+            if (Modifier.isAbstract(mod) && !isObjectMethod(m)) {
+                if (sm != null)
                     return null;  // too many abstract methods
                 sm = m;
             }




From David.Holmes at oracle.com  Wed Jul 20 12:16:38 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 20 Jul 2011 22:16:38 +1000
Subject: Request for review: Make MethodHandleProxies.isSingleMethod()
	agnostic of ordering of methods returned from Class.getMethods()
In-Reply-To: <1311159119.1024.56.camel@chalkhill>
References: <1311159119.1024.56.camel@chalkhill>
Message-ID: <4E26C726.7050409@oracle.com>

Hi Neil,

Neil Richards said the following on 07/20/11 20:51:
> java.lang.invoke.MethodHandleProxies.isSingleMethod(Class<?> intf)
> returns a boolean indicating whether the provided interface has only one
> defined method upon it.
> 
> When making this consideration, it tries not count any method defined on
> the interface that is also defined by java.lang.Object (and so will
> always be there for all implementations of the interface).
> 
> Because of this, for example, isSingleMethod should return 'true' for
> java.util.Comparator, which has two defined methods - compare() and
> equals() - as all but one of these methods are also defined by
> java.lang.Object.
> 
> isSingleMethod() makes the consideration my iterating through the array
> of Method objects returned from Class.getMethods().
> 
> The API javadoc for Class.getMethods() [1] says (amongst other things):
> "The elements in the array returned are not sorted and are not in any
> particular order." 

Indeed and this order even changed during JDK7 development.

> However, isSingleMethod() currently relies upon any methods defined on
> java.lang.Object appearing in the list before any others.
> 
> I suppose this happens to be the case currently (at least, when using
> hotspot), but it is a generally brittle assumption for this code to rely
> upon.

I don't know if the author actually made that assumption or whether the 
code just happens to only work in that case, but it is certainly broken 
logic.

> Please find below a suggested change which removes this assumption by
> making the algorithm agnostic to the ordering returned by
> Class.getMethods().

I agree that the suggested change fixes the problem.

However, unless I'm missing something subtle, why do we need to check 
for the method being abstract? Aren't all interface methods always 
implicitly abstract?

> Please consider this change for committal.

I'll let one of the libs team file a bug :)

Cheers,
David Holmes

> Thanks,
> Neil
> 
> [1] http://download.oracle.com/javase/7/docs/api/java/lang/Class.html#getMethods%28%29
> 


From sebastian.sickelmann at gmx.de  Wed Jul 20 19:42:04 2011
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 20 Jul 2011 21:42:04 +0200
Subject: Bound MethodHandle at runtime
Message-ID: <20110720194204.154130@gmx.net>

Hi,

first of all. Your Job at invokedynamic is really awesome. I have started a project called "mockinject" at java.net a few year ago that need to hook inside method calls and invokedynamic will make it really easy to do it in jdk7. I got some problem with the actual implementation some time ago, but i want to restart the project with invokedymic.

mockinject does a lot of byte-code-fiddeling and this is really bug intensive. 
So i decided to start another project "jvmdebug" that emulates the real byte-code-instruction-execution with simulation-code which has debug-information-pointers to asm-dumps of the real-class. My favorite IDE detects the debug-information show the asm-dump and so it looks like you are debugging the byte-code.

And here is my question: Is there a way to identify the actually bound method-handle that will be used by an invokedynimic call? It would be really usefull for the user to get this information before executing the invokedynamic instruction.

Kind regards
Sebastian
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zur?ck-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone


From jonathan.gibbons at oracle.com  Wed Jul 20 20:23:12 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 20 Jul 2011 20:23:12 +0000
Subject: hg: jdk8/tl/jdk: 7068617: Core libraries don't build with javac
	-Xlint:all -Werror
Message-ID: <20110720202322.A374947585@hg.openjdk.java.net>

Changeset: 9505edecc8b5
Author:    jjg
Date:      2011-07-20 12:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9505edecc8b5

7068617: Core libraries don't build with javac -Xlint:all -Werror
Reviewed-by: darcy
Contributed-by: alexandre.boulgakov at oracle.com

! make/java/java/Makefile
! src/share/classes/sun/reflect/generics/reflectiveObjects/NotImplementedException.java
! src/share/classes/sun/reflect/misc/ConstructorUtil.java
! src/share/classes/sun/reflect/misc/FieldUtil.java
! src/share/classes/sun/reflect/misc/MethodUtil.java
! src/share/classes/sun/reflect/misc/ReflectUtil.java



From forax at univ-mlv.fr  Wed Jul 20 20:28:20 2011
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Wed, 20 Jul 2011 13:28:20 -0700
Subject: Bound MethodHandle at runtime
In-Reply-To: <20110720194204.154130@gmx.net>
References: <20110720194204.154130@gmx.net>
Message-ID: <4E273A64.2070403@univ-mlv.fr>

On 07/20/2011 12:42 PM, Sebastian Sickelmann wrote:
> Hi,
>
> first of all. Your Job at invokedynamic is really awesome. I have started a project called "mockinject" at java.net a few year ago that need to hook inside method calls and invokedynamic will make it really easy to do it in jdk7. I got some problem with the actual implementation some time ago, but i want to restart the project with invokedymic.
>
> mockinject does a lot of byte-code-fiddeling and this is really bug intensive.
> So i decided to start another project "jvmdebug" that emulates the real byte-code-instruction-execution with simulation-code which has debug-information-pointers to asm-dumps of the real-class. My favorite IDE detects the debug-information show the asm-dump and so it looks like you are debugging the byte-code.
>
> And here is my question: Is there a way to identify the actually bound method-handle that will be used by an invokedynimic call? It would be really usefull for the user to get this information before executing the invokedynamic instruction.
>
> Kind regards
> Sebastian

Wrong list,
there is a specific list for JSR 292:  mlvm-dev at openjdk.java.net

R?mi



From lvjing at linux.vnet.ibm.com  Thu Jul 21 08:14:13 2011
From: lvjing at linux.vnet.ibm.com (Jing LV)
Date: Thu, 21 Jul 2011 16:14:13 +0800
Subject: A method with return type size_t returns negative value
In-Reply-To: <4E12D5F2.4010409@linux.vnet.ibm.com>
References: <4D89BB76.5060900@linux.vnet.ibm.com>
	<4D89CA29.7040302@oracle.com>	<4D8AF3C4.7020005@linux.vnet.ibm.com>
	<4D8B3A6B.8040005@oracle.com>	<4DB68125.7080003@linux.vnet.ibm.com>
	<4DB685AF.9070602@oracle.com> <4DC24218.6070009@linux.vnet.ibm.com>
	<4E12D5F2.4010409@linux.vnet.ibm.com>
Message-ID: <4E27DFD5.4010904@linux.vnet.ibm.com>

Ping, anyone notice this? :)
My plan is that we'd search all source to find all kinds of such issues, 
and then refine them in a uniform solution. If jint is not good enough, 
how about ssize_t?

? 2011-7-5 17:14, Jing LV ??:
> Hello,
>
>     It's been quite a long time and it seems jdk7 is doing well now. I 
> know there is still several days before its release, anyway, Alan or 
> someone else, would you please tell me if we can start work on jdk8, 
> and restart the discussion on the bugs like this (I remember there are 
> still some to be discussed)? Thanks!
>
>
> ? 2011-5-5 14:22, Jing LV ??:
>> ? 2011-4-26 16:43, Alan Bateman ??:
>>> Jing LV wrote:
>>>> Hello,
>>>>
>>>>      Thanks for raising the defect. I see there is no patch now, so 
>>>> I create one (as the defect mentioned jint may be good, I use jint 
>>>> here).
>>>>      I have no Sun Online Account Id, would someone take a look?
>>> The function prototypes would also require to be updated and there 
>>> are a couple of other areas that would require clean-up too. If it's 
>>> okay with you, I think we should postpone this to jdk8. This code 
>>> has been using size_t for many years and I don't think is actually 
>>> causing a real problem. I agree it should be cleaned up but we are 
>>> out of time in jdk7. Another point is that jdk8 will be our 
>>> opportunity to remove the dependencies on the JVM_* functions and so 
>>> this code will be changing anyway (I realize we're not using these 
>>> in the Windows code but the functions need to match as they are used 
>>> from shared code).
>>>
>>> -Alan.
>> Hi Alan,
>>
>>      I am OK with Java8. And I am wondering if a portlib or something 
>> may help. I'd think deeper and provide some proposal.
>>
>
>


-- 
Best Regards,
Jimmy, Jing LV




From Alan.Bateman at oracle.com  Thu Jul 21 13:32:30 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Jul 2011 14:32:30 +0100
Subject: A method with return type size_t returns negative value
In-Reply-To: <4E27DFD5.4010904@linux.vnet.ibm.com>
References: <4D89BB76.5060900@linux.vnet.ibm.com>	<4D89CA29.7040302@oracle.com>	<4D8AF3C4.7020005@linux.vnet.ibm.com>	<4D8B3A6B.8040005@oracle.com>	<4DB68125.7080003@linux.vnet.ibm.com>	<4DB685AF.9070602@oracle.com>
	<4DC24218.6070009@linux.vnet.ibm.com>	<4E12D5F2.4010409@linux.vnet.ibm.com>
	<4E27DFD5.4010904@linux.vnet.ibm.com>
Message-ID: <4E282A6E.7010305@oracle.com>

Jing LV wrote:
> Ping, anyone notice this? :)
> My plan is that we'd search all source to find all kinds of such 
> issues, and then refine them in a uniform solution. If jint is not 
> good enough, how about ssize_t?
ACK, saw your mails and will get back to you soon on this.

-Alan


From chris.hegarty at oracle.com  Thu Jul 21 16:29:11 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 21 Jul 2011 16:29:11 +0000
Subject: hg: jdk8/tl/jdk: 7068416: Lightweight HTTP Server should support
	TCP_NODELAY
Message-ID: <20110721162934.6C4F8475B2@hg.openjdk.java.net>

Changeset: 70ec3aa8e99a
Author:    chegar
Date:      2011-07-21 17:28 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70ec3aa8e99a

7068416: Lightweight HTTP Server should support TCP_NODELAY
Reviewed-by: alanb, michaelm

! src/share/classes/sun/net/httpserver/ServerConfig.java
! src/share/classes/sun/net/httpserver/ServerImpl.java
! test/com/sun/net/httpserver/Test1.java



From weijun.wang at oracle.com  Fri Jul 22 02:25:57 2011
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 22 Jul 2011 02:25:57 +0000
Subject: hg: jdk8/tl/jdk: 6330275: Rework the PaddingTest regression test.
Message-ID: <20110722022608.0BF564762F@hg.openjdk.java.net>

Changeset: c8dbb9e19355
Author:    weijun
Date:      2011-07-22 10:25 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8dbb9e19355

6330275: Rework the PaddingTest regression test.
Reviewed-by: wetmore, smarks

! test/ProblemList.txt
! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java



From Lance.Andersen at oracle.com  Fri Jul 22 21:37:17 2011
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 22 Jul 2011 17:37:17 -0400
Subject: Found 3 NullPointerExceptions
In-Reply-To: <4E29EBFC.2030202@reini.net>
References: <4E29EBFC.2030202@reini.net>
Message-ID: <B2B04BD5-2489-4C47-AF16-8F18568FE4B0@oracle.com>

Hi Patrick,

I will look at your proposed change on Monday

Best
Lance
On Jul 22, 2011, at 5:30 PM, Patrick Reinhart wrote:

> Hi everybody,
> 
> I found and fixed 3 NullPointerException's  within the classes SerialBlob/SerialClob. Attached you find the corrected classes and test to cover the changes.
> 
> Best regards
> 
> Patrick
> <webrev.zip>


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From kelly.ohair at oracle.com  Sat Jul 23 04:32:59 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Sat, 23 Jul 2011 04:32:59 +0000
Subject: hg: jdk8/tl: 2 new changesets
Message-ID: <20110723043259.6B87D4767C@hg.openjdk.java.net>

Changeset: fd8615098a54
Author:    ohair
Date:      2011-07-22 17:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/fd8615098a54

7069993: Adjust make/jprt.properties file for jdk8
Reviewed-by: katleman

! make/jprt.properties

Changeset: f42e3d9394b4
Author:    ohair
Date:      2011-07-22 21:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/f42e3d9394b4

Merge




From kelly.ohair at oracle.com  Sat Jul 23 04:33:07 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Sat, 23 Jul 2011 04:33:07 +0000
Subject: hg: jdk8/tl/corba: 7069993: Adjust make/jprt.properties file for jdk8
Message-ID: <20110723043309.49DC54767D@hg.openjdk.java.net>

Changeset: 949fb60ca830
Author:    ohair
Date:      2011-07-22 17:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/949fb60ca830

7069993: Adjust make/jprt.properties file for jdk8
Reviewed-by: katleman

! make/jprt.properties



From kelly.ohair at oracle.com  Sat Jul 23 04:33:23 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Sat, 23 Jul 2011 04:33:23 +0000
Subject: hg: jdk8/tl/jaxp: 7069993: Adjust make/jprt.properties file for jdk8
Message-ID: <20110723043323.AB5DA4767E@hg.openjdk.java.net>

Changeset: 4f0fcb812767
Author:    ohair
Date:      2011-07-22 17:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4f0fcb812767

7069993: Adjust make/jprt.properties file for jdk8
Reviewed-by: katleman

! make/jprt.properties



From kelly.ohair at oracle.com  Sat Jul 23 04:33:31 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Sat, 23 Jul 2011 04:33:31 +0000
Subject: hg: jdk8/tl/jaxws: 7069993: Adjust make/jprt.properties file for jdk8
Message-ID: <20110723043331.8B8964767F@hg.openjdk.java.net>

Changeset: 64df57a1edec
Author:    ohair
Date:      2011-07-22 17:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/64df57a1edec

7069993: Adjust make/jprt.properties file for jdk8
Reviewed-by: katleman

! make/jprt.properties



From kelly.ohair at oracle.com  Sat Jul 23 04:33:49 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Sat, 23 Jul 2011 04:33:49 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20110723043432.711CA47680@hg.openjdk.java.net>

Changeset: 0ec4b6498a69
Author:    ohair
Date:      2011-07-22 17:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ec4b6498a69

7069993: Adjust make/jprt.properties file for jdk8
Reviewed-by: katleman

! make/jprt.properties

Changeset: a499fdfbe723
Author:    ohair
Date:      2011-07-22 21:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a499fdfbe723

Merge




From kelly.ohair at oracle.com  Sat Jul 23 04:34:43 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Sat, 23 Jul 2011 04:34:43 +0000
Subject: hg: jdk8/tl/langtools: 2 new changesets
Message-ID: <20110723043450.24B1347681@hg.openjdk.java.net>

Changeset: 2d3096441387
Author:    ohair
Date:      2011-07-22 17:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d3096441387

7069993: Adjust make/jprt.properties file for jdk8
Reviewed-by: katleman

! make/jprt.properties

Changeset: 36f31b87b0ab
Author:    ohair
Date:      2011-07-22 21:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/36f31b87b0ab

Merge




From peter.lawrey at gmail.com  Sun Jul 24 07:18:54 2011
From: peter.lawrey at gmail.com (Peter Lawrey)
Date: Sun, 24 Jul 2011 08:18:54 +0100
Subject: Contribution to Bug 100120
Message-ID: <CAOgwmTgzvys4uMSikAuR5k7FRKnRRQm8T42fy2XMQ4HG065G5g@mail.gmail.com>

Hello,

I am trying to following the http://openjdk.java.net/contribute/
What is the next step to progressing bug
https://bugs.openjdk.java.net/show_bug.cgi?id=100120
It has a suggested fix provided.

Regards,
  Peter.


From Ulf.Zibis at gmx.de  Sun Jul 24 13:15:27 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 24 Jul 2011 15:15:27 +0200
Subject: Contribution to Bug 100120
In-Reply-To: <CAOgwmTgzvys4uMSikAuR5k7FRKnRRQm8T42fy2XMQ4HG065G5g@mail.gmail.com>
References: <CAOgwmTgzvys4uMSikAuR5k7FRKnRRQm8T42fy2XMQ4HG065G5g@mail.gmail.com>
Message-ID: <4E2C1AEF.9080604@gmx.de>

At least:
- provide a formal patch as attachment to bug 100120
- pray for a sponsor
- pray, the sponsor would have time ;-)

-Ulf


Am 24.07.2011 09:18, schrieb Peter Lawrey:
> Hello,
>
> I am trying to following the http://openjdk.java.net/contribute/
> What is the next step to progressing bug
> https://bugs.openjdk.java.net/show_bug.cgi?id=100120
> It has a suggested fix provided.
>
> Regards,
>    Peter.
>


From Alan.Bateman at oracle.com  Sun Jul 24 15:17:52 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 24 Jul 2011 16:17:52 +0100
Subject: Contribution to Bug 100120
In-Reply-To: <CAOgwmTgzvys4uMSikAuR5k7FRKnRRQm8T42fy2XMQ4HG065G5g@mail.gmail.com>
References: <CAOgwmTgzvys4uMSikAuR5k7FRKnRRQm8T42fy2XMQ4HG065G5g@mail.gmail.com>
Message-ID: <4E2C37A0.7030900@oracle.com>

Peter Lawrey wrote:
> Hello,
>
> I am trying to following the http://openjdk.java.net/contribute/
> What is the next step to progressing bug
> https://bugs.openjdk.java.net/show_bug.cgi?id=100120
> It has a suggested fix provided.
>
> Regards,
>   Peter.
>   
I would suggest re-basing the patch and attaching it to the bug. It 
would also be good to create a standalone test case that can be used to 
demonstrate the contention (we could add it to tests in 
jdk/test/java/lang/reflect/Proxy so that future maintainers have some 
performance tests to run). If a patch is attached then you could start a 
discussion here, get it reviewed, and get a sponsor to help get it in.

-Alan.


From mike.duigou at oracle.com  Sun Jul 24 23:51:20 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Sun, 24 Jul 2011 16:51:20 -0700
Subject: Contribution to Bug 100120
In-Reply-To: <4E2C37A0.7030900@oracle.com>
References: <CAOgwmTgzvys4uMSikAuR5k7FRKnRRQm8T42fy2XMQ4HG065G5g@mail.gmail.com>
	<4E2C37A0.7030900@oracle.com>
Message-ID: <BA2FE5C3-D520-4231-A0D8-A50AA3AA97C2@oracle.com>

One other valuable bit of valuable info missing from the current bug writeup is an explanation of why the RFE (request for enhancement) matters. Where is the problem encountered, how widespread is the problem, how much of a bottleneck does it represent, etc.? Any context you can provide can only help to attract attention and effort to this problem. 

I suspect that in the past there was a resistance to converting to ConcurrentHashMap because of the additional overhead that CHM introduced. This has been fixed in JDK 7 so this resistance may no longer apply. 

Mike


On Jul 24 2011, at 08:17 , Alan Bateman wrote:

> Peter Lawrey wrote:
>> Hello,
>> 
>> I am trying to following the http://openjdk.java.net/contribute/
>> What is the next step to progressing bug
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100120
>> It has a suggested fix provided.
>> 
>> Regards,
>>  Peter.
>>  
> I would suggest re-basing the patch and attaching it to the bug. It would also be good to create a standalone test case that can be used to demonstrate the contention (we could add it to tests in jdk/test/java/lang/reflect/Proxy so that future maintainers have some performance tests to run). If a patch is attached then you could start a discussion here, get it reviewed, and get a sponsor to help get it in.
> 
> -Alan.



From David.Holmes at oracle.com  Mon Jul 25 02:29:50 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 25 Jul 2011 12:29:50 +1000
Subject: Contribution to Bug 100120
In-Reply-To: <4E2C37A0.7030900@oracle.com>
References: <CAOgwmTgzvys4uMSikAuR5k7FRKnRRQm8T42fy2XMQ4HG065G5g@mail.gmail.com>
	<4E2C37A0.7030900@oracle.com>
Message-ID: <4E2CD51E.2090306@oracle.com>

Alan Bateman said the following on 07/25/11 01:17:
> Peter Lawrey wrote:
>> Hello,
>>
>> I am trying to following the http://openjdk.java.net/contribute/
>> What is the next step to progressing bug
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100120
>> It has a suggested fix provided.
>>
>> Regards,
>>   Peter.
>>   
> I would suggest re-basing the patch and attaching it to the bug. It 
> would also be good to create a standalone test case that can be used to 
> demonstrate the contention (we could add it to tests in 
> jdk/test/java/lang/reflect/Proxy so that future maintainers have some 
> performance tests to run). If a patch is attached then you could start a 
> discussion here, get it reviewed, and get a sponsor to help get it in.

The original code is provided under GPL3. I don't know how you go about 
incorporating such code into OpenJDK ?

But as Mike says, first you have establish there is a general problem 
that needs to be solved and that adding this class, or changing the 
existing implementation is a reasonable change to make for the OpenJDK.

David

> -Alan.


From Alan.Bateman at oracle.com  Mon Jul 25 04:16:43 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 25 Jul 2011 05:16:43 +0100
Subject: Contribution to Bug 100120
In-Reply-To: <4E2CD51E.2090306@oracle.com>
References: <CAOgwmTgzvys4uMSikAuR5k7FRKnRRQm8T42fy2XMQ4HG065G5g@mail.gmail.com>
	<4E2C37A0.7030900@oracle.com> <4E2CD51E.2090306@oracle.com>
Message-ID: <4E2CEE2B.7020507@oracle.com>

David Holmes wrote:
>
> The original code is provided under GPL3. I don't know how you go 
> about incorporating such code into OpenJDK ?
I don't know how the GPL3 header ended up on that version but presumably 
he can attach a patch to the bug that is against the current version of 
java.lang.reflect.Proxy that is in the jdk8 forest.

-Alan.


From David.Holmes at oracle.com  Mon Jul 25 04:37:45 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 25 Jul 2011 14:37:45 +1000
Subject: Contribution to Bug 100120
In-Reply-To: <4E2CEE2B.7020507@oracle.com>
References: <CAOgwmTgzvys4uMSikAuR5k7FRKnRRQm8T42fy2XMQ4HG065G5g@mail.gmail.com>
	<4E2C37A0.7030900@oracle.com> <4E2CD51E.2090306@oracle.com>
	<4E2CEE2B.7020507@oracle.com>
Message-ID: <4E2CF319.2060409@oracle.com>

Hi Alan,

Alan Bateman said the following on 07/25/11 14:16:
> David Holmes wrote:
>>
>> The original code is provided under GPL3. I don't know how you go 
>> about incorporating such code into OpenJDK ?
> I don't know how the GPL3 header ended up on that version but presumably 
> he can attach a patch to the bug that is against the current version of 
> java.lang.reflect.Proxy that is in the jdk8 forest.

But in this case the person wishing to advance the bug (Peter) is not 
the person who filed the bug. It isn't clear if the original submitter 
was actually contributing a patch or simply pointing to an alternate 
implementation that doesn't have the problem.

So ignoring for now whether this is a suitable patch, what would the 
process be if you came across third-party code (such as this) that is 
under GPL3 and you wanted to use that code in the OpenJDK? can it be done?

David


> -Alan.


From peter.lawrey at gmail.com  Mon Jul 25 08:10:55 2011
From: peter.lawrey at gmail.com (Peter Lawrey)
Date: Mon, 25 Jul 2011 09:10:55 +0100
Subject: Contribution to Bug 100120
In-Reply-To: <4E2CF319.2060409@oracle.com>
References: <CAOgwmTgzvys4uMSikAuR5k7FRKnRRQm8T42fy2XMQ4HG065G5g@mail.gmail.com>
	<4E2C37A0.7030900@oracle.com> <4E2CD51E.2090306@oracle.com>
	<4E2CEE2B.7020507@oracle.com> <4E2CF319.2060409@oracle.com>
Message-ID: <CAOgwmTjy6QnHMuaMcBZvSvwpUjLNygJsEWYBkUHJsrsj9MpFaw@mail.gmail.com>

The reason for starting this line of enquiry:

I have been developing an Ultra High Frequency trading system in Java. In
this environment 100 microseconds from packet-in to packet-out measured
externally would be consider reasonable but not great.  I have ended up
re-writing some portions of the core libraries to support these latency
requirements. In many case a 3x to 10x speed improvement was achieved. (This
speed improvement was achieved using custom solutions which may not be
general enough to include in the core libraries) I am looking to use the
experience I have gain to improve the core libraries rather than just
writing replacements.

Instead of raising bugs, I thought it better to learn the process first.  I
don't particularly care which bug I try first. Is this a good bug to start
with?

Regards,
  Peter.


From lvjing at linux.vnet.ibm.com  Mon Jul 25 08:24:50 2011
From: lvjing at linux.vnet.ibm.com (Jing LV)
Date: Mon, 25 Jul 2011 16:24:50 +0800
Subject: BufferedOutputStream does not throw exception after it's closed
In-Reply-To: <4DB5A5D3.1060805@oracle.com>
References: <4D3EE928.1030701@linux.vnet.ibm.com>
	<4D3EEC37.5050004@univ-mlv.fr>	<4D5CDAD4.4040704@linux.vnet.ibm.com>
	<4D5CE3F0.1090704@oracle.com> <4DB59D84.3070906@linux.vnet.ibm.com>
	<4DB5A5D3.1060805@oracle.com>
Message-ID: <4E2D2852.70900@linux.vnet.ibm.com>

Hello,

     I see the defect 7015589 is accepted but no further action is 
taken. I suggest we may make it in java8?
     Currently the defect is marked as "spec", not sure if this is 
determine to spec only? If no, I'd like to make a patch to throw an 
IOException after close. Any comments? Thanks.

? 2011-4-26 0:48, Mandy Chung ??:
>  Hi Jing,
>
> On 04/25/11 09:12, Jing LV wrote:
>> Hi Alan,
>> I have many trouble to find 7015589 - I thought it was on 
>> bugs.sun.com but search never return a correct result. I guess it was 
>> the problem of the system. However up to now I can find nothing. I 
>> aslo try it as a CR number, but I don't find it under ~alanb/7015589 
>> . Would you please tell me what number is it and how can I check the 
>> status like this ( I remember there is a few on my list).
>
> I think this is what you are looking for:
>    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7015589
>
> Mandy


-- 
Best Regards,
Jimmy, Jing LV




From chris.hegarty at oracle.com  Mon Jul 25 21:42:14 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 25 Jul 2011 21:42:14 +0000
Subject: hg: jdk8/tl/jdk: 7035556: DatagramSocket.java:183: warning:
	unreachable catch clause
Message-ID: <20110725214247.121EF47709@hg.openjdk.java.net>

Changeset: 07a12583d4ea
Author:    chegar
Date:      2011-07-25 14:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07a12583d4ea

7035556: DatagramSocket.java:183: warning: unreachable catch clause
Summary: Remove redundant catches in bind
Reviewed-by: alanb, michaelm, wetmore, chegar
Contributed-by: kurchi.subhra.hazra at oracle.com

! src/share/classes/java/net/DatagramSocket.java



From patrick at reini.net  Tue Jul 26 17:46:02 2011
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 26 Jul 2011 19:46:02 +0200
Subject: Found 3 NullPointerExceptions
In-Reply-To: <B2B04BD5-2489-4C47-AF16-8F18568FE4B0@oracle.com>
References: <4E29EBFC.2030202@reini.net>
	<B2B04BD5-2489-4C47-AF16-8F18568FE4B0@oracle.com>
Message-ID: <E9D5266E-90DA-4287-93A8-CAD2ECB28C61@reini.net>

Hi Lance,

Did you already had the time looking into my suposed changes?

Regards 

Patrick

Am 22.07.2011 um 23:37 schrieb Lance Andersen - Oracle <Lance.Andersen at oracle.com>:

> Hi Patrick,
> 
> I will look at your proposed change on Monday
> 
> Best
> Lance
> On Jul 22, 2011, at 5:30 PM, Patrick Reinhart wrote:
> 
>> Hi everybody,
>> 
>> I found and fixed 3 NullPointerException's  within the classes SerialBlob/SerialClob. Attached you find the corrected classes and test to cover the changes.
>> 
>> Best regards
>> 
>> Patrick
>> <webrev.zip>
> 
> <oracle_sig_logo.gif>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 


From Lance.Andersen at oracle.com  Tue Jul 26 21:29:56 2011
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 26 Jul 2011 17:29:56 -0400
Subject: Found 3 NullPointerExceptions
In-Reply-To: <E9D5266E-90DA-4287-93A8-CAD2ECB28C61@reini.net>
References: <4E29EBFC.2030202@reini.net>
	<B2B04BD5-2489-4C47-AF16-8F18568FE4B0@oracle.com>
	<E9D5266E-90DA-4287-93A8-CAD2ECB28C61@reini.net>
Message-ID: <1E7C1AB1-90EE-4397-ADBE-FCB4EEB173B9@oracle.com>

Hi Patrick,

Still on my list as been in a lot of fire drills.

best
lance
On Jul 26, 2011, at 1:46 PM, Patrick Reinhart wrote:

> Hi Lance,
> 
> Did you already had the time looking into my suposed changes?
> 
> Regards 
> 
> Patrick
> 
> Am 22.07.2011 um 23:37 schrieb Lance Andersen - Oracle <Lance.Andersen at oracle.com>:
> 
>> Hi Patrick,
>> 
>> I will look at your proposed change on Monday
>> 
>> Best
>> Lance
>> On Jul 22, 2011, at 5:30 PM, Patrick Reinhart wrote:
>> 
>>> Hi everybody,
>>> 
>>> I found and fixed 3 NullPointerException's  within the classes SerialBlob/SerialClob. Attached you find the corrected classes and test to cover the changes.
>>> 
>>> Best regards
>>> 
>>> Patrick
>>> <webrev.zip>
>> 
>> <oracle_sig_logo.gif>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From jonathan.gibbons at oracle.com  Tue Jul 26 23:39:22 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 26 Jul 2011 23:39:22 +0000
Subject: hg: jdk8/tl/jdk: 7069870: Parts of the JDK erroneously rely on
	generic array initializers with diamond
Message-ID: <20110726233937.3F37147743@hg.openjdk.java.net>

Changeset: c563e8060adf
Author:    jjg
Date:      2011-07-25 16:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c563e8060adf

7069870: Parts of the JDK erroneously rely on generic array initializers with diamond
Reviewed-by: ksrini, mcimadamore
Contributed-by: alexandre.boulgakov at oracle.com

! make/tools/src/build/tools/jarsplit/JarSplit.java
! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java



From chris.hegarty at oracle.com  Wed Jul 27 17:11:10 2011
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 27 Jul 2011 17:11:10 +0000
Subject: hg: jdk8/tl/jdk: 6670868: StackOverFlow with bad authenticated Proxy
	tunnels
Message-ID: <20110727171130.50DDF47774@hg.openjdk.java.net>

Changeset: a80562f7ea50
Author:    chegar
Date:      2011-07-27 18:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a80562f7ea50

6670868: StackOverFlow with bad authenticated Proxy tunnels
Reviewed-by: michaelm

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java



From ahughes at redhat.com  Wed Jul 27 18:04:56 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Wed, 27 Jul 2011 19:04:56 +0100
Subject: Regression in OpenJDK8 Makefiles
Message-ID: <20110727180456.GA22822@rivendell.middle-earth.co.uk>

Hi,

Can someone please tell me why:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119

reverted my earlier fix:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0

without any discussion?

The correct fix would have been to bump the boot source language/target class
versions to 7, not erase the lines altogether.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From maurizio.cimadamore at oracle.com  Wed Jul 27 18:05:32 2011
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 27 Jul 2011 18:05:32 +0000
Subject: hg: jdk8/tl/langtools: 3 new changesets
Message-ID: <20110727180538.6884A47776@hg.openjdk.java.net>

Changeset: 0b5beb9562c6
Author:    mcimadamore
Date:      2011-07-27 19:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0b5beb9562c6

7062745: Regression: difference in overload resolution when two methods are maximally specific
Summary: Fix most specific when two methods are maximally specific and only one has non-raw return type
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java
+ test/tools/javac/generics/rawOverride/7062745/T7062745neg.java
+ test/tools/javac/generics/rawOverride/7062745/T7062745neg.out
+ test/tools/javac/generics/rawOverride/7062745/T7062745pos.java

Changeset: d5f33267a06d
Author:    mcimadamore
Date:      2011-07-27 19:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d5f33267a06d

7046778: Project Coin: problem with diamond and member inner classes
Summary: Diamond inference generates spurious error messages when target type is a member inner class
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java
! test/tools/javac/generics/diamond/neg/Neg09.out

Changeset: e427c42e1a7e
Author:    mcimadamore
Date:      2011-07-27 19:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e427c42e1a7e

7057297: Project Coin: diamond erroneously accepts in array initializer expressions
Summary: Diamond in array initializer expressions should be rejected
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/CannotCreateArrayWithDiamond.java
+ test/tools/javac/generics/diamond/7057297/T7057297.java
+ test/tools/javac/generics/diamond/7057297/T7057297.out



From kelly.ohair at oracle.com  Wed Jul 27 18:58:59 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 27 Jul 2011 11:58:59 -0700
Subject: Regression in OpenJDK8 Makefiles
In-Reply-To: <20110727180456.GA22822@rivendell.middle-earth.co.uk>
References: <20110727180456.GA22822@rivendell.middle-earth.co.uk>
Message-ID: <72D8DC66-1C30-4656-B47E-F4E83D13A3AF@oracle.com>


On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote:

> Hi,
> 
> Can someone please tell me why:
> 
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119
> 
> reverted my earlier fix:
> 
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0
> 
> without any discussion?

My apologies, the webrev should have been made public.

> 
> The correct fix would have been to bump the boot source language/target class
> versions to 7, not erase the lines altogether.

Unfortunately, that did not work with jdk7 as a boot, and jdk6 won't work as a boot jdk
soon anyway. Since we will be requiring a jdk7 as the boot jdk, I did not feel it was needed
to even specify this. Anything compiled with the boot javac technically doesn't care what
the source/target is, or should, and the class files created just need to work with the boot jdk,
and should not be shipped as part of the jdk8 being built.

When I looked at the Makefiles, there was no comment as to why we even had to set the -source
or -target options when using the boot javac at all.
My conclusion was that it was unnecessary, and deleting these lines made 'jdk7 as boot' work.

If that was wrong I apologize, why does this matter?

-kto

> -- 
> Andrew :)
> 
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> Support Free Java!
> Contribute to GNU Classpath and IcedTea
> http://www.gnu.org/software/classpath
> http://icedtea.classpath.org
> PGP Key: F5862A37 (https://keys.indymedia.org/)
> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37



From kumar.x.srinivasan at oracle.com  Wed Jul 27 20:39:55 2011
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Wed, 27 Jul 2011 20:39:55 +0000
Subject: hg: jdk8/tl/langtools: 7068902: (javac) allow enabling or disabling
	of String folding
Message-ID: <20110727203957.5D3FA47781@hg.openjdk.java.net>

Changeset: 0d6d41563040
Author:    ksrini
Date:      2011-07-27 11:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d6d41563040

7068902: (javac) allow enabling or disabling of String folding
Summary: Contributed by netbeans team, modified to suit by the langtools team.
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/parser/StringFoldingTest.java



From ahughes at redhat.com  Wed Jul 27 23:28:54 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 28 Jul 2011 00:28:54 +0100
Subject: Regression in OpenJDK8 Makefiles
In-Reply-To: <72D8DC66-1C30-4656-B47E-F4E83D13A3AF@oracle.com>
References: <20110727180456.GA22822@rivendell.middle-earth.co.uk>
	<72D8DC66-1C30-4656-B47E-F4E83D13A3AF@oracle.com>
Message-ID: <20110727232853.GG22822@rivendell.middle-earth.co.uk>

On 11:58 Wed 27 Jul     , Kelly O'Hair wrote:
> 
> On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote:
> 
> > Hi,
> > 
> > Can someone please tell me why:
> > 
> > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119
> > 
> > reverted my earlier fix:
> > 
> > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0
> > 
> > without any discussion?
> 
> My apologies, the webrev should have been made public.
> 
> > 
> > The correct fix would have been to bump the boot source language/target class
> > versions to 7, not erase the lines altogether.
> 
> Unfortunately, that did not work with jdk7 as a boot

Why was this?  I don't understand why anything would fail with javac -source 7 -target 7 over
just javac.

, and jdk6 won't work as a boot jdk
> soon anyway.

Well, yes I assumed this patch was related to moving to OpenJDK7 as the minimum bootstrap JDK.

> Since we will be requiring a jdk7 as the boot jdk, I did not feel it was needed
> to even specify this. Anything compiled with the boot javac technically doesn't care what
> the source/target is, or should, and the class files created just need to work with the boot jdk,
> and should not be shipped as part of the jdk8 being built.
> 
> When I looked at the Makefiles, there was no comment as to why we even had to set the -source
> or -target options when using the boot javac at all.
> My conclusion was that it was unnecessary, and deleting these lines made 'jdk7 as boot' work.
> 
> If that was wrong I apologize, why does this matter?
> 

It means that we are depending on whatever defaults the bootstrap
javac uses rather than being explicit.  In most cases, that might not
cause a problem but I know I've run into problems with this and I
think it better to be safe than sorry, as you don't know what the
bootstrap javac is or what its default is.  If we expect the
bootstrap javac to produce java 7 class files, it should be set
explicitly:

http://blogs.oracle.com/darcy/entry/build_advice_set_source_target

I think I've hit it mostly with using ecj as the bootstrap javac, but
it couldcause an issue during development if the bootstrap javac
started producing 1.8 code by default but the VM used wasn't capable of
handling it.  Unlikely maybe, but I think it's better to have this set
explicitly and just avoid such issues altogether.

> -kto
> 
> > -- 
> > Andrew :)
> > 
> > Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> > 
> > Support Free Java!
> > Contribute to GNU Classpath and IcedTea
> > http://www.gnu.org/software/classpath
> > http://icedtea.classpath.org
> > PGP Key: F5862A37 (https://keys.indymedia.org/)
> > Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From kelly.ohair at oracle.com  Thu Jul 28 00:12:01 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 27 Jul 2011 17:12:01 -0700
Subject: Regression in OpenJDK8 Makefiles
In-Reply-To: <20110727232853.GG22822@rivendell.middle-earth.co.uk>
References: <20110727180456.GA22822@rivendell.middle-earth.co.uk>
	<72D8DC66-1C30-4656-B47E-F4E83D13A3AF@oracle.com>
	<20110727232853.GG22822@rivendell.middle-earth.co.uk>
Message-ID: <07E4D248-8D06-417F-A439-896ABC42B8CA@oracle.com>


On Jul 27, 2011, at 4:28 PM, Dr Andrew John Hughes wrote:

> On 11:58 Wed 27 Jul     , Kelly O'Hair wrote:
>> 
>> On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote:
>> 
>>> Hi,
>>> 
>>> Can someone please tell me why:
>>> 
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119
>>> 
>>> reverted my earlier fix:
>>> 
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0
>>> 
>>> without any discussion?
>> 
>> My apologies, the webrev should have been made public.
>> 
>>> 
>>> The correct fix would have been to bump the boot source language/target class
>>> versions to 7, not erase the lines altogether.
>> 
>> Unfortunately, that did not work with jdk7 as a boot
> 
> Why was this?  I don't understand why anything would fail with javac -source 7 -target 7 over
> just javac.

Basically, we never really know what the BOOT javac will accept.
I assume that if we use the default for javac, that the BOOT java can run them.

> 
> , and jdk6 won't work as a boot jdk
>> soon anyway.
> 
> Well, yes I assumed this patch was related to moving to OpenJDK7 as the minimum bootstrap JDK.
> 
>> Since we will be requiring a jdk7 as the boot jdk, I did not feel it was needed
>> to even specify this. Anything compiled with the boot javac technically doesn't care what
>> the source/target is, or should, and the class files created just need to work with the boot jdk,
>> and should not be shipped as part of the jdk8 being built.
>> 
>> When I looked at the Makefiles, there was no comment as to why we even had to set the -source
>> or -target options when using the boot javac at all.
>> My conclusion was that it was unnecessary, and deleting these lines made 'jdk7 as boot' work.
>> 
>> If that was wrong I apologize, why does this matter?
>> 
> 
> It means that we are depending on whatever defaults the bootstrap
> javac uses rather than being explicit.  In most cases, that might not
> cause a problem but I know I've run into problems with this and I
> think it better to be safe than sorry, as you don't know what the
> bootstrap javac is or what its default is.  If we expect the
> bootstrap javac to produce java 7 class files, it should be set
> explicitly:
> 
> http://blogs.oracle.com/darcy/entry/build_advice_set_source_target
> 
> I think I've hit it mostly with using ecj as the bootstrap javac, but
> it couldcause an issue during development if the bootstrap javac
> started producing 1.8 code by default but the VM used wasn't capable of
> handling it.  Unlikely maybe, but I think it's better to have this set
> explicitly and just avoid such issues altogether.

IF these class files were becoming part of the final jdk image, then I would agree,
but they aren't. I see no reason to be explicit here, or to even specify it.

I am assuming that the BOOT javac comes from a BOOT jdk image, and that it
has a java command in that BOOT jdk, that can run the default classes created by that
BOOT javac.

So what is the BOOT javac used for?

As far as I know, it is used to compile the bootstrap langtools javac.jar and it is used to
build the jdk/make/tools jar files, both of which we run during the build but we do not
deliver into the final jdk image.
Both are run with the BOOT jdk java command.

The sources for langtools and these jdk/make/tools might be jdk5 or jdk6 or jdk7
sources, but that's an issue for those sources to deal with, in terms of checking that
the BOOT jdk is 'good enough' to compile them, and the BOOT java is good enough to run them.
If the building of these particular sources NEEDS to set the source/target, again, that's
something for that particular part of the build to specify.

If the BOOT jdk was jdk8, I would want these sources built for jdk8 and run with a jdk8,
it should just work.

-kto


> 
>> -kto
>> 
>>> -- 
>>> Andrew :)
>>> 
>>> Free Java Software Engineer
>>> Red Hat, Inc. (http://www.redhat.com)
>>> 
>>> Support Free Java!
>>> Contribute to GNU Classpath and IcedTea
>>> http://www.gnu.org/software/classpath
>>> http://icedtea.classpath.org
>>> PGP Key: F5862A37 (https://keys.indymedia.org/)
>>> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37
>> 
> 
> -- 
> Andrew :)
> 
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> Support Free Java!
> Contribute to GNU Classpath and IcedTea
> http://www.gnu.org/software/classpath
> http://icedtea.classpath.org
> PGP Key: F5862A37 (https://keys.indymedia.org/)
> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37



From ahughes at redhat.com  Thu Jul 28 02:06:22 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 28 Jul 2011 03:06:22 +0100
Subject: Regression in OpenJDK8 Makefiles
In-Reply-To: <07E4D248-8D06-417F-A439-896ABC42B8CA@oracle.com>
References: <20110727180456.GA22822@rivendell.middle-earth.co.uk>
	<72D8DC66-1C30-4656-B47E-F4E83D13A3AF@oracle.com>
	<20110727232853.GG22822@rivendell.middle-earth.co.uk>
	<07E4D248-8D06-417F-A439-896ABC42B8CA@oracle.com>
Message-ID: <20110728020622.GM22822@rivendell.middle-earth.co.uk>

On 17:12 Wed 27 Jul     , Kelly O'Hair wrote:
> 
> On Jul 27, 2011, at 4:28 PM, Dr Andrew John Hughes wrote:
> 
> > On 11:58 Wed 27 Jul     , Kelly O'Hair wrote:
> >> 
> >> On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote:
> >> 
> >>> Hi,
> >>> 
> >>> Can someone please tell me why:
> >>> 
> >>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119
> >>> 
> >>> reverted my earlier fix:
> >>> 
> >>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0
> >>> 
> >>> without any discussion?
> >> 
> >> My apologies, the webrev should have been made public.
> >> 
> >>> 
> >>> The correct fix would have been to bump the boot source language/target class
> >>> versions to 7, not erase the lines altogether.
> >> 
> >> Unfortunately, that did not work with jdk7 as a boot
> > 
> > Why was this?  I don't understand why anything would fail with javac -source 7 -target 7 over
> > just javac.
> 
> Basically, we never really know what the BOOT javac will accept.

I was referring more to the actual build failure when you tried this.

If we're requiring 7 support as a minimum for bootstrapping, surely we know it will support this.

> I assume that if we use the default for javac, that the BOOT java can run them.

This is the assumption that has not always held in my experience.

Being explicit means that a newer javac can be used with an older VM.

snip...

> 
> If the BOOT jdk was jdk8, I would want these sources built for jdk8 and run with a jdk8,
> it should just work.
> 

This seems to contradict what you're saying about the files ending up in the image.  Why
does it matter if they use the minimum supported version?  Presumably an OpenJDK8 VM will
be able to run 1.7 class files.  But an OpenJDK7 VM wouldn't be able to run 1.8 class files
if these are the default produced by the bootstrap javac.

> -kto
> 
> 
> > 
> >> -kto
> >> 
> >>> -- 
> >>> Andrew :)
> >>> 
> >>> Free Java Software Engineer
> >>> Red Hat, Inc. (http://www.redhat.com)
> >>> 
> >>> Support Free Java!
> >>> Contribute to GNU Classpath and IcedTea
> >>> http://www.gnu.org/software/classpath
> >>> http://icedtea.classpath.org
> >>> PGP Key: F5862A37 (https://keys.indymedia.org/)
> >>> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37
> >> 
> > 
> > -- 
> > Andrew :)
> > 
> > Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> > 
> > Support Free Java!
> > Contribute to GNU Classpath and IcedTea
> > http://www.gnu.org/software/classpath
> > http://icedtea.classpath.org
> > PGP Key: F5862A37 (https://keys.indymedia.org/)
> > Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From dl at cs.oswego.edu  Thu Jul 28 20:40:29 2011
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 28 Jul 2011 16:40:29 -0400
Subject: ArrayList.subList
Message-ID: <4E31C93D.9010700@cs.oswego.edu>


While puzzling over why one of the demo videos on ForkJoin
out there required surprisingly high sequential thresholds, I
noticed that ArrayList.subList creates lists with per-access
overhead proportional to the sublist depth. Which is
not at all conducive to recursive use. Does anyone
know any reason why this was done? (No one who I
thought would know the answer does.) It is easy to keep
the overhead flat (we do so in CopyOnWriteArrayList and
the new jsr166e.extra ReadMostlyVector.)
If no one knows a reason not to, I'll put together a patch.
(I have a vague deja vu feeling that I might have done this
once before years ago...)

-Doug







From jonathan.gibbons at oracle.com  Thu Jul 28 21:44:16 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 28 Jul 2011 21:44:16 +0000
Subject: hg: jdk8/tl/jdk: 7068616: NIO libraries do not build with javac
	-Xlint:all, -deprecation -Werror
Message-ID: <20110728214426.116BF477BD@hg.openjdk.java.net>

Changeset: 7525866a4046
Author:    jjg
Date:      2011-07-28 13:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7525866a4046

7068616: NIO libraries do not build with javac -Xlint:all,-deprecation -Werror
Reviewed-by: alanb, chegar
Contributed-by: alexandre.boulgakov at oracle.com

! make/com/sun/nio/Makefile
! make/com/sun/nio/sctp/Makefile
! make/java/nio/Makefile
! make/java/sun_nio/Makefile
! make/sun/nio/Makefile
! make/sun/nio/cs/Makefile
! src/share/classes/java/nio/X-Buffer.java.template
! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
! src/share/classes/java/nio/channels/FileChannel.java
! src/share/classes/java/nio/charset/Charset.java
! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java
! src/share/classes/sun/nio/ch/Reflect.java
! src/share/classes/sun/nio/ch/SelectorImpl.java
! src/share/classes/sun/nio/ch/Util.java
! src/share/classes/sun/nio/cs/FastCharsetProvider.java
! src/share/classes/sun/nio/cs/StreamDecoder.java
! src/share/classes/sun/nio/cs/ThreadLocalCoders.java
! src/share/classes/sun/nio/fs/Util.java
! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java
! src/solaris/classes/sun/nio/ch/SctpNet.java
! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java
! src/windows/classes/sun/nio/ch/PendingIoCache.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java



From mike.duigou at oracle.com  Thu Jul 28 22:53:05 2011
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 28 Jul 2011 15:53:05 -0700
Subject: ArrayList.subList
In-Reply-To: <4E31C93D.9010700@cs.oswego.edu>
References: <4E31C93D.9010700@cs.oswego.edu>
Message-ID: <A1A4F9E0-D908-4E70-B5D2-526111C16157@oracle.com>

I had a similar issue with Set recently. The problem is that structural changes in sub-sub-lists aren't correctly reflected in the sub-list parents if the sub-sub-lists are disconnected from the parent. The chain back to to the parent through all intermediate sub-lists is used to update list bounds. Seems weird to me but that's nonetheless how the original implementors made it work.

Mike

On Jul 28 2011, at 13:40 , Doug Lea wrote:

> 
> While puzzling over why one of the demo videos on ForkJoin
> out there required surprisingly high sequential thresholds, I
> noticed that ArrayList.subList creates lists with per-access
> overhead proportional to the sublist depth. Which is
> not at all conducive to recursive use. Does anyone
> know any reason why this was done? (No one who I
> thought would know the answer does.) It is easy to keep
> the overhead flat (we do so in CopyOnWriteArrayList and
> the new jsr166e.extra ReadMostlyVector.)
> If no one knows a reason not to, I'll put together a patch.
> (I have a vague deja vu feeling that I might have done this
> once before years ago...)
> 
> -Doug
> 
> 
> 
> 
> 



From dl at cs.oswego.edu  Thu Jul 28 23:20:36 2011
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 28 Jul 2011 19:20:36 -0400
Subject: ArrayList.subList
In-Reply-To: <A1A4F9E0-D908-4E70-B5D2-526111C16157@oracle.com>
References: <4E31C93D.9010700@cs.oswego.edu>
	<A1A4F9E0-D908-4E70-B5D2-526111C16157@oracle.com>
Message-ID: <4E31EEC4.7070309@cs.oswego.edu>

On 07/28/11 18:53, Mike Duigou wrote:
> I had a similar issue with Set recently. The problem is that structural
> changes in sub-sub-lists aren't correctly reflected in the sub-list parents
> if the sub-sub-lists are disconnected from the parent. The chain back to to
> the parent through all intermediate sub-lists is used to update list bounds.
> Seems weird to me but that's nonetheless how the original implementors made
> it work.

Thanks.  I hadn't noticed that the parenthesized "i.e., this list"
in the List specs 
(http://download.oracle.com/javase/7/docs/api/java/util/List.html#subList%28int,%20int%29 
-- pasted below)
overly constrains the interpretation of "backing list",
which would otherwise naturally refer to the ArrayList. This
would be challenging to fix in ArrayList while retaining
compatibility, even though it is sensibly ignored in
other List implementations.


The semantics of the list returned by this method become undefined if the
backing list (i.e., this list) is structurally modified in any way other than
via the returned list. (Structural modifications are those that change the size
of this list, or otherwise perturb it in such a fashion that iterations in
progress may yield incorrect results.)


> On Jul 28 2011, at 13:40 , Doug Lea wrote:
>
>>
>> While puzzling over why one of the demo videos on ForkJoin out there
>> required surprisingly high sequential thresholds, I noticed that
>> ArrayList.subList creates lists with per-access overhead proportional to
>> the sublist depth. Which is not at all conducive to recursive use. Does
>> anyone know any reason why this was done? (No one who I thought would know
>> the answer does.) It is easy to keep the overhead flat (we do so in
>> CopyOnWriteArrayList and the new jsr166e.extra ReadMostlyVector.) If no one
>> knows a reason not to, I'll put together a patch. (I have a vague deja vu
>> feeling that I might have done this once before years ago...)
>>
>> -Doug
>>
>>
>>
>>
>>
>
>



From ahughes at redhat.com  Thu Jul 28 23:43:02 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Fri, 29 Jul 2011 00:43:02 +0100
Subject: hg: jdk8/tl/jdk: 7068616: NIO libraries do not build with javac
	-Xlint:all, -deprecation -Werror
In-Reply-To: <20110728214426.116BF477BD@hg.openjdk.java.net>
References: <20110728214426.116BF477BD@hg.openjdk.java.net>
Message-ID: <20110728234302.GA22822@rivendell.middle-earth.co.uk>

On 21:44 Thu 28 Jul     , jonathan.gibbons at oracle.com wrote:
> Changeset: 7525866a4046
> Author:    jjg
> Date:      2011-07-28 13:34 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7525866a4046
> 
> 7068616: NIO libraries do not build with javac -Xlint:all,-deprecation -Werror
> Reviewed-by: alanb, chegar
> Contributed-by: alexandre.boulgakov at oracle.com
> 
> ! make/com/sun/nio/Makefile
> ! make/com/sun/nio/sctp/Makefile
> ! make/java/nio/Makefile
> ! make/java/sun_nio/Makefile
> ! make/sun/nio/Makefile
> ! make/sun/nio/cs/Makefile
> ! src/share/classes/java/nio/X-Buffer.java.template
> ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
> ! src/share/classes/java/nio/channels/FileChannel.java
> ! src/share/classes/java/nio/charset/Charset.java
> ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java
> ! src/share/classes/sun/nio/ch/Reflect.java
> ! src/share/classes/sun/nio/ch/SelectorImpl.java
> ! src/share/classes/sun/nio/ch/Util.java
> ! src/share/classes/sun/nio/cs/FastCharsetProvider.java
> ! src/share/classes/sun/nio/cs/StreamDecoder.java
> ! src/share/classes/sun/nio/cs/ThreadLocalCoders.java
> ! src/share/classes/sun/nio/fs/Util.java
> ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java
> ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java
> ! src/solaris/classes/sun/nio/ch/SctpNet.java
> ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java
> ! src/windows/classes/sun/nio/ch/PendingIoCache.java
> ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
> ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
> 

Is there some (very welcome) focus on fixing these errors at the moment?
If so, is this across this board or just the jdk tree (or even parts of the jdk
tree)?  

I fixed a few a while back during the OpenJDK7 cycle, though only
enough to get it to build with -Werror enabled (and not -Xlint).
Sadly, it's still such a slow process to get patches in that I haven't
done more on this.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From alexandre.boulgakov at oracle.com  Thu Jul 28 23:47:06 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Thu, 28 Jul 2011 16:47:06 -0700
Subject: hg: jdk8/tl/jdk: 7068616: NIO libraries do not build with javac
	-Xlint:all, -deprecation -Werror
In-Reply-To: <20110728234302.GA22822@rivendell.middle-earth.co.uk>
References: <20110728214426.116BF477BD@hg.openjdk.java.net>
	<20110728234302.GA22822@rivendell.middle-earth.co.uk>
Message-ID: <4E31F4FA.4070305@oracle.com>


On 7/28/2011 4:43 PM, Dr Andrew John Hughes wrote:
> On 21:44 Thu 28 Jul     , jonathan.gibbons at oracle.com wrote:
>> Changeset: 7525866a4046
>> Author:    jjg
>> Date:      2011-07-28 13:34 -0700
>> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7525866a4046
>>
>> 7068616: NIO libraries do not build with javac -Xlint:all,-deprecation -Werror
>> Reviewed-by: alanb, chegar
>> Contributed-by: alexandre.boulgakov at oracle.com
>>
>> ! make/com/sun/nio/Makefile
>> ! make/com/sun/nio/sctp/Makefile
>> ! make/java/nio/Makefile
>> ! make/java/sun_nio/Makefile
>> ! make/sun/nio/Makefile
>> ! make/sun/nio/cs/Makefile
>> ! src/share/classes/java/nio/X-Buffer.java.template
>> ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
>> ! src/share/classes/java/nio/channels/FileChannel.java
>> ! src/share/classes/java/nio/charset/Charset.java
>> ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java
>> ! src/share/classes/sun/nio/ch/Reflect.java
>> ! src/share/classes/sun/nio/ch/SelectorImpl.java
>> ! src/share/classes/sun/nio/ch/Util.java
>> ! src/share/classes/sun/nio/cs/FastCharsetProvider.java
>> ! src/share/classes/sun/nio/cs/StreamDecoder.java
>> ! src/share/classes/sun/nio/cs/ThreadLocalCoders.java
>> ! src/share/classes/sun/nio/fs/Util.java
>> ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java
>> ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java
>> ! src/solaris/classes/sun/nio/ch/SctpNet.java
>> ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java
>> ! src/windows/classes/sun/nio/ch/PendingIoCache.java
>> ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
>> ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
>>
> Is there some (very welcome) focus on fixing these errors at the moment?
> If so, is this across this board or just the jdk tree (or even parts of the jdk
> tree)?
I'm working on removing javac warnings throughout the security, 
networking, and core libraries for a summer internship.

-Sasha
>
> I fixed a few a while back during the OpenJDK7 cycle, though only
> enough to get it to build with -Werror enabled (and not -Xlint).
> Sadly, it's still such a slow process to get patches in that I haven't
> done more on this.


From ahughes at redhat.com  Fri Jul 29 00:03:14 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Fri, 29 Jul 2011 01:03:14 +0100
Subject: hg: jdk8/tl/jdk: 7068616: NIO libraries do not build with javac
	-Xlint:all, -deprecation -Werror
In-Reply-To: <4E31F4FA.4070305@oracle.com>
References: <20110728214426.116BF477BD@hg.openjdk.java.net>
	<20110728234302.GA22822@rivendell.middle-earth.co.uk>
	<4E31F4FA.4070305@oracle.com>
Message-ID: <20110729000314.GB22822@rivendell.middle-earth.co.uk>

On 16:47 Thu 28 Jul     , Alexandre Boulgakov wrote:
> 
> On 7/28/2011 4:43 PM, Dr Andrew John Hughes wrote:
> > On 21:44 Thu 28 Jul     , jonathan.gibbons at oracle.com wrote:
> >> Changeset: 7525866a4046
> >> Author:    jjg
> >> Date:      2011-07-28 13:34 -0700
> >> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7525866a4046
> >>
> >> 7068616: NIO libraries do not build with javac -Xlint:all,-deprecation -Werror
> >> Reviewed-by: alanb, chegar
> >> Contributed-by: alexandre.boulgakov at oracle.com
> >>
> >> ! make/com/sun/nio/Makefile
> >> ! make/com/sun/nio/sctp/Makefile
> >> ! make/java/nio/Makefile
> >> ! make/java/sun_nio/Makefile
> >> ! make/sun/nio/Makefile
> >> ! make/sun/nio/cs/Makefile
> >> ! src/share/classes/java/nio/X-Buffer.java.template
> >> ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
> >> ! src/share/classes/java/nio/channels/FileChannel.java
> >> ! src/share/classes/java/nio/charset/Charset.java
> >> ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java
> >> ! src/share/classes/sun/nio/ch/Reflect.java
> >> ! src/share/classes/sun/nio/ch/SelectorImpl.java
> >> ! src/share/classes/sun/nio/ch/Util.java
> >> ! src/share/classes/sun/nio/cs/FastCharsetProvider.java
> >> ! src/share/classes/sun/nio/cs/StreamDecoder.java
> >> ! src/share/classes/sun/nio/cs/ThreadLocalCoders.java
> >> ! src/share/classes/sun/nio/fs/Util.java
> >> ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java
> >> ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java
> >> ! src/solaris/classes/sun/nio/ch/SctpNet.java
> >> ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java
> >> ! src/windows/classes/sun/nio/ch/PendingIoCache.java
> >> ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
> >> ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
> >>
> > Is there some (very welcome) focus on fixing these errors at the moment?
> > If so, is this across this board or just the jdk tree (or even parts of the jdk
> > tree)?
> I'm working on removing javac warnings throughout the security, 
> networking, and core libraries for a summer internship.
> 

Oh nice one!  Very welcome work.

But I guess that's not even the whole jdk tree, right?  And definitely not corba?

> -Sasha
> >
> > I fixed a few a while back during the OpenJDK7 cycle, though only
> > enough to get it to build with -Werror enabled (and not -Xlint).
> > Sadly, it's still such a slow process to get patches in that I haven't
> > done more on this.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From jonathan.gibbons at oracle.com  Fri Jul 29 00:46:38 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 28 Jul 2011 17:46:38 -0700
Subject: hg: jdk8/tl/jdk: 7068616: NIO libraries do not build with javac
	-Xlint:all, -deprecation -Werror
In-Reply-To: <20110729000314.GB22822@rivendell.middle-earth.co.uk>
References: <20110728214426.116BF477BD@hg.openjdk.java.net>
	<20110728234302.GA22822@rivendell.middle-earth.co.uk>
	<4E31F4FA.4070305@oracle.com>
	<20110729000314.GB22822@rivendell.middle-earth.co.uk>
Message-ID: <4E3202EE.3020800@oracle.com>

On 07/28/2011 05:03 PM, Dr Andrew John Hughes wrote:
> On 16:47 Thu 28 Jul     , Alexandre Boulgakov wrote:
>> I'm working on removing javac warnings throughout the security,
>> networking, and core libraries for a summer internship.
>>
> Oh nice one!  Very welcome work.
>
> But I guess that's not even the whole jdk tree, right?  And definitely not corba?
>
>> -Sasha


Note that Sasha has also already done langtools, jdk build tools and 
pack200. Go, Sasha!

-- Jon


(jdk8/tl)

changeset:   348:0b615980879e
user:        jjg
date:        Thu Jun 30 16:51:35 2011 -0700
description:
7061195: Clean up makefiles for JDK 8
Reviewed-by: ohair, jjg
Contributed-by: alexandre.boulgakov at oracle.com




(jdk8/tl/langtools)

changeset:   1015:18002d039806
user:        jjg
date:        Thu Jun 23 11:49:27 2011 -0700
description:
7058174: Reduce langtools build warnings
Reviewed-by: jjg
Contributed-by: alexandre.boulgakov at oracle.com




(jdk8/tl/jdk)

changeset:   4409:7525866a4046
tag:         tip
user:        jjg
date:        Thu Jul 28 13:34:31 2011 -0700
description:
7068616: NIO libraries do not build with javac -Xlint:all,-deprecation 
-Werror
Reviewed-by: alanb, chegar
Contributed-by: alexandre.boulgakov at oracle.com


changeset:   4407:c563e8060adf
user:        jjg
date:        Mon Jul 25 16:20:39 2011 -0700
description:
7069870: Parts of the JDK erroneously rely on generic array initializers 
with diamond
Reviewed-by: ksrini, mcimadamore
Contributed-by: alexandre.boulgakov at oracle.com


changeset:   4401:9505edecc8b5
user:        jjg
date:        Wed Jul 20 12:19:41 2011 -0700
description:
7068617: Core libraries don't build with javac -Xlint:all -Werror
Reviewed-by: darcy
Contributed-by: alexandre.boulgakov at oracle.com


changeset:   4379:63be90976177
user:        ksrini
date:        Fri Jul 08 10:25:57 2011 -0700
description:
7060849: Eliminate pack200 build warnings
Reviewed-by: ksrini, jjg
Contributed-by: alexandre.boulgakov at oracle.com


changeset:   4374:74328e59a4bf
user:        jjg
date:        Thu Jun 30 17:59:13 2011 -0700
description:
7058708: Eliminate JDK build tools build warnings
Reviewed-by: ohair, jjg
Contributed-by: alexandre.boulgakov at oracle.com


changeset:   4373:cf4edfcd7119
user:        jjg
date:        Thu Jun 30 16:50:34 2011 -0700
description:
7061195: Clean up makefiles for JDK 8
Reviewed-by: ohair, jjg
Contributed-by: alexandre.boulgakov at oracle.com


changeset:   4372:e4c936c28960
user:        jjg
date:        Thu Jun 30 16:48:44 2011 -0700
description:
7061190: Update boot JDK version for JDK 8
Reviewed-by: ohair, jjg
Contributed-by: alexandre.boulgakov at oracle.com





From xuelei.fan at oracle.com  Fri Jul 29 09:53:13 2011
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Fri, 29 Jul 2011 09:53:13 +0000
Subject: hg: jdk8/tl/jdk: 7068662: Reserve and restore the default locale
Message-ID: <20110729095335.A6C9A477DD@hg.openjdk.java.net>

Changeset: cea7c749f805
Author:    xuelei
Date:      2011-07-29 02:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cea7c749f805

7068662: Reserve and restore the default locale
Reviewed-by: alanb, weijun

! test/com/sun/org/apache/xml/internal/security/exceptions/LocaleTest.java
! test/java/beans/XMLDecoder/Test6341798.java
! test/java/io/pathNames/win32/bug6344646.java
! test/java/net/CookieHandler/B6791927.java
! test/java/net/URLConnection/SetIfModifiedSince.java
! test/java/util/Locale/LocaleCategory.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java
! test/java/util/ResourceBundle/Bug6190861.java
! test/java/util/ResourceBundle/Control/Bug6530694.java
! test/java/util/ResourceBundle/Control/StressTest.java
! test/java/util/ResourceBundle/Test4314141.java
! test/java/util/ResourceBundle/Test4318520.java
! test/java/util/jar/JarFile/TurkCert.java
! test/javax/crypto/Cipher/Turkish.java
! test/javax/swing/JColorChooser/Test6524757.java
! test/sun/security/tools/keytool/KeyToolTest.java
! test/sun/text/resources/Collator/Bug4248694.java
! test/sun/text/resources/Collator/Bug4804273.java
! test/sun/text/resources/Collator/Bug4848897.java
! test/sun/text/resources/Format/Bug4651568.java
! test/sun/util/resources/Locale/Bug4965260.java
! test/sun/util/resources/TimeZone/Bug4640234.java



From dl at cs.oswego.edu  Fri Jul 29 10:34:07 2011
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 29 Jul 2011 06:34:07 -0400
Subject: ArrayList.subList
In-Reply-To: <4E31EEC4.7070309@cs.oswego.edu>
References: <4E31C93D.9010700@cs.oswego.edu>	<A1A4F9E0-D908-4E70-B5D2-526111C16157@oracle.com>
	<4E31EEC4.7070309@cs.oswego.edu>
Message-ID: <4E328C9F.3050008@cs.oswego.edu>

On 07/28/11 19:20, Doug Lea wrote:

> Thanks. I hadn't noticed that the parenthesized "i.e., this list"
> in the List specs
> (http://download.oracle.com/javase/7/docs/api/java/util/List.html#subList%28int,%20int%29
> -- pasted below)
> overly constrains the interpretation of "backing list",
> which would otherwise naturally refer to the ArrayList. This
> would be challenging to fix in ArrayList while retaining
> compatibility, even though it is sensibly ignored in
> other List implementations.

As a bandaid, a faster but still compatible path for
simple get/set operations on ArrayList.subList could be
put in at the expense of adding a a few extra fields.
This would remove the main problem here. Mike: do you
want to try this? If not, I'll send something.

(BTW, similar wording is similarly ignored in  JDK
{Sorted,Navigable}Map.subMap implementations; i.e.,
TreeMap and ConcurrentSkipListMap).


-Doug




From alexandre.boulgakov at oracle.com  Fri Jul 29 23:32:55 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Fri, 29 Jul 2011 16:32:55 -0700
Subject: Code review request: 7072523 java.math should be built with javac
	-Xlint:all -Werror
Message-ID: <4E334327.9060400@oracle.com>

Hello Joe,

Could you review the attached two-line update to ensure that no javac 
warnings are introduced into java.math?
Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072523

Thanks,
Sasha
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 7072523.patch
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20110729/54468465/7072523.patch>

From alexandre.boulgakov at oracle.com  Fri Jul 29 23:33:15 2011
From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov)
Date: Fri, 29 Jul 2011 16:33:15 -0700
Subject: Code review request: 7072353 JNDI libraries do not build with javac
	-Xlint:all -Werror
Message-ID: <4E33433B.8000900@oracle.com>

Hello,

Please review these JNDI changes.
Bug detail: 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072353<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068616>
webrev: http://cr.openjdk.java.net/~mduigou/7072353/0/webrev/

Thanks,
Sasha


From joe.darcy at oracle.com  Fri Jul 29 23:43:04 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 29 Jul 2011 16:43:04 -0700
Subject: Code review request: 7072523 java.math should be built with javac
	-Xlint:all -Werror
In-Reply-To: <4E334327.9060400@oracle.com>
References: <4E334327.9060400@oracle.com>
Message-ID: <4E334588.1090509@oracle.com>

On 7/29/2011 4:32 PM, Alexandre Boulgakov wrote:
> Hello Joe,
>
> Could you review the attached two-line update to ensure that no javac 
> warnings are introduced into java.math?
> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072523
>
> Thanks,
> Sasha

Approved.

Thanks,

-Joe


From jonathan.gibbons at oracle.com  Sat Jul 30 00:08:15 2011
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 30 Jul 2011 00:08:15 +0000
Subject: hg: jdk8/tl/jdk: 7072523: java.math should be built with javac
	-Xlint:all -Werror
Message-ID: <20110730000824.9407647800@hg.openjdk.java.net>

Changeset: 4030297803eb
Author:    jjg
Date:      2011-07-29 16:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4030297803eb

7072523: java.math should be built with javac -Xlint:all -Werror
Reviewed-by: darcy
Contributed-by: alexandre.boulgakov at oracle.com

! make/java/math/Makefile



From dl at cs.oswego.edu  Sat Jul 30 17:23:30 2011
From: dl at cs.oswego.edu (Doug Lea)
Date: Sat, 30 Jul 2011 13:23:30 -0400
Subject: ArrayList.subList
In-Reply-To: <4E328C9F.3050008@cs.oswego.edu>
References: <4E31C93D.9010700@cs.oswego.edu>	<A1A4F9E0-D908-4E70-B5D2-526111C16157@oracle.com>	<4E31EEC4.7070309@cs.oswego.edu>
	<4E328C9F.3050008@cs.oswego.edu>
Message-ID: <4E343E12.6040601@cs.oswego.edu>

On 07/29/11 06:34, Doug Lea wrote:
> As a bandaid, a faster but still compatible path for
> simple get/set operations on ArrayList.subList could be
> put in at the expense of adding a a few extra fields.

I should have checked before posting -- exactly
this bandaid already exists in current version,
disguised by using  "ArrayList.this" as one of these fields.
As long as people restrict sublist accesses to get and set,
they are not hitting penalty proportional to depth.
I don't know how to do any better while retaining
compatibility.

-Doug